Repository navigation
Open
Labels
Description
Lesson
Module: 03 Detection Requirements
Lesson: 4. Risk & Exposure Context
Target file: core/03-detection-requirements/04-risk-exposure-context.md
Research issue: #12
Scope
Copied from the module README, which is the source of truth. If the scope needs to change while writing, change the README in the same pull request and say why.
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)
Goal of This Issue
Write the lesson. The lesson is complete when a pull request is merged that:
- adds the target file, based on
templates/lesson-template.mdand written to the Style Guide - meets each learning objective above and stays out of the out-of-scope topics, pointing to the lesson or module that covers them instead
- passes the checklist for authors
- links the lesson from the module README's lesson list
- updates the module's
ai_assistancefield and README AI Assistance section to cover this lesson
The module's status stays draft. Technical review happens at the module level once its lessons are written (Review Process).
How to Participate
- Claim: comment on this issue to take it. A maintainer will assign you and add you to the Contributors section below. One writer leads each lesson; others are welcome to contribute.
- Collaborate: open a draft pull request early and link this issue. To let co-contributors push to your branch, add them as collaborators on your fork (fork Settings → Collaborators). Every commit must be signed off (DCO).
- Boundaries: if the lesson starts covering material owned by another lesson or module, raise it here or in the pull request rather than expanding the scope.
- Inactivity: claims with no activity for 4 weeks may be released after a reminder.
Contributors
Writer:
Contributors:
Additional Context
None yet.
Activity
Treyrob3 commentedon Nov 7, 2026
I would like to take/claim this one