Assessing IAM

My experience with formal technology planning spans over 20 years.  As an external consultant, I can offer fresh insights as inputs to planning and strategy development.

The planning approach I have used have always included an assessment phase — a set of tasks in the project that is primarily concerned with collecting information about the environment.  This works well when done prior to project planning, strategy work and program development.

Assessments are a vital part of Code Technology’s work in identity management. An IAM Assessment can be delivered on its own, or as part of an identity management strategy project.  The approach we have formulated for IAM Assessments is a little different than the generic IT information gathering. Identity management assessments need to be structured to address key components that impact IAM design and delivery.

If you’ve followed this blog for any length of time, you’ll know that I regularly reference the Pan-Canadian Identity Management and Authentication (IdM&A) Framework.  This framework has provided an excellent structure for assessment and strategy development work.

My approach, then, is to leverage the framework in the development of an IAM assessment.  Without the structure and completeness of this framework it would be difficult to ensure everything was covered.

The heart of the assessment is information gathering: infrastructure, applications, identity stores, policies, processes, etc.  Once these details are collected, analysis of the environment is performed using  the seven Pan-Canadian IdM&A components.

Key questions are used to drive the assessment analysis:

  • Legal –Under what legal agreements and legislation does the organization operate? How do these drive compliance for IAM?
  • Privacy – How well does the environment match to privacy obligations?
  • Security – Does the current environment meet or exceed information security standards? What key identity and access risks need to be considered?
  • Trust – What trust arrangements (if any) exist between federated organizations?
  • Assurance – What processes and technology exist to ensure information assets are protected to the appropriate level of assurance?
  • Identity – How are identities organized and managed?  What identity attributes are stored and utilized?
  • Service Management – How robust and flexible is the current environment? How will it need to be supported?
An assessment is more than just information gathering — the analysis can help to immediately highlight strengths and weaknesses in the environment.  Follow on work can use this documented ‘snap shot’ of the identity management environment to address security gaps, make improvements and plan for new solutions.

Legal obligations and identity

Let’s start by stating the obvious: identity management systems must abide by provincial/state and national laws.  An IAM assessment needs to identify the laws and legislation that govern the organization to ensure identity-related systems are appropriately structured and legally compliant.

legal review of identity management IAM assessment(Disclaimer: I’m not a lawyer, not even close… I don’t even watch Law and Order anymore! Please consider this article general information only.  For some actual legal opinion, check out the Canadian Privacy Law Blog.)

When implementing an IAM system, a review of the legal aspects of identity is important.  Issues can arise when identity management systems do not consider the legal requirements.  For example, privacy legislation may put limits on what type of information an organization may collect and store (e.g. sensitive personal information).  Or there may be legal limits on how information is shared, or how a user is notified about identity information sharing.

On the flip side, misunderstandings about what legislation allows and disallows can lead to poor user experiences or systems with reduced functions.  In one case, I was developing an identity strategy for a client who is subject to some fairly specific privacy legislation.  We wanted to share identity information between business applications and with other partners.

Several senior people in the sessions insisted that the act disallowed this type of information sharing.  I knew there were restrictions so I sifted through the actual privacy legislation to be sure.  I was surprised to find that the restriction was not as severe as the group thought.  The act stated that the intended use of personal information needed to be clearly stated, and that the individual needed to consent to this use.  This clarification allowed the group to create a framework for collecting identity information for a specific use, collecting consent from their users, and then sharing the identity information within the stated use.

By including a legal review in an IAM assessment or solution project, clients can have confidence that their systems are compliant with their obligations.


Service Management and identity

Identity & Access Management (IAM) systems need to be reliable, perform well and have adequate end-user support.  When assessing Service Management needs for an IAM environment,  a number of factors need to be considered.

Wikipedia defines IT Service Management as ‘is a discipline for managing information technology (IT) systems, philosophically centered on the customer’s perspective of IT’s contribution to the business.’  Service Management for an IAM system needs to consider both the business area and end-user needs – and these may differ depending on perceptions, actual usage patterns and functions of the IAM system.

To this last point, IAM offers a wide range of functionality: authentication (login), authorization, account creation, provisioning, administration, reporting, etc.  The service management profile for these functions can vary; for example, login and authorization services need to be highly available and well supported, while functions like reporting are less critical.  Assessing service management for IAM, therefore, needs to look at each functional area of the system.

Data centre service management has swung wildly in the past 30 years, from centrally controlled and highly available mainframe environments to more lax client-server setups of the late 80s and early 90s.  Today’s expectation for the quality of enterprise data centre services has returned to a more strict standard.  Business sponsors and users expect the equipment, network and services to be highly available, with scheduled outages and evergreen plans (for future expansion).

Help desk services need to be assessed to ensure IAM services are properly supported.  Help desk support can range from the basic email, ‘best-effort’ model to full 24/7 phone and remote take-over support.  Understanding end-user requirements is critical to striking a balance between help desk costs and a quality support model.

I’ve had a number of clients identify 24/7 support for their infrastructure and help desks – and then balk when the cost of such a service is realized.  The justification for the blanket support is that if the application is promoted as being online, it needs to always be available.  Many clients want to respond to help requests when they occur.  However, in my public sector experience anyway, these systems (and the IAM providing protection) are often used for non-critical purposes.  Registering for a program, accessing document stores, even retrieving information needed for business purposes – these types of transactions are rarely critical in nature and tend not to deserve ’round the clock support.

In the private sector, the decision to provide this type of support is strictly a financial one.  The cost of supporting users versus the revenue gained (and the long-term benefit to the brand) can be calculated to support extended hours for support.

IAM that supports medical systems are perhaps the one type of system that will always require extended support hours, highly available systems and responsive end-to-end architectures.  This is particularly true for systems that support health workers (physicians and nurses) and their access to patient and reference information.  Failing to implement an appropriate high level of service management for the IAM systems used in healthcare can be disastrous.

It will be interesting to see what the new breed of patient-oriented portals choose to provide in the way of redundancy, performance and support services.  These emerging systems are geared to providing patients access to their own health information – data that they can use for education, self-diagnosis or treatment – but it isn’t clear that the portals will need to be highly available.  If they do, the sponsors will need to dig deep to fund their operations.

Service management is key to a sustainable identity management solution and a proper assessment of technology, people and processes is an important part of any IAM review.


Related: Kuppinger Cole have an article on ITIL vs IT Service Management that is worth a read.

Assurance and identity

Because I spend most of my days implementing IAM systems, Identity Assurance is a bit of a pet topic of mine – it seems that IAM design frequently comes back to the type of information being accessed and the quality of the end-user’s identity.  In enterprise systems that provide access to sensitive information, a review of Identity Assurance is critical to ensure appropriate controls are in place to protect that information.

Identity Assurance is, according to Wikipedia, ‘the ability for a party to determine, with some level of certainty, that an electronic credential representing an entity … can be trusted to actually belong to the entity.’  Identity Assurance is commonly expressed in ‘levels of assurance’, ranging from 1 (low assurance) to 4 (very high assurance).

When doing IAM assessments I have found many client systems have been built without levels of assurance in mind.  Systems with sensitive information are accessed with the same electronic credentials created for a system with basic, publicly-classified information.  In other words, an account is created for a simple site and reused for access to a site with more confidential information.

This poses a number of problems…

  • The credential itself is not of sufficient strength to access the confidential site.  For example, the password rules used may be sufficient for the simple site but are not strong enough for the confidential site.  This could make the confidential site prone to vulnerabilities (e.g. dictionary attacks on weak passwords) that would have significant consequences.
  • The credential has been issued to a user without adequate identity proofing.  There are many examples of low level credentials from social media sites.  An OpenID based on a Google account is not verified and linked to a real-world user – something that may well be fine for access to Google apps.  But accepting that same self-issued credential to access more confidential information is likely not appropriate without increasing the identity assurance.
  • The user may no longer be in sole possession of the credential – either they have stopped using it for an extended period (and it has been unknowingly hacked), or they are willingly sharing it with a co-worker, spouse, etc.  Sharing a credential is actually fairly common within households, especially for access to family blogs, Flickr and other social media sites.  Using such a credential for a sensitive application poses a number of risks.

Fortunately there are some excellent standards and frameworks for determining appropriate levels of assurance.  These tend to be based on a business-driven information classification exercise, i.e. the level of assurance required is directly related to the sensitivity of the information and how it is used.  Once that classification has been performed, the assessment can be done to ensure:

  • appropriate identity proofing is performed;
  • the credential is issued in a secure manner;
  • the credential’s lifecycle is properly managed (e.g. dormant accounts are revoked);
  • the credential has been properly authorized to be used by the application or site; and
  • the technical environment in which the credential is used is appropriately managed and secured for the type of information being accessed.

By understanding the information being accessed and applying a standardized process to assessing Identity Assurance, the strengths and weaknesses of the IAM system can be readily determined.