Zero Trust - Identity as a Perimeter

“Sometimes, it’s easier living the lie”

If we ever needed to jumpstart the move to “Identity-as-a-Perimeter”, COVID-19 certainly made sure it happened. For more than a year most of the global workforce was forced to work remotely and the enterprise had to find creative ways to deliver IT services to the WFH population. If the typical remote access/VPN solution was designed for a 80/20 split between onsite/remote workforce, the ratio was turned on its head overnight. Organizations that planned for the worst-case scenario coped quickly, while those that did not discovered they had to compromise and enable less secure access to enterprise data, sometimes using personal PCs of users on their home network.

The issue with this new so-called Identity-as-a-perimeter is it becomes so much more critical to protect the identity. The iconic scene towards the end of Catch me if you can causes the character of Leo take a pause as he realizes he’s been taking the easy way out. Sometimes it is easier to ignore that the classic perimeter has died a quiet death. The identity has popped out of the protected network and is the new perimeter.

Nice catchphrase, but what does it mean?

Identity-as-a-perimeter feels somewhat like a misnomer since there is no actual seperation from protected resources provided by identities. That separation is still a function of the network. The identity performs the function of organizing the data/attributes that can be used to govern access to the network. Traditionally, the relevance for security was just the set of credentials of an identity (username+password). Now however, identities are a collection of attributes that include data such as job role, home and work locations, organization unit, status, groups and roles. All of these attributes provide a decision point for the policy enfrocement point (PEP) to allow or prevent access to protected resources. Thus all the identities together form a logical layer around the protected resources. A user cannot be granted access inside this logical layer without first providing the right identity.

The enhanced identity governance approach to developing a ZTA uses the identity of actors as the key component of policy creation. If it were not for subjects requesting access to enterprise resources, there would be no need to create access polices. For this approach, enterprise resource access policies are based on identity and assigned attributes. The primary requirement for resource access is based on the access privileges granted to the given subject. — NIST SP 800-207 3.1.1

The explosion of identities

Note that with the Zero Trust Architecture, for a wholistic approach, every actor that requires access to a protected resource should have an identity. Thus the identity is not just for users, but also third-parties, guests (albeit unauthenticated but not anonymous), and even systems. This ensures access to data can be governed by a standard set of policies that take identities as the input.

%%{init:{"theme":"forest"}}%%
graph LR;
A[Enterprise User]--->|entperprise id|B{ PEP }
C[Third-party user]--->|federated id|B
D[Guest]--->|temporary id|B
E[Server]--->|cert-based id|B
F[API]--->|secret/cert|B
B-->G[(data)]
B -...- H[[PDP]]

And since identity now forms the perimeter in the ZTA, it becomes important to secure the identities for each of these entities. Some example that provide the identity mechanism and protection services are:

• Centralized IDAM for Enterprise Users and Third-party contractors
• B2C User store for external users like customers
• PKI for devices/servers and API (API gateways provide the actual mechanis to protect APIs)
• Key Vault for storing secrets and certificates and providing a mechanism to retrieve these on-demand (vs. hardcoding or storage on local resource)

Eliminating implicit trust and enforcing explicit trust on Identities

Having the identities defined for the entities interacting with protected resources is the first part of ZTA. The next bit is to eliminate any mechanisms operating on implicit trust of an identity and replacing it with an explicit trust mechanism. For example, an implicit trust system may operate something like this:

graph LR;
A[User]-->|authentication|B[Access System]
B-->|implicit trust|D[Network Firewall]
D-->E[Database]

Replacing this with an explicit trust mechanism may look like this:

graph LR;
A[User]--->|authentication|B[Access System]
B-.-|user risk analysis|1[Threat Intel]
B-.-|activity monitoring|2[Activity Logs]
B-->|session control|D[Network Firewall]
D-->E[Database]
B-.-|data access policy|E

In the flow above, the access system is making access decision not just on authentication credentials, but also other identiy attributes such as user risk (eg: using threat intel to detect leaked credentials), activity monitoring (eg: using inputs from UEBA for anomalous behaviour) and data access polciy (as governed by data store). It is using all these decision to direct the firewall for session control. This “continuous evaluation” of the identity eliminates implicit trust and enables explicit trust, which is the goal for ZTA. A comparable flow for privileged access is shown below, incorporating “just-in-time” and “just-enough” access.

graph LR;
A[Admin User]--->|multifactor authentication|B[Access System]
B-.->|jit role provisioning |F[Privileged Access Mgmt]
B--->|monitored session|E[Server]
F-.->E

In conclusion, Identities help provide ZT based access controls when combined with the right set of technologies and solutions. It is by no means the only way to achieve a Zero Trust Architecture, but is essential to protecting data using ZT tenets.

Suggested reading

1. Microsoft Zero Trust Identity Deployment
2. IOTAC: Zero Trust Identity Driven Security
3. Zero Trust and Identity as the New Perimeter: What About Tokens?