Guides
Practical guides for detection engineers who keep rules in git. Each one names the commands and pages a platform documents, gives the read date, and ends with a checklist.
- Choosing a rule language per estate
Write detections in the language your SIEM runs, unless you operate more than one SIEM or expect to move. Then write Sigma and convert. Sentinel runs KQL, Splunk runs SPL, Google runs YARA-L, Elastic runs EQL and ES|QL, and Panther runs Python. Each choice trades portability for fidelity. - Converting Sigma with pySigma and what breaks
pySigma and sigma-cli convert one Sigma rule into queries for Splunk, Kusto and Elasticsearch, and Panther and Sekoia accept Sigma more directly. Conversion yields a query, not a deployed rule. Field mapping, correlation, rule metadata and unsupported modifiers are where converted rules quietly stop matching. - A detection-as-code pipeline from repository to SIEM
A detection-as-code pipeline has five stages: validate, test, review, deploy and verify. Panther, Elastic, Microsoft Sentinel, Google Security Operations and Splunk each document a CLI or repository connection for the deploy stage. None of them hands you a finished pipeline, so you wire the stages yourself. - Measuring ATT&CK coverage without fooling yourself
ATT&CK coverage numbers usually count tagged rules, not working detections. A technique is covered when a rule exists, runs, has data, and has been tested. Sentinel, Elastic, Panther and Hunters document a coverage view, but each measures a different thing, so read what the colours mean before quoting a percentage. - A 30-day plan to move an existing rule set into git
You can move an existing rule set into git in 30 days if you start with export and validation, not tests. Week one inventories and exports, week two builds the repo and CI, week three adds tests and a health baseline, week four switches deploys to the pipeline and drills rollback. - Rule health: noisy, silent, drifted and expensive rules
Rules fail four ways after deployment: they get noisy, go silent, drift when fields change, or cost too much to run. Sentinel, Elastic and Google document the most health signals. Most others document one or none, and field drift alerts tied to rules are close to absent across the set. - Unit tests and replay for detection rules
Unit tests check a rule against a handful of fixed events. Replay runs it over stored data to see volume and false positives. You need both, and platforms document them unevenly: Panther, Splunk and Elastic ship unit tests, Google and Sentinel lean on replay, and several vendors document neither. - Versioning, rollback and environment promotion for rules
Git gives you a history of the file. The SIEM holds the copy that runs, and some platforms keep their own revisions too. Elastic, Google, Sentinel and Splunk document rule history or audit. No platform read documents a full dev, staging and production promotion flow for rules, so you build that.