Analysing Application Activity
The end to end strategy linking identity verification and authentication to intent
Getting Assurance Right From the Start
Many identity and access management strategies spend a lot of time on upfront data and login checks. This includes strong on-boarding (for staff and customers) which has evolved into fairly automated processes for evidence collection, verification and validation stages during profile creation. For example, instead of self-asserted data being presented during customer registration or a simple HR entry being created for a new member of staff, both flows now incorporate data triangulation techniques.
Identity Assurance
The most common example is the presentation of a document created by a trusted-third party - perhaps a passport issuer or driving license authority. This document is scanned (or presented in person) and compared to the person doing the presenting. Remotely of course this is often done using a mobile phone - to both take a picture of the document, then in turn the taking of a “selfie” with liveness checks to compare the image characteristics and indeed prove the person is currently performing the registration. All well and good. If all that completes successfully a profile is created, perhaps with some sort of attribute tagging to acknowledge that certain attributes have been collected from a trusted source.
The NIST guidelines do a good job of explaining this process (specifically 800-63A) and how a platform can create identity assurance levels (IAL) during the profile creation stage.
Login Assurance
The next and sometimes more tricky part, is to carry that assurance on through the login stage. Again the NIST guidelines (this time 800-63B) help here and describe something known as an authentication assurance level (AAL) which helps to identify and in turn uphold assurance based on presented authentication factors. The tricky part can be to link the IAL to the AAL - via secure credential creation and issuance for example.
Now, assuming those stages are working effectively, we have something resembling identity attribution - allowing identity providers and downstream systems by the interrogation of tokens, sessions and claims - to know exactly who they are dealing with. Not just someone (or thing, as we need to also provide similar capabilities for non-human identities and agentic identities too) but a specific someone that has a chain of custody and trust back to a bio-metrically proven identity.
Not many platforms do this effectively. Some are good at IAL. Some are good at AAL. Some do neither. Some do parts of each.
Analysing Intent
However, unfortunately attribution is only half of the end to end identity security puzzle. We also need to consider intent.
For intent, we need to start performing analytical techniques post-authentication.
What is the identity (assured or otherwise) actually doing?
What activity is being performed?
What does it have access to?
What should it have access to?
This in turn can then help to start to understand:
What risk is associated with the activity?
Is it malicious?
Has it been performed previously?
Have other identities performed this event?
This in turn moves an organisation into the realms of detection engineering and controls - hopefully in an attempt to disrupt or stop entirely a malicious activity from completing. This movement to the “left of boom” of identity attacks is something I have written about previously.
This shift to “intent analysis” for want of a better concept requires a deeper understanding of what is happening within and across applications that the identity is accessing. Isolated approaches to per-app analysis can only provide a limited view of activity - and a shift to understanding cross-app and even time-based analysis is now emerging.
We need to do more in this area.
I articulate this concept in more detail in a recent article for Reveal Security - “Security Starts When Authentication Ends: Analysing Application Activity”
“Some other subtle requirements will emerge here – from the ability to cross-reference behaviour across systems, but also across specific time-lines. This improves the ability to identify changes in behaviour either for an individual against itself – the classic “salami attack”, or across a group of peers, allowing specific “trendy” events to be collected to create “trends” of bad behaviour. Individual events that go under the threshold from a risk perspective can then be re-evaluated in runtime based on better intelligence across the entire application ecosystem.”
About The Author
Simon Moffatt has nearly 25 years experience in IAM, cyber and identity security. He is founder of The Cyber Hut - a specialist research and advisory firm based out of the UK. He is author of CIAM Design Fundamentals and IAM at 2035: A Future Guide to Identity Security. He is a Fellow of the Chartered Institute of Information Security, a regular keynote speaker and a strategic advisor to entities in the public and private sectors.