detection-engineering

Detection Engineering

Detections are code: versioned, documented, tested, reviewed. You propose; humans review and deploy. Never claim a rule is deployed.

Inputs that trigger work

• Hunt found activity with no alert (detection gap).
• Incident where first detection was late (dwell time > 0).
• Rule producing repeated false positives (tuning).
• New TTP from threat intel relevant to the environment.

ADS (Alerting and Detection Strategy) — Palantir framework

Every proposal documents:

1. Goal — what behaviour it detects.
2. Categorization — ATT&CK tactic/technique.
3. Strategy Abstract — how, at a high level.
4. Technical Context — data sources, fields, platform details.
5. Blind Spots and Assumptions — what it misses, what must be true.
6. False Positives — known benign triggers.
7. Validation — how to generate a true positive to test it.
8. Priority — alert severity and why.
9. Response — what the analyst should do when it fires.

Rule formats

Prefer Sigma (portable) with a Wazuh mapping note; use native Wazuh XML when the logic depends on Wazuh decoders or if_sid chaining.

Sigma essentials: title, id (UUID), status: experimental, description, references, author, date, tags (attack.t1110.001), logsource (product/service/category), detection (selections + condition), falsepositives, level.

Wazuh mapping notes:

• Custom rules live in local_rules.xml (or files under /var/ossec/etc/rules/), IDs 100000–120000, so they don't collide with the stock ruleset. Write them as custom rule 100210 in findings.
• Chain on stock rules with <if_sid> (the parent matched this event) or <if_matched_sid> plus frequency / timeframe (a count of earlier matches). Model frequency rules on the stock sshd brute-force rule 5712, which fires after 8 matches of rule 5710 from the same source within 120 seconds and then stays quiet for 60. As a custom rule 100210 that reads:

  <rule id="100210" level="10" frequency="8" timeframe="120" ignore="60">
    <if_matched_sid>PARENT_SID</if_matched_sid>
    <same_source_ip />
    <description>...</description>
  </rule>
  

  Other correlation options in the stock ruleset: <same_user />, <same_field>, <if_matched_group>.
• Map Sigma fields to decoded Wazuh fields (data.win.eventdata.commandLine, data.win.system.eventID, data.srcip, data.dstuser) with <field name="..."> PCRE2 or OS_Regex patterns. Field names drop the data. prefix inside rules (<field name="win.eventdata.commandLine">).
• Add <mitre><id>T1110.001</id></mitre>, a meaningful <group> (plus compliance groups such as pci_dss_10.2.4 if it supports a requirement), and set the level with the classification in alert-triage. Level 12+ pages people.
• To tune a noisy stock rule, prefer a child rule at level 0 matching the benign pattern (<if_sid>PARENT</if_sid> + fields) over editing the stock rule. Changes to stock files are lost on upgrade.
• Load wazuh-rules-and-decoders for decoders and rule evaluation order, and wazuh-windows-sysmon for Windows/Sysmon field paths.