skip to content

Before you cut the legacy circuit an attacker can still use, what evidence would justify spending a two-hour trading outage on it?

level: seniorimportance: should knowfreq 47%

answer

  1. absence of records is weak evidence
  2. sampling hides the rare client
  3. retention shorter than the business cycle
  4. deny-and-log before you cut
  5. retire the name last, sinkholed

basics

~20 s

Positive evidence over a full business cycle, not silence. Sampled flow records and a short retention window hide low-volume clients, so run a reversible deny-and-log period first and let the complaints be your inventory before you spend the outage.

solid answer

~50 s

Absence of records is the weakest evidence in the room. Flow exporters sample, retention is usually shorter than a retail business cycle, and the clients most likely to break — a nightly batch, a quarter-end stock count, a vendor support tunnel, the disaster-recovery path — speak rarely enough to fall between samples. So I would gather positive evidence instead: flow toward the legacy address on the circuit, query logs for the internal name that still points at the old front door, and broker session records showing the same population has moved. Then, rather than cutting, I would deny-and-log that application on the legacy path for a window I can reverse in minutes, repeat it across a month-end and a peak trading weekend, and only then spend the outage. Every month I wait is a month the cheapest way in stays open and unwatched.

code

text · 11 lines
text
# IPFIX export, circuit-facing interface, sampling 1:1000, 30-day retention
# start                end                  src          dst        proto sport dport pkts  bytes
2026-08-24T02:14:03Z  2026-08-24T02:14:09Z 10.42.7.19   10.9.0.20  TCP   51442 443     6   2318
2026-08-25T02:14:01Z  2026-08-25T02:14:08Z 10.42.31.8   10.9.0.20  TCP   49903 443     5   1904
...
# nothing at all for 10.9.0.20:8443 (the legacy admin front door) in the window
#
# reading it: two surviving records at 1:1000 stand for a much larger nightly population,
# and the empty admin line is not evidence of disuse - it is what sampling plus 30-day
# retention looks like for a client that speaks at quarter-end. No payload is present in
# either case, so these records show that bytes moved, never what they were.

go deeper

for a junior

Know that a flow record shows the addresses, ports, packet and byte counts and times, and carries no payload, so it can prove traffic happened but never what it contained or that none exists.

for a middle

Be ready to explain why sampling and retention make silence weak evidence, and to describe a reversible deny-and-log period as a way to produce evidence rather than wait for it.

for a senior

Show the whole decommission sequence you would run, the business-cycle boundaries you insist on covering, the rollback, and the reason the name is retired last and pointed at something that logs.

for a principal

Own the trade between the outage cost and the standing exposure: name who signs the window, what you tell them about the risk of waiting, and how many cycles of delay you are prepared to accept.

## What the outage actually costs Cutting the legacy path to a migrated application in a 400-shop estate is not a change ticket, it is a trading decision. The window is short, overnight, signed by someone who owns takings; if tills or stock adjustments break at 07:00 the cost is measured in shops that cannot trade. So the evidence bar is not "I think it is unused" — it is "I can say who still depends on this and I have dealt with them". At the same time, delay has a price on the other side of the ledger: while the old front door stands, it is the cheapest route to the application for anyone who reaches a shop network, and it is the route nobody is watching any more because attention followed the new project. ## Why silence proves almost nothing The reflex is to look for traffic and, finding none, cut. Four things break that reasoning: - **Sampling.** Flow exporters commonly sample. A record that survives sampling stands for many that did not, and a client that connects twice a month may never produce a surviving record at all. - **Retention.** If you keep 30 days of records and the business cycle is a quarter, you have not observed the quarter-end stock count, the annual inventory, or the seasonal peak. - **Exporter gaps.** A path with no exporter, or an interface not included in the export, is silent for reasons that have nothing to do with usage. - **What flow records are.** A flow record carries the five-tuple, byte and packet counts and timestamps. It carries no payload at all, so it can tell you bytes moved and never what they were, or which application-level client sent them. Here is the shape of the evidence and the trap inside it. ## The positive evidence to gather - **Flow on the circuit toward the legacy address**, over as long a window as retention allows, with the sampling rate stated next to the result so nobody reads absence as proof. - **Query logs for the internal name** that still resolves to the legacy front door. This shows the name was asked for — not what the process did next — but a name nobody asks for is a much stronger signal than an address nobody hits, because caching aside, it captures clients that would connect if they ran. - **Broker session records for the same user population**, confirming the humans have moved. - **A client census that no log will give you**: batch schedules, the vendor's support arrangement, the disaster-recovery runbook, and the till and handheld build configs where an endpoint is baked in. These are the ones that will bite, and they are found by reading documents and asking owners, not by watching wires. ## The move that beats waiting: deny-and-log Do not make a two-hour irreversible cut your first experiment. Turn the legacy path for that one application into a **logged deny** during a window you can revert in minutes. Now absence of complaints is evidence generated on purpose, and every denial you log is a client you did not know about, named with a source address you can chase back to a shop and a device. Repeat it across the boundaries that matter — a month-end, a peak trading weekend, and whatever the estate's annual event is — before booking the real outage. Each repetition converts unknown clients into a named list. ## The order of the ending 1. Stop new use: no new permits and no new applications on the legacy path. 2. Deny-and-log the application on that path, in reversible windows, across a business cycle. 3. Remove the permit for that application. 4. Remove the route, if this application was the last thing on it. 5. Retire the internal name **last** — and point it at something that logs and refuses rather than deleting it outright. A deleted record produces a resolution failure that clients retry silently and nobody reports; a record that answers and refuses tells you exactly who is still asking, months after you thought it was over. ## Who signs, and what you say The window is signed by the trading owner, not by security. What you bring them is: the list of clients found by deny-and-log and dealt with, the cycle boundaries you covered, the rollback that takes minutes, and the sentence that makes the ask reasonable — until this path is gone, the application's real access control is a source address on a shop network, and the programme that was funded to change that has changed nothing for this app. ## How to answer well Lead with "silence is not evidence, and here is why", name sampling and retention specifically, then describe deny-and-log as the way to manufacture the evidence you lack. Finish with the ordering and the sinkholed name — that last detail is what separates someone who has actually done a decommission from someone describing one.

  • The deny-and-log window was quiet. Would you cut on that alone?
    Only if the window covered the cycles that matter. A quiet Tuesday night proves Tuesday nights. I would want a month-end, a peak trading weekend and any annual event inside the observation before booking the outage, plus the document-based census of batch jobs, disaster-recovery paths and vendor support arrangements that no log surfaces. Then the quiet window is confirmation of a list, rather than the list itself.
  • Why not just delete the internal name once the route is gone?
    Because a name that fails to resolve produces silent client retries and no owner ever reports it, so you lose the last inventory you were going to get. Leave the name answering, pointed at something that refuses and logs the attempt, for at least a full business cycle. Every entry is a client that would have hit the old front door. Delete it after that, once the list has stopped growing.
  • Who signs the outage window, and what do you put in front of them?
    The trading owner, because the cost lands on shops that cannot trade. Bring the named clients found and remediated, the cycle boundaries covered, the rollback time, and one sentence on the other side of the ledger — that until the path is cut, the application's real admission test is a source address on a shop network, and it is now the least-monitored path in the estate.

saying these in an interview costs you the question

  • Treats thirty days of no flow records as proof of disuse
  • Ignores that flow exporters sample
  • Cuts irreversibly instead of denying reversibly first
  • Forgets batch jobs, disaster-recovery paths and vendor tunnels
  • Deletes the internal name and loses the last inventory
  • Claims flow records show what the traffic contained

context

resolving links…