I’ve recently been thinking about risk management and compensating controls as it applies to the delivery of online services that require higher assurances of identity. One item that regularly comes up in this area is the existence of entities that are conducting sensitive (financial or otherwise) transactions using nothing more than a userid and password.
Their ability to do so is attributed to the downstream (from the authentication event) analytics and compensating controls that they have implemented. The questions being asked are “Can the assertion of identity from these entities be treated as having an assurance level greater than what can be attributed solely to the token that they are using (userid/password at LOA1)?” or “Should the granularity of the LOA levels themselves be changed to accommodate these additional capabilities that are being used?”
As a starting point, it is instructive to look at a simplified view of such a process. While I am sure there is a similar process at Consumer IdPs, I am going to use a Financial Sector example because the FFIEC Authentication Guidance to Financial Institutions (PDF) provides a lot more transparency around what the Financial Institutions are required to implement per regulations; Implement a layered security program which uses different controls at different points in a transaction process.
First of all, it is important to note that in the case of Financial Institutions (FIs), NIST 800-63-1 (see section 5.3.2) fully acknowledges that the “Know Your Customer” processes that the FIs are required to implement can fully satisfy the identity proofing requirements up to LOA3, and if the financial account was opened in person, of LOA4. So their knowledge and confidence in the identity at the time of account opening is very good. But the token that they bind that identity to in order to create a credential, is typically a very weak userid and password.
What is also important to understand is that the set of actions that a person can perform, after their credential has been verified, is constrained e.g. look at current balance, deposit money, transfer money, add a new payee to online banking etc. And among those actions, some are arguably higher assurance transactions such as transfer money out of the account, add a new payee etc. And that is precisely the place where additional controls can be implemented (as noted above by the red diamonds). The critical point here is that those controls are also unique to the domain and triggered on exceptions to what is considered normal in that particular domain. So the exceptions implemented by a bank are going to be radically different from what is implemented by a Google, Facebook or Twitter.
So the combination of a weak credential combined with the confidence in controls that can catch transactional exceptions allow these organizations to operate within a risk profile they are comfortable with.
Now let us make one of these entities a federated Credential Service Provider (IdP) to an external organization:
What becomes glaringly obvious is that the only thing that can be verified in the flow before the person moves out of the system is if the credential is valid. Given that the weakly bound credential (username/password - Level 1) cannot be supplemented by the info from the analytics and compensating controls, the only thing that can reasonably be asserted to an external relying party is that “An authentication event occurred in my system”.
To me, an organization that issues weak Level 1 tokens, and wants to be a Federated IdP is more akin to the Maginot Line (the supposedly unassailable French fortifications that were not directly attacked but flanked and bypassed by the Germans in WWII), than an immovable object whose processes can be depended on to assert a higher assurance identity.
They are able to withstand direct assaults on their system, but the strong backend processes they have set up are simply not in play and cannot provide information regarding confidence in an identity, greater than Level 1, to an external party when they seek to federate their credentials.
- Relying Parties as IdPs and Assurance Level Escalation
- HOW-TO: Incorporate Risk Management into Assurance Level Determination
- These Are Not The LOAs (1+,2+,3+) You Are Looking For. Move Along
- HOW-TO: Conduct a Risk Assessment to Determine Acceptable Credentials
- Microsoft Research: Where do Security Policies Come From?
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.