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

Friday, February 26, 2010

Stephen Primost

A3e8b5e0becdbfb1b1c706b452b6c388

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

Next post ... a closer look at how this all fits into Identity Management and why it makes sense for the security architect to use these points as a compelling reason for convincing the application developer to agree to use the security framework.

Possibly Related Articles:
13489
Enterprise Security Webappsec->General
Enterprise Security Application Security Digital Identity
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.