SIEM Rules Named
SIEM rules named literacy covers platform syntax, field mappings, and backend conversion — map Sigma to SIEM on YOUR $PURPLE_LAB before production deploy.
Visual · t35_siem_rules_named
SIEM rules named literacy. $PURPLE_LAB only. Original Cyberlium.
Sigma converts, SIEM executes — literacy teaches platform rule anatomy so lab conversions stay testable on hosts you own.
SIEM rules translate Sigma detection into platform syntax — Splunk SPL, Microsoft Sentinel KQL, Elastic EQL, Chronicle YARA-L. Field mappings align Sigma Image to process_name or EventData.Image. Backend tools — sigmac, pySigma — automate conversion with tuning for index and sourcetype. Cyberlium maps Sigma to SIEM on YOUR $PURPLE_LAB — write conversion row for one fictional rule with platform and field mapping notes. Next: Rule Lifecycle.
1. SIEM rule components (named)
Platform syntax: SPL pipe chain, KQL where clause, EQL sequence. Field mapping: Sigma Image → process_name or TargetImage. Index/sourcetype: where rule searches in YOUR lab SIEM. Alert action: severity, ticket creation, SOAR hook — on YOUR org tenant.
On $PURPLE_LAB, write conversion row — Sigma field, SIEM field, platform for one fictional T1059 rule.
Command guide
Try these commands — SIEM rule components (named)
═══ LINUX / macOS (Terminal Practice) ═══
Check system state and user context
Command — copy this
id whoami uname -a
Inspect network sockets listening for connections
Command — copy this
ss -tuln 2>/dev/null || netstat -tuln
Audit active processes
Command — copy this
ps aux | grep -v "\[" | head -15
═══ WINDOWS (POWERSHELL) ═══ Query user identity and system information
Command — copy this
whoami /all Get-ComputerInfo | Select-Object CsName, OsName, OsVersion
Primary tools to practice this lesson: grep, curl. Reference sites: Elastic detection rules (https://www.elastic.co/guide/en/security/current/prebuilt-rules.html); Splunk security content (https://github.com/splunk/security_content); Sigma convert (https://github.com/SigmaHQ/sigma). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why SIEM literacy prevents conversion surprises
Unmapped fields cause rules that never match. Wrong index searches empty datasets. Lab conversion tests on replay logs before production deploy catch mapping errors early.
Students document lab conversions on notes — production deploys follow DaC pipelines and purple re-tests.
3. Lab boundary
Forbidden: deploying converted rules to stranger SIEM tenants. Allowed: SIEM rules named card — conversion row with $PURPLE_LAB fictional mapping.
Ship: SIEM rules named card for YOUR lab conversion. Next: Rule Lifecycle.
4. What you ship: SIEM rules named card for $PURPLE_LAB
Conversion row with field mappings. $PURPLE_LAB named. chmod 600.
5. What you record before the next lesson
Date. SIEM rules named card. $PURPLE_LAB named. File t35-m04-l02-siem-rules-named.txt chmod 600.
6. Wrong vs right: stranger networks vs YOUR purple lab
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
- Wrong: Deploy converted rule without field mapping test. Target stranger SIEM tenant for practice.
- Right: Write SIEM rules named card for YOUR $PURPLE_LAB. Next: Rule Lifecycle.
Mission: map Sigma to SIEM on YOUR lab
1) Name three SIEM platforms. 2) Write conversion row for one Sigma field. 3) Note index/sourcetype for lab tenant. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Test conversion on replay logs — mapping on paper is not mapping in production.
APPLY: SIEM rule conversion primarily maps:
APPLY: True or False: Field mapping aligns Sigma Image to platform process fields.
APPLY: SIEM rules literacy on Cyberlium uses: