Practice — write Sigma detection rules and a SOAR playbook

This exercise combines Module 4 into one working detection-and-response chain. You will write a Sigma rule that detects a specific suspicious behaviour, confirm it would fire correctly against sample log data, and then design a SOAR playbook that responds automatically the moment that Sigma-based alert triggers, connecting detection engineering directly to automated response the way a real security operations workflow does.

Analogy🏏Cricket

💪 Think of it like fitness: you spend weeks training individual movements — the squat, the press, the pull — but a real test is the circuit that chains them into one continuous effort, proving they work together under load, not just in isolation. This exercise is that circuit for Module 4. You will write a Sigma rule that detects a specific suspicious behaviour, confirm it fires correctly against sample logs, then design a SOAR playbook that responds automatically the instant that alert triggers. Chaining detection straight into response is what turns separately-drilled skills into the single continuous workflow a real security operation actually runs.

Step 1 — Choose and scope the detection. Target a concrete, well-understood behaviour: multiple failed SSH logins from a single source IP followed by one success, the same brute-force-then-success pattern from Lesson 20's correlation rule. Write this as a Sigma rule targeting authentication logs, tagging it with the relevant MITRE ATT&CK technique for credential access so its coverage is visible in any later gap analysis.

Analogy🏏Cricket

♟️ Think of it like chess: rather than vaguely resolving to 'play better', a serious student drills one concrete, well-understood pattern at a time — a specific opening trap — until they recognise it instantly and know the refutation cold. Step one of this exercise scopes the detection just as narrowly: target the concrete brute-force-then-success pattern of multiple failed SSH logins from one source IP followed by a success, the exact sequence from the earlier correlation lesson. Write it as a Sigma rule against authentication logs and tag it with the MITRE ATT&CK credential-access technique, so its coverage shows up plainly in any later gap analysis of the board.

yaml

title: SSH Brute Force Followed by Successful Login
status: stable
logsource:
  category: authentication
  product: linux
detection:
  failures:
    event.action: 'login_failed'
  success:
    event.action: 'login_success'
  timeframe: 10m
  condition: failures | count(by source.ip) >= 5 and success
level: high
tags:
  - attack.credential_access
  - attack.t1110

Step 2 — Validate against sample data. Assemble a small set of sample log lines representing both the malicious pattern, five or more failures then a success from one IP, and a benign pattern, a single mistyped password followed by a normal successful login, and manually trace your rule's condition against each to confirm it fires only on the malicious case, exactly as Lesson 21's testing guidance recommended before any rule reaches production.

Analogy🏏Cricket

🍳 Think of it like cooking: before a new dish reaches a single customer, the chef tastes it against a known standard — a portion seasoned exactly right and one deliberately wrong — to confirm the recipe distinguishes good from bad. Step two of the exercise is that taste test for your Sigma rule. Assemble sample log lines for the malicious case, five or more failures then a success from one IP, and a benign case, a single mistyped password followed by a normal login, then trace the rule's condition against each by hand. Confirm it fires only on the genuinely bad plate, exactly as the testing guidance demanded before any rule reaches production.

text

# Sample events to trace the rule against
# Malicious: 6 failures + 1 success, same IP, within 4 minutes -> SHOULD fire
# Benign: 1 failure + 1 success, same IP, normal typo pattern -> should NOT fire
# Benign: 6 failures, no eventual success within window -> should NOT fire
#         (rule requires the success step, per Lesson 20's correlation logic)

Step 3 — Design the response playbook. Sketch a SOAR playbook triggered by this specific Sigma-based alert. Automate the safe, reversible steps first: enrich the source IP against threat intelligence, and check whether the same IP has targeted other accounts recently. Gate the disruptive step, disabling the compromised account or blocking the source IP at the firewall, behind analyst approval, following Lesson 22's guidance on reserving automation for low-risk actions.

Analogy🏏Cricket

💰 Think of it like finance: a well-designed banking app lets small, reversible actions happen automatically — checking a balance, flagging an odd charge — while anything drastic and hard to undo, like wiring a large sum abroad, is held behind an explicit confirmation step. Step three designs the response playbook on the same principle. Automate the safe, reversible moves first: enrich the source IP against threat intelligence and check whether it has targeted other accounts recently. Then gate the disruptive step — disabling the account or blocking the IP at the firewall — behind analyst approval, reserving automation for the low-risk actions just as the SOAR lesson advised.

yaml

trigger: sigma_rule == "SSH Brute Force Followed by Successful Login"
steps:
  - action: enrich_ip_reputation(alert.source_ip)
  - action: search_related_alerts(alert.source_ip, window="24h")
  - action: notify_slack(channel="#security-ops", summary=alert.summary)
  - approval_required: disable_account(alert.username)
  - approval_required: block_ip_at_firewall(alert.source_ip)

Step 4 — Trace the full chain and review. Walk through the scenario end to end: the malicious log pattern arrives, your Sigma rule fires, the SIEM raises the alert, and the playbook executes its automated steps before pausing for approval on the disruptive ones. Confirm every step maps back to a lesson in this module, and consider what dashboard KPI from Lesson 23 would show whether this exact detection-and-response chain is working well over time.

Analogy🏏Cricket

⚽ Think of it like sports: a coach reviewing a rehearsed set piece traces it end to end on the tape — the trigger run, the pass, the automated movements everyone drilled, and the single moment where a player must read the situation and decide. Step four walks your detection-and-response chain the same way: the malicious log pattern arrives, the Sigma rule fires, the SIEM raises the alert, and the playbook runs its automated steps before pausing for approval on the disruptive ones. Confirm every move maps back to a lesson in this module, and pick the dashboard KPI that would show, over a whole season, whether this exact play keeps working.

Analogy🏏Cricket

💼 Think of it like business: a well-run company handles a standard customer order as one smooth pipeline — the system detects the order, routing passes it cleanly to fulfilment, the warehouse packs it automatically, and only a flagged high-value exception lands on a manager's desk for a human sign-off before it ships. This exercise assembles exactly that pipeline for security: Sigma detects the pattern, the SIEM raises a clean alert, the playbook's safe steps run on their own, and only the disruptive action waits for an analyst's approval before the response is confirmed. Detection, orchestration, automation, and judgment each play their part in one continuous operation.

Chain detection to response: a Sigma rule feeds directly into a triggered SOAR playbook.
Scope detections narrowly around a concrete, well-understood malicious pattern.
Validate rules against both malicious and benign sample data before trusting them.
Automate safe, reversible response steps; gate disruptive ones behind approval.
Trace the full chain end to end and connect it back to a dashboard KPI for ongoing review.