Identity Security is a topic we have tracked and discussed on numerous occasions at The Cyber Hut over the past 12 months. As the role of identity and access management has changed fundamentally over the past 5 years – expanding into customers, citizens, non-humans and machines – IAM has become a prize-winning target for adversarial activity.
Isolated IAM components, poor coverage for products such as identity governance and administration and a lack of live behaviour analytics and analysis has created significant blind spots with respect to visibility, protection and response.
The last 3 years has seen a plethora of micro-sectors emerge such as ITDR (identity threat detection and response – see E28 IAM Bitesize, What is ITDR?), ISPM (identity security posture management), next-generation cloud-first IGA (identity governance and admin) and PAM (privileged access management) driven by generative-AI and automation as well as specific tooling for NHI (non-human identities) and workloads.
As many of the approaches in these areas are relatively new, it is likely we will start to see some considerable changes in technical capabilities, process, migration and of course market consolidation. Only recently we saw Silverfort acquire ITDR startup Rezonate – see a comment on our IAM Radar service for the implications of that.
I recently made a comment and diagram that was published on LinkedIn and received over 51,000 impressions and nearly 200 comments. The point clearly resonated. But what am I saying here?
Innovation and Change
I think firstly, we’re seeing tremendous innovation – and in turn a transience with respect to design patterns and adoption. If we try and analyse what is happening in a 2 way matrix that takes a look at both the identity data point of view as well as the runtime behaviour side of things – then apply that to both humans and non-humans. Now clearly the world is never as simple as a matrix – especially not a 2-dimensional one, but it gives us at least a good starting point for discussion.
Data -v- Runtime
But let me explain a little by what I mean as it pertains to data and runtime. Identities don’t operate in isolation and operate within a life cycle. Life cycles have starts, usage periods and deprovisioning phases and a lot of things happening in between – such as credentials issuance and rotation, permissions association, data generation and syncing, contextual association and so on. From an identity data point of view organisations have continually struggled with the classic “who has access to what” style questions often being posed by compliance initiatives such as Sarbanes Oxley, GDPR, NIS2 and others.
So the data in question is essentially the identity profile (schema, attributes, verification and validation status, risk tags, attribute age/freshness values, start/end dates, owners, managers and so) as well as the permissions the identity may need within specific downstream systems – so groups, roles and so on. These permissions maybe stored in specialised repositories, or within the applications themselves. Recent approaches such as just-in-time access and zero-standing-privileges look to alter how these permissions are managed and associated to accounts and identities. Essentially only doing so when they are used. So data management can be in form of access request/review management, permissions removal based on usage, removal of unused accounts, orphan accounts and so on. Basically a set of static rules or controls that are run. AI has a huge role to play here in accelerating things like permissions description analysis, usage patterns and so on.
The runtime view of the world is then looking at what happens post authentication – the access request, session usage, token usage, claims issuance, policy enforcement and so on. Behaviour monitoring, the creation of baselines, abnormal behaviour analysis and response are becoming hugely critical in answering what is a subtly different question – namely “who is accessing what?”. The use of external threat intelligence data, TTP frameworks such as Mitre Att&ck and threat-informed defence initiatives allow organisations to be more surgical and focused on how they implement controls and response to threats in real time.
Human and Not-So-Human
But we need to consider these two analytical approaches for both people and workloads. Workloads often out-number humans 10-15x to 1, but are of course intrinsically linked to a person – an accountable owner be it coder or devops engineer for example as APIs, pipelines and other automation components are created to deliver services and move data to where it needs to be. These workloads need to be issued credentials – JWTs or certs – and before you can do that, you often need to attest processes and create identity documents that represent these processes – which of course should be attested the same as we proof identity data during onboarding.
What’s Next?
So we have two or more identity types and two or more areas for controls. So where does it go? Well I think ultimately we’re talking about coverage for both landscapes – maybe within the same tooling. It doesn’t seem sensible to have runtime monitoring for one and not the other. Data management may occur separately, namely as the response aspect for both humans and non-humans will be very different – especially with respect to system integration, credential change and policy change. In honesty, most security related identity components are heading towards being able to do both data and runtime monitoring and response – and are tackling that in subtly different ways.