[RESEARCH] 03 Detection Requirements #12

Module

03 Detection Requirements

Target directory: core/03-detection-requirements/

Purpose

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.

Goal of This Issue

Design the module's structure so individual lessons can be claimed and written. This issue does not produce lesson content.

Research is complete when a pull request is merged that adds:

• core/03-detection-requirements/README.md, based on templates/module-template.md, containing:
  • module learning objectives
  • prerequisites
  • the proposed lesson list, with for each lesson:
    • 2–4 learning objectives
    • key topics
    • explicitly out of scope
  • a Boundaries section describing what this module covers versus adjacent modules
• core/03-detection-requirements/module-metadata.yml, based on templates/module-metadata.yml, with status: draft

Once merged, a maintainer opens one issue per lesson as a sub-issue of this one.

Inputs

Community Feedback

• Risk and exposure context in prioritization: internet-facing assets, unpatched vulnerabilities, missing controls — Treyrob3
• Threat research as an input: threat reports, incidents, findings, feeds, and how they become detection ideas — Treyrob3

Seed Material

• TBD

References

Starting suggestions. Add, remove, or replace as research progresses.

• MITRE ATT&CK — https://attack.mitre.org/
• CISA Known Exploited Vulnerabilities (KEV) Catalog
• FIRST Exploit Prediction Scoring System (EPSS)
• MITRE Center for Threat-Informed Defense (CTID) publications

Known Overlaps

How to Participate

• Claim: comment on this issue to join. A maintainer will assign you and add you to the Contributors section below. Multiple contributors may claim the same research issue.
• Lead: a maintainer designates one contributor as lead. The lead coordinates, keeps work moving, and opens the pull request. The lead does not make every decision alone.
• Suggest inputs: only maintainers can edit this issue, so post feedback, seed material, references, or overlaps as comments and a maintainer will add them above.
• Collaborate: use this issue to coordinate. The lead forks the repository and opens a draft pull request early so everyone works from the same document. To let co-contributors push to that branch, the lead adds them as collaborators on their fork (fork Settings → Collaborators). Contributors who are not added can propose edits with suggested changes in the pull request review. Every commit must be signed off (DCO).
• Boundary review: before merging, a contributor from each adjacent module, or a maintainer, confirms the Boundaries section.
• Inactivity: claims with no activity for 4 weeks may be released after a reminder.

Contributors

Lead:

Contributors: @Treyrob3, @mndtrcks

Additional Context

It is worth going deep here.

Questions or want to coordinate in real time? Join the ODE Discord. Record decisions here or in the pull request.