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.

Mike

Author: code

Mike Waddingham is senior Information Technology management consultant with over 30 years of industry experience. He is the owner of Code Technology Corp.