Your emulation miss traces to absent auditd rules on one host image — who owns the finding, and how do you make that stick?

## Why the label decides everything By the time you have walked the chain back, you hold a fact: on hosts built from a particular image, the behaviour you executed produced no audit record at all, while a control host of a different build produced it immediately. You now have to write that down, and the two available labels are not equivalent. - **Detection gap** — the estate saw the behaviour and had no rule for it. Owner: detection engineering. Cost: a rule, days, no infrastructure change. Closes fast and looks like progress on the quarterly slide. - **Collection gap** — the estate did not see the behaviour. Owner: whoever owns the host image and its audit configuration. Cost: an image change, a fleet rebuild cycle, a conversation about audit volume and its performance and storage bill. Closes slowly and looks like an unresolved risk for a quarter. The organisational gravity is entirely towards the first label, and it will be applied by well-meaning people who are trying to be helpful. A senior purple-team lead's real job here is to make the correct label survive contact with that gravity. ## The argument, stated so it cannot be waved away A rule over telemetry that is never produced **cannot fire**. And here is the property that makes it dangerous rather than merely useless: a detection produces no output when it is working perfectly in a quiet estate, and no output when it is dead. Those two states are indistinguishable from the outside, so an unfireable rule is not a null; it is a **positive false belief in coverage**, sitting on the dashboard as a closed finding, and it will be counted as coverage in the next assurance conversation. That is strictly worse than the open gap, because an open gap is at least visible. This is also why the ordinary way of validating rules does not save you. Replaying a captured input through a rule tests the rule's logic. It cannot tell you whether the estate would have produced that input in the first place — only executing the behaviour on a real host of that class can, and that is exactly what the exercise did. ## Making it stick **Evidence.** The finding carries the control-host record and the target's silence over the same window, so the negative is defensible rather than an assertion. Without that, the finding is one person's claim and will be renegotiated. **Scope.** You tested one or two hosts; the finding is about a class. Say how many machines share that build lineage and how you counted, and say plainly what you have not tested. An unscoped finding is either dismissed as an anomaly or inflated into a fleet-wide crisis, and both outcomes lose you credibility. **A real owner.** The finding must name a team with the authority to change the image, not a distribution list. If no such owner exists, that absence is itself the finding to escalate. **An acceptance test that is an execution.** "The audit rule is present in the build definition" is not acceptance; configuration present in a repository is not the same as records arriving from a running host. Acceptance is: rebuild a host of that class, execute the technique again, observe the record, then observe the rule, then observe the alert. Retest the whole chain, because fixing the first link tells you nothing about the three that were never exercised. ## When the answer is no Sometimes the platform team is right to refuse. Broad syscall auditing on a large fleet has a genuine volume and performance cost, and the honest response is not to escalate until you win. It is to convert the finding into an explicitly accepted risk: this technique, on this host class, is currently unobservable; the class contains this many machines running these workloads; here is a narrower rule that would cover the specific behaviour at a fraction of the volume, or a compensating observation on a different surface — the journal record of the unit starting, a file-integrity watch on the unit directory — that gives partial coverage. Then it goes on the risk register with a named accepting owner, and it comes back to the next exercise as a known blind spot rather than an open ticket. The general principle to state in an interview: **an emulation programme's output is not rules, it is correctly attributed and correctly owned findings.** Its credibility depends on every finding routing to the link that actually broke, and on never letting a cheap fix at one link be used to close a problem at another. The moment collection gaps start being closed with detection content, the programme's numbers become fiction, and everyone downstream — including the people who decide whether the SOC gets the audit budget — is reading a report that overstates what the estate can see.