Microsegmentation cut hundreds of real flows: what does it still not remove from an intruder on a valid session?
answer
- ask what the rule is actually deciding
- addresses on one side, accounts on the other
- the account's rights survive the rollout
- count destinations removed, not attacks stopped
basics
~10 sIt removes destinations, not authority. An intruder driving a working, authenticated session keeps every permission that account already held; segmentation only shortens the list of places the account can be used from.
solid answer
~40 sA segment boundary decides which address may open which connection to which address. It has no view of who is driving the session and it never touches what the credential is entitled to do once the packet arrives. So an intruder operating a live, directory-authenticated service-account session inside a payments back-office fabric keeps full rights on every destination the policy still allows, and on those paths the traffic is a permitted flow that looks exactly like the batch job doing its work. What the rollout actually bought is subtraction: the destinations deleted from that origin. It was paid for in legitimate flows severed, exception requests and an outage window. The honest sentence for a review board is `reach from this tier fell from 180 destinations to 9`, never `the intruder was contained`.
go deeper
Be ready to state the split in one line: a boundary changes which destinations are reachable, never what an account is allowed to do. Know that an already-authenticated session crosses an allowed path unchallenged.
Explain why the rule cannot tell the two callers apart, since it matches addresses, ports and direction with no view of who opened the socket, and describe what still reaches what after the cut.
Show you can quantify it: destinations removed per origin, exceptions kept alive, and the legitimate flows broken to get there. Interviewers want the arithmetic, not the slogan.
Own the framing that containment is bought rather than granted. Name who accepted the residual reach, what the severed flows cost the business, and why you stopped cutting where you did.
## The decision a boundary actually makes Every rule a segment boundary holds is some form of *this source may open this kind of connection to this destination*. That is the whole decision. It is made from outside both machines, out of header fields, and it comes out identically whether the process behind the connection is the nightly reconciliation job or an intruder driving that job's own session. ## The two things candidates fuse together - **Reachability** is whether a packet can arrive. - **Authority** is what the destination will do for the account that presents itself once it has arrived. They are enforced by different systems in different places. The boundary enforces the first. The destination application, database or directory enforces the second. A zone or workload-policy rollout changes only the first: nothing in it edits a group membership, shortens a credential's life, or narrows a database grant. The sentence that carries this question is *segmentation subtracts destinations; it does not subtract rights.* ## Why the intruder's traffic is a permitted flow Take a payments back-office fabric with an application tier, a batch tier and a database tier, where every named flow is a service account's real, directory-authenticated session. An intruder operating inside the batch tier with that account's live session opens exactly the connection the policy exists to allow. The boundary matches an allowed source, destination, port and direction and passes it. The database authenticates a credential that is genuine and authorises the rights that account really has. Every layer answers its own question correctly, and the result is an intrusion moving legitimately. This is why an allowance proves so little: | Vantage | What it can decide | What it cannot decide | | --- | --- | --- | | Segment boundary | Whether this address pair, port and direction are permitted | Which process opened the socket, or who is driving it | | Destination service | Whether the presented credential is genuine and entitled | Whether the legitimate owner of that credential is the one using it | ## Containment as arithmetic Because the control only subtracts, the value of the rollout is a count. Before it, an origin in the batch tier could open connections to 180 destinations. After it, 9. The number you bought is 171, and the currency was legitimate flows severed. That framing is what makes the answer defensible in an interview and in a review: it is measurable, it survives scrutiny, and it does not overclaim. The same arithmetic makes the failure mode obvious. If the path the intruder actually used was one of the 9 you kept, the control removed reach they never wanted. That is not a scandal, but it must be said out loud rather than buried under the word *contained*. ## What it cost The price is not the rules. It is: - discovering flows nobody documented, because the estate's real traffic is always wider than its diagram; - the argument with application owners over which real flows die; - an observe-only period, then an outage window, then the tickets from what broke anyway; - the exceptions granted to keep a business flow alive, which are the part of the rollout that survives longest; - a standing review burden, because a policy nobody re-reads drifts back toward permissive. ## What to tell a review board State three things and stop. First, the reach removed, as a count per origin. Second, the exceptions still open and what business flow each one exists for. Third, the explicit negative: an intruder holding a working session keeps the account's full rights on everything still reachable, and this control was never going to change that. A board that hears the negative from you trusts the positive. ## Where the other half of the problem lives Reducing the intruder's authority is real work, but it is entitlement work: fewer rights per destination, per-job accounts instead of one reused batch identity, shorter-lived credentials. It has a different owner and a different budget line. Presenting segmentation as a substitute for it is the classic overclaim, and it is the one an interviewer is listening for.
- If the boundary never touches the credential, what does reduce the intruder's authority?Narrowing the account itself: fewer rights on each destination, per-job identities instead of one reused batch account, shorter-lived credentials. That is entitlement work with a different owner and a different budget, and segmentation is not a substitute for it. Segmentation limits where a credential can be presented; entitlements limit what it can do on arrival. A board answer needs both numbers.
- Your rollout severed forty legitimate flows and the intruder's path was not one of them. Was it wasted?Not necessarily, but say it plainly. The control removed reach on the paths it cut; if the path actually used stayed open as an exception, that engagement was not contained by this control. Report the destinations removed from other origins as the value, the forty flows as the cost, and use the miss as the concrete argument for the exception you were refused.
- Why does an allowed flow between two tiers prove nothing about who opened it?The rule matches an address pair, a port and a direction. Anything on the source host that can reach the socket satisfies it, including a process an intruder is driving with the service account's own session. The allowance means the connection is permitted, not that the legitimate job made it.
Changing the locks on nine of the ten doors does not demote the person holding a valid staff badge. It just means there are fewer rooms where the badge still works.
saying these in an interview costs you the question
- Says segmentation contains an intruder holding valid credentials
- Treats zone rules as a limit on what an account may do
- Reports containment without naming the flows severed to buy it
- Assumes a permitted flow proves a legitimate caller
- Claims lateral movement is impossible after a rollout