Commentary by Mark Wahl
Organizing principles for identity systems:
Catalyst North America 2005: Flaws of Identity? (2005/7/13)
Mike Neuenschwander, Associate Research Director of the Burton Group, presented at the Catalyst North America 2005 conerence on Taking a Holistic Approach to Identity and Privacy in the Enterprise. In his section on Setting architectural priorities, he listed seven (tragic) flaws of identity to be avoided:
Failure of the weakest links mustn't lead to catastrophe
The scope of the identity architecture includes not only the technology components and protocol flows, but the entire process of identity management. This can include human interactions and decision-making which lead to identity data and rights being imported and policy being established for the identity system. Subversion of these human interactions through social engineering, such as described in The Art of Deception, can lead to reduction of trust in the security and reliability of the identity data.
As a failure can occur in a system at any point, it is important that identity management architectures incorporate recovery procedures that can return the system to an operational state, and that these procedures are exercised through simulation, not only to verify that they work, but to train the individuals involved in the recovery procedures and analysis of the underlying cause.
Furthermore, recovery metrics can be established based on these exercises to determine how to increase the availability of the identity management system, through decreasing the mean-time-to-repair for anticipated threats.
Don't put the role before the start
Role engineering - determining the roles in the organization, identifying the rights associated with the roles, and assigning individuals to roles, has often been suggested as a key design task to be performed prior to the rollout of identity-based access control management services. Yet many large organizations have difficulty in locating the role definitions and motivations, or are 'overwhelmed' by situations in which there are as many or more roles than individuals to fill them.
Besides roles for users, what does need to be considered for the Identity Management design process are the perspectives for each community of use that the Identity Management service provides: the perspectives for customers, employees, administrators, attackers, etc.
In the administrative perspective, the roles for maintaining the identity management system itself and the rights contained within it are of particular importance, as malicious attackers who can take on these roles can subvert the rights management system, impersonate legitmate users, plant backdoors, and later remove their tracks.
Not every identity nail requires the technology hammer
The government procedures for identity management systems, defining the policies and processes for how these systems will be used, determines the interface between the identity management technology and operations with the rest of the organizational goverance. These interfaces must ensure that the identity management systems can be determined to operate within the organizations' risk management parameters, and that exceptional situations can be handled. These interfaces must also evolve as the risk environment for the identity management system changes, and as the risk appetite and goverance environment for the organization changes.
Use of a system invites abuse of it
Furthermore, the mere aggregation of identity data in these identity management systems, even if the aggregation is a side effect of the system, can cause value to appear within these systems. This aggregated data may have value to external attackers for identity theft and other crimes.
Identifying things doesn't make them more secure
Identification, however, is a continuous process in building organizational knowledge of the inventory of assets. Each asset provides some value to the organization, and some assets may also expose the organization to risk, or to other negative effects (e.g. a perception that the organization is violating implicit privacy assumptions from one or more communities of individuals represented in the system).
Identity isn't about the individual
Identity management deployments have evolved beyond their initial 'white pages' listing function to incorporate the relationships between the represented individual and:
- their roles
- services provided to the individual
- other individuals, groups and organizations
- the individual represented in other systems
- etc
There are a lot more than 7 flaws
As Mike Neuenschwander states, IdM empowers organizations to flourish, so worth the trouble!