Frontend Labs
⋯

Chapter 57 — Hands-on: build and validate a detection suite

Brief

Build a real detection suite end to end: telemetry pipeline, a prioritised backlog derived from this guide's own attack-path labs, Sigma rules through the full lifecycle, live validation via adversary emulation, a ransomware-specific canary, and a measured ATT&CK coverage heat map — the capstone that proves Part 8's discipline actually works against the techniques you've practiced throughout this guide.

Setup

   * A lab SIEM/log stack: Elastic (or OpenSearch) + a Sigma backend, or
     Wazuh, or Splunk's free tier -- whichever you already have from
     earlier Parts.
   * Log sources from as many earlier labs as you can wire up: CloudTrail
     (Part 2), Kubernetes audit logs + Falco/Tetragon (Part 4), your
     application's structured security events (G1 Ch 50), a WAF/proxy
     log for the web labs (Part 6).
   * Atomic Red Team, Stratus Red Team, and/or CALDERA for live
     emulation.
   * MISP (or a simple feed import) for one piece of enrichment context.

Tasks

   1. TELEMETRY (Ch 52)
      [ ] Wire at least three source categories (cloud control plane,
          k8s audit/runtime, application) into the SIEM via a collector,
          normalised to a common schema.
      [ ] Set up a tiered retention: hot in the SIEM, a cold copy to
          object storage for at least one high-value source.

   2. BACKLOG (Ch 54)
      [ ] Pull together the attack-path findings from your Part 1-6
          labs. Score them with the path-risk formula including the
          detection-coverage-inverse factor.
      [ ] Produce a ranked backlog of at least 8 detections spanning at
          least 4 of this guide's earlier Parts.

   3. BUILD (Ch 51) -- for the top 5 backlog items
      [ ] Write the full Alerting and Detection Strategy (hypothesis,
          ATT&CK mapping, data source, false positives, priority,
          response) for each.
      [ ] Implement as Sigma rules with unit-test fixtures (positive and
          negative).
      [ ] Deploy to your SIEM.

   4. VALIDATE (Ch 51/2)
      [ ] For each, LIVE-VALIDATE by re-running the actual technique
          from its source lab (or the closest Atomic Red Team/Stratus Red
          Team equivalent). Record whether it fired and the latency.
      [ ] Tune at least one rule based on a discovered false-positive
          source.

   5. HUNT (Ch 53)
      [ ] Pick one operational threat-intelligence item (a real ISAC/CISA
          bulletin, or a plausible hypothesis from your own environment)
          and run one structured hunt against your telemetry. Document
          the outcome whether or not you find anything.

   6. RANSOMWARE CANARY (Ch 56)
      [ ] Implement a honeyfile canary and the shadow-copy-deletion /
          backup-service-stop detections. Live-validate with Atomic Red
          Team's T1490/T1489 techniques.

   7. MEASURE
      [ ] Build an ATT&CK Navigator heat map showing covered techniques
          (green, with a live-validation date), partially-covered
          (yellow), and gaps (red) across everything from Parts 1-8.
      [ ] Compute a rough precision figure for your rule set (of alerts
          fired during the validation runs, how many were the intended
          true positive vs an unexpected false positive).

   8. RESPOND (Ch 55)
      [ ] For one high-confidence detection, build a minimal automated
          response (isolate/quarantine) and test it against both a true
          positive and a deliberately-benign near-miss to confirm your
          confidence threshold is set appropriately before trusting it
          with anything destructive.

Deliverable

~/sec-lab/adv/reports/p8-detection.md: the telemetry architecture diagram, the full ranked backlog, the five Alerting and Detection Strategies with their Sigma rules and unit tests, the live-validation results (fired/latency/false- positive notes) for each, the hunt write-up, the ransomware canary validation, the ATT&CK coverage heat map, and the automated-response test results. Plus: "which single detection, if you could keep only one from this whole guide, would you keep — and why."

Definition of done

  • A working, normalised telemetry pipeline spanning at least three source categories with tiered retention.
  • A prioritised, risk-scored backlog of at least 8 detections derived from this guide's own attack-path labs.
  • Five detections built through the full lifecycle (hypothesis, Sigma rule, unit tests, live validation, tuning) with recorded results.
  • One documented threat hunt with an outcome, whether positive or negative.
  • A working ransomware canary and pre-encryption detections, live-validated.
  • An ATT&CK coverage heat map with live-validation dates.
  • One automated response tested against both a true positive and a deliberate near-miss.

Rubric (/100)

   Telemetry pipeline (sources, normalisation, tiering) .. 15
   Backlog: derived from real labs, correctly prioritised  15
   Five detections: full lifecycle, live-validated ....... 30
   Threat hunt: structured, documented outcome ........... 10
   Ransomware canary + pre-encryption detections ......... 15
   Coverage heat map + automated response test ........... 10
   Report ................................................ 5

Further reading

  • Synthesis: this capstone deliberately reuses every earlier Part's labs — re-read Part 1 Ch 1-2, Ch 51-56 together as one connected discipline before starting.
  • Tools: ATT&CK Navigator (mitre-attack.github.io/attack-navigator) for the coverage heat map; SigmaHQ, Atomic Red Team, and Stratus Red Team documentation for the build/validate loop.
  • Reference: revisit Part 1 Ch 2's prevent/detect/log/miss grid — this capstone is that same exercise run at the scale of a real, if small, program.

End of Part 8 — Milestone check

  • I can write a full detection through the lifecycle: hypothesis, ATT&CK mapping, Sigma rule, unit tests, live emulation validation, tuning, and measured maintenance
  • I design a telemetry pipeline with normalisation, tiered retention, and cost-aware routing, and I know what real breach dwell time implies for retention decisions
  • I can run a hypothesis-driven threat hunt sourced from operational intelligence, document a negative result as real value, and feed a finding back into automated detection
  • I can derive a prioritised detection backlog directly from an attack-path graph, ranked by risk and current coverage
  • I know the cloud/container-specific IR mechanics: isolate-don't- terminate, credential blast-radius containment via explicit deny, and encryption-context-scoped breach assessment
  • I can explain the ransomware kill chain, build a stage-4 detection and a honeyfile canary, and design backups that survive an attacker who specifically targets them
  • I built and validated a detection suite end to end against this guide's own attack-path labs, with a measured ATT&CK coverage heat map

Generated from real-life-security-guide-v1.md · 8 Oct 2026 16:36