What does approving one microsegmentation allow rule prove about what an intruder on that workload reaches?
answer
- one edge, not the whole graph
- allows compose, approvals do not
- membership decides who a rule covers
- intruder gets your reach plus the next hop's
- aggregate permission no rule states
basics
~20 sAlmost nothing. It proves one named source group may reach one destination on those ports. What an intruder reaches is the union of every allow covering that workload's groups, then the same from each host it lands on.
solid answer
~50 sAn allow rule is a permission, not a description. Approving it tells you that source group may now reach destination group on those ports, and nothing about the rest of the estate: not who else already reaches that destination, not what else the source may reach, and not what the destination reaches next. In a hypervisor-enforced policy the rules are written against groups and compiled per virtual NIC, so a workload's reach is the union of every allow whose source group it belongs to, resolved through current group membership. An intruder who lands on it inherits that union, then the next hop's union. Nobody approved that composition, because nobody was ever shown it. Computing it needs a membership snapshot plus the whole rule set, on every change, and that computation is real engineering time somebody has to fund and own.
go deeper
Be ready to say plainly what one allow rule proves: a single permitted source-to-destination relation, nothing more. Do not claim it tells you what else the workload can reach.
Explain the mechanics: policy written against groups, compiled per virtual NIC, and a workload's reach being the union over every rule whose source group contains it, resolved through current membership.
Show that you would give reviewers a reachability delta rather than a rule diff, and that you can name the cost of producing it - a membership snapshot and a recomputation on every change.
Own the consequence: auditability is a ceiling on granularity. Be ready to argue where that ceiling sits for your estate and what you would give back to stay under it.
## What the reviewer is actually handed In a hypervisor-enforced microsegmentation deployment, policy is written once against *groups* of workloads (a tier, an application, an environment, a compliance scope) and compiled by the platform into a filter set attached to each individual virtual NIC. Enforcement happens outside the guest, so nothing inside the virtual machine can see, disable or bypass it. That is the property people buy the approach for, and it is genuine. What arrives on the change reviewer's desk is a **diff**: one or two added lines, a source group, a destination group, a protocol and a port range, plus a justification and a ticket number. The reviewer reads it, cannot fault it, and signs. ## A rule is a permission, not a description Getting the direction of the claim right is the whole question. An allow rule **asserts** that one relation is permitted. It does not describe anything: - it does not say the destination is reachable *only* from that source; - it does not say what else the source may reach; - it does not say what the destination may reach next; - it does not say which actual machines are in either group right now. So an approval is evidence about one edge, and reachability is a property of the whole graph. ## Reachability is a composition, not a lookup For a workload W, the set of destinations W may reach is the union, over every allow rule whose source group contains W, of the current membership of that rule's destination group. An adversary with code execution on W does not stop there: they get that union, and then from each host they reach, that host's union in turn. The permitted set an intruder actually enjoys is the transitive closure, and no line of the rule base states it. | What the reviewer sees | What actually decides reach | | --- | --- | | one added allow: source group to destination group, ports | every allow naming any group this workload belongs to | | the author's justification and ticket | the current membership of both groups, set in another system | | rule count before and after the change | the next hop onward from every destination reached | ## The blind spot is the security property The intruder does not need a wrong rule. Take an insurer's virtualised estate: an internet-facing claims-intake workload is compromised through the application it runs. The route from there to the actuarial data store is three separately approved allows plus one long-standing intra-tier rule that lets members of a group talk to each other on any port. Every one of the four was approved by a competent reviewer who was shown a defensible single change. Shown the path end to end, none of them would have signed it. The path lives in the blind spot precisely because it is a composition, and a composition nobody computes is a composition nobody removes. This is why "finer is safer" stops being true at some grain. Past the point where a person can state what the set permits in aggregate, each extra rule buys a narrow deny and costs a little more of the only faculty that finds paths like that one. ## What holding the control costs Two bills, and an honest answer names them. 1. **Computation.** To answer "what can this reach" you need the rule set, a current membership snapshot, and any address translation on the path, and you need to recompute after every change - including changes that touch no rule at all. That is a service somebody builds, runs and owns. 2. **The reviewer's artefact.** If review is to mean anything, the reviewer must be shown the *reachability delta* the change produces rather than the rule delta. Producing that is the same computation, rendered for a human, and it is the difference between a review and a signature. ## What a strong answer offers instead - State a short list of invariants - pairs that must never be reachable - and test the policy against them continuously. - Make "what can this workload reach right now" a query anyone can run in minutes. - Show reviewers the reachability delta, not the rule diff. - Track how long it takes to answer that query, because when it grows past hours the policy has passed the grain the organisation can hold. ## What weak answers say "The rule set is the policy, so read it." "It is deny by default, so we are fine." "Every change was reviewed, so the state is reviewed." All three treat an approval history as knowledge of a permitted set, and it is not.
- The policy is deny by default. Doesn't that bound how bad an over-permissive set can get?It bounds the shape, not the size. Deny by default only means nothing is permitted unless some rule names it - and with tens of thousands of compiled rules, the set some rule names is large and has never been enumerated. The default tells you how a gap fails, not how big the permitted set is.
- How would you actually answer 'what can this virtual machine reach right now'?Compute it: take the workload's current group membership, collect every allow rule whose source group it belongs to, resolve the destination groups back to real workloads, and render the pairs. Then repeat one hop out to get the intruder's view. The point of the exercise is that it is a computation, not a read of the rule base.
- Why is an intra-group 'allow any' rule so much worse than it looks in a diff?It makes group membership the entire control. Everything in that group is mutually reachable on every port, so one compromised or mis-placed member sits in a flat network with the rest. The policy still reads as microsegmentation while behaving, inside that group, exactly like the flat estate it replaced.
Signing one visitor pass tells you that this person may enter that room. It tells you nothing about which rooms a stranger who is already inside the building can walk through.
saying these in an interview costs you the question
- Says the rule set is the policy, so reading it gives you reachability
- Assumes deny-by-default means the permitted set must be small
- Treats an approved change history as a known permission state
- Ignores group membership when reasoning about what a rule covers
- Thinks reachability is per-rule rather than a composition across rules