Category: pan-canadian

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.
Mike

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

SecureKey — The Interview

Andre Boysen is an Executive Vice President at SecureKey Technologies Inc., the Toronto-based technology company that is working with Canadian governments and business on next-generation identity management solutions.  With the backing of Intel, Telus and Visa (among others) SecureKey looks to make a big splash in the world of secure payments and online identity.

SecureKey Concierge is a credential broker solution that allows government web sites to use banking credentials.  With SecureKey Concierge, government sites can take advantage of existing banking credentials in a secure and privacy-protected way.

I had the chance to interview Andre last week.

Code Technology: Tell us a bit about what SecureKey Technologies is all about.

Andre Boysen: SecureKey is in the business of making online authentication easier, that’s basically what we are trying to do.  We got started helping banks to solve ‘card not present problems’ — this type of fraud went to zero with the introduction of chip cards and PINs.  But it still is an problem on the Internet – anyone finds your credit card number and billing address basically they can start ordering stuff.  It’s hard for the banks to figure out who’s real and who’s not.

We noticed that banks were moving to contact-less chips (based on near-field communications or NFC) in order to speed up things.  With NFC for quick purchases like papers and coffee, the customer just has to tap the card, no need to enter a PIN.

We saw the opportunity to use this technology to do payments on the Internet.  We have built an NFC reader and the concept is that you can have this reader on your computer, at home, and when you want to buy something on the Internet, instead of typing in a card number you just tap your card on the reader and pay that way.

One of our strategies is to get our technology embedded into all consumer electronics.  Intel is a significant investor in SecureKey and all the Ultrabooks coming out actually have our NFC reader built in.  And we are working to get it embedded in cell phones.

Code: So how does this technology lend itself to the direction you have taken with SecureKey Concierge?

Andre: So, yes, that’s a good question… Part of this is that we noticed that we are all drowning in user IDs and passwords.  And the problem for governments is that they know who I am on paper but they don’t know me in person, and when I show up on the Internet they have a hard time knowing it’s me.  The solution in the past is for the government to roll out their own credential — the current incarnation is called Access Key.  But (for higher-value transactions) that includes installing software on my computer and with all the support costs related to this, the government realized that serving me online is much more expensive that serving me in person…

The federal government’s idea was to delegate authentication.  An RFP was issued looking for proposals with 10,000,000 subscribers and at least three credential service providers.  SecureKey, partnering with three of the largest Canadian banks, was the only respondent.

Code: Why are the banks interested in this?

Andre: Their primary motivator is that they want to see identity move online. Banks want customer identities, today largely based on the provincial drivers license, to be verifiable.  With SecureKey’s model four key players will participate: federal government, provincial government, banks and telcos.  These four players have a critical role in the consumer’s life.  The federal government can set standards and leverage its buying power in a way that individual provinces can’t.  The provinces are the source of identity — birth certificates and the licenses we carry around in our wallets.  But the problem is that we don’t deal with the province very often; it’s rare that we have to talk with them and this makes it hard to authenticate online.

This is where the banks come in.  They have a very tight relationship with 98% of Canadians — they see their customers often and know them well.  By participating in SecureKey, the banks will get better digital identities, which will help them when accounts are opened.

To take this further, BC is launching new services card and drivers license with an NFC chip inside.  This is compatible with SecureKey technology and will make it easier to conduct secure transactions related to provincial programs.

What the telcos bring to this is something that Canadians always have in their pockets — their phones.  We are working to get phones and carrier networks working with the system as well.

Code: What is the typical use case SKC is looking to solve?

Andre: Any Canadian who wants quick and convenient access to any federal government service can use their bank account to gain that access.

Code: Can you confirm for us the high-level architecture? Is it primarily an identity broker service that sits between the IdP and relying party?

Andre: No, it is better described as a ‘credential’ broker service because there is no identity information passed. The government never gets the unique MBUN  (meaningless but unique number), only a service-specific number.  There is no information about the user passed to the government other than they are an authenticated bank user.  The government does its own enrolment and identity verification.

Code: Is SecureKey Concierge based on SAML?

Andre: The service is based on SAML 2.o and has support for older versions of SAML and Shibboleth.  OAuth and WS-Trust are planned.

Code: How can the service support an investigation?

Andre: It is important to point out that SKC has a privacy-enhanced design — triple blind.  No one participant has a complete picture of the transaction.

Each bank produces an anonymous MBUN for each customer. The banks will pass the MBUN to SKC during authentication. Our service will log any transactions completed in the session against the MBUN.  To preserve anonymity between services SKC will further anonymize the MBUN for each relying party service and SKC will pass a unique number called the Persistent Anonymous Identifier to each RP.

Event tracking is supported.  So let’s say CRA comes to us and says we have an event here and we need to do an investigation.  Keep in mind that the ‘handle’ we give to the RP is the Persistent Anonymous Identifier (PAI).  CRA can provide us with this number and we can provide the event logs that relate to that PAI.  If this isn’t sufficient, we can use the MBUN to go to the banks and get the details of the authentication event from them. Of course, it depends on how serious the issue is — if it is a judicial enquiry there will be more disclosure, but for other investigations we will keep the ‘privacy veil’ on.

For a compromised account, the bank is going to shut it down and the government won’t see that account again.  It is worth noting that banks have pretty sophisticated systems for detecting problems, so breaches are pretty rare events.

Code: Can you share with us the attributes that are passed between the bank and the government site? From my recent use of the service, I couldn’t tell if the bank asserted my name information.

Andre: Only PAI is passed. Name info is not passed. Note that each service (relying party) does own enrolment and may collect name.

We are all about consumer convenience, choice and privacy control. This service is very user-centric. Users are presented options to approve any information via on-screen prompts.  To facilitate this, SecureKey Concierge will have a set of templates to allow RPs to collect pre-determined ‘bundles’ of information.  The RP will use these templates to collect all the info consistently from a provincial card or bank record.

This broker concept becomes even more important as we move into sharing identity attributes.  We want to make sure we continue to support minimal disclosure.

Code: I’ve worked on citizen identity for a while now, and there is always the challenge of keeping up with their preferences and ‘life-changes’.  How does the SKC service manage changes to the citizen’s banking credentials? Let’s say I decide to switch banks, but want to keep my access to the Service Canada site in place. Is this possible?

Andre: Yes, a bank account change can be made via a the ‘Switch My Sign-In Partner’.  The process requires that you have control of both bank accounts in order to make the switch.

Code: The SecureKey Concierge two-factor solution looks to be a bit of a game changer for high-value and/or high-risk transactions.  Where do you see this technology being adopted in the online government-to-citizen space?

Andre: Enterprise authentication is something we can do. SecureKey is trying to make it easier for employees using their access badges. We see healthcare and government and finance are three verticals we are targeting, all with needs for strong authentication.

Code: How are things going? Has interest in SecureKey Concierge started to pick up? Have you seen interest in the service outside of the federal government, BC and Alberta?

Andre: We launched with the government of Canada in April, and have 15 agencies/departments online today.  Two bigger departments, HRDC and CRA, are set to launch this fall.  We expect that by the end of 2012 we’ll have the bulk of Canadian departments online with SecureKey Concierge.

As for other interest — there is nothing we can share just yet! But ‘wrapping up Canada’ (all remaining provinces) is the current goal.  We also want more credential service providers including partners from outside of the banking sector.

Code: Thanks for your time today Andre.

Andre: You’re welcome!

Service Canada and SecureKey Concierge

Service Canada now uses the SecureKey Concierge identity broker service.  This new service allows Canadians to access services using their online banking credentials.  This may be the first federated identity implementation in Canada targeted at citizens.  Until now, Fed ID implementations have been limited to higher education and industry federations.

Here is a screen-by-screen walk-through of how Service Canada’s site can be accessed using SecureKey Concierge and a citizen’s bank account.  (Please excuse the image sizes [click to enlarge].)

1. First, from the ‘Access My Service Canada Account’ page, the link to SecureKey Concierge (SKC) is easy to locate near the bottom of the page:

Note that the government has kept their own Access Key as a login option.

2. Clicking on the SKC login brings up the SKC discovery service.  It is here where you select your preferred identity provider from a list of bank services:

3. Select your bank from the list.  The service then redirects to a customized bank login page (Scotiabank in my case).  Note that this page is different than the bank’s regular online login page – the look, content and URL are different.
4. Note that the SKC logo is carried through to this page.  Once I login — and yes, this is the exact same credential as I use with Scotiabank — I was sent to the SKC terms and privacy notice:

5. The terms and conditions can be found here.  When you ‘Accept and Continue’ you are returned to a Service Canada page:

6. This page confirms which credential the user is to use, and offers to convert an Access Key credential to the SKC credential.  Next:

7. Now, Service Canada lets you know what is upcoming, and informs you of various privacy and service terms.  Once you get past this page, you arrive at their enrolment/registration form: 

This is where Service Canada enrols you into their service by asking for selected shared secrets: SIN, DoB, an access code and your province of residence.  Note that your name is not passed in from SKC, and it appears that your name is not needed on this screen to confirm your identity.

(Also note the use of the term ‘authentication’.  I’d prefer they use ‘enrolment’ but I suppose for users of this service it doesn’t really matter all that much…)

8. Finally, upon successfully entering this information you are rewarded with a lengthy privacy notice and terms page:

9. Accepting terms here results in the main Service Canada service page being displayed (with links to your personal information):

In summary:

  • Service Canada provides an SKC login option.
  • SKC allows the user to select their bank login from a discovery service (page with list of partnering banks).
  • The bank login page is a modified version of what the user is familiar with. The user logs in using their regular online banking credential.
  • SKC’s terms are displayed and agreed to by the user.
  • Service Canada then takes over and walks the user through service-specific enrolment pages.
  • The user accesses the service.

Time for me to complete: 5 mins, 18 seconds.

Once enrolled using the above steps, returning to the service is simpler because the link between your bank credential and the service is maintained.  This link is anonymized so that the bank is not aware of what service you accessed, and Service Canada doesn’t know what bank credential you used.

When returning to the service page, select the SKC login option.  Select your bank and login.  You then get access to the service without being prompted for enrolment information.

Aside from the technology and user experience, there is a lot going on here.  Join the discussion at LinkedIn – Canadiam.

  Updated: Click here for the SecureKey interview…

Mike

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.

IAM strategy consulting

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

 

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:

  1. Classify the information that will be accessed — this becomes the Security Classification of Information.
  2. State the Identity 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

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.