A purple-team replay of known-bad traffic raised no alert — how do you tell silent capture loss from a rule miss?

## Why this is the question and not a rule-tuning question When a replay produces no alert, the competent-but-wrong reflex is to open the rule. It is the wrong first move, because a rule that never saw the bytes cannot be tuned into seeing them, and every hour spent on it is an hour spent confirming the wrong theory. The correct first move is to establish whether the packets were ever presented to the matching engine. ## The four stages, and which of them can be counted **Stage 1 — the mirror or the tap.** An optical tap is entirely passive: it splits light and reports nothing, ever. A mirror session on many platforms exposes no counter for frames its mirror engine discarded. This stage frequently cannot be measured directly. It is bounded indirectly: what the source link carried in the window (from the switch's ordinary interface counters, which are reliable) against the destination port's capacity. A destination port at line rate for any part of the window is a positive finding. **Stage 2 — the aggregation broker.** This one does count. Per-port ingress and egress rates and discard counters exist; the question is whether anyone collects them at a granularity finer than the five-minute poll that hides bursts. **Stage 3 — the sensor's NIC and capture ring.** Interface receive statistics distinguish frames dropped by the driver from frames the NIC missed because no buffer was free. Per-queue counters matter here: loss concentrated on one queue points at an uneven hash rather than a global capacity shortfall. The capture ring keeps its own statistics — packets accepted against packets dropped. **Stage 4 — the engine.** Packets and flows processed, its own internal drops, and the connection log. ## The evidence that actually decides it The sensor's own **connection record for the replay** is the discriminator, because it is written by the same process that would have matched: - **No record at all** — the traffic never reached the engine. Look upstream. - **A record present but one-sided**, or with byte counts far below what you know you sent — partial delivery. Loss upstream, or a direction that never converged on this worker. - **A record complete, with byte counts matching what you sent** — the packets were there and were matched against. Now the problem is genuinely the detection: the rule, the protocol parser, the port assumption, an exception, a disabled ruleset. Corroborate against something outside the sensor. The switch's interface counters for the replay window, the sending host's own record of what it transferred, or the receiving service's log all give you an independent number of bytes to compare against. ## The direction of every claim in this investigation - A zero capture-drop counter proves that **nothing was lost after arrival at the NIC**. It says nothing about the mirror or the broker. - A silent tap proves nothing whatsoever; silence is its normal state. - An absent alert proves that **no rule fired**, which is compatible with loss, with a rule that did not match, with a rule that was disabled, and with a genuinely quiet estate. - A present, complete connection record is the one artefact that lets you say the sensor **had** the data. That is why it, and not the drop counters, is the thing to reach for first. ## What answering this at all costs you None of the above is available retrospectively unless you were already paying for it: the stage counters must be collected continuously, at a sub-minute granularity that survives bursts, and retained long enough to look back at the window in question. That is a metrics-collection and storage cost that has to be argued for before the incident, and it is invariably argued for after. The replay capability itself is a cost too — a scheduled, repeatable, known-payload exercise with a known byte count, run at a known time, is what makes the comparison possible at all. Running it only at average-load hours is a wasted budget: schedule it into the peak window, because the peak window is where the loss lives. ## What you say when you cannot prove it Sometimes the answer is that the mirror stage is unmeasurable on this platform and you cannot distinguish the two causes for last quarter's window. Say that plainly, then state what you can bound — the link carried X, the destination port could carry at most Y, so at least X minus Y was never offered to the sensor — and put the instrumentation gap on the record as a finding of its own. An honest bound is a better answer than a confident story built on a counter that does not measure what the story needs it to.