Assessing IAM

My experience with formal technology planning spans almost 20 years.  As an external consultant, I have the advantage of being objective, and can offer fresh insights as inputs to planning and strategy development.  However, as an outsider, coming into an organization to perform planning can be difficult because you lack an understanding of the infrastructure, software and procedures in place.

As a result, the planning methodologies 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 has worked well when doing large project planning, IT strategy work and program development.

Assessments are also 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 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.  Analysis of the environment is then performed using  the seven Pan-Canadian IdM&A components:

• Legal –Under what legal agreements and legislation does the organization operate?
• Privacy – How well does the environment match to privacy obligations?
• Security – Does the current environment meet or exceed information security standards?
• 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 plan and design improvements and new solutions.

Mike

Code Technology is now offering its standardized IAM assessment service across Canada.  Please contact us at info [at] codetechnology.ca for more information.

A Vision for identity management in Canada

The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that

supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric,

multi-channel service delivery experience when interacting with government.

Most of my consulting work consists of advisory, planning and delivery services in identity management.  So it is no surprise that one of my interests is in seeing how the Pan-Canadian Identity Management & Authentication Strategy can be applied to a variety of IdM projects.  This strategy holds promise for the future development of a national identity framework, one that can cross government jurisdictions and programs.

The Task Force that developed the strategy established a clear vision:

The overarching vision of the Task Force has been a Pan-Canadian IdM&A Framework that supports access by citizens and businesses to a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience when interacting with government.

For those of us (all of us?) that have had dealings with federal, provincial and municipal governments, this is clearly an ambitious vision. It is fair to say that even working within a single government department today — let alone across jurisdictions — is not seamless and rarely is it multi-channel.  When working between different government departments we encounter a patch-work of online, phone and in-person services that require us to present identification at each step and in inconsistent ways.  Improvements in these areas are clearly in our best interest as citizens and tax payers.

The Pan-Canadian vision promotes standards collaboration.  There must be a basis for establishing ‘trusted, collaborative relationships across jurisdictions’, and only through agreed-to standards can we make this goal a reality. This is particularly true in the high-value online service delivery channel.  Identities for use with applications that require high levels of identity assurance must be well supported by issued organizations to be effective in a cross-jurisdictional use case.

The vision also recognizes the importance of leveraging existing IdM infrastructures – clearly many jurisdictions (and departments within) have IdM services in place that can be adapted and leveraged.  The Pan-Canadian vision does not compel organizations to discard functioning systems, and this shows up in one of the service delivery design principles:

The ability to leverage existing infrastructure and the increased interoperability of systems.

So how does such a vision get realized?  How does a country that is famous for regionalism and inter-jurisdictional disputes move towards a unified and collaborative model?

• First, governments can improve the chances of realizing this vision by making identity management a priority. In a country as prosperous as ours, the issue is rarely funding but rather one of priority. Establishing that e-government and e-business need IdM to fuel economic and social development in Canada is key to moving forward.
• Second, the momentum that we are now seeing in implementing the Pan-Canadian strategy needs to be maintained. In-flight projects need to be completed, new ones identified and communications between all parties increased.  Flexibility in the establishment of standards — recognizing differences and allowing for variances — is necessary if all parties are going to participate fully.
• Finally, the standards that emerge from the project work need to be quickly codified and become mandatory for inter-jurisdictional transactions. I realize that ‘quickly’ is a relative term, but we can’t be talking about standards development five years from now — we need the basic standards and protocols established in the next 12 months if we are going to catch up to what the rest of the world is doing.

A vision of a seamless, cross-jurisdictional, user-centric, multi-channel service delivery experience is very much in the ‘go big or go home’ category — and now that governments are starting to become engaged in the execution of the Pan-Canadian strategy, it will be interesting to see how the resulting solutions match up to this ambitious vision.

Mike

(An article that I wrote last year on the Pan-Canadian Identity Assurance model can be found here.)

Identity Assurance — Putting it Together

Last in a series [ <- previous ] [ <-- first ]

When I reviewed the Pan-Canadian Identity Management & Authentication Strategy early last year, my first interest was to understand what it could mean to my identity management projects.  In the area of Identity Assurance I was, frankly, hoping that this new framework would not stray too far from the baseline standards and methods I had been using since 2003.  

It turns out that the Pan-Canadian Assurance component is fairly close to existing approaches.  Where it differs it is primarily in terminology or in the way the classifications for information, registration processes, credential strength and overall assurance have been organized.  Another difference is in the ‘stitching together’ of all components that make up Identity Assurance.

To put this to use on your projects, you need to first establish organizational standards that are aligned with the Pan-Canadian Assurance component:

• Create a set of four information classifications — and provide examples of your own information when you draft this standard.  These map to your Assurance Levels.
• Document standards for registration processes that map to the Assurance Levels.  These don’t have to be detailed use cases, but rather descriptions of minimum process sets that are needed at each level.
• Select different levels for credential strength by combining passwords, ‘secrets’, issued authenticators, and — if it is applicable to your business applications — biometrics.  Keep in mind that the quality of the operational infrastructure needs to be consistent with the authentication events you plan to support.

Once these standards are in place — and you can borrow liberally from the Pan-Canadian Assurance component to get started — your system design can be formally supported.  The process that each project will need to follow is summarized as follows:

1. Classify the information that will be accessed — this becomes the Security Classification of Information.  
    
2. State the Assurance Level required (it is the same as the Security Classification).
    
3. Determine which Registration Process will be required to match the Level of Assurance.
    
4. Select a Credential Strength at the same level.  This is a critical decision — it needs to be strong enough while still being affordable and sufficiently convenient to use.
    
5. Review the design: analyze the levels assigned in each category and document.

One final comment: the Pan-Canadian Strategy defines a framework, not a set of fixed rules.  Adapt the models and components described in the strategy to suit your business needs.  Provided you don’t stray too far from the intent of the framework, your systems will still be able to interoperate with others that based on the framework.

Mike

For more information on designing identity assurance systems and processes, please contact Code Technology at info@codetechnology.ca or 780.990.7742.

Identity Assurance — Credential Strength

5th in a series [ <- previous ] [ <-- first ]

It’s obvious that stronger credentials allow for access to more sensitive information.  What the Pan-Canadian model emphasizes is that the Registration Processes must be equally strong to ensure that credentials are issued (and subsequently used) by the right person.  

The Credential Strength in the model is a combination of the number of factors and the strength of each individual factor.  Three factors are described: something you know, something you have and something you are.  These are consistent with industry standard definitions.

With respect to multiple factors, the model makes a good point: multi-factor authentication is not always stronger that single-factor.  Two weak factors (e.g. PIN and PC geolocation) may not be as useful as a single factor that is very strong (e.g. certain biometrics).

A factor’s strength needs to be assessed based on:

• its fixity to a person, unique factors that can only be attributed to a single individual (think biometric)
• its distinctiveness, unique attributes that by definition are distinct (think government identifiers)
• its permanence, the degree to which a factor is permanently linked to the individual (think life history ‘secrets’)

Here is a good summary quote from the strategy: “Selection of the authentication factors to be applied to a credential depends on the level of assurance required for a given transaction.”  In other words, if you are protecting an asset and it requires High identity assurance, you almost certainly will need multiple factors to achieve High credential strength.

One last point: the Operational Diligence of the IdM environment comes into play here.  The model defines this as the privacy, security, audit, compliance and other processes that ensure the integrity of the overall system. Environments that lack appropriate rigour cannot be used to deliver higher-value services.

In Practice

There is a good table on page 110 of the strategy, adapted from the Identity, Authentication & Authorization Working Group (IAAWG) Guidelines, that identifies different types of credentials and their relative strength.  This table can be used to support decisions around what type of credential should be used for low, medium and high

Examples include:

• Password or PIN — Low strength.
• User ID and Strong Password — also Low strength.  This is because both are ‘something you know’ and therefore this combination is still single-factor authentication.
• Strong Password and Authentication Token — Medium strength, due to two different factors being used.
• Password and Biometric — High strength, one weak and one (potentially) very strong factor combined provide the overall strength.
• Password, Biometric with PKI Certificate and Hardware Token — Very High strength; it would be hard to dispute the identity of the individual presenting this combination…

I’ve done some similar mapping of authentication schemes and come up with similar results.  Putting this sort of table together for your organization is necessary if you are to consistently and accurately determine credential strength for your IdM initiatives.

An important thing to repeat is that the credential strength needs to be consistent with your registration processes.  If these are aligned then you can, for example, allow access to an application with a High information security classification using a High strength credential.

Next: Putting it all together (coming soon).

Identity Assurance — Registration Process

4th in a series [ <- previous ] [ <-- first ]

Registration is the “process by which a person obtains an identity credential, such as a user name or digital certificate, for subsequent authentication.”  All users of applications supported by an IdM solution must register in order to create an electronic credential.

As I’ve blogged about a few times in the past, the identity proofing that takes place in the Registration Process is critical for high-value or confidential transactions.  In the same way that real-world credentials, such as driver’s licenses, require rigorous registration processes, so too does identity proofing for establishing electronic credentials.  Of course, the strength of the registration process must be in keeping with the overall Identity Assurance required.  For access to a blog or creation of a Hotmail account, the identity proofing standard can be quite low.  To use systems that access health or other sensitive information, identity proofing must be high.

For this reason, the pan-Canadian model calls for different levels of Registration depending on the degree to which an identity needs to be substantiated:

0. No Identity — Anonymous Identity.  No Registration is required.

1. Low — Pseudo-anonymous or Unverified Identity.  Identity is registered with little or no verfication of identity.  User supplied information is taken at face value.

2. Medium — Verified Identity.  Identity is verified against information held by an authoritative party.  The process is managed and proves the identity by either validating electronic or user-held ‘evidence’.

3. High — Corroborated Identity.  Identity is not only verified by an authoritative party, it is corroborated by a trusted third party.  The rigor of this approach provides the highest level of registration possible.

The pan-Canadian model notes that the identity proofing can be supported by either evidence supplied by the user (drivers license, military service card, passport, etc.), or by validating a shared secret that the user supplies and that can be retrieved for comparison from a trusted source (such as a government registry).

In assessing the quality of the identity proofing process, two aspects needs to be considered:

1. The Method of Verification.  In person verification is stronger than online verification; corroborated information (e.g. by a person in a position of trust) is better than information supplied by the user alone; and, information verified by multiple sources is better than information that is confirmed by only a single source.

2. The Strength of the Evidence.  Quick — which is more trustworthy: a Canadian passport or a college ID card? Your provincial student number or your movie rental card number?  An email address issued by a well-recognized employers or a Hotmail address?  The identity evidence presented by people varies in quality and strength, and the registration process needs to be designed with appropriately strong identity evidence.

In Practice:

I’ve been involved with the design and implementation of multiple registration processes over the past six years, and each assignment required a careful review of identity proofing processes. (Note: There are different terms used to describe this functionality of an IdM system, including Identification and Enrolment, but for this discussion the general term ‘Registration’ will be used.)

The first step is to determine which of the four Registration levels are required.  (Frankly, Level 0 is not relevant to the implementation of an IdM system and can be ignored.)  If your solution will be enterprise in nature, or it is already known that a large number of applications will be integrated, then it is probably safe to assume that Levels 1, 2 and 3 will all be required.

Next, inventory the potential shared secrets your organization possesses.  What information do you have on file that your clients readily know or can easily look-up?  Account numbers, birth dates and names are examples.  It is quite possible that both Levels 1 and 2 can be supported by data you already have in databases.  Some organizations, such as government departments, have numerous shared secrets to choose from.  Others may not know much about the user before the registration process is initiated — in these cases, in-person registration (supported by paper credentials) will likely be required for access to systems containing sensitive information.

Once you have a list of potential shared secrets and paper credentials that could be used, align them with each of Registration Levels 1, 2 and 3.  For example, a client account number might be suitable for Level 1 (in fact, it probably exceeds the requirement for Pseudo-anonymous Identity), but on its own it may not work so well for the other levels.  You may find that a combination of good quality shared secrets can help you to achieve Level 2 — the account number plus current mailing address and a recently mailed one time access code might be sufficient.  Or, you may want the assurance of in-person identity verification.  (Click here for a discussion on shared secret quality.)

Finally, for pan-Canadian’s Level 3 the information supplied (in most cases via in-person visit) needs to be corroborated by a trusted party via a separate process.  In practice, this would require verification of the presented identity evidence by a third party.

One way to do this is to first have the individual supply the evidence online.  For example, a physician could provide his professional identification number along with his name and date of birth.  Once verified against a trusted data source, the information can be sent to an administrator that works with the physician.  This administrator can confirm the registration event with the physician the next time they meet face-to-face.  Optionally, the administrator could have the physician sign a usage agreement as well.  In effect, this is a corroboration of the registration information, and should satisfy the requirements for a Level 3 process.

Next: Credential Strength.