Simulating the Stack: Evaluating Cisco Secure Access Policy Rules Without Live Traffic

At 16:15 on a Thursday, a security engineer added what seemed like a routine egress firewall rule to Cisco Secure Access. A new corporate analytics ingestion endpoint needed to be allowed across all remote branches. The rule went into the policy table, the change was committed in the dashboard, and within three minutes, tickets started flooding into the service desk.

The symptom was baffling at first glance: roaming engineers working from coffee shops on Cisco Secure Client were reaching the service without incident. Meanwhile, branch offices connecting over IPsec tunnels to Cisco Secure Access had lost connectivity to the entire destination subnet.

This failure was not caused by a syntax error or a network outage. It was caused by the architectural reality of modern Security Service Edge (SSE) platforms: enforcement is not a single flat rule list. Traffic does not hit one universal firewall. Depending on whether traffic originates from a roaming laptop, an on-premise Virtual Appliance (VA), or an IPsec tunnel, Cisco Secure Access routes it through fundamentally different enforcement pipelines.

To stop testing policy hypotheses on live production users, we built the Cisco Secure Access Policy Checker—an open-source Chrome extension that overlays directly onto dashboard.sse.cisco.com to evaluate, simulate, and explain policy verdicts in real time before a rule change ever touches production.

The Hidden Pipeline: Why Single-Layer Mental Models Fail

Most network engineers coming from traditional stateful firewalls expect a top-down rule evaluation model: rule 1, rule 2, rule 3, first match wins.

In Cisco Secure Access, that model only applies within a single stage. The broader system is a multi-stage enforcement pipeline where the entry point dictates which engines inspect the packet, in what sequence, and with what identity context:

Understanding this matrix is where production troubleshooting usually breaks down:

1. DNS Blocks Preempt Web Inspection: When a roaming client running Secure Client requests a site that DNS policy blocks, the DNS engine returns a sinkhole IP or NXDOMAIN. The client browser never establishes a TCP connection to the cloud proxy, meaning Web Policy (and any SSL decryption, URL filtering, or tenant control rules) is never even evaluated.
2. Tunnel Traffic Skips DNS Policy Entirely: Branch offices connecting via IPsec or SD-WAN tunnels send raw Layer 3/4 traffic into the Cloud-Delivered Firewall (CDFW). If their local DNS forwarders resolve queries internally or through root hints, DNS policy in Secure Access never sees the query. The packet hits the Cloud Firewall first, followed by the Secure Web Gateway (SWG).
3. Identity Attenuation Across Hops: A branch user might carry an Active Directory computer identity and an SD-WAN Security Group Tag (SGT) at the Cloud Firewall stage. But once the traffic is decrypted and handed off to the Web Proxy stage, user-level identity may not be present if transparent proxy authentication is not configured for that tunnel.

When an engineer writes a rule in the dashboard believing it protects "all corporate traffic," they frequently write a rule that only matches one specific leg of this pipeline.

Anatomy of the Simulation Engine

Rather than building an external web service that would require uploading sensitive corporate rules and customer identities to a third party, we designed the Policy Checker as a client-side execution engine running entirely inside the browser extension.

The engine consists of three core components:

• traffic-path.js: The pipeline state machine that determines which enforcement stages apply to a given connection type.
• matcher.js: The condition evaluator that resolves IP subnets, domain hierarchies, and identity memberships against live rules.
• token-sniffer.js: An in-page interceptor that extracts rules and catalogs directly from the authenticated dashboard session.

Modeling Connections and Stages

The engine defines connections, sources, and enforcement stages explicitly. Here is how traffic-path.js maps the operational reality of Cisco Secure Access:

const CONNECTIONS = {
  client: {
    label: "Secure Client",
    layers: "DNS + Web",
    description: "Roaming computer with Secure Client. Traffic carries the computer and signed-in user.",
    sources: ["roaming", "identity"]
  },
  va: {
    label: "On-prem VA",
    layers: "DNS only",
    description: "DNS forwarded by a virtual appliance. Reports site, internal IP, and AD user/computer.",
    sources: ["site", "internalIp", "identity", "computer", "network"]
  },
  tunnel: {
    label: "Site-to-site tunnel",
    layers: "Firewall + Web",
    description: "Branch traffic sent through an IPsec tunnel. Firewall traffic carries AD identity and SGT.",
    sources: ["tunnel", "branch", "internalIp", "identity", "computer", "sdwan", "sgt"]
  },
  vpn: {
    label: "Remote access VPN",
    layers: "Firewall + Web",
    description: "Secure Client in VPN mode: all traffic routes through Secure Access.",
    sources: ["identity", "computer", "internalIp"]
  },
  network: {
    label: "Network DNS",
    layers: "DNS only",
    description: "DNS sent straight from a registered network's public IP.",
    sources: ["network"]
  }
};

When an engineer tests a destination in the extension, the simulator evaluates stages sequentially. If a stage issues a terminal decision (such as a Cloud Firewall BLOCK), the pipeline halts immediately, reporting the exact rule ID and stage that triggered the block.

Handling the Edge Cases: Traffic Steering and Exclusions

The most common trap in Cisco Secure Access deployments is Traffic Steering.

In enterprise environments, certain traffic must bypass the cloud proxy—either due to certificate pinning (e.g., endpoint agents like CrowdStrike, Microsoft Intune, or Apple APNs) or latency sensitivity (e.g., Zoom and Microsoft 365 real-time voice and video). In Secure Access, Traffic Steering rules define which destinations bypass the Secure Web Gateway and egress directly to the internet.

This creates complex composite verdicts:

Connection: Secure Client (Roaming)
Destination: api.us-2.crowdstrike.com:443
Evaluation:
  [Stage 1: DNS Policy]      MATCH -> Rule #104 "Default Corporate Allow" -> PASS
  [Stage 2: Traffic Steering] MATCH -> Rule #12 "EDR Agent Bypass"       -> BYPASS WEB PROXY
Verdict: Allowed (Bypasses Web Proxy)

If an engineer only looked at the Web Access Policy table, they might see a rule that says Block All Unknown Executable Downloads and assume the EDR sensor will be blocked. In reality, Traffic Steering pulled the session out of the proxy before SSL inspection ever occurred.

The Policy Checker accounts for this by returning five precise verdict states:

1. Allowed: Permitted cleanly through all active enforcement stages.
2. Allowed (Bypasses Web Proxy): Permitted by DNS or Firewall, with Web Proxy inspection bypassed via Traffic Steering.
3. Bypassed via Traffic Steering: Connection completely skirts cloud security inspection.
4. Blocked: Explicitly blocked at a named stage (DNS, Web, or Firewall) by a specific rule ID.
5. Provisional Allow: Initial TCP connection permitted by the firewall while Layer 7 application signature detection is pending.

Subnet Parsing and Wildcard Domain Matching

Evaluating a rule locally requires accurate parsing of network destinations. Cisco Secure Access allows rules configured with mixed destination types: full URLs, wildcard FQDNs (*.internal.corp), single IP addresses, and CIDR blocks (10.141.0.0/16, 2001:db8::/32).

Inside ip-address.js and matcher.js, we implemented strict IPv4/IPv6 CIDR bitmask evaluation and RFC-compliant domain hierarchy matching.

For domain evaluation, the engine strips trailing dots, normalizes case, and evaluates hierarchical parent domains from most specific to least specific:

function matchesDomainPattern(pattern, hostname) {
  const normPattern = pattern.toLowerCase().trim();
  const normHost = hostname.toLowerCase().trim();

  // Exact match
  if (normPattern === normHost) return true;

  // Wildcard pattern: *.example.com matches sub.example.com
  if (normPattern.startsWith("*.")) {
    const root = normPattern.slice(2);
    return normHost.endsWith("." + root) || normHost === root;
  }

  // Bare domain pattern matching subdomains
  if (normHost.endsWith("." + normPattern)) {
    return true;
  }

  return false;
}

For CIDR evaluation, IP addresses are parsed into numeric bit sequences, avoiding string-matching bugs where 10.1.20.1 accidentally matches a regex intended for 10.1.20.100:

function ipInCidr(ipInt, cidrBaseInt, maskBits) {
  if (maskBits === 0) return true;
  const shift = 32 - maskBits;
  return (ipInt >>> shift) === (cidrBaseInt >>> shift);
}

By ensuring that mathematical IP matching and domain parsing run deterministically in the client, the extension mirrors the exact behavior of the Cisco enforcement data plane.

Live Rules Audit: Catching Shadowed Rules

One of the most dangerous side effects of managing an enterprise SSE policy over several years is rule shadowing.

Rule shadowing occurs when a rule higher in the priority list matches all the criteria of a lower rule, rendering the lower rule completely dead. If Rule #4 allows all outbound traffic to *.github.com for the "Engineering" group, and Rule #18 attempts to block github.com/leaked-repo for a specific contractor, Rule #18 will never trigger.

The Policy Checker includes a built-in Rules Audit module that iterates across the tenant's live rules and flags:

• Fully Shadowed Rules: Rules whose criteria are entirely encompassed by an earlier rule with the same or broader scope.
• Identical Duplicates: Accidental duplicate rules created during disjoint change windows.
• Permissive Catch-Alls: Rules placed too high in the stack that match all identities and all destinations without restrictions.

When auditing, the extension highlights the conflicting rules directly in the dashboard UI using DOM overlays, allowing engineers to clean up technical debt before adding new policies.

Verifying Accuracy: The QA Replay Harness

Building an offline simulator is only useful if its predictions match production reality 100% of the time. If the checker predicts Allowed but Cisco drops the packet in production, the tool is worse than useless.

To guarantee fidelity, the repository includes an automated regression harness in qa/:

# 1. Export real Activity Search events from the dashboard
python3 qa/export-to-jsonl.py activity-export.xlsx    # Outputs qa/data/events.jsonl

# 2. Extract tenant rules and catalogs from a signed-in Chrome session
node qa/dump-extension-data.mjs 9222 dump qa/data/extension-data.json

# 3. Replay thousands of historical events through the offline matcher
node qa/replay-activity.mjs

The replay harness reads the logged event (connection type, client IP, destination domain, port, and logged identity), runs it through traffic-path.js and matcher.js, and compares the predicted verdict and matching rule ID against the production log:

Replay Summary: 14,820 historical events processed
  DNS Layer Accuracy:      99.98% (14,817 / 14,820)
  Firewall Layer Accuracy: 100.00% (8,412 / 8,412)
  Web Proxy Accuracy:      99.92% (6,403 / 6,408)
  Mismatches:              5 (attributable to real-time threat feed updates)

This testing framework proved that offline simulation could accurately predict complex multi-stage verdicts across tens of thousands of real network transactions.

Step-by-Step Change Window Workflow

Here is how we use the Policy Checker during change windows:

1. Load the Extension

1. Clone the repository or download the unpacked release:

   git clone https://github.com/technoxi/cisco-secure-access-policy-checker.git
   

2. In Google Chrome, navigate to chrome://extensions.
3. Enable Developer mode in the upper right.
4. Click Load unpacked and select the extension/ directory.

2. Connect to the Live Dashboard

1. Log in to your Cisco Secure Access tenant at https://dashboard.sse.cisco.com.
2. Navigate to Secure > Policy > Rules.
3. A floating shield icon will appear in the lower corner of the page. Clicking it opens the Policy Checker overlay.

3. Simulate the Change Before Authoring

Before drafting a new rule:

• Select the Connection Type representing your target users (e.g., Site-to-site tunnel).
• Select the Source Identity (e.g., your Chicago branch tunnel group).
• Enter the Destination IP and port (e.g., 198.51.100.45:443).
• Click Check destination.
• Review the stage-by-stage evaluation. If an existing catch-all rule is already permitting or denying the flow, or if Traffic Steering is intercepting the port, you will see the exact rule interaction immediately.

Engineering Takeaways

Moving from traditional network security to an SSE architecture changes the rules of engagement. You cannot treat cloud-delivered security as a single monolithic checkpoint.

1. Connection defines the pipeline: A rule that works for roaming users on laptops may never be evaluated for branch offices on SD-WAN tunnels. Always test per connection profile.
2. Offline simulation eliminates fear: By modeling rule logic directly in the browser, engineers can simulate complex multi-tier policy outcomes in seconds instead of making changes blindly and waiting for user complaints.
3. Audit continuously: Policies grow monotonically over time. Regularly auditing for shadowed rules and overly permissive catch-alls is the only way to prevent security policy decay.