ATT&CK coverage

Coverage of the whole kill chain, all 14 MITRE ATT&CK Enterprise tactics, including the four columns a host-only EDR is structurally blind to: the attacker's own infrastructure, before and after it touches your endpoint.

A shipped rule or engine names 103 ATT&CK techniques by their technique id today (68 counted at the parent technique, sub-techniques folded in), across 14 of 14 Enterprise tactics. 91 of those are on-host, carried by 12 behavioral engines, 79 bundled Sigma rules and a curated critical-config watch running natively in the sensor. The remaining 19 are the four infrastructure columns, Reconnaissance TA0043, Resource Development TA0042, and the infrastructure side of Command and Control TA0011 and Exfiltration TA0010, emitted from the 7.52B-node / 38.6B-relationship internet graph. A host sensor cannot reach those four, because the activity happens on the adversary's own machines.

Two numbers, never one. Telemetry is what the sensor sees, measured at 100% (37 of 37 driven techniques) on a real box. Named detection is what alerts, the 103 techniques above. We publish both and we never restate one as the other. Named detection means a shipped rule or engine targets that technique by its ATT&CK id and can alert on it, which is a claim about the artifact we ship, not a claim that we have watched every one of them fire.

The four columns no host-EDR covers

Two of them are pure: Reconnaissance and Resource Development happen entirely on the adversary's own infrastructure, their domains, addresses, certificates and staged capabilities, long before a packet reaches an endpoint. There is nothing on a host to instrument, so a CrowdStrike or SentinelOne sensor is not weak here, it is structurally absent. Two are hybrid: for Command and Control and Exfiltration the sensor sees the channel and the graph supplies the destination column a host-only product does not have.

Every one of these fires only when the graph itself made a derogatory claim: a threat band, a known-bad listing, a threat-classification label, a corpus-confirmed hash, or a verbatim match against the same out-of-band-interaction provider list the bundled Sigma rule uses. An unlabelled, unbanded, unlisted signal contributes nothing. Confidence is a fixed function of the signal, never tuned per finding, and every finding carries a re-runnable receipt: the exact CALL whisper.assess or whisper.enrich a stranger can run to reproduce the verdict.

The on-host set, by platform

91 techniques (57 at the parent) are named by something running in the sensor itself. The count is not hand-maintained: it lives in a coverage manifest embedded in the binary, and the build guard recomputes it from the shipped artifacts, the Sigma rules' own tags through the same parser and platform admission the evaluator uses, the engines' compile-time technique constants, the critical-config allowlist. Adding a detection without updating the count is a test failure, not a documentation drift.

The platform columns overlap, because one bundle carries every platform's layer side by side and load-time admission selects the subset the running binary can observe.

Measured live, the transcript

On a throwaway Debian 12 box (kernel 6.1), driving real atomics: 100% telemetry (37 of 37 techniques captured, 10 tactics), 32 of 37 signature (86%, the known tool captured by name; the five not named were still captured as telemetry), 17,092 exec events with zero drops (one scan loop alone spawned 10,974 processes). Verbatim captured events:

[T1003.008 read /etc/shadow]  {"comm":"cat","filename":"/usr/bin/cat","pid":1658,"ppid":1656,"uid":0}
[T1489 service stop]          {"comm":"systemctl","filename":"/usr/bin/systemctl","pid":1718,"uid":0}
[T1053.003 cron persistence]  {"comm":"crontab","filename":"/usr/bin/crontab","pid":1732,"uid":0}
[T1547.006 kernel module]     {"comm":"insmod","filename":"/usr/bin/kmod","pid":1875,"uid":0}
[T1027 obfuscation]           {"comm":"base64","filename":"/usr/bin/base64","pid":1986,"uid":0}
[T1071.001 C2 user-agent]     {"comm":"curl","filename":"/usr/bin/curl","pid":2018,"uid":0}
[T1485 data destruction]      {"comm":"dd","filename":"/usr/bin/dd","pid":7462,"uid":0}
[T1105 ingress transfer]      {"comm":"rsync","filename":"/usr/bin/rsync","pid":7495,"uid":0}
[T1574.006 ld.so.preload]     {"kind":"file","event":"create","path":"/etc/ld.so.preload","critical":true}

Two real rule engines, on the host

Most lightweight agents bundle neither YARA nor Sigma; heavyweight ones bolt a YARA integration onto the side and leave Sigma to a SIEM-side converter. The Whisper sensor runs both, in-process: a genuine SigmaHQ-format rule evaluator over all four telemetry streams, and VirusTotal's YARA-X engine over files and memory. Every finding carries the rule name, its author, its license and its ATT&CK technique onto the wire.

The 79 bundled Sigma rules

79 rules ship, one bundle carrying every platform's layer side by side, with attribution preserved on every one. 34 are upstream SigmaHQ rules bundled verbatim under the Detection Rule License 1.1, each keeping its title, id, author, date, references and tags plus a header naming its exact upstream path. 45 are first-party Whisper rules under the MIT License, written where SigmaHQ carries nothing for a lane we ship, and never presented as SigmaHQ content. No GPL rule packs, ever.

An operator rule with the same id overrides the bundled one; the set is capped at 512 rules; aggregation rules are skipped at load because multi-event correlation belongs to the correlators, not to a single-event evaluator.

The YARA lane, and why it counts for nothing here

The YARA side cuts the other way: four rule files ship in the tree, but the default release build carries zero of them. YARA is a build-time opt-in (-tags yara) and the default build ships the engine stubbed out, pinned by a test. So YARA contributes nothing to the 103 above, and the rules are listed here as what the optional build lane carries, not as shipped coverage. That build gate is the only thing keeping YARA off: inside a -tags yara build the engine defaults on exactly like every other engine on this site, {"sensor":{"yara":false}} opts back out, and the compile step, not a runtime key, is what decides whether the default binary you downloaded can ever reach that code path at all.

What alerts today: 12 engines and a curated watch

The inventory of the on-host verdict layer, engine by engine, with the technique ids each one's finding actually carries on the wire, and the exact config key that turns it off (a full paste-able opt-out block is on Detection engines). The critical-config watch is listed alongside them but is a different shape: it emits a critical-stamped file event rather than a detection event, and it is counted as such. Backed by 2,112 test functions and 93 fuzz targets in the sensor package alone.

Every on-host engine is observe-only, and detection is spliced beside the telemetry stream, never into it: an event is always forwarded downstream first, and only then does a detector look at a copy, so detection can never delay, drop or alter telemetry.

The matrix, 15 columns

The graph techniques column is the taxonomy size per tactic; the telemetry column is what we drove and captured in the measured run (it sums to 37). The per-tactic counts do not sum to 712 because a technique can belong to more than one tactic; 712 is the count of unique techniques in the taxonomy, which the graph already carries along with 1,916 actor nodes, 344 of which carry USES_TECHNIQUE edges. MITRE ATT&CK v19 splits Defense Evasion into two columns, which is why 14 canonical tactics draw as 15 here.

What we do not count

The manifest keeps an exclusion ledger, and these are deliberately outside the 103:

• T1055.012 process hollowing and T1620 reflective code loading. The injection engines classify both shapes and carry a stable wire signal for them, but the finding's technique field emits the parent T1055. Counted inside T1055 until the wire names the sub-technique.
• The YARA lane. The only rule carrying a technique meta is the EICAR self-test, and the default build ships zero YARA. Its lane is a separate build.
• The ETW Threat-Intelligence feed. Built, and dark on every shipped build: it needs Microsoft's anti-malware attestation and a protected-process launch. No count impact, since T1055 is already carried by the region sweep.
• The sshd_config watch. Labelled adjacent to T1098.004 in the allowlist, not a direct detection of it, so it is not counted as one.

Telemetry is likewise never summed into these counts. The five raw streams (exec, file, conn, dns, and image-load on Windows) are visibility, listed apart, and they are what the 37-of-37 figure measures.

Telemetry vs analytic, the load-bearing distinction

The telemetry column and the telemetry rows are visibility, the sensor sees it, measured 100% across the run. The analytic layer, a verdict that alerts, is the graph reputation (live for C2 and exfiltration destinations and for file hashes), the per-process trust tier, the four infrastructure columns, and the on-host engines and rule sets inventoried above: 103 named techniques. That layer is narrower than the telemetry and growing, we report both, and we never claim an alert we cannot demonstrate. Every on-host engine tops out below full certainty on purpose: intent-certainty and destination reputation are the graph's second pass to add. A fired verdict is held by default, not blocked, until you opt into a response lever. See Detection engines for the engine-by-engine status.