Cyber Defense Matrix 2.0 · Function · DE
DETECT(DE)
Continuous monitoring, anomaly detection, and adverse-event analysis. The column whose value is measured in mean time to detect.
DETECT is the NIST CSF 2.0 function that monitors for cybersecurity events and analyzes them for adverse outcomes. In the Cyber Defense Matrix 2.0 it covers continuous monitoring (DE.CM) and adverse event analysis (DE.AE). The column's effective value is measured by mean time to detect (MTTD) and by the ratio of analyst-hours spent on real incidents vs. false-positive tuning.
What DETECT covers and what it does not
DETECT is about visibility, not response. Once an event is identified and confirmed as an incident, the work moves to RESPOND. The line is usually drawn at 'is this a confirmed incident?' Anything before that — telemetry, correlation, tuning, triage — is DETECT. Anything after — investigation, containment, eradication — is RESPOND.
The two NIST CSF 2.0 categories are DE.CM (Continuous Monitoring) and DE.AE (Adverse Event Analysis). Practitioners typically think in tool categories: SIEM, XDR, EDR, NDR, UEBA, deception, SOC services. The column is where most of the operational security headcount lives because the work is continuous.
The SIEM-vs-XDR question
The last five years have given SecOps teams a genuine choice: SIEM-centric (Splunk, Sentinel, Chronicle, Elastic, Exabeam) or XDR-centric (CrowdStrike Falcon Complete, SentinelOne Singularity, Palo Alto Cortex XDR, Microsoft Defender XDR). The honest answer is that large, mature SOCs benefit from a SIEM-centric model because they can invest in detection engineering. Small and mid-market teams benefit from XDR because the detection content is curated by the vendor and tuned against a broader telemetry set than any one customer sees.
The failure modes mirror the architecture choice. SIEM-centric programs under-invest in detection engineering and end up with noisy rules and alert fatigue. XDR-centric programs over-trust vendor content and fail to develop organization-specific detections. In the matrix both architectures can produce full coverage; the difference is in where the operational work concentrates.
Per-asset-row detection coverage patterns
DETECT × Devices and DETECT × Users are almost always strong — EDR plus IdP logging covers 80% of observable activity in a typical enterprise. DETECT × Networks is mid-strength, covered by a mix of NDR, firewall logs, and DNS monitoring. DETECT × Applications is uneven — application logs are rarely ingested at useful granularity. DETECT × Data is almost always weak outside of DLP-alert streams.
In the extension rows: DETECT × Cloud is strong for organizations that adopted a CNAPP/Wiz/Orca/Lacework class of tool, absent otherwise. DETECT × OT/IoT requires specialized telemetry (Claroty, Nozomi, Dragos) and is rarely present unless the business is industrial. DETECT × AI/ML is effectively unsolved commercially; most programs treat it as a DLP + anomaly-detection stretch. DETECT × Supply Chain relies on third-party intel feeds and is inherently indirect.
Why detection engineering matters more than tool choice
The single strongest predictor of DETECT effectiveness is not tool selection — it is whether the program has a detection engineering practice. That means a named individual or team responsible for writing, testing, tuning, and retiring detection rules against a documented threat model. Programs with this practice consistently achieve lower MTTD and higher precision regardless of whether they run Splunk, Sentinel, or XDR. Programs without it plateau at vendor-supplied content quality, which is usually adequate for generic threats and inadequate for targeted ones.
Frequently asked
Do we need SIEM and XDR?
Most organizations under 2,000 employees do not. XDR covers the detection workload and the telemetry sources most incidents actually use. SIEM becomes necessary when compliance (PCI DSS, HIPAA) requires log retention beyond XDR defaults, when detection engineering is mature enough to author custom content, or when telemetry sources (mainframes, legacy apps, OT) fall outside XDR coverage.
Where does threat hunting fit?
In DETECT. Hunting is proactive investigation of telemetry for threats that no existing rule would catch. It lives adjacent to detection engineering — successful hunts become detection rules. The distinction from incident response is that hunts operate on a hypothesis, not on an alert.
Is UEBA a separate category or part of SIEM/XDR?
Both. Exabeam, Securonix, Gurucul sell standalone UEBA platforms. Most SIEMs and XDRs now include UEBA capabilities. The standalone market is shrinking; the capability is not. Treat UEBA as a feature that cuts across DE.AE (adverse event analysis) rather than as its own cell.
How does deception fit DETECT?
Deception tools (Attivo/SentinelOne Singularity Hold, TrapX, Illusive) are high-signal detection mechanisms — anything touching a decoy is by definition suspicious. They are DETECT tools that happen to have very low false-positive rates. A mature program uses deception to cover cells where traditional detection is weak (OT/IoT, lateral movement on segmented networks).