/siem-detection

name: siem-detection
description: "Engineer and audit SIEM detection rules — log source coverage, Sigma / KQL / SPL / Elastic query authoring, MITRE ATT&CK mapping, false-positive tuning, and detection-as-code workflows. Use when the user mentions 'SIEM,' 'detection engineering,' 'detection rules,' 'Sigma,' 'KQL,' 'SPL,' 'Splunk,' 'Sentinel,' 'Elastic,' 'Wazuh,' 'Chronicle,' 'detection-as-code,' 'MITRE ATT&CK mapping,' 'log coverage,' 'alert tuning,' 'use case development,' or needs help building or improving security detections."
allowed-tools: Read, Write, Bash, Grep, Glob, WebSearch

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:**

| Category | Sources | Observes | |---|---|---| | Endpoint | EDR (CrowdStrike, SentinelOne, Defender), Sysmon, osquery | Process exec, file write, network, registry, parent-child | | Network | Zeek/Bro, Suricata, NSM, firewall, DNS query logs | Connections, protocols, DNS queries, TLS metadata | | Identity | Okta, Entra ID, AD, Auth0, GCP/AWS sign-in | Authentications, MFA, group changes, role assignments | | Cloud | CloudTrail (AWS), Audit Logs (GCP), Activity Log (Azure) | API calls — what was created/changed/deleted | | Application | App logs, WAF logs, load balancer logs, gateway logs | Request URLs, status codes, auth outcomes | | SaaS | Google Workspace, M365, Salesforce, GitHub audit | Admin actions, sharing, sensitive doc access |

**Run a gap check:**

• Pull the [MITRE ATT&CK Enterprise matrix](https://attack.mitre.org/matrices/enterprise/)
• 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.

| Threat character | Best model | Example | |---|---|---| | Known IOC (hash, IP, domain) | Threat-intel lookup | Sysmon hash matches known malware | | Known pattern (specific command, specific path) | Signature rule | `powershell.exe -enc <base64>` | | Known anomaly (behavior outside baseline) | Statistical detection | Service account suddenly authenticating from new geography | | Sequence of events | Correlation rule | Failed logon → success → privilege change in 5 min | | Novel / never-seen-before | Threat hunting (see `threat-hunting`) | Hypothesis-driven SIEM search | | Insider abuse | UEBA / risk scoring | Cumulative risky behaviors weighted over time |

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
| proje