Siem Detection

SIEM Detection — Detection Engineering

Build, audit, and maintain SIEM detection content — the rules that fire alerts. Distinct from incident-triage (responds when alerts fire) and from soc-operations (runs the SOC that triages alerts). This skill is the engineering layer: log coverage, rule authoring, tuning, and detection-as-code workflows.

Cross-references: incident-triage for what happens after the alert, threat-hunting for proactive hypothesis-driven hunts that often graduate into detection rules, breach-patterns for detection ideas pulled from public breach disclosures, soc-operations for the alert-triage operations on top of the detections engineered here.

Scope

This skill covers:

• Log source coverage assessment ("are we even collecting the events we'd need to detect X?")
• Rule authoring across major SIEM query languages (Sigma, KQL, SPL, Elastic ES|QL, Chronicle YARA-L)
• MITRE ATT&CK mapping — every rule tagged with technique IDs for coverage analysis
• Detection-as-code workflows (rules in Git, CI tests, deployment automation)
• Alert tuning workflow — reducing false positives without losing true positives
• Coverage gap analysis using ATT&CK Navigator

This skill does NOT cover:

• Live alert triage (that's incident-triage)
• Building a SOC team or alert escalation criteria (soc-operations)
• Active threat hunting (threat-hunting)

Methodology

Step 1: Map log sources to ATT&CK coverage

Before writing any rule, audit what you can detect.

Categorize log sources by what they observe:

Run a gap check:

• Pull the MITRE ATT&CK Enterprise matrix
• For each technique relevant to your environment, ask: which of my log sources would surface this?
• Techniques with NO source mapped are blind spots — write them down before writing any rules

Common blind spots:

• Endpoint logs but no command-line argument capture (most Windows event logs default to logging only the binary, not the args)
• Cloud audit logs collected but ReadOnly: true events filtered out — pre-attack recon invisible
• No SaaS audit logs — every modern attack involves a SaaS pivot at some point
• App logs without correlation IDs — can't connect "WAF saw payload" to "app processed payload"

Step 2: Pick the right detection model per case

Not every threat needs a SIEM rule. Match the detection model to what you're detecting.

Signature rules are cheapest to write and easiest to tune; statistical detections need baseline data and produce more false positives in the first month.

Step 3: Write the rule

Use Sigma as the source of truth where possible

Sigma is the cross-SIEM detection format. Write the rule in Sigma; auto-convert to your backend via sigmac / sigma-cli / pySigma. Even if you only target Splunk today, future-you will thank you.

title: AWS IAM CreateUser Followed by AttachUserPolicy
id: <UUID>
status: experimental
description: Detects an identity creating a new IAM user and immediately attaching an admin policy
references:
  - https://attack.mitre.org/techniques/T1136/003/
author: <name>
date: 2026-05-26
tags:
  - attack.persistence
  - attack.t1136.003
logsource:
  product: aws
  service: cloudtrail
detection:
  create_user:
    eventName: CreateUser
  attach_policy:
    eventName: AttachUserPolicy
    requestParameters.policyArn|contains: 'Administrator'
  timeframe: 10m
  condition: create_user and attach_policy
falsepositives:
  - Legitimate provisioning workflows (CI roles that bootstrap admin accounts)
level: high

KQL (Microsoft Sentinel / Defender / Azure Monitor)

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0
| summarize FailureCount = count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 5m)
| where FailureCount > 10
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(1h)
    | where ResultType == 0
) on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, FailureCount

(Failed logons spike on one user/IP, then a success on the same user/IP — classic password spray success.)

SPL (Splunk)

index=aws sourcetype=aws:cloudtrail
  (eventName=CreateUser OR eventName=AttachUserPolicy)
| transaction userIdentity.arn maxspan=10m
| where like(eventName, "%CreateUser%") AND like(eventName, "%AttachUserPolicy%")
| table _time, userIdentity.arn, eventName, requestParameters

ES|QL (Elastic)

FROM logs-aws.cloudtrail-*
| WHERE event.action == "CreateUser" OR event.action == "AttachUserPolicy"
| STATS create_count = COUNT(*) BY user.arn, event.action
| WHERE create_count > 0

(Use the LookML / KQL / SPL / ES|QL that matches your SIEM, but author the canonical version in Sigma.)

Step 4: Map to MITRE ATT&CK

Every rule should tag at least one ATT&CK technique. Coverage maps roll up to ATT&CK Navigator (navigator.mitre-attack.org):

• Export your rules with their ATT&CK tags
• Render onto the Navigator matrix
• Identify coverage gaps by tactic — "we have nothing for Initial Access via Phishing" is more actionable than "we need more rules"

The Navigator JSON format is open; building this report from your rules-as-code repo is a few hundred lines of Python and pays for itself the first time someone asks "what do we detect?"

Step 5: Tune

The false-positive lifecycle:

1. Deploy the rule with `level: experimental` for 1-2 weeks 2. Review every fire — true positive, false positive, suppressible? 3. For each FP, ask: can I narrow the rule (more specific filter) or add a tuning exception (allow-list specific known-good)? 4. Track the ratio — if FPs are > 80% after tuning, the detection model is wrong (signature might need to be statistical, or vice versa). Don't paper over a bad model with 100 allow-list entries. 5. Promote to `level: high` / production only after FP rate is acceptable

Rules that have never fired are also a signal — either the log coverage is broken, the query is wrong, or the threat truly hasn't occurred. Verify which by running a deliberate-test event through the system.

Step 6: Detection-as-code

Rules live in Git, not in the SIEM console.

detections/
├── aws/
│   ├── credential-access/
│   │   └── iam-create-user-attach-admin.yml
│   └── ...
├── windows/
├── linux/
└── identity/
    └── okta-password-spray.yml
.github/workflows/
└── detection-ci.yml

CI checks:

• Sigma validates (sigma-cli check)
• ATT&CK tag present and resolvable
• Description and references fields non-empty
• Backend translation succeeds (sigma convert -t splunk etc.)
• Optional: replay the rule against a known-good event store and assert hit count

Deployment: post-merge, push rules to the SIEM via API. Roll back via Git revert.

Output Format

Coverage assessment:

# SIEM Detection Coverage
## Environment: [name]
## Date: [date]

### Log sources mapped
| Source | Status | Notes |
|---|---|---|

### ATT&CK coverage
| Tactic | Techniques covered / total | Blind spots |
|---|---|---|

### Rule inventory
| Rule | ATT&CK | Severity | Status | Last fired |
|------|--------|----------|--------|------------|

### Tuning queue
[Rules in experimental / needing FP triage]

### Recommended next 30 days
[Prioritized — usually 3-5 items]

Per-rule documentation lives with the rule (Sigma YAML), not in a separate runbook. The description, references, and falsepositives fields are the runbook.

Boundaries

• Detection content for your own environment, or environments where the user has explicit authorization
• Refuse to write evasion rules or detections designed to flag legitimate security tools
• Detections that intentionally surveil employees beyond what HR/legal have approved are out of scope — escalate to the user
• Provide enough context with each rule that the analyst who triages the alert understands what to do; rules without that context produce alert fatigue

References

• MITRE ATT&CK Enterprise matrix
• MITRE ATT&CK Navigator
• Sigma rules repo (SigmaHQ/sigma)
• Florian Roth's "Detection Engineering" writings
• Splunk Security Essentials / Microsoft Sentinel content hub / Elastic detection rules repo
• "Detection Engineering Maturity Matrix" (Florian Roth)
• "The Pyramid of Pain" (David Bianco) — IOC value hierarchy
• NIST SP 800-92 (Computer Security Log Management)