skip to content

Budget funds interior sensors on one segment in five: how do you choose, and what do you tell an auditor about the segments an intruder could cross unseen?

level: principalimportance: nice to knowfreq 26%

answer

  1. the deliverable is the gap, not the plan
  2. rank by consequence, not by bytes
  3. three tiers beat a yes or no
  4. new segments are unsensed by default
  5. the risk owner signs, not security

basics

~20 s

Choose by what a compromise there would cost and by whether any other record would exist, not by traffic volume. Then publish a dated per-segment list stating what is sensed, at what depth, and where no record would exist at all — and have the risk owner accept it, not the security team.

solid answer

~50 s

The deliverable is not a sizing plan, it is a defensible statement of negative coverage. I would rank segments by what an intruder operating only inside them could reach, whether they carry management or credential paths, and whether some other record source would exist if network sensing does not — then fund sensors where the marginal evidence is highest, tier the middle band down to header-level records, and mark the rest explicitly unsensed. What goes to the auditor is a dated table: segment, sensing depth, and a plain answer to "if an intrusion happened only here, what record would exist" — including the answer "none". Two things make it hold up: the accountable risk owner signs the residual rather than the security team absorbing it, and the list is reconciled against the platform inventory on a schedule, with anything new classified unsensed until proven otherwise. A coverage percentage measured in bytes is the trap; most of the bytes are one noisy segment.

go deeper

for a junior

Understand that sensing is never complete and that knowing which parts of a network are unmonitored is itself a security deliverable.

for a middle

Be able to explain why a coverage figure based on inspected bytes is misleading, and why coverage should be counted per segment instead.

for a senior

Show how you tier sensing — full, connection-level, none — and how you keep the register true as the platform creates segments without asking.

for a principal

Own the accountability: produce the negative-coverage statement, get the business risk owner to accept it in writing, and be ready to say plainly that an intrusion confined to an unsensed segment would leave no network record.

## What is actually being asked for An auditor, an insurer or a customer's security team does not want your architecture. They want an answer to one question, per segment: **if it happened only here, would any record exist?** With funding for one segment in five, the honest answer is "no" for most of the estate, and the professional act is to say so precisely rather than to imply coverage you do not have. So the output of this programme is a **dated list of what is not sensed**, maintained like an asset register. That is a different artefact from a deployment plan, and treating it as the deliverable changes how you choose. ## Choosing the fifth Ranking by traffic volume is the reflex and it is wrong — the loudest segments are usually replication and telemetry. Better inputs: - **Consequence of a contained intrusion.** What can an intruder reach if their whole path stays inside this segment? A segment holding a data store and its clients is a complete objective; a segment of stateless front-ends is a waypoint. - **Management and credential paths.** Segments carrying administrative access, secret distribution or build and deployment traffic are where a lateral path becomes an estate-wide one. - **Marginal evidence, not absolute evidence.** If a segment already produces strong host or application records, network sensing adds less than it does where the workloads are opaque appliances or third-party images that carry no other telemetry. Spend where the alternative is nothing. - **Node density.** A capture point on a dense node converts more otherwise-invisible traffic into observable traffic than one on a sparse node. - **Rate of change.** A segment that is rebuilt weekly makes any static claim about it stale faster. ## Tier instead of choosing binary "One in five" is a budget, not a design. Three tiers usually beat a binary split: | tier | what exists | roughly | | --- | --- | --- | | full | inner packets, inspected | the chosen fifth | | reduced | connection-level records only, no payload | a wider band, cheap on the node | | none | nothing — stated explicitly | the remainder | The reduced tier is what lets you shrink the "none" list without new budget, and the distinction matters to the reader: a segment where you can say two workloads exchanged bytes is in a different position from one where nothing at all would exist. ## Making the claim survive contact Three failure modes kill coverage statements: **Percentages measured in bytes.** "We inspect 80% of east-west traffic" can be true while 90% of segments are dark, because one replication segment is most of the bytes. Always express coverage as a count of segments and name them. **Silent decay.** Teams create segments and node pools without asking security. The list is only true if it is reconciled against the platform's own inventory on a schedule, with a standing rule that **anything new is unsensed until proven otherwise**. Without that rule, the document ages into a false statement, which is worse than no statement. **Unstable placement.** Because the scheduler moves workloads, a claim about a service is not durable. Claims must be anchored to nodes and segments, which change slowly, not to service pairs, which do not. ## Who signs This is the part that separates a principal answer from a senior one. The security function produces a **fact** — these segments have no sensing, and here is what that means for evidence after an intrusion. It does not have the authority to accept the consequence. The accountable owner of the business capability running in those segments signs the residual, dated, with a review point. That does three things: it puts the cost where the decision is, it converts "security says we need more sensors" into a funding conversation with a named counterparty, and it means the answer to an auditor is "yes, and here is who accepted it" rather than an argument about whether the gap was known. When an owner refuses both the sensor and the residual, the remaining lever is to make the unsensed segment matter less — reduce what runs there, or reduce what it can reach — which is a different budget and a different team, and it is a legitimate outcome to propose. ## What to say out loud in the interview Commit to the uncomfortable sentence: for the four segments in five with no sensor, an intruder whose entire path stayed inside one of them would leave **no network record at all**, and the first indication would come from somewhere else or from someone else. Saying that plainly, with a dated list and a signature behind it, is a stronger position than any claim of near-complete coverage — because the near-complete claim will not survive the first question about same-node traffic.

  • An auditor asks for a single coverage percentage. Why resist a bytes-based number?
    Because bytes concentrate. One replication or telemetry segment can be most of the traffic, so "80% of east-west inspected" is compatible with almost every segment being dark. Coverage that means anything is a count of named segments and the depth of sensing on each, which is also the form that can be checked against an inventory.
  • A team stands up a new segment next month. How does your published list stay true?
    By reconciling against the platform's own inventory on a fixed cadence and applying a default: anything appearing in the inventory and not in the sensing register is classified unsensed and appears in the next dated version. Without that rule the document silently becomes a false statement, which is worse than publishing nothing.
  • Who should sign off the unsensed list, and why does it matter?
    The accountable owner of the business capability running in those segments, not the security team. Security produces the fact; accepting the consequence is a risk decision with a budget attached. That signature turns an internal complaint into a funding conversation and gives the auditor a named person rather than an argument about whether the gap was known.
  • The owner refuses both the sensor and the residual. What is left?
    Change the consequence rather than the visibility: reduce what runs in that segment, reduce what it can reach, or move the workloads that make it valuable onto instrumented nodes. That is a different budget and usually a different team, and proposing it is a legitimate outcome — what is not legitimate is leaving the gap undocumented because nobody would sign.

saying these in an interview costs you the question

  • Reports coverage as a percentage of bytes inspected
  • Ranks segments by traffic volume rather than consequence
  • Lets the security team absorb the residual risk
  • Publishes a coverage list with no date or review cycle
  • Implies full east-west coverage the estate cannot support

context