# INSTRUCTOR GUIDE — Day 4 AI as SOC force-multiplier

Answer key and teaching notes for the Day 4 GUI labs (blue: AI-assisted
detection engineering; red: detection evasion). **Do not hand this to students.**
All data is synthetic and reuses the web01 incident from Day 2 (RFC5737 IPs,
`.invalid` domains).

## The two labs

- **Blue — AI-assisted detection engineering** (`day4-detection-eng`). Students
  use AnythingLLM over `attack-scenario.md` + `sigma-starter.yml` to draft
  detection rules for the web01 intrusion, then validate them. Maps to **D3
  AI-Assisted Security** (24% of the exam). The point is the generate → validate
  → repair loop: the AI drafts, the human checks.
- **Red — Red-team the detection** (`day4-evasion`). Students reason (from
  `evasion-challenges.md`) about how an attacker evades four naive rules and how
  to harden each. Defensive work from the attacker's angle.

## Blue lab — what a good answer contains

The single highest-value detection is **brute-force-then-success from the same
IP** (naive rule caught late otherwise). A strong rule correlates repeated
`Failed password` events and a subsequent `Accepted password` from the *same*
SourceIP within a window — not just "many failures" and not just "a success".

Watch for the AI's two failure modes, because catching them IS the lesson:
1. **A rule that doesn't match the data.** The AI may invent field names sshd
   logs don't emit. Have students test against the real `auth.log`.
2. **A rule that fires on everything.** "Alert on any failed login" is useless.
   Push on false positives every time.

The other detections worth drafting: unusual-source login for a known account
(`deploy` not from `198.51.100.14`), new UID 0 account, security-service-stopped
(`auditd`), remote-script-to-shell egress, bulk export. The generate → validate
→ repair habit is the transferable skill — the AI accelerates a detection
engineer, it does not replace their judgment.

## Red lab — the through-line

Every naive rule fails the same way: it matches a **surface artifact** (a
string, a threshold, an IP, a tool name) instead of the **behavior**. Expected
evasions:
1. String match "UNION SELECT" → case/comment/encoding tricks; detect the
   injection *pattern* or the DB error responses instead.
2. Fixed threshold 20/min → slow to 19/min, distribute across IPs, spray
   usernames; detect the *ratio* of failures to successes across a window.
3. Blocklist IP → attacker rotates cheap cloud IPs; detect behavior, not
   address.
4. User-Agent name → trivially spoofed; detect request *behavior* (rate, paths,
   parameter shapes).

The debrief question: "what is the attacker's goal, and what signal of it can't
they cheaply change?" That distinguishes a rule that catches yesterday's attack
from one that catches tomorrow's.

## Classroom fit

- **Blue:** any detection/blue-team, SIEM, or Security Onion / Splunk unit —
  students already write rules; here the AI is the drafting partner.
- **Red:** offensive-security or detection-tuning units; pairs naturally with the
  blue lab so students build a rule, then try to beat it.

## Files students get

Blue: `attack-scenario.md`, `sigma-starter.yml`. Red: `evasion-challenges.md`.
No answer key ships in the pack.