Rule Anatomy

Rule anatomy literacy names condition, threshold, timeframe, and action — map detection parts on YOUR $SOC_LAB failed-auth scenario without deploying to production.

Rule Anatomy• Audio Walkthrough

00:00/03:16

Visual · t29_rule_anatomy

Detection rule literacy. $SOC_LAB only. Original Cyberlium.

Every alert is a rule that fired — literacy names the parts before you paste noisy logic into a live tenant.

Detection rules combine log source, filter condition, aggregation threshold, time window, and alert action (create ticket, severity, tag). Example literacy: Win auth 4625 | count by src_ip > 10 in 5m → medium severity brute-force candidate on lab host LAB-WS-01. Cyberlium maps rule anatomy on YOUR $SOC_LAB scenario — fictional entities only. Next: Sigma Named.

1. Rule components (named)

Source: which log type feeds the rule. Condition: field predicates (EventCode=4625). Aggregation: count, distinct, sum. Window: 5m, 1h. Action: severity, title, assignment group — document on lab paper.

On $SOC_LAB, label each component for one brute-force candidate rule on YOUR auth sample.

Command guide

Try these commands — Rule components (named)

═══ LINUX / BASH (SOC Analyst Triage) ═══

Filter system logs for security-relevant warnings and errors

Command — copy this

journalctl -p 3 -xb --no-pager | head -20

Search for suspicious persistent cron entries or service changes

Command — copy this

ls -lat /etc/cron.* /etc/systemd/system/ | head -15

═══ WINDOWS POWERSHELL ═══ Triage recent system service installations (Event 7045)

Command — copy this

Get-WinEvent -FilterHashtable @{LogName='System';Id=7045} -MaxEvents 5 -ErrorAction SilentlyContinue | Format-Table TimeCreated, Message -Wrap

Check open listening network connections with process owners

Command — copy this

Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess | Sort-Object LocalPort

Primary tools to practice this lesson: grep, curl. Reference sites: Sigma specification (https://github.com/SigmaHQ/sigma/wiki/Specification); Sigma win 4625 rules (https://github.com/SigmaHQ/sigma/tree/master/rules/windows/builtin/security); MITRE T1110.001 (https://attack.mitre.org/techniques/T1110/001/). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.

2. Why anatomy precedes tuning

Noisy rules missing time windows flood L1. Anatomy questions on escalation: what threshold, what window, what exclusions exist? Students answer from lab rule sketch before touching vendor UI.

Defenders version rules and document false-positive history — lab notes practice that metadata.

3. Lab boundary

Forbidden: deploying untested rules to employer production SIEM. Allowed: rule anatomy diagram — five components filled for $SOC_LAB scenario.

Ship: rule anatomy diagram for YOUR lab brute-force scenario. Next: Sigma Named.

4. What you ship: rule anatomy diagram for $SOC_LAB

Source, condition, aggregation, window, action on lab scenario. $SOC_LAB named. NO prod deploy. chmod 600.

5. What you record before the next lesson

Date. Rule anatomy diagram. $SOC_LAB named. File t29-m05-l01-rule-anatomy.txt chmod 600.

6. Wrong vs right: stranger SIEM vs YOUR sample logs

Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.

Wrong: Deploy noisy rule to production without review. Skip time window in sketch.
Right: Write rule anatomy diagram for YOUR $SOC_LAB scenario. Next: Sigma Named.

Hands-on Exercise