AI Red Team · Module 5 · Detect

Detection Engineering, Threat Intelligence and Deception as Code

The lesson covers the engineering that feeds the SOC under DE.CM Continuous Monitoring and DE.AE Adverse Event Analysis. Participants build a detection as code with mapping, tests and rationale, take a threat report to a tested detection with an AI drafting assistant at Level 1 Assisted, structure and grade intelligence in STIX, register honeytokens, canaries and decoys as code with pre-approved reversible responses, and keep every step inside the legal boundary of the organisation's own estate.

Lesson 19 of 28Chapter 1990 minutes

Read the chapterThe whitepaperThe slides

All courses / AI Red Team / Module 5 / Chapter 19

Learning objectives

After the lesson the participant can:

Key concepts

Detection as code
Each detection is a file in a repository, changed through pull requests, review and pipeline tests, with the SIEM's deployed state derived from the repository. Sigma is the portable format the chapter uses, converted to the target platform's query language.
Rationale
The artefact that makes the reasoning reviewable: the motivating intelligence or finding, the targeted behaviour, the fields relied on and the variants knowingly not caught. The reviewer checks it for traceability, evidence, limits and consequence.
Tuning is detection change
Narrowing is how detections silently die, so every proposed exclusion is reviewed as a rule change. Regression on every repository, parser or log-source change catches a rule that stopped matching when a supplier changed a log format.
Grading by people
Grading separates source reliability from information credibility. AI may propose a grade, but an analyst assigns it. An AI summary is not a source: unsupported claims are removed, and a claim combined from sources of different reliability takes the weakest grade.
Honeytoken, canary and decoy
A honeytoken is a credential or record no legitimate process uses, a canary announces when it is read, and a decoy is a larger construct that looks real to an intruder. Each is entered in a version-controlled register with location, owner, alert and response playbook.

Interactive exercises

Do them here and get feedback at once. Choose a card and then where it belongs, or drag it.

Interactive exercise 1 · Match

Terms of detection, intelligence and deception

Match each term to what it is, as the chapter uses it.

Interactive exercise 2 · Scenario

A proposed exclusion

Apply the chapter's rules on tuning, as a detection engineer at Hansa Mutual.

Teaching plan

15 minThe teacher presents the five elements of a detection and walks through Nordvik Region's payee-change rule, its tests and the gap its rationale records.
15 minWork through the one-day path from report to deployed detection and the three properties of AI-drafted detections; participants apply the four soundness checks to a sample rationale.
15 minReview AI in the intelligence cycle, STIX with markings and grading, and the Hansa Mutual assessment with one AI claim removed.
35 minExercise: groups write a detection rationale with test cases and a decoy register entry for the same threat.
10 minGroups check each other's decoy entries against the legal boundary: synthetic content, no lure into misconduct, nothing that acts outside the estate.

Discussion

  1. The payee-change rule knowingly misses a compromised caseworker account using the web client. Why is recording that gap worth more than a rule that claims to cover everything?
  2. The book expects that tooling optimised for speed will try what it finds, and labels this an expectation, not an observation. How would you verify it in an exercise?
  3. A touched decoy may reveal a curious employee and not an intruder. How do data-protection law and consultation with employee representatives shape where you would place decoys?

Written exercise

Exercise · 35 minutes

Write a detection rationale and a decoy register entry

Choose one behaviour that matters to your organisation or to Hansa Mutual's claims portals, expressed as an ATT&CK or ATLAS technique. Part one: write the detection's rationale and tests, not the query: the motivating report or finding, the behaviour, the log source and fields relied on, the events that must and must not alert, the emulation from the catalogue that provides positive data, the expected false positives per day and the variants not caught. Part two: write a decoy register entry for the same path: type, placement, synthetic content and refresh, signal severity and route with triage bypass, the response playbook with pre-approved reversible actions at Level 3 Bounded and those needing approval, the estate-only boundary, legal and employee-representative review, and the verifying chaos experiment.

Deliverable: A detection rationale with test cases and stated gaps, and a decoy register entry in the structure of HM-DEC-0042.

Self-test

Choose an answer to see whether it is right, or open the answer below each question.

  1. In the one-day path from report to detection, what should an engineer do if no catalogued emulation exists for a technique?

    Show the answer

    B. Request a catalogue entry instead of writing ad hoc attack behaviour
    Step three says to run a catalogued, benign emulation per technique and, if none exists, to request a catalogue entry. Evidence must come from an emulation, not from an event written to match the rule.

  2. Why must a canary passage in a citizen-service assistant's retrieval store be kept from the public?

    Show the answer

    D. Because returning it to a resident would be misinformation from the authority itself
    Generated decoy content uses only synthetic records, and a canary passage returned to a resident would be misinformation from the authority itself, so a test verifies this after every retrieval change.

  3. Which statement reflects the chapter's legal boundary for deception and response?

    Show the answer

    A. No decoy, detection or playbook may contain a step that acts outside the estate
    Accessing another party's systems without authorisation is treated as an offence under national criminal law, and neither NIS 2 nor DORA authorises it. A passive request to an endpoint the organisation controls stays on the defensive side.