Wazuh NIST CSF 2.0 Rule Pack
The problem
Wazuh detects plenty. Proving to an auditor that a given alert maps to a given NIST CSF 2.0 subcategory is a separate job done in spreadsheets, months later, from memory. The alert and the compliance evidence live in different systems and drift apart immediately.
The idea
Put the mapping in the alert. Every rule in the pack emits its NIST CSF 2.0 subcategory as a Wazuh group and its MITRE ATT&CK technique in the rule metadata, so a single alert JSON already carries full framework context by the time it reaches the dashboard.
An SSH brute-force alert arrives tagged nist_de.cm-01 and nist_rs.ma-02, with T1110.001 and its tactic and technique names attached. Nobody has to reconstruct that mapping afterwards, because it was never separate from the detection.
Coverage
Fifty active detections across five NIST functions. Detect carries the bulk of it with 36 rules across DE.AE-02, DE.AE-03, DE.CM-01, DE.CM-03 and DE.CM-09. Protect has 11 across PR.AA-01, PR.AA-05 and PR.DS-01. Identify, Govern and Recover have one each: ID.RA-03, GV.PO-01 and RC.RP-01.
The skew towards Detect is honest rather than accidental. A SIEM rule pack is a detection instrument; claiming deep Govern or Recover coverage from log rules would be exactly the kind of overclaiming that makes compliance mapping worthless.
The detections themselves cover the everyday (sudo escalation, new local admin accounts, cron modification, SSH brute force) as well as the ones that mean the day is already bad: LSASS memory access, DCSync, Kerberoasting, pass-the-hash, volume shadow copy deletion, Defender tampering via PowerShell.
Evidence as a build artefact
Each rule ships with a synthetic trigger.log that must fire it and a benign.log that must not. A static evidence validator runs without Wazuh at all; a live harness runs the same corpus through wazuh-logtest against a real manager. Current result: 57 PASS, 0 FAIL.
The benign corpus is the half that matters. A rule that fires on its trigger log proves very little. A rule that stays silent on traffic designed to look almost like the trigger is the one you can put in front of an analyst without burning their attention.
One rule per file, organised by primary NIST function. No batch dependencies, so any single rule can be deployed, disabled or forked without touching the rest.
Scope and limits
Every project page on this site carries this section. If a tool is not ready for something, the honest place to say so is next to the claim, not three pages into a README.
- Community-maintained. Not an official Wazuh repository and not endorsed by Wazuh Inc.
- Rules map only where there is explicit telemetry-supported alignment to a subcategory. Coverage gaps are left as gaps rather than filled with weak mappings.
- Requires endpoint prerequisites: Sysmon and audit policy on Windows, auditd and iptables logging on Linux. Without them a large share of the pack simply never fires.
- Respond (RS) and Recover (RC) coverage is thin by design and is on the roadmap.
Building something in this territory, or hiring for it?