Clarity Matters: Identity and Access Capabilities

I am working on a proposed revision to the Zero Trust Reference Model from The Open Group and wanted to get your feedback on it. This article covers the Identity and Adaptive Access Management (IAAM) capabilities and their supporting Architecture Building Blocks (ABBs).

For reference, my previous post on similar updates to Asset Centric Security Operations (ACSO) is here - https://www.dhirubhai.net/feed/update/urn:li:activity:7297257447734300672/

Capabilities define 'what' a function does by defining the durable outcomes that don't change even as tech/threats/etc. continuously evolve. These are similar to business capabilities like 'ship products to customers' which remains unchanged even if you switch from shipping by plane to train/truck/etc. or track the shipments with computers instead of paperwork based processes).

?

These capabilities answer the question 'what is modern identity and access management?'

?

The Identity and Adaptive Access Management Platform (IAAMP) ABBs bring these capabilities to life with processes and technologies. The final 'people' elements for this capability will be defined in an separate upcoming roles and glossary standard.

?

These IAAM capabilities and ABBs have evolved since the currently published snapshot at https://publications.opengroup.org/s232 in several ways.

First, these combines the Adaptive Access Control and Digital Identity into a single view of identity and access. This is because we realized it was more valuable to provide a single clear view of this discipline rather than requiring you to reconcile two sets of related implications that a Zero Trust approach introduces:

• Everything is explicitly verified
• Everything gets an identity

?

Every subject and access request should be explicitly verified

Zero Trust requires explicitly validating all access requests (including the trustworthiness of subjects making them).

To do this effectively and at scale, Zero Trust introduces adaptive access that extends the classic authentication and authorization model with a new interim step.

This new 'trusted' phase fits between classic 'known' (authenticated) and 'allowed' (authorized) phases to ensure that the subject and the access session (to be formed by the access request) are trustworthy enough to access the requested asset.

This is similar to how airport security goes beyond checking ID (authentication) and also checks all passengers for dangerous items and materials like bombs, guns, and knives that could endanger all passengers and planes (trusted). There is a little bit of app-specific authorization (is your flight leaving soon from these gates, do you have premium ticket, etc.), but the true granular authorization (flight/destination, seat/class, price, etc.) is still performed by the airlines (analogous to business rules in individual workloads/applications).

The adaptive access approach allows this to happen at scale by defining policy that can adapt to dynamic changes (e.g. establishing high/medium/low trust level of a subject/session depending on whether they are using phishing resistant authentication, coming from an known hostile or anonymized (TOR) IP, violating physics in the subjects geographic locations (e.g. impossible travel), matching previous behavior patterns, using a device with known compromise/vulnerability, etc.). Similarly, you also want to measure the trust of a target before allowing the subject to use it and possibly give it access to sensitive data, identity tokens, etc.

?

Everything gets an identity

The second change is partially related to the first. In order to apply this policy effectively, you need to have a digital identity for all objects so that they can be tracked and processed by policy. Can't restrict access to X app if the app doesn't have an identity. This also is essential for many other changes as you move from a pre-Zero Trust mindset of "its behind the firewall/perimeter so we don't need to know much about it" to a Zero Trust 'assume compromise' approach where "we have to identify and protect the most important stuff because attackers keep getting past it with phishing and cred theft (and it may not even be on our network)"

This leads to a lot more use of identity:

Another driver of digital identity is the use of sovereign or external identities where organizations find that for some use cases, it is much easier to use an identity the user provides rather than forcing them to get an identity managed by the organization. This avoids the organization having to manage through its lifecycle (which doesn't always happen effectively) and avoids the user having to remember yet another password/etc. (or just reusing an existing password, which increases risk across organizations)

Other Changes

We also made a few additional changes and clarifications since the previous release including:

• Added in certificate and key management as they are identity elements which are often overlooked
• Added application consent management, which is effectively the inverse/complement of application permissions (e.g. what can apps see about users vs. what users can see/do in apps)
• Added consent for personal data use that emerged in the wake of GDPR and other privacy regulations
• Added key integration processes across the organization
• Added operational excellence processes (change/problem/etc. management)

Feedback is welcome

What do you all think of these? Do they cover everything?

The current version of reference model (without these draft changes in it yet) is published at https://publications.opengroup.org/s232

?