Build a Zero Trust deployment backlog using Invariant

Use Invariant deny-others rules with enforce: false to identify permitted traffic flows into or out of a network segment that do not match your minimum access requirements. The resulting policy_violations_unenforced report serves as a backlog of flows that need to be explicitly allowed in your Zero Trust policy or blocked by network configuration.

SSH Access: To our knowledge, only certain hosts should be permitted to access SSH in the DATACENTER network (172.16.50.0/24).

Create a policy file with a strict deny-others rule set to enforce: false. Scope it (within) to the traffic you want to control (here, SSH).

invariant/policies/zero_trust_backlog.yaml
access-policy:
  - name: zero-trust-datacenter-backlog
    comment: Identify all TCP/UDP ingress flows to Datacenter for Zero Trust policy
    owner: security-[email protected]
    enforce: false              # <--- This makes this policy unenforced
    ingress-network: DATACENTER
    rules:
      - type: ingress-deny-others
        comment: Identify all internal SSH traffic which can reach the Datacenter
        within:
          - protocol: tcp
            destination-port: SSH
        deny-all-except:
          flows:
            - comment: Known business requirement
              source-address: MGMT_SERVER
              destination-port: SSH
              protocol: tcp

def/networks.yaml
networks:
  DATACENTER:
    values:
      - address: 172.16.50.0/24
  MGMT_SERVER:
    values:
      - address: 192.168.50.10/32

Run Invariant Analysis:

invariant run --target /path/to/your/snapshot/

4. Generate the Backlog: Use invariant show to view the policy_violations_unenforced report. This lists all traffic flows permitted by your current network configuration that are not explicitly allowed in your deny-all-except list. This is your Zero Trust backlog.

# View the backlog report as JSON
invariant show policy_violations_unenforced --json

# View the backlog as TSV
invariant show policy_violations_unenforced --tsv

Understanding the `policy_violations_unenforced` Report (Your Zero Trust Backlog)

When using an ingress-deny-others or egress-deny-others rule with enforce: false, the policy_violations_unenforced report acts as a discovery tool. It does not indicate network errors or failures. Instead, it meticulously lists every specific traffic flow that your current network configuration allows into (for ingress) or out of (for egress) the target network (ingress-network or egress-network), but which is not explicitly permitted within the deny-all-except.flows section of your unenforced rule.

Think of it as Invariant saying, "Based on your network's current state (routing, ACLs, etc.), these flows can happen. You haven't explicitly allowed them in your Zero Trust rule yet. Do you want to?"

Each item in this report represents one such flow, providing the details needed to decide whether to formally allow it in your policy or block it in your network configuration.

policy_violations_unenforced.json
[
  {
    "index": 0,
    "ok": false,
    // ok: false means Invariant found a flow that can reach the DATACENTER network
    // that is not permitted in `deny-all-except`.
    // This is exactly what we want for backlog generation.
    "skipped": false,
    "enforce": false,  // Invariant won't generate alerts or mark the snapshot as failing
    // Sections policy, rule, and resolved_as re-iterate your rule specification
    "policy": {
      "name": "zero-trust-datacenter-backlog",
      "comment": "Identify all TCP/UDP ingress flows to Datacenter for Zero Trust policy",
      "owner": "[email protected]",
      "ingress-network": {
        "list": [
          "DATACENTER"
        ],
        "object": null
      }
    },
    "rule": {
      "type": "ingress-deny-others",
      "comment": "Identify all internal SSH traffic which can reach the Datacenter",
      "within": [
        {
          "protocol": ["tcp"],
          "destination-port": ["SSH"]
        }
      ],
      "deny-all-except": {
        "flows": [
          {
            "comment": "Known business requirement",
            "source-address": ["MGMT_SERVER"],
            "destination-port": ["SSH"],
            "protocol": ["tcp"]
          }
        ]
      }
    },
    // This shows how Invariant interpreted the rule's addresses/port names
    "resolved_as": [
      {
        "destination_address": [
          "172.16.50.0/24"
        ],
        "destination_port": [
          "tcp/22"
        ],
        "protocol": [
          "tcp"
        ],
        "source_address": [
          "192.168.10.98/32"
        ]
      }
    ],
    "within_resolved_as": [
       {
        "destination_address": null,
        "destination_port": [
          "tcp/22"
        ],
        "protocol": [
          "tcp"
        ],
        "source_address": [ 
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16"
        ]
       }
    ],
    "violations": 1, // How many unique issues were found
    "checks": 5,     // How many searches were performed behind the scenes by the tool
    "flow_str": "tcp src_ip=192.168.10.98 dst_ip=172.16.50.1 dst_port=22",
    // flow_str is the violation flow:
    // - Protocol: tcp
    // - Source IP: 192.168.10.98 (ALICE_DESKTOP in this example)
    // - Destination IP: 172.16.50.1 (part of DATACENTER)
    // - Destination Port: 22 (SSH)
    "start": "@enter(dist-1[Vlan10])",
    // "start" specifies where the violation flow originates in the model
    // - Device: dist-1
    // - Interface: Vlan10
    // - @enter(...): this is traffic entering dist-1 through interface Vlan10
    "traces": [
      // A detailed array of hops showing how the packet traverses the network,
      // including routing decisions and ACL evaluations at each step.
      {
        "disposition": "ACCEPTED", // Indicates this trace was successfully delivered
        "hops": [
           // Virtual traceroute details
        ],
      }
    ]
  }
]

Tips:

Focus on flow_str: This traffic flow is currently possible but not allowed by your deny-all-except.flows list. In our example, it's SSH from 192.168.10.98 (Alice's Desktop) to 172.16.50.1 in the Datacenter.
Understand the path with traces: The traces section shows a path the packet could take and which ACLs and which routes facilitated it. This helps you understand why this flow is allowed by your current network configuration. For example, an ACL on a router might have a permissive rule allowing this specific SSH connection, or maybe there's no ACL blocking it at all along a path you did expect.
Understand start: This indicates the entry point of the flow into the network model, helping you contextualize its origin.

Workflow: For every flow (flow_str) identified in this report, work with your team to determine if it represents a real business requirement or it can be closed.

If required: Update the the deny-all-except.flows list and re-run the analysis tool.

If not required: Remediate the issue in your network configuration.

Iterative Process: Once the report is empty, you can change enforce: false to enforce: true to activate your Zero Trust policy segment.

Important

Invariant finds examples of flows not allowed by your rules. Resolving one finding may reveal additional violations not initially included in the violation search.

Understanding the policy_violations_unenforced Report (Your Zero Trust Backlog)​

Understanding the `policy_violations_unenforced` Report (Your Zero Trust Backlog)