Detection Engineering as Code

Detection teams find that their logic accumulates rather than being designed. A rule is written in the console during an incident, tuned twice the following month, then left alone. Nobody knows who owns it, which log source it depends on, whether it has ever produced a true positive, or what happens when a vendor renames a field. Six months later the same behaviour gets a second rule, because the first could not be found.

What results cannot be measured. Coverage rests on a count of rules rather than a mapping to attacker behaviour, every platform migration is a rewrite, and testing means waiting for an alert to fire in production.

Treat detections as source code. Each rule lives in a repository as a vendor-neutral Sigma rule with metadata: owner, MITRE ATT&CK technique, required log sources, severity, known false positives and a test fixture. A build step converts Sigma into the query dialect of each platform, with a processing pipeline that maps Sigma's field names to that platform's schema, using the project's official converter (sigma-cli) or the pySigma library inside your own toolchain, so one intent ships to the SIEM, the data lake and the endpoint tooling without three hand-written copies drifting apart.

Pull requests need a second engineer, and continuous integration runs every rule against recorded and synthetic events. A rule that fails to fire on its positive fixture, or that fires on its negative fixture, fails the build. Coverage becomes a query rather than an opinion, because every rule carries its technique mapping and a report renders the ATT&CK matrix from the repository.

1. Detection engineer. Describes the behaviour in plain language, naming the technique and the log source, before any query is attempted.
2. Rule author. Encodes it in Sigma using the Sigma taxonomy's field names, narrow enough to explain to a reviewer.
3. Peer reviewer. Checks the usual failure modes: missing parent process, case sensitivity, an unsupported wildcard, a field found on only one platform.
4. Pipeline. Validates the schema, converts to each target dialect, and fails on conversion errors rather than emitting a broken query.
5. Fixture runner. Replays positive and negative fixtures and asserts both the expected match and the expected silence.
6. Approver. Confirms the false positive budget and the response guidance attached to the alert, then merges.
7. Deployment and review. Publishes to staging with output muted, watches volume, promotes to production, and re-validates rules whenever a log source changes shape.

• Detection content managed as a product with an owner, a backlog and release notes
• One vendor-neutral rule source compiled to each platform's dialect
• Pipeline as code, so the toolchain is reproducible and reviewable
• Coverage derived from rule metadata rather than analyst recollection
• Ingestion cost treated as a design constraint of the rule

• Require peer review and a passing test run before any rule reaches production.
• Restrict who may mute or disable a rule, and record every mute with a reason and an expiry.
• Keep fixtures free of real personal data by synthesising or redacting identifiers.
• Scope the pipeline identity to detection content only, never to log deletion.
• Monitor the pipeline for failed conversions, stale rules and drift from the repository.
• Alert when a rule stops matching for a period inconsistent with its baseline.

• Reviewable, tested rules vs. a new detection takes hours instead of minutes, which hurts most during an incident.
• Platform portability vs. the lowest common denominator: Sigma cannot express every native analytic, so a minority of rules stay platform-specific and drift.
• Measured coverage vs. the matrix rewards breadth, which invites shallow rules written to fill cells.
• Automated deployment and rollback vs. a bad rule can reach every platform at once, so the pipeline needs the care of any production deployment path.

• Sigma is a source, not a runtime. The repository is authoritative and the deployed query is a build artefact. Editing a rule in the console breaks the link, and the next deployment overwrites the change.
• Fixtures need boring negatives. A rule tested only against an attack sample will fire on everything. Include routine administrative activity that resembles the behaviour but should not alert.
• Set a false positive budget per rule. A ceiling of a few alerts a week, with retirement or retuning above it. Unbudgeted rules train analysts to ignore the queue.
• Log source dependency is part of the rule. A rule that stops matching because a field was renamed is worse than no rule. Assert the schema version and alert when the source changes shape.
• Map to what the rule detects. ATT&CK metadata should describe the behaviour caught, not the behaviour hoped for, or the coverage report becomes decoration.

A financial services firm runs one SIEM, a data lake for long-term search, and an endpoint product with its own detection language. Three engineers maintain roughly four hundred rules across those systems, most written directly in a console. A cloud migration forces a change of SIEM, and the audit committee asks which ATT&CK techniques are covered. Nobody can answer either question with confidence.

The team builds a repository and converts the rules that matter, starting with the twenty that produced most of last year's confirmed incidents. Each carries a fixture taken from a red team exercise or a past case, with identifiers and hostnames replaced. Conversion to the new query language is done by the pipeline, and the first run fails on a third of the rules, mostly because they referenced fields that no longer exist or used syntax the new platform rejects.

Two quarters later the matrix shows coverage honestly: strong on credential access and discovery, thin on cloud control plane activity. That gap becomes a funded work item rather than a surprise during an incident. Some rules are still written natively, but the ones that matter are tested before they ship. None of that work is visible to the business, which is rather the point.