Why can a server segment hold an outbound destination allow-list when a user segment never can, and what does that give an intruder?

## What "converging on default deny" actually means At an internet egress border the last rule in the outbound policy is either permit or deny. Flipping that final rule to deny, on its own, changes nothing about what leaves - everything above it decides that. So the programme is never "turn on default deny"; it is "move segments, one at a time, into a state where a written allow-list above the final deny is sufficient for them". Some segments get there. Some never will, and a design that does not say which is dishonest. ## The eligibility test A segment can hold a border destination allow-list when three things are true at once. **Finite.** The destinations the segment must reach can be written down. Finite does not mean small - sixty entries is fine. It means bounded: a licence server, three package mirrors, an identity partner, two vendor telemetry endpoints, a payment gateway. **Knowable in advance.** A new destination arrives because somebody changed something - deployed a service, signed a vendor, moved a mirror - not because a person decided to visit somewhere. That is what makes the list maintainable rather than a permanent chase. **Owned.** Every entry has a person who can be asked why it exists and who answers when it breaks. An unowned entry is one nobody can defend and nobody dares remove; a list of those is how a rule base becomes untouchable. | Segment | Destination set | Owner per entry | Eligible | |---|---|---|---| | Research server VLAN | ~40 named services | Yes, the service team | Yes | | Administrative server VLAN | ~25 named services | Yes | Yes | | Staff and student wireless | the internet | No | No, permanently | ## Why the unit is the population, not the device The laptop in a lab and the laptop on an administrator's desk are the same hardware running the same image. What differs is who drives it and what they are entitled to reach. That is why this policy is written per population segment rather than per device class, and why "we will manage the endpoints better" is not an answer to the eligibility question - it addresses the machine, not the unbounded destination set the human needs. ## What each answer gives an adversary On an allow-listed server segment, an intruder's outbound options are the entries on the list. Anything else dies at the border and leaves a record of the attempt. That is a genuine constraint - it is the whole reason the work is funded - but it is a constraint, not a wall: the permitted entries are usable by anything on that segment, including code that should not be there. On the user segment there is no destination constraint at all. Whatever lands there can reach whatever it wants. The correct thing to write in the design is the sentence people avoid writing: *this population is not filtered by destination, and that risk is carried elsewhere* - by forcing traffic onto an inspected path, by identity, by detection on the endpoint. Naming it is what lets somebody else decide whether that is acceptable. ## What eligibility costs even when you pass it A converged segment is not free. It comes with an exception request path that has to exist for as long as the rule does, a deny log somebody is funded to read, and a standing argument every time a project's destination is not on the list on the day it ships. Those costs are why converging four segments properly beats declaring twelve. ## The failure mode The expensive mistake is attempting an allow-list on a browsing population. The list widens with every request, nobody can refuse a request to reach a legitimate public website, and within a year it contains wildcard entries covering whole hosting providers - which is permit-any with extra steps. You have paid the full price of the control and kept none of its property, and worse, the list's existence gets cited as evidence that the segment is controlled.