Open with the 2013 Target breach: attackers were inside Target's network for roughly 3 weeks before the company confirmed the intrusion — even though FireEye monitoring alerts had actually fired days earlier and were dismissed as noise. 40 million payment cards were exfiltrated. Ask: 'The controls fired. What failed?' Elicit that detection tooling is only half the equation — someone has to review and act on it. Then cite the industry statistic: median attacker dwell time is still ~10-16 days (Mandiant M-Trends). Frame today's essential question on the board: How do defenders know they've been attacked, and how fast?

1. 6m

   Detection is not prevention

   Content

   Security controls fall into two categories that students routinely conflate. Prevention controls (firewalls, access controls, encryption, IPS — intrusion prevention systems) try to stop an attack from succeeding. Detection controls (logs, monitoring, IDS — intrusion detection systems, file integrity monitoring, SIEM alerts) assume attackers will get through and are designed to reveal that fact quickly. An IDS inspects traffic and raises an alert; an IPS sits inline and can drop the packets. The letter difference is the whole point: 'D' watches, 'P' blocks. Detection matters because prevention is never perfect — zero-days exist, insiders exist, misconfigurations exist. The critical metric is dwell time: the gap between compromise and discovery. Every day of dwell time is more data exfiltrated, more lateral movement, more persistence installed.

   Delivery

   Emphasize the D-vs-P letter cue — students will lose points on the AP exam mixing IDS and IPS. Ask cold: 'A firewall blocking port 445 — detection or prevention?' (prevention) 'A rule that emails the SOC when 20 failed logins happen in 60 seconds — detection or prevention?' (detection) Head off the misconception directly: a system with strong encryption and MFA still needs monitoring, because credentials get phished and keys get stolen. Prevention reduces likelihood; detection reduces impact by shortening dwell time.

2. 7m

   The monitoring pipeline: sources → SIEM → alerts

   Content

   Modern detection is a pipeline. Event sources — authentication servers, web application logs, endpoint agents, firewall logs, DNS queries, cloud audit trails — continuously emit log records. Those records are shipped to a SIEM (Security Information and Event Management platform such as Splunk, Elastic Security, or Microsoft Sentinel) where they are normalized into a common schema, stored, and then evaluated by correlation rules. A correlation rule is a piece of logic that fires when a pattern across one or more sources matches an attack signature — for example, 'more than 10 failed logins from a single source IP within 2 minutes, followed by one success' correlates a brute-force pattern that no single log line reveals on its own. Matching rules produce alerts routed to analysts. This is why raw logs alone don't protect anything: a 4 GB auth log with 20 malicious lines buried in it is useless without correlation and review.

   Delivery

   Walk students through the pipeline diagram left to right, naming a concrete source at each stage. Emphasize normalization — a Windows event ID 4625 and a Linux 'Failed password' line both mean 'failed authentication' but look nothing alike; the SIEM makes them comparable. Ask: 'If you turn on logging but never send it to a SIEM or read it, what have you gained?' (an audit trail after the fact, but no timely detection). Pre-empt the misconception that logs are self-protecting.

3. 7m

   Baselines, anomalies, IOCs, and false positives

   Content

   Two complementary detection strategies. Signature-based detection looks for known-bad patterns — a specific malware hash, a known C2 IP, a SQL injection string. Anomaly-based detection first establishes a baseline of normal — average logins/hour per user, typical outbound data volume, usual process tree on a server — and alerts when live activity deviates by some threshold. The baseline-vs-anomaly graph illustrates this: a flat band of normal activity, then a sharp spike that crosses the threshold line and fires an alert. Both approaches emit IOCs — indicators of compromise — concrete observables an analyst can pivot on: a file hash, an IP, a registry key, a log pattern. The tradeoff is the false-positive rate: tighten thresholds and you catch subtle attacks but drown analysts in noise; loosen them and real attacks slip through. This is where alert fatigue killed Target — the alerts existed, but the signal-to-noise ratio was so bad they were dismissed.

   Delivery

   Anchor the graph: point out the baseline band, the threshold, and the anomaly spike. Give a concrete IOC example — the SolarWinds attack surfaced when analysts noticed the SUNBURST malware beaconing to avsvmcloud.com, a domain nobody in the org had ever contacted. Push students on tradeoffs: 'Your CEO gets 3 login-from-new-location alerts a day and complains. What do you tune, and what do you risk?' Correct the misconception that 'no alert = nothing happened' — sophisticated attackers stay under thresholds and may delete or forge logs (which is why audit logs should be shipped off-host in real time).

1. 15m

   Log analysis: identify the attack in an authentication logLab

   Targets AP Skill Category 3 Detect Attacks and Skill Category 1 Analyze Risk. Students work individually (5 min) then pair-share (3 min) to analyze the log below; debrief 7 min. Walk around and check that students are counting failed attempts per source IP and noting the successful login that follows. Correct answer: 203.0.113.45 executes a brute-force attack against user 'admin' — 12 rapid failures in under 30 seconds followed by a success at 02:14:33; the legitimate admin login from 10.0.4.22 during business hours is the baseline for comparison. Expected IOCs students should extract: source IP 203.0.113.45, target account 'admin', time window 02:14:04–02:14:33, user-agent 'curl/7.68.0' (non-browser), and the immediate post-login GET /admin/config.php. Student handout: Part 1 — The log excerpt (webapp auth log, timezone UTC) ``` 2024-03-14 09:02:11 LOGIN_SUCCESS user=admin src=10.0.4.22 ua=Mozilla/5.0 2024-03-14 12:47:03 LOGIN_SUCCESS user=jrivera src=10.0.4.31 ua=Mozilla/5.0 2024-03-14 14:19:55 LOGIN_FAIL user=jrivera src=10.0.4.31 ua=Mozilla/5.0 2024-03-14 14:20:08 LOGIN_SUCCESS user=jrivera src=10.0.4.31 ua=Mozilla/5.0 2024-03-15 02:14:04 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:06 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:08 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:10 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:12 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:15 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:18 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:21 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:24 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:27 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:30 LOGIN_FAIL user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:33 LOGIN_SUCCESS user=admin src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:34 GET /admin/config.php src=203.0.113.45 ua=curl/7.68.0 2024-03-15 02:14:41 GET /admin/users.php?export=1 src=203.0.113.45 ua=curl/7.68.0 ``` Part 2 — Answer the following (write full sentences): 1. Classify the attack. What type is it, and what specific evidence in the log supports your classification? 2. List four distinct IOCs an analyst should extract and could reuse to hunt for related activity. 3. Compare the 14:19:55 failure to the 02:14 sequence. Why is one benign and one malicious? Cite baseline reasoning. 4. Propose ONE detection rule (in plain English, threshold + time window + action) that would have alerted on this pattern. Then state one plausible false positive your rule would produce and how you would tune it.

   Materials

   • Student computer with text editor or terminal
   • Printed or digital copy of the auth log excerpt below

   Example outputs

   • Attack = credential brute-force (dictionary or password-spray against 'admin') that succeeded. Evidence: 12 LOGIN_FAIL entries from a single external IP 203.0.113.45 against one account in ~30 seconds, terminating in LOGIN_SUCCESS, immediately followed by access to /admin/config.php and a user export — classic post-compromise reconnaissance/exfiltration.
   • IOCs: (1) source IP 203.0.113.45, (2) user-agent string 'curl/7.68.0' targeting a login endpoint, (3) the 02:14:04–02:14:33 timestamp window, (4) URL pattern /admin/users.php?export=1 hit from a non-browser UA.
   • Detection rule: '≥ 8 LOGIN_FAIL from the same source IP within 60 seconds → alert and temporarily block the IP.' False positive: a legitimate user with a forgotten password and an auto-fill loop; tune by whitelisting internal RFC1918 ranges and requiring the failures to target a privileged account, or by adding a follow-on LOGIN_SUCCESS as the trigger.
2. 10m

   File integrity monitoring: catch the tampered file with SHA-256Lab

   Targets AP Skill Category 3 Detect Attacks. Students perform a live file-integrity check to see how one changed byte produces a completely different hash — the mechanism behind file integrity monitoring tools like Tripwire and AIDE. Circulate and verify students actually run the hash commands. Expected finding: the modified file's SHA-256 changes completely (avalanche effect); the other three are byte-identical to their originals. Student handout — run this on your machine: Part 1 — Create four baseline files Open a terminal in an empty folder and run: - `echo "user list v1" > users.txt` - `echo "config: prod" > config.txt` - `echo "admin=alice" > admin.txt` - `echo "logs enabled" > logging.txt` Part 2 — Baseline the hashes Run (Linux/macOS): `sha256sum *.txt` (or on macOS: `shasum -a 256 *.txt`) Run (Windows PowerShell): `Get-FileHash *.txt -Algorithm SHA256` Copy the four hashes into the table below. This is your known-good baseline. - users.txt = ______________________________________________________ - config.txt = ______________________________________________________ - admin.txt = ______________________________________________________ - logging.txt = ______________________________________________________ Part 3 — Simulate an attacker Close your eyes to your partner's screen. Partner picks ONE file and changes ONE character (e.g., `echo "admin=eve" > admin.txt`). Do NOT tell your partner which one. Part 4 — Detect the tampering Re-run the same hash command. Compare each new hash to your baseline. Any hash that differs — even by one character — means that file has been modified. Write your answers: 1. Which file was tampered with? How do you know? 2. Look at the changed hash vs the original. How many characters of the 64-character hash are different? What does that tell you about SHA-256's sensitivity to input changes? 3. An attacker who wanted to hide their edit might try to restore the original modification time (`touch -t`). Would that fool file integrity monitoring? Why or why not?

   Materials

   • Student computer with a terminal (Linux/macOS shasum or sha256sum; Windows: Get-FileHash in PowerShell)
   • Four small text files created at the start of the activity

   Example outputs

   • 'admin.txt was tampered with. Its baseline hash was 2c26b46b… and after modification it became 8f434346… — every other file's hash was unchanged.'
   • 'About 60 of the 64 hex characters differ. This is the avalanche effect — a single-bit change in the input produces a hash that looks completely unrelated to the original, so even the smallest tampering is unmissable.'
   • 'No. File integrity monitoring compares content hashes, not metadata. Changing the mtime with touch does not change the file's bytes, so the SHA-256 still differs from the baseline and the alert still fires.'

1. A financial services company deploys full-disk encryption, MFA, and a next-gen firewall. The CISO argues that because these prevention controls are strong, the company can defer investment in a SIEM and log review process. Evaluate this argument in 3–5 sentences. Reference dwell time and at least one specific attack scenario that would defeat the listed prevention controls. (Targets Skill Category 1 Analyze Risk and Skill Category 3 Detect Attacks.)

   short answerThe argument is flawed because prevention is never perfect: a phished MFA-fatigue attack or a stolen session token bypasses MFA, and encryption at rest does not protect data an authenticated attacker reads through the application. Without a SIEM and log review, the organization has no way to observe post-compromise activity, so dwell time grows unbounded — a breach could persist for weeks or months (median dwell time is ~10-16 days) before discovery, dramatically increasing data loss. Detection controls are what shorten dwell time and limit impact once prevention fails. The CISO should invest in the SIEM in parallel, not defer it.

2. Which of the following BEST distinguishes an IDS from an IPS?

   multiple choiceC. An IDS observes traffic and generates alerts on suspicious activity, while an IPS is inline and can block or drop the traffic it identifies as malicious. (A) Both block attacks, but an IPS only works on encrypted traffic. (B) An IDS is a hardware device and an IPS is software. (C) An IDS observes traffic and generates alerts on suspicious activity, while an IPS is inline and can block or drop the traffic it identifies as malicious. ← correct (D) An IDS uses signatures and an IPS uses only anomaly detection.

3. A web application normally receives 200-400 login attempts per hour with a ~3% failure rate. Over one hour the SIEM records 380 attempts with a 47% failure rate, and 90% of the failures target only three usernames. (a) Identify the most likely attack. (b) State two specific IOCs. (c) Propose a correlation rule and identify one realistic false-positive source. (Targets Skill Category 3 Detect Attacks.)

   short answer(a) A password-spray attack — the total volume is within baseline (380 vs 200-400) but the failure rate spiked from 3% to 47% and failures concentrate on a handful of privileged usernames, which is the signature of spraying common passwords across a few accounts to stay under per-account lockout thresholds. (b) IOCs: (1) failure rate ≥ 40% within a 1-hour window, (2) ≥ 90% of failures targeting a small set (≤ 3) of usernames; also acceptable: the specific source IPs or user-agents from those failed attempts. (c) Rule: 'If hourly failure rate deviates > 5σ from the 30-day baseline AND failures concentrate on ≤ 5 accounts, alert.' False positive: a password-policy rotation day when many users mistype their new passwords — tune by suppressing during scheduled rotation windows or requiring the failures to come from external IPs.

4. After an incident, an analyst notices that the last three hours of the web server's authentication log are missing, though the server was online the whole time. A junior colleague says, 'No alerts fired and now there are no logs to look at, so nothing happened.' What is wrong with this reasoning, and what detection control would have prevented this blind spot? (Targets Skill Category 3 Detect Attacks.)

   short answerThe reasoning is wrong on two counts. First, absence of an alert does not mean absence of an attack — attackers deliberately stay below alert thresholds and tamper with or delete logs to erase their tracks, so missing logs are themselves a strong IOC. Second, relying on logs stored on the compromised host means an attacker with root can rewrite history. The control that would have prevented this is centralized, real-time log shipping to a SIEM (or a write-once/append-only log store), so that even if the local log is wiped the SIEM copy — and an alert on 'log source went silent' — survive to reveal the intrusion.

• ☐Projector for auto-generated slide deck
• ☐One student computer per student (or per pair) with terminal access
• ☐Printed copies of the auth-log excerpt handout (one per student)
• ☐Printed copies of the file-integrity lab handout (one per student)
• ☐Whiteboard and markers for capturing student-proposed IOCs during debrief