The Assurance Framework

2006-10-17T00:45:00.000-07:00

Assurance Frameworks are an essential approach to authentication. They underpin the Identity side of the Identity & Access Management process, and put all the major factors into one context. The factors are :
- Registration Strength
- Credential Strength
- Business Risk
- Authentication Mechanism
- Assertion Confidence
- Transaction Assurance

Identity Management systems need such a framework to ensure trust, risk, consistency and continuity over time. Most organisations use one even though they don’t realise it, or haven’t formalised it yet .... every organisation needs one, tailored to its own risk profiles.

====================
The following is a simplified overview of how to establish and use an Assurance Framework.

High-level Context Diagram
This diagram shows where an assurance framework sits in relation to the other Identity and Access mechanisms. It underpins the Identity processes (provision and transact).

User registration (the Y axis) is a process that many organisations already use. For example opening a new bank account, applying for a new passport or acquiring a digital certificate. A number of identification items (including birth certificates, photo-ids, and passports) are valued and totalled to reach a number of points on the registration scale. Registration can be further strengthened where required with more identification items, by additional staff security clearances, or customer reference checks.

Credentials (the X axis) such as fixed passwords are no longer regarded as secure enough for most on-line interactions; two factors are the new objective, and stronger credentials could be needed in some circumstances. For example, high-wealth customers, high-risk transactions, e-procurement, security network administration all need better security than a basic password provides.

The Assurance Framework
This diagram shows how to set up and interpret an assurance framework. It applies equally to external and internal users.
For a given identity assertion (username and credential) the assurance level can be readily determined.
NIL - An Assurance Level of 0 doesn’t require any user registration or a password (eg browsing web brochureware or Googleing).
MINIMAL - An Assurance Level of 1 (green area) requires minimal registration and maybe a fixed password (eg accessing some restricted parts of some web sites, HoTMaiL, blog publishing).
LOW - An Assurance Level of 2 (yellow area) requires a pin/password of various strengths, and a better knowledge of the user (eg eBay, employee LAN accounts).
MODERATE - An Assurance Level of 3 (orange area) means it should be a two-factor process, with a stronger registration process (eg ATM transaction, some on-line business transactions).
HIGH - An Assurance Level of 4 (red area) means it should be a non-repudiable two-factor process. This suggests at least one biometric for verification (eg finger or iris scan) and perhaps a stronger registration (eg security clearance to Secret level).
EXTREME - An Assurance Level of 5 and above may require a three-factor process and a stronger registration (eg security clearance to Top-Secret level).

But does the user's assurance level meet the transaction's assurance level?

Transaction Risk
This diagram shows how to determine the assurance needed for any given transaction. The example is Change Bank Account details over the internet by an existing customer.
The highest risk or impact rating for the transaction Change Bank Account over the Web by a Customer is Level 3. According to the bank’s Assurance Framework, the customer should be required to present a 2-factor credential to guarantee trust in the transaction.

But will the bank enforce this rule?

Applying the Assurance Model
The difference between the actual risk (level 3) and the customer’s current assurance rating can be mapped onto the assurance framework. The customer account currently only has password protection.
Although the customer should be required to present a 2-factor credential, the bank has decided not to issue a stronger credential for now. They will allow the customer to present their existing single-factor credential and mitigate the risk in some other way. The application owner has identified and evaluated the risks, has mitigated those risks as far as possible, and is willing to accept (sign-off) the residual risk.

Perhaps customers should also consider risk and trust in this manner and start insisting on stronger assurance - this does not necessarily mean stronger credentials.

====================

Identity and Access Management

The Assurance Framework