A fleet owner refuses your auditd watch on 40% of hosts. What do you ship, and what coverage do you claim?

## The situation You have a detection for SSH key persistence on a Linux server fleet - an adversary appending a public key to a service account's `authorized_keys` to hold access. The behaviour is only visible through host audit records, and the older half of the estate has no endpoint sensor at all. The team that owns the fleet declines to load the audit watch on 40 percent of the hosts, citing syscall volume and the operational risk of touching the audit configuration on their busiest machines. They own that configuration and they can say no. This is not a technical problem with a technical answer. It is a decision about what you deploy, what you claim, and who carries what is left. ## First, test whether the objection is about your rule or about audit rules in general Volume objections are frequently correct about a different rule than the one you are proposing. A broad syscall-level rule really can be costly on a busy host. A watch on a small set of specific paths is orders of magnitude cheaper, because it is evaluated only when those objects are touched. Bring numbers from the hosts where it already runs: records per host per day, the actual added load. Offer to narrow the watch further - the service accounts that matter rather than every home directory. Very often the negotiation ends here, and re-scoping recovers most of the 40 percent. Be careful about one tempting concession: excluding the noisy legitimate writer by process, so that config-management writes are never recorded. That looks like a clean volume win and it is a hole shaped exactly like the thing you are detecting, since an adversary who can write the file can usually write it in a way that matches the exclusion. Narrow by path, not by whoever is writing. ## Second, price the alternatives honestly If the watch genuinely cannot ship, there are weaker options, and their weakness has to be stated rather than glossed: - **A periodic file inventory.** Config management or an inventory agent reads the key files on a schedule and reports their contents or a digest; you diff successive snapshots. This catches a key that is still present at snapshot time. It loses the acting process, the acting user and the moment of change, it cannot see a key added and removed between snapshots, and its detection latency is the snapshot interval. - **Detecting the consequence instead of the act.** Authentication records showing an interactive login as a service account that should never log in interactively catch some of the same intrusions, later and by a different route. That is a different rule with its own inputs, not a substitute for this one. Each of these is a real control; none of them is the control you wanted, and the coverage record must not treat them as equivalent. ## Third, ship what is real The rule goes out scoped to the hosts where the prerequisite has been proven from evidence, with the covered set - or the criterion that defines it - written into the rule's metadata. On the remainder it is inert **by design and on the record**. Two things follow from that phrasing. The rule is not a lie, because it never claimed those hosts. And the gap is not invisible, because "inert here, for this reason, since this date" is a sentence somebody can act on. ## Fourth, put the residual risk where it belongs This is the part that is genuinely a leadership call rather than an engineering one. A control declined by the team that would have to operate it is a risk accepted by that team, recorded like any other exception: what is not detected, on which hosts, what the compensating signal is, who accepted it, and what triggers a review - a security event on those hosts, a change to the fleet's baseline image, the next audit cycle. The failure mode to avoid is the security organisation quietly carrying a gap it did not choose, and reporting a coverage figure that includes hosts it knows are blind. ## Why the claim matters as much as the rule Coverage numbers are consumed by people who cannot check them: a risk committee, a customer questionnaire, a regulator's evidence request, the next incident's timeline. "Detection deployed for SSH key persistence" and "detection covering 540 of 900 Linux hosts, with the remainder under a named exception" are the same rule and completely different statements. The second is smaller, harder to say and the only one you can defend when the intrusion lands on one of the 360 - and being able to point at a dated, owned exception is a far better position than explaining why the dashboard said green.