SOC › Module 5 › Lesson 1
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.
Visual · t29_rule_anatomy
Detection rule literacy. $SOC_LAB only. Original Cyberlium.
Opening
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 -WrapCheck 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.
Mission: dissect rule on YOUR lab scenario
1) Name five rule components. 2) Fill each for failed-auth threshold rule. 3) Set fictional severity and title. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Window + threshold together — ten failures in five minutes differs from ten in a week.
Knowledge Check
APPLY: Detection rule anatomy includes:
Multiple choice
Knowledge Check
APPLY: True or False: Time window affects whether repeated events trigger an alert.
True or False
Knowledge Check
APPLY: Rule anatomy literacy on Cyberlium uses:
Multiple choice