A purple-team technique you executed produced no alert — at which stages could the miss have occurred?
answer
- silence names no link
- four links, four owners
- record, rule, alert, action
- evidence per link, never a guess
- no alert observed, not undetected
basics
~20 sA miss can sit at four stages: the record was never generated, no rule matched the record, no alert reached the queue, or nobody acted on the alert. The absence of an alert names none of them.
solid answer
~40 sSilence at the end of a chain does not tell you which link broke. There are four: **collection** (did the host emit and deliver a record of the behaviour at all), **detection logic** (did a rule express something that matches that record), **alerting** (did a firing actually become an item in a queue someone reads), and **response** (was it worked and acted on). Each has a different owner and a completely different fix, and each needs its own evidence before you may claim it. Until you have walked back, the only honest line in the report is "no alert observed" — not "undetected", and certainly not "we need a new rule". Misattributing the stage is the classic purple-team failure: it buys a rule for data that does not exist, and everyone believes coverage improved.
go deeper
Be ready to name the four links in order — record generated, rule matched, alert queued, action taken — and to say that no alert on its own identifies none of them.
An interviewer expects you to attach the evidence to each link: the host's own audit log for collection, the rule re-run for logic, the alert store for alerting, the ticket for response.
Demonstrate that you stop at the first proven link and state what is still untested, and that you never let a miss be closed with a rule before collection has been evidenced.
Own the reporting standard: exercise findings carry their stage evidence and route to the stage owner, so a cheap detection fix cannot be used to close a collection problem.
## The chain, and why silence is ambiguous When you execute a technique yourself — say a systemd timer unit on a Linux server fleet that launches a benign payload every ten minutes (`T1053.006`) — you have something a real intrusion never gives you: **ground truth**. You know exactly what ran, on which host, at which second, under which user. That is the whole reason purple-team execution exists. But the output you get back is often a single fact: *no alert appeared*. That fact, on its own, is compatible with at least four completely different states of the world, and they are not interchangeable. **Stage 1 — collection.** No record of the behaviour ever reached anywhere you can search. On Linux this usually means the auditd rule that would have caught the `execve` was never loaded on that host, or auditd was not running, or the record was generated and then lost between host and platform. The behaviour is invisible: nothing you write downstream can see it. **Stage 2 — detection logic.** The record exists and is searchable, but no rule expresses a condition that matches it. This is the genuine "detection gap" — the estate saw the behaviour and had nothing to say about it. A subtle variant: a rule exists and its logic is sound, but the field it keys on was renamed or dropped during normalisation, so it can never match. That looks like a logic gap and is really a schema problem. **Stage 3 — alerting.** A rule matched, but no alert arrived in a queue a human reads. The rule was disabled or in test mode; a scheduled search's window closed before the data was indexed; a suppression or deduplication window swallowed the firing; the alert was routed at a severity nobody triages; or an automation auto-closed it. **Stage 4 — response.** The alert existed and was worked, and nothing happened — worked to a wrong verdict, or worked to the right verdict with no action behind it. Here the evidence is a ticket with a timestamp and a disposition on it. ## Why the misattribution is expensive The default conclusion after a failed emulation is "we need a detection for that". It is wrong roughly as often as it is right, and it is wrong in an actively harmful way. A rule written over telemetry that is not collected **cannot ever fire**, and a rule that never fires is indistinguishable from a rule watching a quiet estate. You have not added coverage; you have added a permanent false belief in coverage, plus a line on a dashboard that says the gap is closed. Meanwhile the actual owner — whoever controls the host image and its audit configuration — never learns they have a blind class of machines. The stages also have different owners and different clocks. Collection is a platform or image problem measured in build cycles. Detection logic belongs to the detection engineers and can move in a day. Alerting is a pipeline and configuration problem. Response is a process and staffing problem. Naming the wrong stage sends the finding to the wrong team, who will close it without fixing anything. ## The discipline Walk the chain **forwards from the host**, not backwards from the pager, and produce an artefact per stage: | Stage | The evidence that settles it | |---|---| | Collection | The record present, or provably absent, in the host's own audit log over the execution window — with a positive-control host that does produce it | | Detection logic | The rule's own query re-run over the window against the stored record | | Alerting | The alert store and case system searched by rule identifier over a widened window; the rule's enablement and suppression state at that time | | Response | The ticket, its disposition and its timestamps | Two cautions. First, **stop at the first stage that explains the miss, but say what remains unproven**: if no record ever existed, you have learned nothing at all about whether the rule, the routing or the analysts would have worked. Your report covers one link, not four. Second, several links can be broken at once, and fixing the first does not guarantee the alert appears — which is why the acceptance test for any of these findings is *re-executing the technique*, not inspecting a configuration. Finally, keep the direction of every claim straight. An alert firing proves a rule matched a record; it does not prove something malicious happened. And the absence of an alert proves nothing whatsoever about the estate until you have said which link it came from.
- Why is "we need a new detection rule" the wrong default conclusion after a failed emulation?Because if the miss was at collection, the new rule is written over data that is never produced. It can never fire, and a rule that never fires looks exactly like a rule watching a quiet estate. You have bought a permanent false belief in coverage and left the real owner — whoever controls the host's audit configuration — unaware they have a blind host class.
- What may you honestly write in the report before the walk-back is finished?"No alert was observed for this execution", with the host, the exact command and the time window. Not "undetected" and not "detection gap" — both assert a stage you have not yet evidenced. The claim you can defend is about what you saw, not about what the estate is capable of.
- Does finding a broken link at one stage rule out problems at the later ones?No — it hides them. If no record was ever generated, the rule, the routing and the analysts were never exercised at all, so you have zero evidence about them. Say so explicitly in the finding: one link is proven broken and three remain untested. That is also why the retest re-executes the technique end to end.
saying these in an interview costs you the question
- Assumes every miss means a missing detection rule
- Says no alert proves the technique is undetectable here
- Reports undetected without ever checking the alert queue
- Treats absent telemetry and an unmatched rule as one finding
- Claims all four stages are fixed after fixing one