A red team crossed your 40,000-rule microsegmentation policy using only approved allows - how do you recover a set you can state?

## Why the obvious moves fail The red team's path was assembled from allows that were each defensible when approved. That kills three instincts at once: - **Read the rule base.** Nobody reads 40,000 compiled rules, and if they did, the defect is not in any line - it is in the composition. - **Hire more reviewers.** A second reviewer looking at the same diff reaches the same conclusion, because the diff genuinely is fine. You would buy throughput, not assurance. - **Tighten the review standard.** There is no standard that rejects a correct single change on the grounds that the whole is unknowable. The defect is that the organisation has no statement of what the set permits, and the only way out is to produce something statable. ## Step 1: invariants before rules Write down what must never be reachable. Not what should be allowed - the allow side is unbounded and is what produced 40,000 rules in the first place. The deny side is small and human-sized: - the internet-facing claims-intake tier must never reach the actuarial data store on any port; - nothing outside a named administrative group may reach the policy administration plane; - workloads in the vendor-supported appliance group may originate only to their two named update destinations; - the pre-production environment must never reach production storage. Tens of lines, readable in one sitting, arguable by a business owner. **That list is the policy.** The compiled rules are an implementation of it, and implementations may be unreadable if the specification is testable. The list has to stay small deliberately. When someone proposes the two-hundredth invariant, the honest answer is usually that the boundary model is wrong, not that the list needs another line. ## Step 2: compute effective reachability Build the thing nobody has: a function from (rule text, current group membership, any address translation on the path) to the set of permitted pairs, with a transitive view of one or two hops so you see what an intruder inherits rather than what an application needs. It does not need to be elaborate. It needs to be **fast enough to run on every change** and **honest about its inputs** - a reachability answer computed against last month's membership snapshot is worse than no answer, because it is trusted. Run the invariants against it continuously, and fail the change that breaks one. That converts an unreadable rule set into a set with a testable specification, which is a very different security posture even though not one rule was deleted. ## Step 3: change the reviewer's artefact The reviewer should be shown: *this change lets 412 workloads reach the payments tier on tcp/8443, up from 6, and does not break any invariant*. That is a review. `+ allow tier=app -> tier=pay tcp/8443` is a signature. Same underlying computation, rendered for a human, and it is the single highest-value thing you can build here. ## Step 4: coarsen, deliberately and second Only now consider giving grain back. Wherever a distinction in the rules does not correspond to a distinction in trust - eleven groups for one application's tiers that all trust each other anyway - collapse it. Coarsening is not automatically a regression: a policy at a grain the organisation can state beats a finer one it cannot, because the finer one hides paths. But do it after the invariants exist, so you can prove the collapse did not break one. ## Proving the boundary denies When the auditor, or your own risk owner, asks for evidence, a rule export is not evidence. Two things are: 1. **Negative tests.** A scheduled attempt from inside each source group toward each invariant destination, with a result history. It exercises the compiled policy, current membership and the path together, which is the only combination that matters. 2. **The invariant test record** on every change, showing that every change since the last audit was evaluated against the stated deny set. Hypervisor-side flow records showing the drop corroborate this. The rule that names the deny does not, because a rule above it, a membership change or a translation on the path can all make it irrelevant. ## What it costs, plainly - A standing owner and engineering time for the reachability computation - not a project, a service. - A membership snapshot pipeline, because the computation is worthless without it. - Real isolation handed back wherever you coarsen, which a risk owner has to accept rather than an engineer decide. - A consolidation window during which policy change slows, which needs a business owner's consent before you start rather than an apology afterwards. ## What a weak answer sounds like "We will audit the rule base and remove what is unused." That is a different problem with a different owner, it does not address a path made of *used* rules, and it will consume the year.