Detection, Investigation and Intelligence Tools
This chapter serves four connected activities of a security operation: engineering detections, investigating what they raise, hunting for what they miss, and turning intelligence about threats and vulnerabilities into decisions. It treats tools of all four kinds. The artefacts are the records that carry a detection from idea to retirement (DET-*), an investigation from alert to closed case (CASE-*), a hunt from hypothesis to conversion (HNT-*) and an intelligence item to a requirement (INTEL-*). The own tools are few: the series gives no software for this activity, only records and one Python interface sketch. The third-party tools are the platforms and open standards on which the records rest, among them Sigma, STIX and TAXII, MITRE ATT&CK, the exploit-prediction and exploited-vulnerability sources, and the SIEM, EDR and case-management categories. The methods are the practical guides that the originating books attach to the artefacts. The tools come chiefly from AI Red Team (Chapters 2, 11, 18 and 19) (4, Nordqvist, 2026) and AI Blue (Chapters 2, 5, 6, 8, 9 and 12) (8, Nordqvist, 2026), with the detection record for AI agents and the decay estimate from AI Purple (Chapters 3 and 12) (9, Nordqvist, 2026), the delegated patch playbook from The Transformed Security Architect (Chapter 10) (6, Nordqvist, 2026) and the first detection platform sketch from Architecture as Code (Chapter 9B) (1, Nordqvist, 2025).
The chapter answers two questions. Which formats and records carry a detection from idea to retirement? And how is an AI-assisted investigation recorded? The short answers are these. A detection is a versioned record with logic in a portable format, a mapping to adversary technique, tests, an owner, a cost budget and a review date; a case is a record in which every conclusion traces to evidence, and in which it is visible who or what reached it. The chapter does not repeat the reasoning of the originating books. It says what each tool is, when to reach for it, what it needs and what it produces, and where the book that defines it gives the rest.
Figure 12.1: The detection lifecycle as the series' records describe it. The dated decision at the end feeds back into review or a new requirement.
How to read the entries
Each principal tool has an entry in the format fixed in the chapter authoring guide. Where an originating book gives a full template, the chapter quotes it from the manuscript of that book as it stands at the date of this book, removing only whole fields, and says so. The records are illustrative in the originating books: they use the fictional organisations Nordvik Region and Hansa Mutual and invented dates. They are shown as a form to adapt, not as evidence that any organisation ran them. Third-party tools are described only as far as their own documentation or standard allows; what the series does with them is attributed to the series.
The chapter groups the tools into five families: detection records and rules, case records and the platforms around them, playbook records at the boundary with response, hunt records, and intelligence and vulnerability data. Chapter 13 takes up response and recovery, and Chapter 14 the loop that verifies detections.
Detection records and rules
Most organisations begin with detection content written by a supplier for an average customer and changed on the supplier's schedule. AI Red Team concludes that a detection the organisation cannot read, review and test is a dependency and not a capability (4, Nordqvist, 2026). The tools of this family make each detection a file in a repository with an owner, tests and a date on which someone must decide again. They sit at three levels. The rule format (Sigma) says what is detected. The detection record (DET-*) wraps the rule with the discipline around it. The checklists and estimates around the record say whether the detection can still be trusted.
Detection record (DET-*)
| Kind | Artefact |
| Origin | AI Blue, Chapter 6 and Appendix B.4 (8, Nordqvist, 2026) |
| Purpose | Defines a detection with its logic, data sources, ATT&CK mapping, tests, owner and review date. |
| Use when | A detection is written, adopted from a supplier or drafted by an assistant, and whenever its status changes. |
| Inputs | A detection requirement (from intelligence, a hunt or a finding), the detection logic, the schema and health of its data sources, test events. |
| Outputs | A merged, owned record that the SIEM deployment is derived from. |
| Identifier family | DET-NR-*, DET-HM-* (the same family is used in AI Purple and in the Sigma example of AI Red Team; see the findings) |
| Full template | AI Blue, Appendix A, Chapter 6 (DET-HM-0455, DET-NR-0001) |
The record is the central artefact of the chapter. Four fields carry its discipline. max_silence_minutes on each data source makes the detection's dependence on a log source testable: a detection over a source that has gone quiet is a declared claim, not a working one. The rollout block states in advance what happens to a noisy rule, a review that tunes, narrows or retires it when it exceeds its alert budget for two consecutive weeks, and an automatic revert at twice the budget. The cost block makes the price in analyst time visible. And review_date forces a decision to keep, change or retire the detection instead of letting it persist because nobody looked.
The worked example below is the record the planned figure calls for: a detection with test cases and a date on which its life is reviewed. AI Blue gives no field named for retirement; it uses review_date, about six months after the last simulation (three months for a high-severity detection), and the decision it forces is one of keep, change or retire. The example is quoted from AI Blue, Appendix A (illustrative), unchanged.
id: DET-HM-0455
title: Service account used from a host not seen before
version: 1.2.0
status: production
owner: team-detection-engineering # accountable: detection engineering lead
origin:
intelligence: INTEL-HM-0142
hunt: HNT-HM-0031
drafted_by: HM-SEC-002 # Level 1 Assisted, AIDR-0312
reviewed_by: detection-engineer-2
attack:
tactic: defence-evasion
techniques: [T1078] # Valid Accounts
logic:
format: sigma
ref: detections/sigma/identity/service_account_new_host.yml@v1.2.0
data_sources:
- name: idp-signin-log
required_fields: [account, account_type, result, source_host, source_market]
max_silence_minutes: 30
- name: service-account-baseline # source hosts seen in the last 30 days
max_silence_minutes: 1440
severity: medium
applies_in: [PL, DE, NL, SE, NO, UK, CH]
tests:
unit:
positive: tests/DET-HM-0455/service_account_from_new_host.json
negative: tests/DET-HM-0455/service_account_from_baseline_host.json
replay:
window_days: 30
expected_alerts_per_week: {max: 6}
simulation:
scenario: BAS-IDP-021
last_run: 2027-03-02
result: pass
cost:
alert_budget_per_week: 6
observed_alerts_per_week: 4
precision_30d: 0.75
rollout:
stages: [shadow-14d, pilot-shift, all-shifts]
tune_or_retire_review_if: alerts_per_week > alert_budget_per_week for 2 consecutive weeks
rollback_if: alerts_per_week > 2 x alert_budget_per_week for 2 consecutive weeks
review_date: 2027-09-02 # about six months after the last simulation
Watch for two things. The origin block names the drafting system and its level, which is what makes an AI-drafted detection auditable; a record that omits it cannot support the closure check described under case records. And the tests are only as independent as their authors: AI Blue requires at least one positive and one negative case that a person wrote or reviewed, and does not count tests produced by the same run as the logic.
Sigma (rule format)
| Kind | Third-party tool (open standard and rule repository) |
| Origin | AI Red Team, Chapters 19 and 26 (4, Nordqvist, 2026); AI Blue, Chapters 2, 6 and 9 and Appendix A; AI Purple, Chapters 5 and 10 |
| Purpose | A generic, open signature format for detection rules, described by SigmaHQ as a generic signature format for SIEM systems (78, SigmaHQ, n.d.). |
| Use when | A detection should survive a change of SIEM supplier, be reviewed as text and carry technique tags and tests. |
| Inputs | A log source, field conditions, ATT&CK tags. |
| Outputs | A rule file that a converter turns into the query language of the SIEM in use. |
| Identifier family | A rule id (a UUID in the Sigma example of AI Red Team); the DET-* record references the rule by path and version. |
In the series a Sigma rule is the logic of a detection record, and the record adds what Sigma does not: owner, cost and review date (4, Nordqvist, 2026) (8, Nordqvist, 2026). The three inventory entries for Sigma (from Books 4, 8 and 9) describe the same standard and are treated as one. The limit of what the series claims is that Sigma is portable in principle; the conversion toolchain's coverage of any particular SIEM is something to verify before relying on it. The ATT&CK technique identifiers that rules carry come from MITRE ATT&CK (67, MITRE, n.d.).
Detection rule with test cases (Sigma)
| Kind | Artefact |
| Origin | AI Red Team, Chapter 19 (4, Nordqvist, 2026) |
| Purpose | A Sigma rule with test cases and ATT&CK mapping, versioned as code. |
| Use when | A threat report or an information-sharing report describes behaviour the organisation cannot yet detect. |
| Inputs | A graded report, the data-source catalogue, benign emulation data. |
| Outputs | A rule, a test file stating which events must and must not alert, and a rationale naming the variants not caught. |
| Full template | AI Red Team, Chapter 19, "Worked example: a Sigma rule with test cases and ATT&CK mapping" |
The AI Red Team example is one of Nordvik Region's first own detections, written after a regional information-sharing group reported a compromised staff account used to change the bank account to which a benefit is paid. The rule is quoted below (illustrative; the book's header comment is kept).
# Illustrative: Nordvik Region, rules/benefits/payee_change_outside_role.yml
title: Benefit payee account changed outside the caseworker role
id: 6f1c2a8e-3b7d-4e52-9a61-2d84c0f7b913
status: test
description: >
Detects a change to the bank account a benefit is paid to when the change
is not made by a benefits caseworker through the case-management web client.
Motivated by information-sharing group report RGISG-2027-014.
author: Nordvik Region detection engineering (NR-DET-0007)
date: 2027-02-15
tags:
- attack.impact
- attack.t1565.001
- attack.defense-evasion
- attack.t1078
logsource:
product: nordvik_casemgmt
service: benefits_audit
detection:
selection:
event.action: payee_account_changed
filter_caseworker_web:
actor.role: benefits-caseworker
client.id: casemgmt-web
condition: selection and not filter_caseworker_web
falsepositives:
- Corrections by the finance unit during month-end reconciliation
level: high
The book's test file, which sits next to the rule, maps it to control CTRL-NR-BEN-012: a caseworker's change must not alert; a finance-role change through the batch API must; a benign emulation (EMU-NR-031) on a synthetic case must alert within five minutes; and a 30-day benign replay may produce at most four alerts. The rule does not catch a compromised caseworker account using the web client, and the rationale records that gap. The test file itself is described, not printed, in the book; Appendix B of AI Red Team marks the template as planned (see the findings).
Detection record for AI agents
| Kind | Artefact |
| Origin | AI Purple, Chapter 12 and Appendix B.12 (9, Nordqvist, 2026) |
| Purpose | A detection record, for example for an agent that exceeds its permission ceiling, with ATLAS tags and positive and negative tests. |
| Use when | An AI system or agent goes into production, or a red-team finding shows an agent action that raised no alert. |
| Inputs | The agent's permission manifest at a pinned version, the policy decision log, the tool-side audit log, a catalogued scenario. |
| Outputs | A tested, owned DET-* record with two separate conditions, routing that no AI may close, a replay budget and a link to a coverage record. |
| Identifier family | DET-HM-0561 (the example); FND-* for the finding it came from |
| Full template | AI Purple, Appendix A, "Detection record DET-HM-0561" |
The record extends the DET-* form with fields for the system owner, the ATLAS technique, a manifest-derived baseline and routing. Its logic keeps two conditions apart: a call denied under a ceiling rule (medium) and a call that was allowed but falls outside the manifest (high). The second pages the agent operator, who may revoke the agent's credentials at once, and neither condition is in a class that an AI closes by itself (9, Nordqvist, 2026). It extends the form; it does not replace the DET-* record. The companion method (below) says how to write it.
Detection record for an agent over its permission ceiling (method)
| Kind | Method |
| Origin | AI Purple, Chapter 12 (practical guide) |
| Purpose | Produce a tested, owned detection that fires when an agent calls outside its permission ceiling, and routes the alert within 15 minutes. |
| Use when | Writing the record above. |
| Inputs | The manifest registry, the policy log and tool-side log in the SIEM, a verified-clean 30-day window for the baseline. |
| Outputs | A merged record, a coverage record with last test date and an expiry. |
The guide's order matters: confirm the telemetry before writing logic, because a detection over an uncollected source is a declared claim; write the two conditions separately; add a baseline only for what the manifest cannot state, and re-baseline on a change of model, prompt template, manifest or tool. Its defaults (no more than five alerts a week in the replay, a first alert within 15 minutes, precision of at least 0.7 after tuning, a 90-day expiry for a priority agent) are the book's, to be adapted and written down.
Detection checklist for AI systems and agents
| Kind | Artefact |
| Origin | AI Purple, Chapter 12 and Appendix B.12 |
| Purpose | Lists the telemetry and detections needed for tool misuse, anomalous retrieval and permission-ceiling breaches. |
| Use when | Before an AI system goes into production. |
| Inputs | AI gateway and agent-runtime logs, the ATLAS technique list. |
| Outputs | A checklist and detection records. |
AI Purple describes the checklist in Appendix B and illustrates it in the chapter's practical guide; it gives no separate template, so the chapter cannot quote one.
Decay estimate (DCY-*)
| Kind | Artefact |
| Origin | AI Purple, Chapter 3 and Appendix A (9, Nordqvist, 2026) |
| Purpose | Estimates how fast detections decay between tests. |
| Use when | Deciding which detections to retest, and when a passing test has stopped being evidence. |
| Inputs | The last passing test of each detection, its age, the changes to its dependencies since, an expiry rule. |
| Outputs | A state per detection (current, at-risk, expired) and a dated action. |
| Identifier family | DCY-HM-2028-01 |
| Full template | AI Purple, Appendix A, "Decay estimate for three detections" |
The example gives priority detections a 90-day expiry and others 180 days. DET-HM-0455, tested on 2027-12-14 and then affected by an identity-provider connector upgrade, is at risk; a cloud-identity detection whose audit-log source was reassigned without updating its owner is expired, and "coverage record shows technique unverified" until it is retested or retired. This is the series' answer to the question what a passing test is worth after a year: it is worth something only while the thing tested has not changed.
Reviewing an AI-drafted detection (method)
| Kind | Method |
| Origin | AI Blue, Chapter 6 (practical guide) |
| Purpose | Accept a drafted detection only on evidence, at a review cost below the cost of writing it unaided. |
| Use when | An assistant or a person drafts a detection. |
| Inputs | The draft, the schema of the named data source, the replay result, the alert budget. |
| Outputs | A merged record whose origin names the drafting system, its level and the reviewer. |
Six steps: check grounding (every field and value exists in the source's schema, which the pipeline checks), check technique fit (a draft that cannot be explained without the report's strings is rejected), check that the tests are independent, check the cost against the alert budget (default for a new medium-severity detection: no more than six alerts a week for the whole SOC), name the owner and set the review date, and record the origin. AI Blue also measures the drafter: acceptance rate, rework, review time and early retirement. Hansa Mutual's assistant HM-SEC-002 produced 48 drafts in the first quarter of 2027 and 15 were merged, an acceptance rate of 0.31 (8, Nordqvist, 2026).
Taking a threat report to a deployed, tested detection in a day (method)
| Kind | Method |
| Origin | AI Red Team, Chapter 19 (practical guide) |
| Purpose | Turn a relevant threat report into a reviewed, tested and deployed detection within one working day, without lowering the bar for review. |
| Use when | A graded report describes behaviour the organisation does not detect. |
| Inputs | A graded report, the data-source catalogue, a catalogued benign emulation per technique. |
| Outputs | A live rule in the regression suite, a rationale naming its gaps, a recorded review and a coverage map entry. |
The day is budgeted: 30 minutes to triage and grade, one hour to draft at Level 1 Assisted, two hours to produce the data by catalogued benign emulation, one hour to test, one hour to review and one to deploy in stages (4, Nordqvist, 2026). The guide forbids writing ad hoc attack behaviour to produce test data; if no emulation exists, the request is for a catalogue entry. Defaults such as at most four expected false positives a day are to be adapted to the SOC's capacity.
Advanced threat detection platform (Python)
| Kind | Artefact |
| Origin | Architecture as Code, Chapter 9B (1, Nordqvist, 2025) |
| Purpose | A Python example of a threat detection platform for European organisations. |
| Use when | As an illustration of the interface of a detection service, not as a deployable tool. |
| Full template | Architecture as Code, Chapter 9B, "Advanced threat detection platform" |
The listing defines a severity enumeration, a SecurityFinding data class and an AdvancedThreatDetection class with methods to correlate sources for persistent threats, monitor GDPR compliance, assess supply-chain risk, generate an executive report and run automated incident response. The book states in the listing that it is an interface specification whose internal methods are stubs. The chapter does not reproduce it: it is Python, not a record, and it is not runnable as given. Its use is as a reminder that the detection output (the finding) has a structure.
SIEM, EDR, case management and SOAR (platform categories)
The series names four categories of platform rather than products (AI Blue, Chapter 2) (8, Nordqvist, 2026). The table gives the series' one-line description of each and the blue team function it serves.
| Category | What the series says it does | Functions |
|---|---|---|
| SIEM (also AI Purple, Chapters 9 and 12) | Collects, normalises and stores logs; runs detections; raises alerts; supports search. In AI Purple, the detection layer under test. | B2 Detect, B3 Investigate |
| EDR (AI Blue, Chapters 2, 8 and 10) | Records endpoint activity, detects on it, and can isolate a host or kill a process. | B2 Detect, B3 Investigate, B4 Respond |
| Case management and ticketing | Holds alerts, cases, assignments, evidence references and the audit trail. | B3 Investigate, B4 Respond, B5 Learn |
| SOAR | Orchestrates enrichment and response steps as playbooks across tools. | B3 Investigate, B4 Respond |
These are categories of software; no product is endorsed and the books give no source for any. The limit of the claim: the series asks of each that it expose the records of this chapter (a detection deployed from a repository, a case record kept in version control or exported, an audit trail), not that it be of a particular make.
Case records and the platforms around them
An investigation produces conclusions, and the question for the record is whether a second person can reproduce them without the AI that helped reach them. AI Blue answers with a case record in which evidence, queries and reasoning are separate, hashed and attributed; AI Red Team adds a record of how an AI triage verdict was grounded; and AI Blue adds a log of the analyst's own use of AI per step.
Grounded triage record
| Kind | Artefact |
| Origin | AI Red Team, Chapter 18 (4, Nordqvist, 2026) |
| Purpose | A JSON record of an AI triage verdict grounded in telemetry and asset context. |
| Use when | A triage assistant gives a verdict on an alert. |
| Inputs | The alert, the detection, evidence references to telemetry and policy. |
| Outputs | A record with a verdict, a priority, statements each tied to evidence, a list of what is not established, the model and prompt identifiers, the autonomy level and an empty field for the analyst's decision. |
| Identifier family | NR-SEC-001/triage/<date>/<number> |
| Full template | AI Red Team, Chapter 18, "Worked example: a grounded triage record" |
The two fields that matter are not_established, which records the absence of evidence (in the example, no endpoint events for 26 hours) instead of leaving a fluent gap, and analyst_decision: null, which shows at Level 1 that the verdict is a proposal. Nordvik Region's assistant NR-SEC-001 produced the example.
Case record (CASE-*)
| Kind | Artefact |
| Origin | AI Blue, Chapter 8 and Appendix B.6 (8, Nordqvist, 2026) |
| Purpose | Records evidence, queries, reasoning and who or what reached each conclusion so the case is reproducible. |
| Use when | Any case in which an AI wrote queries, drafted a timeline or proposed a conclusion; in practice every case. |
| Inputs | A detection, a mandate, a scope authorisation, hashed evidence, queries and their authors. |
| Outputs | A closed or open record, with corrections and hostile-content handling recorded. |
| Identifier family | CASE-HM-1207 (example), CASE-HM-1311, CASE-HM-1318 |
| Full template | AI Blue, Appendix A, Chapter 8 |
The example is a mailbox case at Hansa Mutual. The record separates the AI's work from the analyst's (written_by, rerun_by), keeps a corrections list in which the reviewer's changes to the AI draft are visible (a timestamp read as local time when it was UTC; an attribution to attacker infrastructure that the evidence did not support), and logs the hostile free-text field the agent read with the number of tool calls that followed it. The aware_at field starts the clock for reporting duties; it is the record's link to regulation, and the legal reading belongs to the book that defines it. The excerpt below removes whole fields (the evidence list, the query list and the hypothesis list) and keeps the rest as AI Blue gives it (illustrative).
case_id: CASE-HM-1207
market: NL
kind: account-compromise # the account holder is not the subject of the case
detection: DET-HM-0388 # external forwarding rule created
aware_at: 2027-05-18T06:09:00Z # clock start for reporting duties
severity: high
mandate: MND-HM-SOC-02
ai: {agent: HM-SEC-001, level: "2 Supervised", skill: investigate-mailbox/1.4.0}
scope:
authorised_by: duty-manager-hamburg
data: [idp_signin_log, mail_audit_metadata]
excluded: [message_bodies, attachments]
window: [2027-05-17T00:00:00Z, 2027-05-18T07:00:00Z]
timeline:
- {id: T-1, utc: 2027-05-18T05:58:12Z, claim: "sign-in from a network not seen before for this account", evidence: EV-01, status: corrected}
- {id: T-2, utc: 2027-05-18T06:03:41Z, claim: "external forwarding rule created", evidence: EV-02, status: corrected}
corrections:
- {entry: T-2, ai_draft_utc: 2027-05-18T04:03:41Z, fault: "audit log stamps UTC; read as local time (UTC+02:00) and converted"}
- {entry: T-1, ai_draft: "from attacker infrastructure", fault: "attribution not supported by EV-01"}
hostile_content:
- {id: HC-1, field: mailbox_rule_name, treated_as: data, tool_calls_after_read: 0}
review: {reviewer: market-reviewer-nl, started_from: evidence, closed: false}
Five checks before an AI-assisted case is closed (method)
| Kind | Method |
| Origin | AI Blue, Chapter 8 (practical guide) |
| Purpose | Establish that a case's conclusions rest on evidence a person has seen and can reproduce. |
| Use when | Before a person closes a case in which an AI drafted any part of the work. |
| Inputs | The case record, the evidence manifest, the permission log, the access log. |
| Outputs | A case record naming the five checks and their results, closed by the incident commander or SOC lead in their own name. |
The checks are grounding and alternatives, independent reproduction (by default all conclusion-critical queries and 20 per cent of the rest, at least three, by a route that does not use the AI), hostile content and permissions, custody, and scope and proportionality. The reviewer starts from the evidence, not the narrative. One in twenty timelines carries a seeded wrong entry so that the team can see whether review catches it (8, Nordqvist, 2026). For a high-severity case the review takes place within one working day of the analyst's conclusion.
Analyst AI-use log
| Kind | Artefact |
| Origin | AI Blue, Chapter 12 and Appendix A (Artefact 1) (8, Nordqvist, 2026) |
| Purpose | Records per step the route, usage mode, data class, purpose and checks of an analyst's own use of AI in a case. |
| Use when | An analyst uses an assistant or work tool while handling a case. |
| Inputs | The case identifier, the steps in which AI was used. |
| Outputs | A list attached to the case: for each step the route, mode, data class, purpose, how far the output was used, what it was checked against and the analyst. |
| Identifier family | Attached to a CASE-* (example CASE-HM-1318) |
| Full template | AI Blue, Appendix A, Chapter 12, "Artefact 1" |
This is the series' answer to the second question of the chapter from the analyst's side. The case record shows what an agent in the SOC's own pipeline did; the AI-use log shows what the analyst did with an assistant outside it. In the example a timeline draft ran in Mode 1 on restricted data and was edited; a query draft ran in Mode 3 and was used as drafted, checked against the query run log. AI Blue says elsewhere (Chapter 21) that such logs are team-level evidence and never per-person scoring; the works agreement clause that sets this rule belongs with the people tools of Chapter 22.
Playbook records at the boundary with response
A case ends in action, and the records of action belong to Chapter 13. They are named here because the planned structure of this chapter and the inventory both place them at the edge of investigation.
| Entry | Origin | One-line purpose | Treated in |
|---|---|---|---|
Playbook manifest (PBK-*, example PBK-HM-ISOLATE-01) |
AI Blue, Chapter 10 and Appendix B.8 | Codifies a response with trigger, corroboration, action class, approvals, rollback and stop path. | Chapter 13 |
| Incident response playbook as state machine | Architecture as Code, Chapter 9C | Playbook with Subscribe, Assess, Act, Document steps; described, no code. | Chapter 13 |
| AWS Step Functions, Azure Logic Apps, Temporal | Architecture as Code, Chapters 9C and 20 | Workflow engines named for playbooks as state machines. | Chapter 13 |
One link is worth stating here. The trigger of a playbook manifest lists the DET-* identifiers that may start it (in the example, DET-HM-0455 and DET-HM-0307), so that a change to a detection can be traced to the playbooks it affects.
Hunt records
A hunt looks for what the detections miss. Its product is a record that another hunter can review and repeat, and its most important field is the one that says what was not searched.
Hunt record (HNT-*)
| Kind | Artefact |
| Origin | AI Blue, Chapter 9 and Appendix B.7 (8, Nordqvist, 2026) |
| Purpose | Records a hunt's hypothesis, data, queries, result and coverage statement, with a conversion target. |
| Use when | Every hunt, including one proposed by an assistant and one that finds nothing. |
| Inputs | A hypothesis from an intelligence record, a scoped data set, a reviewed query pack, a cost budget. |
| Outputs | A merged record with a result, a coverage statement, and either a detection identifier or a repeat date. |
| Identifier family | HNT-HM-*, HNT-NR-* |
| Full template | AI Blue, Appendix A, Chapter 9 (HNT-HM-0031) |
The example hunts for a service account of a claims export job used from a host outside its registered set. It records 214 matched events, all read by a person, 211 explained by a scheduler migration (change CHG-PL-2291) and three opened as a case. Its coverage block lists what was searched (41 accounts in one group), what was not (118 accounts outside it), a data gap (no host-level logon telemetry on nine legacy file servers) and a technique variant not covered. The conversion block hands the gap to detection engineering as DET-HM-0455, the record quoted earlier. The record is not quoted here for reasons of length; the origin of the detection record above shows the link. The coverage statement turns a null result from reassurance into information: it says what the queries could and could not have found.
Four-week hunt cycle (method)
| Kind | Method |
| Origin | AI Blue, Chapter 9 (practical guide "Running a four-week hunt cycle") |
| Purpose | Run a hypothesis-driven hunt from choice to a detection or a dated repeat. |
| Use when | Running a standing hunt programme. |
| Inputs | Candidate hypotheses (including AI-proposed ones), a data-platform cost budget. |
| Outputs | A reviewed hunt record. |
The weeks are: choose and scope, with a query budget; draft and review the query pack (no query runs on the full period before a seven-day sample, and none exceeds 10 per cent of the hunt's budget without the platform owner's agreement); run and read the events, reading the top ten of any ranked list and a random ten below the line; close with the coverage statement and the conversion. The cost rule protects B2 Detect, because the platform that hunts is the platform that detects.
Intelligence and vulnerability data
Intelligence is useful when it changes a decision, such as which detection to write (4, Nordqvist, 2026). The tools in this family record the intelligence, grade it, structure it for exchange and carry it into requirements; the second half of the family prioritises vulnerabilities, where the decision is which to fix first and who may decide.
Intelligence record (INTEL-*)
| Kind | Artefact |
| Origin | AI Blue, Chapter 5 and Appendix A (8, Nordqvist, 2026) |
| Purpose | Records an intelligence item and traces it to a hunt and a detection requirement. |
| Use when | A report, sector-sharing item or other intelligence arrives that may change what the blue team does. |
| Inputs | The source, its reliability, an AI extraction of techniques and indicators, a reviewer's grounding check. |
| Outputs | A verdict, a hypothesis, and the hunt and detection requirement it produces, with a review date and a decision record. |
| Identifier family | INTEL-HM-0142 (example) |
| Full template | AI Blue, Appendix A, Chapter 5 |
The record keeps what a reviewer rejected (in the example, an attribution to a named actor that the source supported only as similarity), carries an expiry on indicators and states seeded_error_in_batch: caught. It links forward to the HNT-HM-0031 hunt and the DET-HM-0455 requirement, the chain this chapter follows.
Weekly intelligence-to-detection routine
| Kind | Artefact |
| Origin | AI Blue, Chapter 5 and Appendix A (intel/routine.yaml) |
| Purpose | Configures a weekly routine that turns intelligence into hunts and detection requirements. |
| Use when | Setting up the intelligence cycle of a SOC. |
| Outputs | A routine with cadence, extraction at Level 1 Assisted with no tools that act, a reviewer who differs from the analyst, seeded errors, a 30-day conversion window and a default 28-day indicator expiry. |
Its defaults are illustrative and meant to be adapted to the works agreement and risk appetite. Reporting is at team level, never by name.
AI-assisted threat assessment (STIX report)
| Kind | Artefact |
| Origin | AI Red Team, Chapter 19 (4, Nordqvist, 2026) |
| Purpose | A STIX 2.1 report object for an AI-assisted intelligence assessment graded by people. |
| Use when | An assessment is shared or stored in a structured form and AI helped extract or translate. |
| Inputs | Source reports, technique mappings, a grade assigned by an analyst. |
| Outputs | A report with a confidence value, an ATT&CK external reference, a data marking, and custom properties recording the grading and the AI assistance. |
| Full template | AI Red Team, Chapter 19, "Worked example: an AI-assisted assessment in STIX" |
The example shows Hansa Mutual's cell recording ai_claims_without_source_removed: 1, which is the property to copy: the assessment states how many AI claims without a source were removed. The custom properties carry an organisation prefix (x_hansa_) and are the series' own extension, not part of STIX. AI Red Team adds that shared intelligence carries its restrictions into every system that processes it, so that an assessment marked for a closed community is not sent to an external model whose terms allow retention.
Building an AI-aware threat profile (method)
| Kind | Method |
| Origin | AI Red Team, Chapter 2 (practical guide) |
| Purpose | Produce a short, versioned threat profile labelled by evidence and translated into requirements. |
| Use when | Before choosing which detections and emulations to prioritise, and at least quarterly thereafter. |
| Inputs | The organisation's exposure, at least one national or European synthesis, provider reports, its own incident and exercise findings. |
| Outputs | A profile with one entry per threat, by ATT&CK or ATLAS technique, each labelled, with requirements and an owner. |
The guide starts from exposure, not from the news. It writes entries at the level needed to design a control or test, never as procedures, and links each to detections and emulation scenarios so that a gap shows as a missing link.
STIX and TAXII
| Kind | Third-party tool (open standards) |
| Origin | Architecture as Code, Chapters 9B and 9C; AI Red Team, Chapters 10 and 19; AI Blue, Chapters 2, 5 and 11; AI Purple, Chapters 5 and 22 |
| Purpose | OASIS standards to structure (STIX 2.1) and exchange (TAXII 2.1) threat intelligence (79, OASIS Cyber Threat Intelligence (CTI) TC, 2021). |
| Use when | Intelligence is exchanged between organisations, a sector group or a threat-intelligence platform. |
| Inputs / outputs | STIX objects such as indicators, attack patterns and reports; TAXII defines how they are exchanged. |
The four inventory entries from Books 1, 4, 8 and 9 are the same pair of standards. The series adds that STIX objects carry a confidence property, external references and data markings, and adds its own record of how AI was used. A threat-intelligence platform, which AI Blue describes as holding indicators and reports and exchanging them in standard formats, is a category of software rather than a standard.
Vulnerability prioritisation sources
Four public sources recur in the series as inputs to a decision about which vulnerability to fix first, and they are used in combination, not alone.
| Source | Kind | What it is | Origin in the series |
|---|---|---|---|
| CISA Known Exploited Vulnerabilities (KEV) catalogue | Third-party tool (catalogue) | A catalogue of vulnerabilities for which exploitation has been observed (81, CISA, n.d.) | Books 3, 4, 5, 6, 8, 9 and 10 |
| European Vulnerability Database (EUVD) | Third-party tool (database) | ENISA's database of vulnerability information, launched on 13 May 2025 under the NIS 2 Directive (82, ENISA, 2025) | Books 4, 5, 6, 8, 9 and 10 |
| Exploit Prediction Scoring System (EPSS) | Third-party tool (score) | A FIRST score that estimates the probability that a vulnerability will be exploited (80, FIRST, n.d.) | Books 3, 4, 5, 6, 8 and 10 |
| SSVC | Third-party tool (method) | Named in AI Red Team, Chapter 11, as a decision-based prioritisation method suggested by the NCSC; the series gives it only a passing mention. CISA describes SSVC as a decision-tree method with the outcomes Track, Track*, Attend and Act (121, CISA, n.d.) | Book 4 |
The limit of the series' claim is that none of these is a verdict. AI Platform and Security cites FIRST as describing EPSS as a prioritisation input rather than a pass or fail threshold (Chapter 18) (3, Nordqvist, 2026) (80, FIRST, n.d.), and combines it with known exploitation and local exposure. Sixteen slice entries repeat these three sources across the books, three of them as combined entries ("EPSS, CISA KEV and EUVD", "Known-exploited vulnerability catalogues", "CISA KEV and EUVD"); the table treats them once. CVSS, a severity score named in passing in AI Platform and Security (Chapter 9), is a severity description and not a likelihood (122, FIRST, n.d.); the series does not rely on it for prioritisation and gives no source for it, so it is left to Appendix A.
Patch-window compression and delegated patch decisions
The series takes the prioritisation into a decision about who may act. Three tools form a chain.
| Kind | Method (patch-window compression); method (defining delegated patch decisions); artefact (delegated patch decision) |
| Origin | AI Platform and Security, Chapter 18; AI Red Team, Chapter 11 (3, Nordqvist, 2026) (4, Nordqvist, 2026) |
Patch-window compression prioritises patches by EPSS and known exploitation so that the window between disclosure and fix shrinks for the vulnerabilities that matter. Defining delegated patch decisions for known-exploited vulnerabilities is the practical guide: start with fixes for KEV-listed or EUVD-exploited vulnerabilities on internet-facing assets; state conditions (a supplier-published or internally proven fix, a rollback tested within 90 days, a post-change health check); set time limits (as a default, mitigation within 24 hours and the fix within 72 hours; seven days for internal assets); exclude what must not be delegated; record the decision as a versioned record; verify with a chaos experiment each quarter. The delegated patch decision (DPD-*) is that record. The example, quoted from AI Red Team, Chapter 11 (illustrative):
# Illustrative: Nordvik Region, delegated patch decision for the inference platform
kind: DelegatedPatchDecision
id: DPD-NR-001
version: 1.0.0
approvedBy: regional-director
proposedBy: ciso
scope:
assetGroup: inference-platform # hosts the citizen-service assistant
owner: platform-team
class:
trigger: [kev-listed, euvd-exploited]
conditions:
fixSource: supplier-published
rollbackTestedWithinDays: 90
postChangeHealthCheck: required
timing:
mitigationWithinHours: 24
applyIn: next-maintenance-window
maxHoursToFix: 72
changeBoard:
required: false
reportAfterwards: true
excluded: [irreversible-firmware-change, change-to-security-tooling]
evidence: [change-record, rollback-test-result, health-check-result]
The Transformed Security Architect, Chapter 10 (6, Nordqvist, 2026) records a second form of the same decision, the delegated patch playbook decision, as an AI Decision Record (AIDR-0554) with the patch-velocity policy HM-PATCH-SLO-2027. Its notable fields are agents.may_apply_fixes_in_production: false, so that the pipeline applies the fix under a person's delegated authority and not an agent, and an enforcement policy check that fails any change claiming the delegation without a rollback test inside 90 days. The two records differ in shape (a kind: DelegatedPatchDecision against an adr_id) and in organisation; see the findings. Both belong equally to Chapter 18, where delegation is treated; they are kept here because their trigger is intelligence data.
Other named sources
| Entry | Origin | One-line purpose |
|---|---|---|
| Big Sleep | AI Red Team, Chapter 11 | A Google Project Zero and DeepMind project on using language models to find vulnerabilities, cited in the series as evidence, not as a tool the reader adopts (15, Google Project Zero, 2024) |
| security.txt (RFC 9116) | AI Purple, Chapter 22 | A file format for vulnerability disclosure contacts (83, Foudil & Shafranovich, 2022) |
Across the usage modes
The records of this chapter do not change with the mode; who writes them and under what identity does. The table draws on the mode analysis of AI Red Team, Chapter 19, and the case and detection records of AI Blue (4, Nordqvist, 2026) (8, Nordqvist, 2026).
| Mode | Opportunity | Characteristic vulnerability | What the record must show |
|---|---|---|---|
| Mode 0 Ambient AI | Vendor detection content and verdicts in SIEM and EDR | Logic the organisation cannot read or test | That the detection exists as a record only if the organisation has taken it into its repository (the supplier-default route of DET-NR-0001) |
| Mode 1 Conversational assistants | Drafting rules, summarising reports | Telemetry or restricted intelligence pasted in | An AI-use log entry with route, data class and what the output was checked against |
| Mode 2 Embedded workplace assistants | Summaries inside SIEM and ticketing | Summaries that drop hedges or grades | Evidence references behind every statement of a case |
| Mode 3 Agentic work tools | A coding agent builds fixtures and tests | An agent with an engineer's credentials touching the repository | Test authorship in the DET-* record; tests not produced by the run that wrote the logic |
| Mode 4 Built AI applications | Drafting detections at scale (HM-SEC-002), triage (NR-SEC-001) |
Injection through threat reports; rules that never fire | Origin block with drafting system and level; not_established in triage |
| Mode 5 Autonomous production agents | An investigation agent (HM-SEC-001); an agent whose own actions are detected |
Own agents exceeding their mandate | Mandate, level and skill version in the case record; a DET-* record for the agent itself |
By autonomy level the series is consistent: AI drafts rules, tests and assessments at Level 1 Assisted, which is the default for all detection change; the pipeline deploys a reviewed rule after explicit approval at Level 2 Supervised; and Level 4 Autonomous is not used for detection logic, exclusions or decoy placement (4, Nordqvist, 2026). In the case record the investigation agent HM-SEC-001 runs at Level 2 Supervised. The hunt, intelligence and vulnerability records do not change by mode, except that a delegated patch decision is itself an act of delegation and is bounded by the conditions in the record.
Nordvik Region and Hansa Mutual
The two organisations use the same records at different scales; the facts below are those of the earlier volumes. Nordvik Region is a public authority with one security architect and six office-hours analysts and outsources out-of-hours monitoring under framework agreement NR-2025-044 (6, Nordqvist, 2026). It began by taking one supplier-default rule into the repository as DET-NR-0001, adopted on 2027-02-08 under decision AIDR-0701, with an alert budget of eight a week; it wrote the benefit payee Sigma rule after a sector report; its triage assistant NR-SEC-001 runs at Level 1; and it delegated fixes for KEV-listed or EUVD-exploited vulnerabilities on its inference platform under DPD-NR-001.
Hansa Mutual is an insurer with a group SOC, four detection engineers and a drafting assistant HM-SEC-002 at Level 1 Assisted. Its chain runs from sector report INTEL-HM-0142 through hunt HNT-HM-0031 to detection DET-HM-0455, which is later shown in a decay estimate to be at risk after a connector change. It investigates with HM-SEC-001 at Level 2 Supervised, as CASE-HM-1207 shows; it writes a detection record for its claims-triage agent (DET-HM-0561); and it delegates fixes to known-exploited vulnerabilities by a playbook under AIDR-0554.
Treatment of the slice
The inventory assigned 98 entries to this chapter. Of these, 56 are treated in an entry or named in a family table of this chapter (including combined entries for Sigma, STIX and TAXII, and the vulnerability sources, which merge 3, 4 and 16 slice entries respectively into single treatments). The three playbook entries are named in a table and recommended for Chapter 13. The other 39 entries were assigned to this chapter by the keyword rules but belong elsewhere, because they concern intake, drift, maturity, procurement, delegation, verification or people; they are listed under "Reassign" in data/findings/chapter_12.md. Appendix A holds every entry.
Summary
This chapter collected the tools for detection, investigation, hunting and intelligence. Its conclusions are these. A detection is a record, not a rule: logic in a portable format, a technique mapping, tests that a person has seen, an owner, an alert budget and a date. A passing test has a half-life, and a decay estimate says when it has run out. An AI-assisted investigation is recorded by a case record that separates what the AI did from what a person checked, by a log of the analyst's own use of AI, and by a closure routine that starts from evidence. A hunt is recorded with what it did not search. Intelligence records carry the reviewer's rejections as well as the accepted items, and the vulnerability sources inform a decision and do not make one. Across the usage modes, the form of the record stays the same and the identity under which it is written changes; Level 1 Assisted is the default for AI in detection change, and Level 4 Autonomous is not used for detection logic. The records chain by identifier, INTEL to HNT to DET to CASE, and that chain is the series' most useful lead for anyone who has to show an auditor how a detection came to exist.
Sources
- Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
- Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
- Nordqvist, G. AI Red Team: AI as an Active Part of Cyber Defence in European Enterprises and Public Authorities. (4, Nordqvist, 2026)
- Nordqvist, G. The Transformed Security Architect: Role, Craft and Career in the Age of AI in European Enterprises and Public Authorities. (6, Nordqvist, 2026)
- Nordqvist, G. AI Blue: How Artificial Intelligence Transforms the Blue Team in European Enterprises and Public Authorities. (8, Nordqvist, 2026)
- Nordqvist, G. AI Purple: How Red and Blue Learn Together When AI Joins the Loop in European Enterprises and Public Authorities. (9, Nordqvist, 2026)
- Big Sleep team, Google Project Zero and Google DeepMind. From Naptime to Big Sleep: Using Large Language Models To Catch Vulnerabilities In Real-World Code. (15, Google Project Zero, 2024)
- MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (67, MITRE, n.d.)
- SigmaHQ. Sigma: Generic Signature Format for SIEM Systems. (78, SigmaHQ, n.d.)
- OASIS Cyber Threat Intelligence. STIX Version 2.1. (79, OASIS Cyber Threat Intelligence (CTI) TC, 2021)
- Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). (80, FIRST, n.d.)
- Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. (81, CISA, n.d.)
- European Union Agency for Cybersecurity. European Vulnerability Database (EUVD). (82, ENISA, 2025)
- Foudil, E. A File Format to Aid in Security Vulnerability Disclosure (security.txt). (83, Foudil & Shafranovich, 2022)
- Cybersecurity and Infrastructure Security Agency. Stakeholder-Specific Vulnerability Categorization (SSVC). (121, CISA, n.d.)
- Forum of Incident Response and Security Teams. Common Vulnerability Scoring System SIG. (122, FIRST, n.d.)