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

So, the application designer has disclosed that the solution for the web services being designed will involve the (1) need to authenticate; (2) need to determine levels of authorization; and (3) [by the way] need to have some personalized data be carried forward to the application. If you, as a the security architect involved in the security assessment process, are smart, you would have a security framework to meet these requirements. And if you are “lucky” the application designer will have aligned the requirements to the security framework. But, the reality is that even with an architecture supported by standards and guideline, convincing the application developers to follow it is another story.

Rather than take on the “creative conflict”, a discussion should be a convincing proposal that the information is in place to make it easier for the application developer to obtain the information through the use of the “architecture” than creating yet-another database. The proper manner is to bring value to the organization and enable the development process to be easier with the architecture. The key to bringing value is to have the information in the “best” place (here!), at the “best” time (now!) and with the “best” information (right!).

The application developer will be interested in two types of data to drive the application: the identity information and the application’s database. Identity Management as a service deals with the former (discussion of the security requirements and implications of the latter are to be discussed in future posts). Although there are multiple products out in the market that are label to perform identity management, it is more than just technology (the tool), it also involves people and processes. Information about a digital identity that is combed from multiple data sources and stored in other information stores is a result of a set of operational procedures (people, process, and technology) that manage the information flow.

Security for Identity Management involves a lot more than just Confidentiality, Integrity, Availability, so I prefer to use the Parkerian Hexad (elements of information security proposed by Donn B. Parker in his book “Fighting Computer Crime, A New Framework for Protecting Information,” [John Wiley & Sons, 1998].) to proposed how to make “here!”, “now!” and “right!” the feasible end result (goal) of a good identity management procedure. The core elements (six) lay out the parameters that, for the developers, make the choice of the architect’s vision of an identity information store of “digital identity” preferable to that of creating yet-another identity store through yet-another registration process:

1.  Confidentiality – not only will the process protect who has access to the data during the “managing” of the identity data from the data source of record into the identity information store (such as an “LDAP directory) but that the process that created data into the data source of record was also protected.

2.  Possession or control – the process by which the information is delivered from the data source of record to the identity information store is secured, similar to a “chain of custody,” is well understood and controlled.

3.  Integrity – the information itself is not compromised, being consistent with its intended state asserts the validity of the data.

4. Authenticity – the claim that the data is coming from an reliable source is the assertion that the information from the data source of record is valid and truthful is important to document so that the information may not be mis-used under false assumption. The ways that the management process can assert authenticity of the data will be discussed later.

5. Availability – the identity information store needs to be accessible to the application for it to be of any use. But, more importantly, the information that feeds into the identity information store must be accessible, and the rules as to how current the information is should be well understood.

6. Utility – the most important is the agreement that the data is useful and that it will meet all the requirements for authentication, authorization, and personalization without causing an excessive amount of overhead in processing time and development costs.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect