siem-detection

Name: siem-detection
Author: briiirussell

114installs36forks

How to install siem-detection?

briiirussell/cybersecurity-skills/siem-detection

$npx -y skills add briiirussell/cybersecurity-skills --skill siem-detection

Installs into the current project.

Summary

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,'

Files · 1

View on GitHub

SKILL.md

1	# SIEM Detection — Detection Engineering
2
3	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.
4
5	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.
6
7	## Scope
8
9	This skill covers:
10	- Log source coverage assessment ("are we even collecting the events we'd need to detect X?")
11	- Rule authoring across major SIEM query languages (Sigma, KQL, SPL, Elastic ES\|QL, Chronicle YARA-L)
12	- MITRE ATT&CK mapping — every rule tagged with technique IDs for coverage analysis
13	- Detection-as-code workflows (rules in Git, CI tests, deployment automation)
14	- Alert tuning workflow — reducing false positives without losing true positives
15	- Coverage gap analysis using ATT&CK Navigator
16
17	This skill does NOT cover:
18	- Live alert triage (that's `incident-triage`)
19	- Building a SOC team or alert escalation criteria (`soc-operations`)
20	- Active threat hunting (`threat-hunting`)
21
22	## Methodology
23
24	### Step 1: Map log sources to ATT&CK coverage
25
26	Before writing any rule, audit what you can detect.
27
28	Categorize log sources by what they observe:
29
30	\| Category \| Sources \| Observes \|
31	\|---\|---\|---\|
32	\| Endpoint \| EDR (CrowdStrike, SentinelOne, Defender), Sysmon, osquery \| Process exec, file write, network, registry, parent-child \|
33	\| Network \| Zeek/Bro, Suricata, NSM, firewall, DNS query logs \| Connections, protocols, DNS queries, TLS metadata \|
34	\| Identity \| Okta, Entra ID, AD, Auth0, GCP/AWS sign-in \| Authentications, MFA, group changes, role assignments \|
35	\| Cloud \| CloudTrail (AWS), Audit Logs (GCP), Activity Log (Azure) \| API calls — what was created/changed/deleted \|
36	\| Application \| App logs, WAF logs, load balancer logs, gateway logs \| Request URLs, status codes, auth outcomes \|
37	\| SaaS \| Google Workspace, M365, Salesforce, GitHub audit \| Admin actions, sharing, sensitive doc access \|
38
39	Run a gap check:
40	- Pull the [MITRE ATT&CK Enterprise matrix](https://attack.mitre.org/matrices/enterprise/)
41	- For each technique relevant to your environment, ask: which of my log sources would surface this?
42	- Techniques with NO source mapped are blind spots — write them down before writing any rules
43
44	Common blind spots:
45	- Endpoint logs but no command-line argument capture (most Windows event logs default to logging only the binary, not the args)
46	- Cloud audit logs collected but `ReadOnly: true` events filtered out — pre-attack recon invisible
47	- No SaaS audit logs — every modern attack involves a SaaS pivot at some point
48	- App logs without correlation IDs — can't connect "WAF saw payload" to "app processed payload"
49
50	### Step 2: Pick the right detection model per case
51
52	Not every threat needs a SIEM rule. Match the detection model to what you're detecting.
53
54	\| Threat character \| Best model \| Example \|
55	\|---\|---\|---\|
56	\| Known IOC (hash, IP, domain) \| Threat-intel lookup \| Sysmon hash matches known malware \|
57	\| Known pattern (specific command, specific path) \| Signature rule \| `powershell.exe -enc <base64>` \|
58	\| Known anomaly (behavior outside baseline) \| Statistical detection \| Service account suddenly authenticating from new geography \|
59	\| Sequence of events \| Correlation rule \| Failed logon → success → privilege change in 5 min \|
60	\| Novel / never-seen-before \| Threat hunting (see `threat-hunting`) \| Hypothesis-driven SIEM search \|
61	\| Insider abuse \| UEBA / risk scoring \| Cumulative risky behaviors weighted over time \|
62
63	Signature rules are cheapest to write and easiest to tune; statistical detections need baseline data and produce more false positives in the first month.
64
65	### Step 3: Write the rule
66
67	#### Use Sigma as the source of truth where possible
68
69	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.
70
71	```yaml
72	title: AWS IAM CreateUser Followed by AttachUserPolicy
73	id: <UUID>
74	status: experimental
75	description:

People who liked this also viewed

6 picks

Type

siem-detection

114installs36forks

View on GitHub

How to install siem-detection?

briiirussell/cybersecurity-skills/siem-detection

$npx -y skills add briiirussell/cybersecurity-skills --skill siem-detection

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SIEM Detection — Detection Engineering
2
3	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.
4
5	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.
6
7	## Scope
8
9	This skill covers:
10	- Log source coverage assessment ("are we even collecting the events we'd need to detect X?")
11	- Rule authoring across major SIEM query languages (Sigma, KQL, SPL, Elastic ES\|QL, Chronicle YARA-L)
12	- MITRE ATT&CK mapping — every rule tagged with technique IDs for coverage analysis
13	- Detection-as-code workflows (rules in Git, CI tests, deployment automation)
14	- Alert tuning workflow — reducing false positives without losing true positives
15	- Coverage gap analysis using ATT&CK Navigator
16
17	This skill does NOT cover:
18	- Live alert triage (that's `incident-triage`)
19	- Building a SOC team or alert escalation criteria (`soc-operations`)
20	- Active threat hunting (`threat-hunting`)
21
22	## Methodology
23
24	### Step 1: Map log sources to ATT&CK coverage
25
26	Before writing any rule, audit what you can detect.
27
28	Categorize log sources by what they observe:
29
30	\| Category \| Sources \| Observes \|
31	\|---\|---\|---\|
32	\| Endpoint \| EDR (CrowdStrike, SentinelOne, Defender), Sysmon, osquery \| Process exec, file write, network, registry, parent-child \|
33	\| Network \| Zeek/Bro, Suricata, NSM, firewall, DNS query logs \| Connections, protocols, DNS queries, TLS metadata \|
34	\| Identity \| Okta, Entra ID, AD, Auth0, GCP/AWS sign-in \| Authentications, MFA, group changes, role assignments \|
35	\| Cloud \| CloudTrail (AWS), Audit Logs (GCP), Activity Log (Azure) \| API calls — what was created/changed/deleted \|
36	\| Application \| App logs, WAF logs, load balancer logs, gateway logs \| Request URLs, status codes, auth outcomes \|
37	\| SaaS \| Google Workspace, M365, Salesforce, GitHub audit \| Admin actions, sharing, sensitive doc access \|
38
39	Run a gap check:
40	- Pull the [MITRE ATT&CK Enterprise matrix](https://attack.mitre.org/matrices/enterprise/)
41	- For each technique relevant to your environment, ask: which of my log sources would surface this?
42	- Techniques with NO source mapped are blind spots — write them down before writing any rules
43
44	Common blind spots:
45	- Endpoint logs but no command-line argument capture (most Windows event logs default to logging only the binary, not the args)
46	- Cloud audit logs collected but `ReadOnly: true` events filtered out — pre-attack recon invisible
47	- No SaaS audit logs — every modern attack involves a SaaS pivot at some point
48	- App logs without correlation IDs — can't connect "WAF saw payload" to "app processed payload"
49
50	### Step 2: Pick the right detection model per case
51
52	Not every threat needs a SIEM rule. Match the detection model to what you're detecting.
53
54	\| Threat character \| Best model \| Example \|
55	\|---\|---\|---\|
56	\| Known IOC (hash, IP, domain) \| Threat-intel lookup \| Sysmon hash matches known malware \|
57	\| Known pattern (specific command, specific path) \| Signature rule \| `powershell.exe -enc <base64>` \|
58	\| Known anomaly (behavior outside baseline) \| Statistical detection \| Service account suddenly authenticating from new geography \|
59	\| Sequence of events \| Correlation rule \| Failed logon → success → privilege change in 5 min \|
60	\| Novel / never-seen-before \| Threat hunting (see `threat-hunting`) \| Hypothesis-driven SIEM search \|
61	\| Insider abuse \| UEBA / risk scoring \| Cumulative risky behaviors weighted over time \|
62
63	Signature rules are cheapest to write and easiest to tune; statistical detections need baseline data and produce more false positives in the first month.
64
65	### Step 3: Write the rule
66
67	#### Use Sigma as the source of truth where possible
68
69	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.
70
71	```yaml
72	title: AWS IAM CreateUser Followed by AttachUserPolicy
73	id: <UUID>
74	status: experimental
75	description:

People who liked this also viewed

6 picks

Type