Detection as code, so your rules survive changing your SIEM

Two problems show up in every security operation we review. The detection rules live in the SIEM's web interface, written by people who have since left, with no record of why any of them exists. And nobody knows which ones still work, because a rule that stopped matching anything looks identical to a rule for something that stopped happening.

Both are the same problem: detection is treated as configuration rather than as code.

What Sigma is, and what it is not

Sigma is a YAML format for expressing detection logic against log data, with converters that compile a rule into the query language of a specific platform. Write the logic once, generate the query for whichever backend you run.

The value is not primarily portability between vendors, though that matters when you migrate. It is that the rule becomes a file: reviewable in a pull request, versioned, testable, and carrying metadata explaining what it detects and why.

There is also a large public rule repository, which is a genuinely useful starting point and a poor finishing point. Public rules are written against generic environments and will be noisy in yours, which is the same problem described in Falco tells you what a container did.

What it is not: a detection engine, a replacement for your SIEM, or a way to avoid understanding your log sources. The conversion is only as good as the field mapping between the rule's expected schema and the shape your logs actually arrive in, and that mapping is the real work.

The pipeline that makes it work

The shape is the same as any code pipeline, which is the point.

Rules live in a repository, one file per rule, organised by log source. A pull request adds or changes a rule. CI validates the syntax, converts the rule to every backend you target to confirm it compiles, and runs it against a set of sample events with known verdicts. Merging deploys it to the SIEM through the platform's API.

The testing step is the one teams skip and the one that matters. Keep a small corpus of log events, some that should match and some that should not, and assert the rule's verdict on each. Without it, the first test of a rule change is production, which for detection means you find out when it misses something.

Metadata belongs in the rule file: what technique it covers, what the false positive sources are, what severity it carries, and what the responder should do. A rule with a response note attached is a rule someone can act on at three in the morning.

The lifecycle nobody builds

Rules are not written once. They need a lifecycle with a named owner, and most operations do not have one.

Coverage. Map your rules against an attack technique framework and look at what is not covered. The honest finding is usually that coverage is deep in one area, typically endpoint, and absent in others, typically cloud control plane and identity.

Validation. A rule that has never fired is either excellent or broken, and you cannot tell from the outside. Test it deliberately by generating the behaviour it looks for, which is what adversary emulation is for, as in adversary emulation and purple teaming.

Tuning. Track the true positive rate per rule. A rule producing constant false positives is worse than no rule, because it consumes the attention that would have caught something real.

Retirement. Delete rules for systems you no longer run. A rule set that only grows becomes a rule set nobody trusts.

Review quarterly: what fired, what did not, what was a true positive, what should be deleted.

Cloud detections are where most operations are thin

The detections that matter for a cloud estate are not the classic endpoint ones, and they are where we most often find gaps.

Identity is the highest-value source. New credential created for a privileged identity, a role assumed from an unusual location, a change to a permission policy, multi-factor disabled, a dormant account suddenly active. Most cloud intrusions are visible here before they are visible anywhere else.

Then the control plane: logging disabled, a security tool's configuration changed, a snapshot shared with an external account, a storage bucket made public, a large-scale delete of backup objects. That last one is the detection argued for in a backup the attacker can delete, and it is high value because it happens before the visible damage.

The prerequisite is that the logs exist. Data access logging is frequently off by default, and the cost of turning it on everywhere is real, which is the tension described in Cloud Logging and Cloud Storage costs. Decide deliberately which sources are worth their ingestion cost, rather than defaulting to everything or nothing.

Detection as code and compliance are the same artefact

This is the part that pays for the work twice.

An auditor asking how you detect unauthorised access wants evidence. A versioned repository with rules, review history, test results and a coverage map is a far better answer than a screenshot of a console, and it is the same evidence you would assemble anyway for the frameworks in one control set across frameworks.

Several frameworks require monitoring and detection capability and, increasingly, evidence that it is maintained rather than merely present. A git history showing rules added, tuned and retired is exactly that evidence, produced as a side effect of doing the work properly.

The things people forget

• Field mappings are the hard part. Two log sources describing the same event use different field names, and a rule that converts cleanly can still match nothing.
• Log normalisation upstream saves rule complexity. Deciding a schema at ingestion is worth more than clever rules downstream.
• Detection depends on retention. A rule looking back seven days is useless if the logs are kept for three.
• Volume changes break assumptions. A rule with a threshold tuned last year fires constantly after the service grows.
• Alert routing is part of the rule. Severity, destination and response note belong in the file, not in a separate system.
• Public rules need attribution and review. Importing a repository wholesale produces noise and a false sense of coverage.

What to do this week

Export your current detection rules from your SIEM into a git repository, as they are, with no conversion. That single act gives you a diffable baseline and usually reveals two things immediately: how many rules exist that nobody can explain, and how many reference systems you no longer run. Deleting the second group is the fastest improvement available. We start the detection workstream of a security engagement with exactly that export.