uvic – Code Technology

Pan-Canadian Identity Assurance Model

In October 2008, I wrote a five part review of identity assurance, based on the framework contained in the Pan-Canadian Strategy for Identity Management and Authentication. At the time these blog posts were the only Canadian resource available for analyzing and planning identity assurance.

Since then a number of changes have occurred that have prompted me to update these posts. For example, an Assurance, Identity and Trust Working Group was established by the national Identity Management Steering Committee. This team prepared a report, the Pan-Canadian Assurance Model, that provides more guidance and detail than the original framework.

Having said this, the goal of the model remains unchanged; it strives to standardize identity assurance to allow for provincial and federal systems to interoperate. It is foundational to the broader Pan-Canadian framework, and is key to implementing citizen services across the country.

The identity assurance model is primarily concerned with establishing agreed-to levels of assurance and defining the concepts and terms each party need to understand. It has an emphasis on federation and looks to support risk management activities within partnering organizations.

The Pan-Canadian identity assurance model is represented as follows (click/tap to enlarge):

While this model is an important input into this blog post series, it needs to be supplemented by real-world experience. For each topic in the series, I will inject examples from my experience implementing IAM solutions over the past ten years, and provide insight into the opportunities and challenges offered by the model.

First in the series, click here for the post on Information Classification.

Mike

Identity Assurance — Putting it Together

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

When I reviewed the Pan-Canadian Identity Management & Authentication Strategy in 2008, my first interest was to understand what it could mean to my client’s 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 was fairly close to the approaches I was already using. Where it differs 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 requirements for Identity 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 your system design can be formally supported. The process that each project will need to follow is summarized as follows:

Classify the information that will be accessed — this becomes the Security Classification of Information.
State the Identity Assurance Level required (it is the same as the Security Classification).
Determine which Registration Process will be required to match the Level of Assurance.
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.
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

Tired of reading? Check out the 72 Things I’ve Learned About IAM…

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. And the Pan-Canadian model emphasizes that the identity-proofing portion of 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 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 IAM 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 other words, if your IT shop has a weak record for availability, or has failed multiple security audits, you may need to improve the operations before implementing IAM above Level 2.

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 factors are ‘something you know’ and therefore this combination is still single-factor authentication.
Strong Password and SMS Text PIN — 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 and identity proofing 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 Together.

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 IAM solution must be identified and be registered 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 sensitive 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 identity proofing process must be in keeping with the overall Identity Assurance required. For access to a blog or creation of an Instagram or Gmail account, the identity proofing standard can be quite low. To register for systems that access health or other sensitive information, identity proofing must be much more stringent.

For this reason, the Pan-Canadian assurance model (left-most column) calls for different levels of registration depending on the degree to which an identity needs to be substantiated:

1. Low — Pseudo-anonymous. Identity is registered with little or no verification of identity. User supplied information is taken at face value. If validation is performed, it is cursory.

2. Medium — Identity Validated. Identity is validated to a moderate level of assurance, and registration is typically performed via an online registration process. Shared secrets are exchanged to validate the identity during the process.

3. High — Verified Identity. Identity is verified against information held by an authoritative party. The process is managed and typically delivered in-person (e.g. a counter service). A third-party physical credential (e.g. picture ID) may be presented and compared to an organization-held data source.

4. Very High — Corroborated Identity. Identity is not only verified by an authoritative party via an in-person process, it is corroborated by a trusted third party. The rigour of this approach provides the highest level of registration possible and is typical of critical process such as passport issuance.

The Pan-Canadian model notes that the identity proofing can be supported by either:

evidence supplied by the user (driver’s 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 is better than information supplied by the user alone; and, identity 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? 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 dozens of identity proofing and registration processes over the past ten years, and each assignment required a careful review of identity proofing processes. (Note: There are different terms used to describe this functionality of an IAM 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. 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. (Level 4 registration is rare and, in addition, unworkable online).

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 formal names are examples. It is quite possible that both Levels 1 and 2 can be supported by data you already maintain in enterprise 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 such as driver’s licenses) 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, but on its own it may not work so well for higher 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. At Level 3, you will want the assurance of in-person identity verification. (Click here for a discussion on shared secret quality.)

Finally, for pan-Canadian’s Level 4 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 support Level 3 and 4 regsitration is to first have the individual supply the evidence online. For example, a physician could provide his college 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 or 4 process.

Next: Credential Strength.

Identity Assurance — Trust Levels

3rd in a series [ <- previous ] [ <- first ]

The second part of the Assurance Component of the Pan-Canadian Assurance Model to discuss are Transaction Assurance Levels, or more simply, Trust Levels.

Trust Levels are defined in the pan-Canadian IdM&A Framework as ‘a pre-established statement of the level of certainty that is needed to access information or conduct a transaction.’ They are directly linked to the Information Classification.

The model establishes four trust levels:

1. No Trust — Anonymous Transaction. Used with information that is unclassified (e.g. published information).

2. Low Trust — Routine Transaction. Used for protection of systems containing basic information, i.e. information with a Security Classification of Low.

3. Medium Trust — Verified Transaction. Used with systems that need to protect confidential data, such as some medical records, tax information, identity information, etc.

4. High Trust — Corroborated Transaction. The highest level of trust; required for protecting information classified as High (e.g. cabinet documents, criminal trial information, etc.)

It is important to note that the ‘transaction’ referred to in this discussion is the business transaction that will be supported by the identity and access management system. For example, medium trust is needed by business transactions that needs to be verified (due to the sensitivity of the information being protected).

In Practice:

Trust Levels allow for a clear description of what we need to establish before we allow access to an application or information set. On the surface, the Trust Levels differ little from the Security Classifications, but the exercise in assessing trust and assigning a Trust Level is important. It forces the business to ask some key questions: How much do I need to do before allowing access to this information? Have I classified the information correctly and is it reflected the Trust Level?

As can be seen from these questions, the word ‘trust’ forces the business to look at the Security Classifications in a somewhat different light. That allows for better conversations around what the value of the information is and what an appropriate access solution might look like.

Next: Registration Process.

Identity Assurance — Information Classification

2nd in a series [ <- previous ]

The first component of the Pan-Canadian Assurance Model to review is the Security Classification of Information.

There are a number of ways that organizations can classify their information. The Pan-Canadian model uses the Canadian Public Sector Security Classification Guideline developed by the National CIO Subcommittee on Information Protection (NCSIP). The guideline is quite straight-forward as its justification is summarized by the following quote:

…when electronic information is shared with external jurisdictions that are not aware of the value or sensitivity of an information asset, it becomes essential that the classification rating be established so that the information protection requirements can be quickly understood, communicated, and acted upon.

Here are the guideline’s information classifications and my interpretations of each:

1. Unclassified — Typically publicly available information. A breach, loss or unauthorized modification would not result in injury to individuals or organizations.
2. Low — Basic information about an individual, internal administrative systems or the status of a government process. Breaches of Low level information could cause significant injury (in the legal sense) to individuals or organizations including financial loss, service level impacts and/or embarrassment.
3. Medium — Medical/health information, an individual’s tax information, trade secrets, identity information that could be used to support fraud, etc. Breach or loss “could reasonably be expected to cause serious personal or enterprise injury” including significant financial loss, legal action, etc.
4. High — Cabinet documents, oil & gas exploration data, criminal case information, information on a police informant, etc. If information rated High were breached, stolen or modified without authorization, “extremely serious” injury to individuals or organizations could be expected to occur.

The above provides general guidelines on how information should be classified. It is fairly consistent with classification models I’ve used in the past, and the examples in the guideline are quick easy to understand.

In Practice:

When using this type of guidance, it is important to develop your own examples so that the information your organization manages is used for illustrative purposes. For example, if you manage permits or licenses, be clear as to how that information is classified both during and the permit application process and after it is completed.

Educate your business clients on the guideline. IT staff must NOT make the classification decision, nor should they influence the decision-makers one way or the other. Business owners and ‘information stewards’ need to classify the information. Use workshop settings to uncover information being managed, and use the examples to define information classifications.

It is important to perform information classification activities outside the activity to select security controls. While it is very true that the classification will impact the controls you select, the knowledge that costly or difficult-to-implement controls might be needed must not influence the way information is classified.

Document the classifications — this could be done by each business area, or recorded centrally as an appendix to information classification standards or information management documentation.

The information classifications are mapped to the right most column in the model. This column, titled “Potential Impact of Identification/Authentication Error” will drive the remainder of the identity assurance analysis.

Next: Trust Levels.