skip to content

After a segmentation rollout, how far can an intruder on a valid session still reach, counting every exception you left open?

level: seniorimportance: should knowfreq 41%

answer

  1. it is a set you can enumerate
  2. the first ring is not the answer
  3. count the entries nobody calls a flow
  4. reach times rights, and rights did not move
  5. policy read is intent, not enforcement

basics

~20 s

Compute it as a closure, not a feeling. From the compromised origin list every allow entry still matching it, exceptions included, then repeat from each destination reached. The answer is that set times the account's rights.

solid answer

~40 s

Treat it as arithmetic. Take the origin the intruder holds, enumerate every policy entry whose source still matches it, including the exceptions granted at cutover to keep the nightly batch alive, the broad within-tier allows, and the management, backup and monitoring paths that were never in anyone's diagram. That gives hop one. Each destination reached is then a new origin with its own allow list, so you repeat until the set stops growing, and the honest answer is the closure rather than the first ring. Then overlay authority: what that service account may actually do on each destination, since the boundary changed none of it. Publish the result as a written statement of what still reaches what, naming each exception's owner, and mark it as policy-derived, because rules state intent rather than enforcement.

go deeper

for a junior

Understand that after a rollout some destinations are still reachable on purpose, and that the list of those exceptions is a real document rather than an embarrassment to hide.

for a middle

Be able to walk the enumeration: matching entries from the origin, then the destinations those reach, until the set stops growing, including the paths that exist for management and backup.

for a senior

Demonstrate the closure plus the authority overlay, and volunteer the limit that a policy-derived statement is intent rather than proven enforcement.

for a principal

Own the artefact and its lifecycle: who maintains the reach statement, when exceptions expire, and how the next incident review diffs against it instead of starting again.

## Why the question is arithmetic and not judgement *How far could they have gone* is answerable, and a review board is entitled to a number. The number exists because the control is subtractive: the intruder's authority is fixed by the account, and the only variable your project changed is the destination set. So the residual reach is a set you can enumerate, and its size is the honest measure of what the rollout did and did not buy. ## Step one: the first ring Start from the origin the intruder holds, a host in the batch tier of a payments back-office fabric. List every policy entry whose source still matches that host. The entries people remember are the named application flows. The ones that dominate the answer are usually the ones nobody thinks of as flows at all: - **The rollout exception.** The one kept because severing it would have stopped nightly reconciliation. These are typically the widest entries in the whole policy, because they were written under time pressure to make something work. - **Broad within-tier allows.** *Anything in this tier may talk to anything else in this tier* is a single line that can contribute hundreds of destinations. - **Management, backup and monitoring paths.** Almost always allowed from everywhere to everywhere, almost never counted, and frequently the widest reach in the estate. - **Bidirectional rules.** A rule written to let a destination call back adds an origin you did not intend to grant. ## Step two: the closure Each destination reached is a new origin. If the intruder's session, or another credential recoverable from where they now stand, lets them work from that machine, its allow list applies too. Stop when the set stops growing. Reporting only the first ring is the most common way this answer goes wrong, and it always understates. ## Step three: overlay authority Reach is only half of it. For each destination in the closure, state what the service account may actually do there: read a schema, write a table, execute a job, administer the instance. This is where the leaf's core point lands. Segmentation subtracted destinations and left the rights untouched, so the reach set multiplied by the account's entitlements is the real answer to *how far*, and the second factor is not yours to change. ## Step four: say what kind of claim this is A reach statement derived from reading policy is a statement of intent. It assumes the device is in the path, the agent is installed, the rule is in the version actually loaded, and no alternative route exists. Establishing that a boundary genuinely denies is a separate exercise with its own method, and until it has been done the statement should be labelled as derived from policy. Saying that unprompted is what separates a senior answer from a confident one. ## The artefact The output is not a slide. It is a written statement of what still reaches what: per origin, the destinations still reachable, the entry that permits each one, the business flow it exists for, the owner who accepted it, and an expiry where one applies. It is the thing that lets next year's version of this question be answered by diffing rather than by re-deriving, and it is the document the board actually wants when it asks how far the intruder could have gone. ## What good sounds like *From the batch tier, reach fell from 180 destinations to 9. Six of the 9 are the reconciliation exception to the database tier, which the payments owner accepted in writing and which expires at the next release. Two are the backup path, allowed estate-wide. Through those 9 the closure reaches a further 14. On every one of the 23, an intruder holding this account's session has the rights the account has, because nothing in this project changed that. This is derived from policy; we have not yet tested the denials.*

  • Why is reading the policy not enough to state residual reach?
    Because policy is intent. The device may not be in the path for that pair, the agent may not be installed on the destination, the loaded version may differ from the reviewed one, and an unmapped route may bypass the enforcement point entirely. All of those turn an intended deny into a real allow. Label the statement as policy-derived until denial has actually been established, which is its own exercise.
  • Which entries usually dominate the residual set?
    The long-lived ones kept to save a business flow, plus the paths nobody classifies as flows: a batch window opened to a whole database tier, a backup or management path allowed estate-wide, a monitoring poller permitted to every host. Each is one line in the diff and hundreds of destinations in the closure, which is why the count has to be computed rather than eyeballed.
  • The board asks for one number. What do you give them?
    Destinations reachable from the compromised origin, closure included, before and after. Then immediately qualify it: the account's rights on each of those destinations are unchanged, and a named share of the remaining reach comes from exceptions that specific owners accepted. One number with two qualifications is defensible; one number alone will be quoted back at you after the next incident.

saying these in an interview costs you the question

  • Reports the first ring and calls it the residual reach
  • Omits backup, management and monitoring paths from the count
  • Presents a policy-derived statement as proven denial
  • Assumes exceptions granted at cutover have expired
  • States reach without stating the account's rights on those destinations

context

resolving links…