/
ABAC Vision: Complexity with "Deny" type permission policies

ABAC Vision: Complexity with "Deny" type permission policies

BLUF (Bottom Line Up Front)

During the stress-testing of our Zero Trust decision chain, we uncovered a flaw in how our linear flowchart handles Effect: Deny policies. Attempting to force an "Explicit Deny" (blacklist) through our single-pass architecture results in a "Blacklist Paradox" that paralyzes the system and locks out authorized users. Consequently, we must either restrict the MVP to positive Allow conditions only, or think about building a multi-stage evaluation engine.

Below is the detailed post-mortem of how we arrived at this conclusion, the explanation of the logic trap, and a proposed architectural blueprint required if we choose to support “Explicit Deny” policies

Decision Chain.jpg

.

Part 1: The Initial Stance (The Need for a Fail-Safe)

Initially, we validated the Policies grant access? -> Denied -> Access Denied path on our flowchart as a critical INFOSEC fail-safe.

  • The Intent: We needed a mechanism for administrators to create surgical "Nuclear Overrides." If a specific threat emerges (e.g., a compromised subnet or an unmanaged device type), Security Operations needs to deploy an Effect: Deny policy that instantly neutralizes the threat.

  • The Assumption: We assumed our single-pass linear flowchart could handle this because if a threat matched the "bad" attributes, the engine would read the Deny effect and route them to Access Denied.

Part 2: The Logical Collapse (The Blacklist Paradox)

The collapse of this assumption occurred when we stress-tested how a safe user interacts with an Explicit Deny policy within our current linear flowchart.

  • The Scenario: InfoSec creates a single Explicit Deny policy: Target: download_file, Effect: Deny, Condition: Device == Unmanaged.

  • The Test Subject: A safe user operating on a Managed device attempts to download a file.

The Fatal Trace (Using our single-pass flowchart):

  1. Existence Check: Are there policies applying to this action? –> YES. (The InfoSec Deny policy exists). Legacy RBAC is now bypassed.

  2. Attribute Match: Do user & session attributes match the policy? –> The engine asks: "Is this user Unmanaged?" The answer is NO. The user is Managed.

  3. The Routing Failure: On our flowchart, the NO path exiting the Attribute Match diamond routes directly to Access Denied.

The Paradox: Because our architecture is built on an Implicit Deny backbone (if you don't match a policy's attributes, you are blocked), running a blacklist policy through it ironically blocks everyone who isn't on the blacklist. The safe user failed to meet the conditions of the blacklist, so the system implicitly denied them. The system bricked itself.

Part 3: The MVP Scope Reduction

To resolve this without expanding timelines, the immediate recommendation was to drop Effect: Deny from the MVP.

  • The Logic: If we force administrators to write Positive Conditions Only (e.g., Effect: Allow, Condition: Device == Managed), our linear flowchart works flawlessly.

  • The Protection: Because we enforce a Strict Intersection (Logical AND) combining algorithm for multiple policies, we don't technically need Explicit Deny to stop overly broad policies. If a junior admin writes "Allow Everyone," it is logically ANDed against InfoSec's "Allow only Managed Devices," resulting in a secure perimeter. Dropping Explicit Deny keeps the MVP mathematically pure and highly performant.

Part 4: Proposal on How to Support Explicit Deny Policies

If we decide that dropping Explicit Deny is unacceptable for our enterprise or DoD customers, we must abandon the single-pass flowchart. We cannot evaluate Allow policies and Deny policies in the same linear step.

To support Explicit Deny without triggering the Blacklist Paradox, and without violating our strict "Denied by Default" mandate, the Policy Decision Point (PDP) must execute a multi-loop engine, evaluating blacklists before whitelists.

Here is the proposed routing in detail:

Phase 0: Jurisdiction & The Fallback Check

  • Question: Are there any Permission or Resource policies (Allow or Deny) applying to this action?

  • If NO: Fall back to the legacy RBAC block.

  • If YES: Enter the ABAC Engine. Legacy RBAC is now permanently bypassed for this request.

Phase 1: The Explicit Deny Loop (The Blacklist)

  • Question: Does the user positively match any Effect: Deny conditions?

  • If YES: Access Denied. (Terminal. The threat is neutralized).

  • If NO: Proceed to Phase 2. (Surviving a blacklist does not grant access; it only means you are not explicitly banned).

Phase 2: The Explicit Allow Loop (The Whitelist)

  • Question: Are there any Effect: Allow policies, AND does the user positively satisfy the Strict Intersection (AND) of all of them?

  • If YES: Access Granted. (Terminal).

  • If NO: Access Denied. (This is the strict Option 1 Implicit Deny. You survived the blacklist, but you failed to meet the positive requirements of the whitelist).

Note: This routing guarantees that if a user fails the Allow loop, they are explicitly denied. They do not fall back to RBAC, preventing role-based loopholes.

Part 5: The Strategic "Why" (Business Case for Explicit Deny)

While the multi-stage engine increases complexity (and possibly backend latency?), there are three reasons Tier-1 defense and enterprise clients might eventually demand it:

  1. The Tactical Kill Switch: In an active cyber incident, a Security Operations Center (SOC) cannot waste time auditing 50 different Allow policies to ensure a compromised IP subnet is excluded from all of them. An Explicit Deny allows them to deploy a single, global rule that instantly supersedes all other logic across the platform.

  2. The "Orphaned Policy" Risk If linear evaluation fails, the easy engineering solution is to drop Effect: Deny entirely and force administrators to only write positive Allow constraints. Because we use a Strict Intersection (AND) algorithm, overlapping Allow policies theoretically tighten the perimeter.
    However, this introduces the Orphaned Policy (Accidental Granter) vulnerability.
    The Disaster Scenario (Using only Allow policies):

    1. HR's Policy: Allow IF Rank >= Major

    2. InfoSec's Policy: Allow IF Device == Managed

    3. Combined State: User must be a Major AND Managed. (Secure).

During a system cleanup, an HR admin accidentally deletes their rank policy. Now, a Private on a Managed Device tries to download a file. The engine checks the only remaining policy (InfoSec's). The Private is on a Managed Device. Access Granted. InfoSec's policy, which was only ever intended to be a hardware constraint, has accidentally become the sole granter of access for the entire organization.

The Explicit Deny Solution: If InfoSec instead writes an Explicit Deny (Deny IF Device == Unmanaged), they create a permanent negative constraint. If HR deletes their Allow policy, the Explicit Deny survives. When the Private on the Managed Device tries to download a file, they survive the Deny check, but because there are no Allow policies left to positively grant them access, they hit the Implicit Deny wall. Explicit Deny policies are essential because they only destroy access; they never build it. They are immune to the Orphaned Policy vulnerability.

  1. Impact Level 6 (IL6) Auditing: It is cognitively simpler for an auditor to verify a single global guardrail ("Deny all access from outside the USA") than to prove the negative by reviewing every individual Allow policy in the database.

Conclusion & Next Steps

We must make a definitive product sequencing decision.

  • Path A (Speed to Market): Drop Explicit Deny. Enforce positive Allow conditions only. Keep the current linear flowchart.

  • Path B (Enterprise Readiness): Scope the Multi-Stage Evaluation Engine into the MVP. It delays launch but delivers true hyperscale policy resolution.