From 97ef34a5052e7d753b425c0327ac67347d015813 Mon Sep 17 00:00:00 2001 From: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> Date: Fri, 23 Oct 2026 21:31:01 -0500 Subject: [PATCH 1/7] tub module 03 Detection Requirements README Signed-off-by: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> --- core03-detection-requirements/README.md | 28 +++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 core03-detection-requirements/README.md diff --git a/core03-detection-requirements/README.md b/core03-detection-requirements/README.md new file mode 100644 index 0000000..6588f3f --- /dev/null +++ b/core03-detection-requirements/README.md @@ -0,0 +1,28 @@ +# Detection Requirements +## Overview: +Covers deciding what to detect and in what order: where detection ideas come from, how to turn them into actionable requirements, and how to prioritize them against threats and the organization's actual risk and exposure. + +## Learning Objectives: +By the end of this module, learners should be able to: +* TBD + +## Prerequisites: +TBD + +## Lessons: +TBD + +## Boundaries: +TBD + +## Labs: +None yet + +## Datasets: +None yet + +## References: +- MITRE ATT&CK +- CISA Known Exploited Vulnerabilities (KEV) Catalog +- FIRST Exploit Prediction Scoring System (EPSS) +- MITRE Center for Threat-Informed Defense (CTID) publications From 3dee6c8c4be7cf6e0f8394ad31cff83a2493d536 Mon Sep 17 00:00:00 2001 From: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> Date: Fri, 23 Oct 2026 21:34:35 -0500 Subject: [PATCH 2/7] Add module 03 metadata Signed-off-by: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> --- .../module-metadata.yml | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 core03-detection-requirements/module-metadata.yml diff --git a/core03-detection-requirements/module-metadata.yml b/core03-detection-requirements/module-metadata.yml new file mode 100644 index 0000000..3ae90c1 --- /dev/null +++ b/core03-detection-requirements/module-metadata.yml @@ -0,0 +1,32 @@ +title: Detection Requirements + +slug: + +status: draft # draft | in-review | reviewed | stable | needs-update | deprecated + +version: + +summary: > + Covers deciding what to detect and in what order: where detection ideas + come from, how to turn them into actionable requirements, and how to + prioritize them against threats and the organization's actual risk and + exposure. + +learning_objectives: [] + +prerequisites: [] + +authors: + - Treyrob3 + +reviewers: [] # GitHub handles (without @) of independent approving reviewers + +maintainers: [] + +last_reviewed: null # YYYY-MM-DD, set by a maintainer on approval + +related_tracks: [] + +related_labs: [] + +related_datasets: [] From a3a3d14f80369b1a5dbb9310d96ca2dfd702c05b Mon Sep 17 00:00:00 2001 From: Tallis Jordan Date: Sun, 1 Nov 2026 22:56:29 -0500 Subject: [PATCH 3/7] Move module 03 to the right folder Signed-off-by: Tallis Jordan --- .../03-detection-requirements}/README.md | 0 .../03-detection-requirements}/module-metadata.yml | 0 2 files changed, 0 insertions(+), 0 deletions(-) rename {core03-detection-requirements => core/03-detection-requirements}/README.md (100%) rename {core03-detection-requirements => core/03-detection-requirements}/module-metadata.yml (100%) diff --git a/core03-detection-requirements/README.md b/core/03-detection-requirements/README.md similarity index 100% rename from core03-detection-requirements/README.md rename to core/03-detection-requirements/README.md diff --git a/core03-detection-requirements/module-metadata.yml b/core/03-detection-requirements/module-metadata.yml similarity index 100% rename from core03-detection-requirements/module-metadata.yml rename to core/03-detection-requirements/module-metadata.yml From f760daf8169c8d58af5694602ccdb79f3018b39f Mon Sep 17 00:00:00 2001 From: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> Date: Tue, 27 Oct 2026 11:17:17 -0500 Subject: [PATCH 4/7] Remove trailing colons Signed-off-by: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> --- core/03-detection-requirements/README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/core/03-detection-requirements/README.md b/core/03-detection-requirements/README.md index 6588f3f..15d9b11 100644 --- a/core/03-detection-requirements/README.md +++ b/core/03-detection-requirements/README.md @@ -1,27 +1,27 @@ # Detection Requirements -## Overview: +## Overview Covers deciding what to detect and in what order: where detection ideas come from, how to turn them into actionable requirements, and how to prioritize them against threats and the organization's actual risk and exposure. -## Learning Objectives: +## Learning Objectives By the end of this module, learners should be able to: * TBD -## Prerequisites: +## Prerequisites TBD -## Lessons: +## Lessons TBD -## Boundaries: +## Boundaries TBD -## Labs: +## Labs None yet -## Datasets: +## Datasets None yet -## References: +## References - MITRE ATT&CK - CISA Known Exploited Vulnerabilities (KEV) Catalog - FIRST Exploit Prediction Scoring System (EPSS) From d4e6db9033efc38d7876f2bc6439db7ed024ed13 Mon Sep 17 00:00:00 2001 From: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> Date: Tue, 27 Oct 2026 11:22:48 -0500 Subject: [PATCH 5/7] Draft lesson 4 Signed-off-by: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> --- core/03-detection-requirements/README.md | 32 +++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/core/03-detection-requirements/README.md b/core/03-detection-requirements/README.md index 15d9b11..ed69f9b 100644 --- a/core/03-detection-requirements/README.md +++ b/core/03-detection-requirements/README.md @@ -10,7 +10,37 @@ By the end of this module, learners should be able to: TBD ## Lessons -TBD +### 4. Risk & Exposure Context + +#### Learning Objectives + +- Explain how asset criticality, exposure, and vulnerability state change the priority of a detection requirement +- Use vulnerability intelligence (KEV, EPSS, CVSS) as inputs to detection requirements and describe the limits of each +- Identify when detection should act as a compensating control for risk that cannot be remediated in the near term +- Scope a compensating detection requirement to the asset's exposure and its remediation timeline + +#### Key Topics + +- Asset criticality: business impact, crown-jewel systems, and why the same technique warrants different priority on different assets +- Attack surface and exposure: internet-facing versus internal, identity exposure, and third-party or vendor access +- Vulnerability state as a detection input: + - CISA KEV: confirmed exploitation in the wild + - EPSS: likelihood of exploitation + - CVSS: severity rather than risk, and why it should not drive priority alone +- Detection as a compensating control: + - End-of-life and end-of-support systems the business depends on, such as point-of-sale systems and legacy reporting applications or databases + - Why remediation is often deferred: upgrade cost, operational downtime, and vendor dependencies + - Treating detection as an interim control while remediation remains a long-term goal +- Missing or failed preventive controls: where prevention is absent, detection carries more weight +- Requirement expiry: re-evaluating or retiring exposure-driven requirements when the exposure is remediated or the asset is decommissioned +- Sources of exposure context: vulnerability scanning, asset inventory and CMDB data, attack surface management, and cloud posture management + +#### Out of Scope + +- Operating a vulnerability management program (scanning cadence, patching workflows, SLAs) +- Combining risk factors into a final priority (Lesson 6) +- Telemetry required to observe exploitation (Module 02) +- Building exploitation detections (Module 05) ## Boundaries TBD From 508946820a573cea5e093f7af2fa929e40fe9dc7 Mon Sep 17 00:00:00 2001 From: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> Date: Tue, 27 Oct 2026 11:27:04 -0500 Subject: [PATCH 6/7] Implement lesson 6 Signed-off-by: Ronald Robertson <71863668+Treyrob3@users.noreply.github.com> --- core/03-detection-requirements/README.md | 32 ++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/core/03-detection-requirements/README.md b/core/03-detection-requirements/README.md index ed69f9b..1c8f27e 100644 --- a/core/03-detection-requirements/README.md +++ b/core/03-detection-requirements/README.md @@ -41,6 +41,38 @@ TBD - Combining risk factors into a final priority (Lesson 6) - Telemetry required to observe exploitation (Module 02) - Building exploitation detections (Module 05) +*** +### 6. Prioritization + +#### Learning Objectives + +- Combine threat, impact, exposure, feasibility, and effort into a defensible priority for a detection requirement +- Evaluate the strengths and failure modes of common prioritization approaches +- Decide when a risk should be addressed through detection, prevention, or explicit acceptance +- Communicate prioritization decisions to stakeholders in terms of risk reduction + +#### Key Topics + +- Prioritization inputs: threat relevance, potential impact, asset exposure, telemetry feasibility, and engineering effort +- Prioritization approaches: + - Qualitative tiers (high / medium / low) + - Weighted scoring models + - Threat-driven ranking (for example, prevalence of techniques in relevant threat activity) + - Coverage-gap-driven ranking +- Failure modes: + - Headline-driven priority: high-profile news creating pressure to act on threats with little relevance to the environment + - Severity over exposure: letting a single input such as CVSS outrank actual exposure and exploitability + - Remediation-only planning: relying on a long remediation effort that later stalls on an undiscovered dependency, with no interim detection in place + - False precision in scoring models, and prioritizing what is easy to build over what matters +- Detect, prevent, or accept: when detection is the right investment and when the better answer is a preventive control or documented risk acceptance +- Re-prioritization triggers: new threat intelligence, incidents, environment changes, and remediated exposure +- Explaining priority to stakeholders: tying decisions to risk reduction rather than rule counts, and grounding responses to headline threats in actual exposure + +#### Out of Scope + +- Detailed treatment of exposure and asset risk inputs (Lesson 4) +- Assessing telemetry availability (Lesson 5) +- Program-level backlog management, capacity planning, and metrics (Module 10) ## Boundaries TBD From 7e1c312ebc7b64b231789460cba0b4b770b71520 Mon Sep 17 00:00:00 2001 From: Tallis Jordan Date: Sun, 1 Nov 2026 22:47:25 -0500 Subject: [PATCH 7/7] Outline module 03 lessons and fill in metadata Signed-off-by: Tallis Jordan --- core/03-detection-requirements/README.md | 201 +++++++++++++++--- .../module-metadata.yml | 27 ++- 2 files changed, 192 insertions(+), 36 deletions(-) diff --git a/core/03-detection-requirements/README.md b/core/03-detection-requirements/README.md index 1c8f27e..a45f973 100644 --- a/core/03-detection-requirements/README.md +++ b/core/03-detection-requirements/README.md @@ -1,25 +1,108 @@ -# Detection Requirements -## Overview +# Detection Requirements + +## Overview + Covers deciding what to detect and in what order: where detection ideas come from, how to turn them into actionable requirements, and how to prioritize them against threats and the organization's actual risk and exposure. ## Learning Objectives -By the end of this module, learners should be able to: -* TBD + +By the end of this module, learners should be able to: + +- Write a detection requirement that states the behavior, required data, triggering conditions, context, and success criteria. +- Identify where detection ideas come from, and evaluate an idea's relevance to the environment. +- Extract detection requirements from a detection threat model. +- Use asset criticality, exposure, and vulnerability state to shape the priority and scope of a requirement. +- Determine whether a requirement can be met with available telemetry within organizational constraints. +- Prioritize requirements and communicate the decisions in terms of risk reduction. ## Prerequisites -TBD + +- Module 01: Detection Engineering Foundations +- Module 02: Telemetry & Data ## Lessons + +### 1. What A Detection Requirement Is + +**Learning Objectives** + +- Explain why requirements come before design, and why a blocked requirement is a valid outcome. +- Scope a vague detection request into a defined problem. +- Write a requirement that states the behavior, data, conditions, context, and success criteria. + +**Key Topics** + +- Starting from the problem, not a query +- Scoping questions (who, which systems, what data, what priority, what response) +- Visibility problems vs. detection problems +- Minimum contents of a requirement +- Verify, don't assume +- Requirements vs. hypotheses and designs + +**Out of scope** + +- Sources of detection ideas (Lesson 2) +- Feasibility in depth (Lesson 5) +- Hypotheses and design (Module 04) + +### 2. Sources of Detection Ideas + +**Learning Objectives** + +- Identify the sources detection ideas come from. +- Evaluate an idea's relevance to the environment. +- Explain why every request goes through the same intake. + +**Key Topics** + +- Threat intelligence +- Incidents and post-incident reviews +- Red team, penetration test, and purple team findings +- Threat hunting +- ATT&CK as a source +- Compliance and stakeholder requests +- News driven requests + +**Out of scope** + +- Researching a behavior (Module 04) +- Running a threat intelligence or threat hunting program +- Prioritizing ideas (Lesson 6) + +### 3. Threat-Informed Requirements + +**Learning Objectives** + +- Build a detection threat model. +- Translate threat scenarios into expected behaviors and required telemetry. +- Use ATT&CK to provide structure and find gaps without using it as a checklist. +- Derive requirements from a threat model. + +**Key Topics** + +- Why "detect everything" fails +- Threat modeling for detection +- Who attacks, what they want, how they get in, what they do next, and what they leave behind +- Threats to behaviors to telemetry to gaps to requirements +- ATT&CK as a tool +- Living threat models + +**Out of scope** + +- Asset and exposure context (Lesson 4) +- Coverage analysis of existing detections (Module 04) +- Researching a behavior in depth (Module 04) + ### 4. Risk & Exposure Context -#### Learning Objectives +**Learning Objectives** -- Explain how asset criticality, exposure, and vulnerability state change the priority of a detection requirement -- Use vulnerability intelligence (KEV, EPSS, CVSS) as inputs to detection requirements and describe the limits of each -- Identify when detection should act as a compensating control for risk that cannot be remediated in the near term -- Scope a compensating detection requirement to the asset's exposure and its remediation timeline +- Explain how asset criticality, exposure, and vulnerability state change the priority of a detection requirement. +- Use vulnerability intelligence (KEV, EPSS, CVSS) as inputs to detection requirements and describe the limits of each. +- Identify when detection should act as a compensating control for risk that cannot be remediated in the near term. +- Scope a compensating detection requirement to the asset's exposure and its remediation timeline. -#### Key Topics +**Key Topics** - Asset criticality: business impact, crown-jewel systems, and why the same technique warrants different priority on different assets - Attack surface and exposure: internet-facing versus internal, identity exposure, and third-party or vendor access @@ -35,23 +118,47 @@ TBD - Requirement expiry: re-evaluating or retiring exposure-driven requirements when the exposure is remediated or the asset is decommissioned - Sources of exposure context: vulnerability scanning, asset inventory and CMDB data, attack surface management, and cloud posture management -#### Out of Scope +**Out of scope** - Operating a vulnerability management program (scanning cadence, patching workflows, SLAs) - Combining risk factors into a final priority (Lesson 6) - Telemetry required to observe exploitation (Module 02) -- Building exploitation detections (Module 05) -*** +- Building exploitation detections (Module 05) + +### 5. Feasibility + +**Learning Objectives** + +- Map a requirement to the log sources, events, and fields it needs. +- Rate a requirement's feasibility. +- Identify platform, organizational, and compliance constraints. +- Record an unsupported requirement as a telemetry gap. + +**Key Topics** + +- Environment assessment (Module 02) vs. per-requirement feasibility +- Field level data source mapping +- Whether the requirement needs a baseline +- Platform, organizational, and compliance constraints +- Whether the SOC can act on the result +- Tracking blocked requirements + +**Out of scope** + +- Assessing log source quality (Module 02) +- Closing telemetry gaps (Module 02) +- Detection design (Module 04) + ### 6. Prioritization -#### Learning Objectives +**Learning Objectives** -- Combine threat, impact, exposure, feasibility, and effort into a defensible priority for a detection requirement -- Evaluate the strengths and failure modes of common prioritization approaches -- Decide when a risk should be addressed through detection, prevention, or explicit acceptance -- Communicate prioritization decisions to stakeholders in terms of risk reduction +- Combine threat, impact, exposure, feasibility, and effort into a defensible priority for a detection requirement. +- Evaluate the strengths and failure modes of common prioritization approaches. +- Decide when a risk should be addressed through detection, prevention, or explicit acceptance. +- Communicate prioritization decisions to stakeholders in terms of risk reduction. -#### Key Topics +**Key Topics** - Prioritization inputs: threat relevance, potential impact, asset exposure, telemetry feasibility, and engineering effort - Prioritization approaches: @@ -68,23 +175,61 @@ TBD - Re-prioritization triggers: new threat intelligence, incidents, environment changes, and remediated exposure - Explaining priority to stakeholders: tying decisions to risk reduction rather than rule counts, and grounding responses to headline threats in actual exposure -#### Out of Scope +**Out of scope** - Detailed treatment of exposure and asset risk inputs (Lesson 4) - Assessing telemetry availability (Lesson 5) - Program-level backlog management, capacity planning, and metrics (Module 10) ## Boundaries -TBD + +| Topic | This module | Adjacent module(s) | +| --- | --- | --- | +| ATT&CK coverage | Using coverage gaps to prioritize | 04 Detection Design (mapping and coverage analysis) | +| Telemetry feasibility | Whether a specific requirement can be met | 02 Telemetry & Data (assessing and improving sources) | +| Threat research | Intake and turning research into requirements | 04 Detection Design (researching the behavior to detect) | +| Backlog and intake process | Per-requirement intake and prioritization | 10 Detection Program Engineering (program level) | +| Vulnerability management | Vulnerability state as a detection input | Operating a vulnerability management program is not covered in Core | +| Baselines | Identifying when a requirement needs one | 02 Telemetry & Data (establishing baselines); 04 Detection Design (using them) | +| Hypotheses and design | Not covered | 04 Detection Design | ## Labs -None yet + +N/A ## Datasets -None yet + +N/A ## References -- MITRE ATT&CK -- CISA Known Exploited Vulnerabilities (KEV) Catalog -- FIRST Exploit Prediction Scoring System (EPSS) -- MITRE Center for Threat-Informed Defense (CTID) publications + +### Detection Requirements and Sources + +- [Alerting and Detection Strategies Framework](https://github.com/palantir/alerting-detection-strategy-framework), Palantir Incident Response Team, 2017. +- [SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management](https://csrc.nist.gov/pubs/sp/800/61/r3/final), Alexander Nelson, Sanjay Rekhi, Murugiah Souppaya, and Karen Scarfone, National Institute of Standards and Technology, 2025. DOI: 10.6028/NIST.SP.800-61r3. +- [The NIST Cybersecurity Framework (CSF) 2.0](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20), National Institute of Standards and Technology, 2024. DOI: 10.6028/NIST.CSWP.29. + +### Threat-Informed Requirements + +- [MITRE ATT&CK, v20.0](https://attack.mitre.org/), The MITRE Corporation, 2026. Retrieved 2026-11-01. +- [The Design and Philosophy of MITRE ATT&CK](https://attack.mitre.org/docs/ATTACK_Design_and_Philosophy_March_2020.pdf), Blake E. Strom et al., The MITRE Corporation, 2020. +- [ATT&CK Detection Strategies](https://attack.mitre.org/detectionstrategies/), The MITRE Corporation, n.d. Retrieved 2026-11-01. +- [Top ATT&CK Techniques](https://ctid.mitre.org/projects/top-attack-techniques), MITRE Center for Threat-Informed Defense, 2024. Retrieved 2026-11-01. + +### Risk and Exposure Context + +- [NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments](https://csrc.nist.gov/pubs/sp/800/30/r1/final), Joint Task Force Transformation Initiative, National Institute of Standards and Technology, 2012. DOI: 10.6028/NIST.SP.800-30r1. +- [NIST IR 8286A Rev. 1: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management](https://csrc.nist.gov/pubs/ir/8286/a/r1/final), Stephen Quinn et al., National Institute of Standards and Technology, 2026. +- [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), Cybersecurity and Infrastructure Security Agency, n.d. Retrieved 2026-11-01. +- [Exploit Prediction Scoring System](https://www.first.org/epss/), Forum of Incident Response and Security Teams, n.d. Retrieved 2026-11-01. +- [Common Vulnerability Scoring System, Version 4.0](https://www.first.org/cvss/v4.0/specification-document), Forum of Incident Response and Security Teams, 2023. +- [Stakeholder-Specific Vulnerability Categorization Guide](https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf), Cybersecurity and Infrastructure Security Agency, n.d. Retrieved 2026-11-01. + +### Feasibility and Prioritization + +- [Top ATT&CK Techniques Methodology](https://center-for-threat-informed-defense.github.io/top-attack-techniques/), MITRE Center for Threat-Informed Defense, 2024. Retrieved 2026-11-01. +- [CISA Cross-Sector Cybersecurity Performance Goals](https://www.cisa.gov/cross-sector-cybersecurity-performance-goals), Cybersecurity and Infrastructure Security Agency, n.d. Retrieved 2026-11-01. + +## AI Assistance + +Research diff --git a/core/03-detection-requirements/module-metadata.yml b/core/03-detection-requirements/module-metadata.yml index 3ae90c1..d1572eb 100644 --- a/core/03-detection-requirements/module-metadata.yml +++ b/core/03-detection-requirements/module-metadata.yml @@ -1,10 +1,7 @@ title: Detection Requirements - -slug: - +slug: detection-requirements status: draft # draft | in-review | reviewed | stable | needs-update | deprecated - -version: +version: 0.1 summary: > Covers deciding what to detect and in what order: where detection ideas @@ -12,16 +9,30 @@ summary: > prioritize them against threats and the organization's actual risk and exposure. -learning_objectives: [] +learning_objectives: + - Write a detection requirement that states the behavior, required data, triggering conditions, context, and success criteria. + - Identify where detection ideas come from, and evaluate an idea's relevance to the environment. + - Extract detection requirements from a detection threat model. + - Use asset criticality, exposure, and vulnerability state to shape the priority and scope of a requirement. + - Determine whether a requirement can be met with available telemetry within organizational constraints. + - Prioritize requirements and communicate the decisions in terms of risk reduction. -prerequisites: [] +prerequisites: + - Module 01 Detection Engineering Foundations + - Module 02 Telemetry & Data authors: - Treyrob3 + - mndtrcks reviewers: [] # GitHub handles (without @) of independent approving reviewers -maintainers: [] +maintainers: + - mndtrcks + - Treyrob3 + +ai_assistance: > + research last_reviewed: null # YYYY-MM-DD, set by a maintainer on approval