Mike, Michael. Okay, eh?

May 26, 2015

Identity matching is tricky. I have been working on health-sector project recently where it really matters that the identity in one system matches the identity in another.  When access to patient information is being managed, identity matters. A lot.

So when I boarded my flight today my ears perked up when the boarding agent asked his coworker “Mike, Michael. Okay, eh?”  The coworker said she thought so and after checking a list of allowed first name synonyms I was free to board.
Of course, the issue here is that my flight was reserved under Mike and my government ID has my legal name Michael. The airline – fairly recently as far as I can tell – has created this list and added a double check before boarding. 

Identity matching matters and I’m guessing we will see a lot more of this type of process implemented for transactions where a high level of assurance is needed.

Mike


Reblog: Anil John

September 6, 2014

For your weekend reading, here is a solid post with reference to Identity Assurance standards and guidelines from prolific identity blogger Anil John:

Anil John post on Identity Assurance G&S

 

Enjoy!

Mike


Pan-Canadian Identity Assurance Model

September 17, 2013

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):

identity_assurance_standard

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


Assurance and identity

June 26, 2011

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


Credit Card Activation

September 3, 2009

credit card identity proofingI haven’t applied for a credit card in a while and so I wasn’t expecting this new identity proofing process from BMO MasterCard

I called the customer service number to activate the card.  In the past, you simply had to enter the 16-digit number and, assuming you are calling from a home phone number, the combination of the card number and phone number were sufficient to validate your identity.

Today, however, the system collected my card number and explained that I would need to participate in an identity proofing process based on my credit history.

After a few minutes on hold, the agent came online.  Here is the transcript, somewhat paraphrased:

Agent: Hello, Mike, we need to confirm your identity using information from your credit history.  We will ask you some questions and you can pick from three multiple-choice answers.  Do you agree to this process?

Me: Uh, Sure.

Agent: Okay, from the following list of credit unions, who have you banked with in the past five years? <she then listed three credit unions.>

Me: <name of credit union.>

Agent: That is correct.  Next, from the following apartment numbers, pick the one that corresponds to a previous residence.

Me: Uh, well I can’t recall the last time I’ve lived in an apartment…

Agent: Well… Let me list the numbers and see if you recognize any: 1101, 6A or 904.

Me: I’m not sure — is this my only option? The last time I lived in an apartment was 1987!

Agent: Well, we need an answer to this question.

Me: I can’t remember an apartment from 20 years ago… can you?

Agent: Uh, no, I see your point… but the credit bureau has this information…

Me: (sigh) I’m sure they do… and I’m sure it is accurate, but this isn’t much use to us if I can’t remember.

Agent: Well, if we can’t finish this process you can go to your bank in person with two pieces of identification to activate your card.

Me: I see.  Well, can I guess?  How about ‘1101’ ?

Agent: Yes! That worked; your card is now activated…

I’ve written about shared secrets and identity proofing before, and I knew that credit bureau information was a rich source of shared secrets.  In fact, these types of questions are likely what is driving the Equifax Over 18 I-Card implementation (used to prove age of user among other things).

So what is new and worth commenting about all this?

  • The questions are locked – the agent only had two questions and I had to get them correct on the first try to proceed.  She was surprised when I asked for an alternate question.
  • There were only three options to each question.  I actually guessed at the apartment number and was successful.  With only 2 questions and three options, my calculation is that a fraudster would have a 16.7% chance of guessing the right answer to both questions.
  • Because my call had to be from my home phone, the threat they are attempting to thwart is (presumably) ‘an intercepted card by someone in the same household (or someone with caller ID spoofing capability)’.  This is seemingly low probability occurance but it is obviously worth the bank’s efforts to implement this additional process.

My best guess is that they are having trouble with intercepted mail and caller ID spoofing.  I wonder if the additional shared secrets presented in a multiple choice format are sufficient to overcome a determined (or lucky guesser!) fraud artist given that they’ve already stolen my mail and know my phone number…

Mike


Identity Assurance — Registration Process

December 24, 2008

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.


Secret strength

June 2, 2008

A while back, I wrote about the three keys to a quality process for using shared secrets in establishing an individual’s identity: quantity, quality and the degree to which a secret is shared.

The quality (i.e. relative strength) of a shared secret is critically important if it is to be used to establish a credential for access to government information.  Quick, rank the following in order of declining strength:

  • a provincial student number
  • your last federal tax return refund or payment amount
  • a randomly generated PIN that is mailed to you
  • your birth date
  • your mother’s maiden name

The student number is a common identifier for the education system.  It uniquely identifies students ‘in the system’ and, in most cases, is assigned at entry into kindergarten and used right through post-secondary.  It’s strength comes from its uniqueness, its ability to be independently verified, the authority that issues it (the government), and the strong processes they follow to issue and maintain the number.  However, student numbers are often displayed on report cards, certificates and countless other paper and electronic documents.  It is not difficult to find out a person’s student number.

Dollar amounts from federal tax returns are similarly unique to an individual (or, at least, the combination of the user’s name, perhaps their SIN and the dollar amount is considered unique).  The information is securely delivered to the individual’s household via Canada Post.  It is reasonable to assume that if you answer this shared secret correctly, you are the individual you claim to be — with one exception: others in your household have access to your mail and tax papers.

One-time PINs are useful in e-government applications when issued to individuals for identity assurance purposes.  Often the government will have good information on the identity of the user, have a reliable address and perhaps a request from the user to establish an electronic identity.  A PIN is created, mailed to the user and then provided by the user in a prescribed online credential creation process.  By having appropriate one-time and PIN expiry processes, the government can be reasonably assured that the individual is who they claim to be with one exception: others in the household may gain access to the correspondence containing the PIN.

Your birth date and your mother’s maiden name are both fairly common shared secrets that have the benefit of easy recall for the user, but suffer from overuse and low secret strength.  Genealogy sites, social networking sites and public records can easily be used to retrieve these ‘secrets’.  A large disadvantage to this type of secret is that it does not change — once compromised it cannot be reset to another value (unlike a password) and becomes useless.

It can be seen that none of these mechanisms allow for absolute assurance — and really, without a strong in-person verification there will always be gaps.  However, several online implementations have been successful by combining shared secrets of different strengths when establishing the identity and by notifying the user when the process was executed.  For example, you wanted to mail the user a PIN but there is concern that it could be used by someone else in the household, two mitigating processes could be used:

1. Send the user a follow-up notice (letter or email or both) when the PIN is consumed thereby alerting them if they had not performed the process themselves; and/or

2. Combine the PIN with additional shared secrets.  A student number and a PIN and one’s birth-date and a previous course mark is a difficult combination to crack, even by someone in the same household.

Striking a balance between the quality and quantity of shared secrets, and introducing a confirmation notice, are the keys to establishing workable online identity assurance solutions.

Mike