Road Map for an Application/Software Security Architect (Part 4)

Planning your application’s use of the digital identity is not an after-thought of system architecture. At the least, it might offer the occasional lack of reliable and conflicting information. At the worst, it provides little, if no protection, at all. And like the proverbial little dutch boy, you will be putting fingers in the holes of the dike, attempting to shore up an weak infrastructure with fixes and excuses.

In my previous post, four classifications of possible vulnerabilities were given. The top one, in my view, is the use of Digital Identity. Application developers are prone to view this as as just another operational infrastructure component that will, by some miracle, provide the reliable credentials for authentication. Authorization is something that either is part of authentication or just a couple of conditions in the lines of code. The problem is more than just the lack of governance of how an application does authentication and (required) authorization; the issue is that the data is not properly planned to support proper authentication and authorization for an application to leverage properly.

Digital Identity:

At a recent security event I attended, a colleague was lamenting how his “LDAP” servers were not being synchronized correctly. Application developers were finding it difficult to verify credentials and had little capability to extend that to more than a very high level authorization process. While in the end he may have an identity management problem, the basic issue is that of poor planning and no strategy for a data model of the digital identity. The digital identity was not serving the application development properly.

Unless you have the luxury of a “green field” when planning a digital identity infrastructure, you need to understand the framework within which you will need to operate. Having a single store for all of the end users with all of the necessary information for all of the applications will not exist. So, to make sense out of it, understand, and inventory, the relationship of the various data stores to the applications, both technically and politically. At a minimum, this would clearly define the purpose and function of the data stores and any LDAP servers, such as Active Directory.

Understanding where the digital information data is only part of the problem. The more difficult problem is understanding how users are identified in each data store and LDAP server. Part of my colleagues problem was that “Jane Jones” was listed as userID of JJones01 in the Active Directory, JJones02 in LDAP, and JaneJones in the key field of UserIdent in the finance database. Of course, the synchronization would not work! If the digital identity for “Jane Jones” is broken, it is not the application designer’s problem to fix it, but an infrastructure issue to mend the relationships so that the infrastructure can be leveraged in a cost efficient and expedient manner. At a minimum, establish relationships between the stores to enable its intended function, and “rules of engagement” including the expectation that certain data is located in specific (and sometimes uniquely) data stores.

Recognizing that there is a difference between the function of authentication and authorization is necessary in maintaining a digital identity across multiple stores. The fewer number of points where authentication is done, the better is the control of the initial access. Authorization can, and most likely, will be spread across stores, but that is fine as long as you have the relationships clearly defined. But authorization comes in two classes: (1) the coarse-grained variety, which is easiest at the point of access control of authentication, and (2) the fine-grained variety, which is complicated by the business logic of the application. Logically, all of this information is part of the “data model” of the digital identity; physically (and politically), it may reside in separate data bases “owned” by the application.

And, lastly, having no governance as to how applications can use (when, why, and how) the various stores of the digital identity will cause chaos. If the policies are in place, and standards are re-enforced then the security framework provides the governance. Enforcement at the various points of the SDLC during security and risk assessment is crucial, both to continue to educate developers and designers, but also to maintain the integrity of the information at the various stores. Ad hoc modification of the data model for digital identity, including locating authorization data in multiple data stores can and does have long term consequences on the viability of the digital identity.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect