Purple › Module 3 › Lesson 1
Detection as Code
Detection as code literacy names version-controlled rules, CI validation, and repo structure — read DaC patterns on YOUR $PURPLE_LAB detection repos before production deployment.
Visual · t35_detection_as_code
Detection as code literacy. $PURPLE_LAB only. Original Cyberlium.
Opening
Rules in tickets rot — literacy teaches detection-as-code so Sigma and SIEM rules live in version control on lab repos you govern.
Detection as code treats rules like software — YAML Sigma files in Git, CI pipelines that lint and test rules, pull requests for detection changes, and tagged releases aligned to ATT&CK coverage. Engineers review diffs, run unit tests against sample logs, and deploy through approved pipelines. Cyberlium outlines detection-as-code on YOUR $PURPLE_LAB — sketch repo structure and one fictional rule file path. Next: Telemetry Needs.
1. Detection-as-code components (named)
Repo structure: rules/, tests/, mappings/, docs/. Version control: Git with branch protection and PR reviews. CI validation: Sigma lint, log replay tests, false-positive baselines. Deployment: pipeline to SIEM or EDR lab tenant on YOUR org assets.
On $PURPLE_LAB, write DaC row — repo path, rule file name, CI check for one fictional T1059 rule.
Command guide
Try these commands — Detection-as-code 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: Sigma repo (https://github.com/SigmaHQ/sigma); Elastic detection as code (https://www.elastic.co/guide/en/security/current/rules-ui.html); Splunk security content (https://github.com/splunk/security_content). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Why DaC beats ad-hoc SIEM clicks
Console-only rules lack history and peer review. Untested deploys cause alert storms. Version-controlled rules survive analyst turnover and feed purple exercise re-tests.
Students sketch lab repo layout on notes — production DaC follows org Git standards and change windows.
3. Lab boundary
Forbidden: committing live victim logs or production secrets into lab repos. Allowed: detection-as-code card — repo structure with $PURPLE_LAB fictional rule example.
Ship: detection-as-code card for YOUR lab repo. Next: Telemetry Needs.
4. What you ship: detection-as-code card for $PURPLE_LAB
Repo structure, rule path, CI check. $PURPLE_LAB named. chmod 600.
5. What you record before the next lesson
Date. Detection-as-code card. $PURPLE_LAB named. File t35-m03-l01-detection-as-code.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
Store rules only in SIEM console with no Git history. Commit production API keys to lab repo.
Right
Write detection-as-code card for YOUR $PURPLE_LAB. Next: Telemetry Needs.
Mission: sketch DaC repo on YOUR lab
1) List repo folders: rules, tests, mappings, docs. 2) Write one fictional rule file path. 3) Name one CI validation step. 4) chmod 600.
Stuck? Ask Cyberlium AI Mentor
Rule without test is hope — DaC pairs every rule with a log replay test.
Knowledge Check
APPLY: Detection as code primarily means:
Multiple choice
Knowledge Check
APPLY: True or False: DaC repos should include tests/ for log replay validation.
True or False
Knowledge Check
APPLY: Detection-as-code literacy on Cyberlium uses:
Multiple choice