I had a discussion with some colleagues are just a bit jaded by the bombardment of sales efforts that appears to be a repackage of existing products and presented as the new panacea to compromised identities. Some comments were, “…it’s the same as trust but verify, just rebranded…” and “… same as RBAC and ‘deny all’ and lease privilege, etc.”

Unfortunately, it seems like all presenters speaking to the merits of ZTA are often sponsored by vendors looking to promote a product that fits into it. To be honest, I wanted to just jump on that band wagon having been jaded by all the sales hype, but then I remembered some presenters explaining why ZTA was coined and in response to the evolution of threats. I had to lay aside confirmation bias and challenge my thinking. What is the difference between ZTA and RBAC and “Deny All” policy?

Zero Trust Architecture (ZTA) and Role-Based Access Control (RBAC) combined with a “Deny All” policy share some similarities, but they are not the same thing. Here’s a breakdown of how they differ:

Zero Trust Architecture (ZTA)

1. Core Principle: Assumes no trust by default, whether inside or outside the network. Trust must be continuously verified.
2. Access Control: Access is granted based on strict identity verification, device health checks, and context (like user location, time of access, etc.).
3. Continuous Monitoring: Constantly monitors and authenticates users and devices, dynamically adjusting access as needed.
4. Layered Defense: Implements multiple security layers, such as encryption, multi-factor authentication, and micro-segmentation.
5. Dynamic Policy Adjustment: Policies and access privileges are adjusted in real-time based on ongoing risk assessments.

Role-Based Access Control (RBAC)

1. Core Principle: Access rights are assigned to roles rather than individuals, simplifying the management of user permissions.
2. Static Roles and Permissions: Once roles are defined and assigned, they typically remain static until manually changed.
3. Less Emphasis on Continuous Verification: Does not inherently include continuous verification of trust once access is granted.
4. Simpler Implementation: Easier to implement and manage in smaller or less complex environments.
5. Limited Context Awareness: Generally lacks the context-aware, dynamic adjustment capabilities found in Zero Trust models.

“Deny All” Policy

1. Basic Rule: Initially blocks all access requests, requiring explicit permission to allow access.
2. Initial Security Stance: Starts from a highly secure stance, but doesn’t specify how trust is established or verified.
3. Lacks Dynamic Adjustment: This approach is static and doesn’t adapt to changing situations or contextual factors.
4. Common in Firewalls and Network Security: Often used in network security to block unauthorized access unless specifically permitted.

Key Differences

• Complexity and Dynamic Nature: ZTA is more complex and dynamic, continuously verifying trust, while RBAC is more static and straightforward.
• Contextual Awareness: ZTA considers the context of access requests, whereas RBAC typically does not.
• “Deny All” is a policy stance that can be part of both ZTA and RBAC but doesn’t define how trust is established or verified.

While there are overlaps, especially in the principle of least privilege and cautious access control, ZTA, RBAC, and “Deny All” policies have distinct characteristics and are used differently within an organization’s security framework.

In response to “trust but verify”, RBAC and default “Deny All” – It appears the key is “continuously.”

The industry is responding to the exponential growth in ransomware attacks. Threat actors living off the land take advantage of the gap that is not “continuously.”

The paradigm associated with RBAC, and “Deny All” concepts were intended to prevent identity compromise. Whereas ZTA starts with the assumption of compromise but intended to quickly detect and contain through continually validating.

ZTA through XDR strategies forces a threat actor, living off the land, to make noise before the ransomware attack comes to fruition.

Almost inversely, service accounts (non-human) have a highly regulated usage pattern.  Deviation from the path is the closest we have to MFA for these identities.

When the most common entry point for ransomware has been through the identity perimeter, it makes sense to adjust strategies to address the identity vulnerabilities.

ZTA is like creating a sea of glass around threat actors, so you hear them go crunch in the night. Conversely, use prescriptive detections to define “normal”. Use this to detect activity when a non-human identity deviates from the path or established patterns to identify indicators of compromise.