Your preflight shows half the Linux fleet has no execve auditing — what do you deliver?
answer
- hunt what reports, say what you did not
- the negative needs a denominator
- deferred is not closed
- collection requirement, named and costed
- use centrally collected sources on dark hosts
basics
~20 sRun the hunt over the hosts that do report, publish the result with its denominator attached, and file a named collection requirement for the dark half. The hypothesis is deferred, not answered, and the write-up must say so.
solid answer
~50 sThree deliverables, and the third is the one people drop. First, a **scoped hunt**: run the hypothesis over the build images that carry execution auditing, and state the scope in the result — hosts searched over hosts in scope, which images, how many days back. Second, a **stated negative**: "no evidence of scheduled-job persistence across the 214 covered hosts" is a defensible sentence; "the Linux fleet is clean" is not, and the difference is the whole point. Third, a **collection requirement** for the dark hosts: the exact record type needed, the host set, which hunt it unblocks, handed to the platform owner with a decision date. Meanwhile I squeeze the uncovered half with what is collected centrally and does not depend on the host's audit configuration — configuration-management inventory of unit and cron files, file-integrity data, resolver query logs — and I mark the hypothesis deferred in the backlog so nobody re-reads the empty half later as reassurance.
go deeper
Know that a hunt over partial coverage is still worth running, and that the result must state which hosts were searched rather than implying the whole fleet.
Be able to describe the three outputs — the scoped hunt, the scoped negative, and a specific collection requirement — and what a compensating source can still show on uncovered hosts.
Demonstrate the judgment call under a week's deadline: scope down, keep the weaker question alive on dark hosts, and write a negative that survives being quoted out of context.
Own the framing that unhunted estate is tracked and owned somewhere visible, so coverage gaps are accepted deliberately by the people who own the hosts rather than absorbed by the hunt team.
## The situation The hypothesis is persistence installed as a `systemd` timer or a user cron entry across a Linux server fleet. The preflight comes back mixed: execution auditing exists on the current build images, is absent on the older ones, and the older images also carry no endpoint sensor. Separately, the resolver query log is searchable for a shorter window than the period the hypothesis concerns. You have a week. The wrong move is to run the query anyway and report what comes back. ## Deliverable one: the scoped hunt Run over what reports. A partial hunt is worth real money — the covered subset is still hundreds of hosts, and adversaries are not careful to land only on the dark ones. What changes is that the scope becomes a first-class part of the output rather than a caveat: - **hosts searched over hosts in scope**, by build image; - **the record types used**, and the field the query actually turned on; - **the look-back window per source**, since sources rarely share one horizon. On the uncovered half, do not simply stop. Ask what is collected centrally and therefore independent of the host's audit configuration: configuration-management state that inventories unit files and cron entries, file-integrity data if it is deployed, resolver query logs for the callout side, and authentication records. These answer a weaker version of the question — they can show a *file that should not be there* even where they cannot show *what it executed* — and a weaker answer over the dark half is far better than none. ## Deliverable two: the negative, stated correctly This is the sentence the organisation will remember, and getting it wrong quietly manufactures assurance. "No evidence of scheduled-job persistence in the 214 hosts covered by execution auditing, over 30 days" is a claim you can defend. "We hunted for persistence and found nothing" will be read as a clean fleet, including by the person who cites it in six months when the same technique is found by somebody else. The direction of the claim matters: the hunt did not establish absence on the dark hosts, it established that it could not look. Anyone who reads only your summary line must still get that. Say the same thing to the hunt backlog. The hypothesis is **deferred**, not closed. A closed hypothesis is one somebody will not re-run. ## Deliverable three: the collection requirement A collection requirement is the durable output of a failed preflight, and it is worth more than the hunt would have been. A good one is specific enough for the owning team to cost: - **what**: execution records for the older build images, plus write coverage on the unit and cron directories — named record types, not "more Linux logging"; - **where**: the host set, by image, with counts; - **why**: the hypothesis it unblocks and the detections that are also blind without it, so it is not one hunter's preference; - **who decides**: the platform owner, with a date; - **what it is worth**: the fraction of the fleet currently unhuntable for this technique class. Make it inherit. The right fix is almost never a per-host change; it is an image or baseline property, so that new builds arrive covered and coverage does not decay back between hunts. ## What to resist Two temptations. The first is inflating the partial hunt into a full one because the report reads better; that is how a SOC ends up unable to say which parts of its estate it has ever actually looked at. The second is treating the gap as your own problem to absorb quietly — running around collecting records by hand, or shelving the hypothesis without telling anybody. The gap belongs to whoever owns those hosts, and it stays visible until they accept it or close it. ## How you know the week was well spent The test is what a colleague inherits. They should be able to read the result and know exactly which hosts were searched, which question was answered, which was not, what is required for it to be answerable, and who was asked. That is a good week even if the hunt found nothing, because the next attempt starts from coverage rather than from the same discovery.
- How would you word the negative result so a non-technical reader cannot over-read it?Put the scope in the same sentence as the finding: no evidence of this technique across the 214 hosts that carry execution auditing, covering two of four build images, over thirty days; the remaining 266 hosts could not be searched for it. Never let a summary line stand that says the fleet is clean, because that line is what gets quoted later.
- What can you still learn about the dark hosts without execution telemetry?Whether unexpected unit files or cron entries exist, using configuration-management inventory or file-integrity data collected centrally; whether those hosts resolved names that the covered hosts did not, using resolver query logs; and whether authentication records show access patterns worth pulling on. It is a weaker question — installation rather than execution — but it is answerable today.
- Is it ever right to run the hunt query anyway, knowing it covers half the fleet?Yes, almost always. The covered half is real estate an adversary could be on, and the query costs little. The condition is that the scope travels with the output and the backlog records the hypothesis as deferred, so partial coverage does not quietly become a clean verdict.
saying these in an interview costs you the question
- Reports the fleet clean when half of it was unsearchable
- Closes the hypothesis instead of deferring it
- Files "we need better Linux logging" as the requirement
- Absorbs the collection gap silently within the SOC
- Abandons the hunt entirely because coverage is partial