Skip to content

DETECT

Objective

Find adversary and anomalous activity fast enough to limit damage. Detection is the operational heart of a CDC: log collection, detection engineering, triage, and threat hunting.

Core capabilities

StandardOCDFFunction from NIST CSF 2.0; the capability breakdown and IDs are this framework's.

ID Capability Description
DE-1 Log collection & management Prioritised onboarding of log sources, covering identity, endpoint, network, cloud, email and critical applications, into a central platform; retention policy; time synchronisation; log integrity protection.
DE-2 Detection engineering A managed lifecycle for detection use cases: idea → develop → test → deploy → tune → retire. Each use case mapped to MITRE ATT&CK techniques and to the threat profile from IDENTIFY.
DE-3 Alert triage & analysis Documented triage process, severity matrix, enrichment with asset criticality, identity context and threat intel, and escalation criteria. The decisions behind it are in Designing alert triage.
DE-4 Coverage assessment Periodic measurement of detection coverage against ATT&CK and against crown-jewel assets; gap-driven engineering backlog.
DE-5 Threat hunting Hypothesis-driven hunts based on threat intel, following a written method such as TaHiTI rather than an improvised one. Every hunt ends with a recorded outcome: a finding, a new detection, or a data gap sent to the DE-1 backlog. Without that record a hunting programme cannot show what it is worth.
DE-6 Detection validation Testing that detections actually fire: unit tests, purple teaming, adversary emulation.
DE-7 Anomaly & integrity monitoring File/configuration integrity monitoring, identity anomaly detection, and monitoring of the CDC's own infrastructure.

Log source onboarding priority

PractitionerThe author's ordering by detection value.

Log sources in onboarding order: identity, endpoint, email and web, cloud control plane, network and critical applications, with the first three marked as the DETECT Level 2 minimum Log sources in onboarding order: identity, endpoint, email and web, cloud control plane, network and critical applications, with the first three marked as the DETECT Level 2 minimum

  1. Identity — directory and IdP authentication, privileged actions; the highest detection value per gigabyte.
  2. Endpoint, meaning EDR telemetry, for process, persistence and lateral-movement visibility.
  3. Email & web gateway — dominant initial access vectors.
  4. Cloud control plane, meaning IaaS and SaaS audit logs. Often forgotten, increasingly critical.
  5. Network, covering firewall, DNS, VPN, netflow and NDR where deployed, for breadth and containment context. Network Detection and Response earns its place precisely where EDR cannot go: unmanaged and unmanageable devices such as IoT, printers, medical and lab equipment, legacy appliances and BYOD; east-west visibility for lateral movement between segments, and as an integrity check on endpoint coverage, since a host talking on the network with no EDR heartbeat is itself a finding. Its limits belong in the same breath: pervasive encryption reduces payload inspection to metadata/behavioural analysis, it sees flows rather than process context, and it is a complement to endpoint and identity telemetry, not a substitute. Decision guide: the more unmanaged devices and flat legacy segments you have, the earlier NDR climbs this priority list; in a fully managed, well-segmented, cloud-heavy estate it stays at 5.
  6. Critical applications & databases — crown-jewel specific.

Edge devices note: firewalls, VPN gateways and remote-access appliances appear above as sources of context, but they are also among the most targeted systems in the estate, and most cannot run EDR. Collect their own system and admin logs, not only the traffic they pass. Alert on configuration changes, new admin accounts and logins to management interfaces, and treat outbound connections that the appliance itself starts as a finding unless they go to a known update or logging destination. Where the vendor offers an integrity check, schedule it. What to do around patching is under edge devices in Protect.

Remote and hybrid work note: architectures retrofitted from on-prem assumptions go blind the moment a laptop leaves the VPN. Prioritise location-independent telemetry, since EDR and identity-provider logs follow the user everywhere, and verify that endpoint telemetry reaches you off-network before declaring source 1–2 coverage complete. The same applies per cloud/SaaS tenant: coverage is per environment, not per organisation.

Owning the SIEM platform, in-house or cloud

Practitioner

A SIEM that nobody clearly owns decays into an unpatched, undersized liability, and it is itself a crown jewel, holding your most sensitive telemetry and your detection logic. Before go-live, settle ownership in writing:

Layer Typical owner, on-prem or self-hosted Covers
Hardware & capacity Infrastructure team Physical/virtual hosts, storage, network, capacity planning against ingest growth
Operating system Infrastructure team OS patching, hardening baseline, backup of the platform itself, monitoring of host health
SIEM application CDC Application upgrades and patching, configuration, data onboarding/parsers, detection content, retention settings, health of the ingest pipeline
Access & platform security CDC, verified independently Admin access through PAM, audit logging of the SIEM itself, integrity of stored logs

The traditional split, where infrastructure maintains the server and OS and the CDC maintains the SIEM platform itself, works well, but only if the interface is explicit: agree patching SLAs for the underlying stack, since an unpatched SIEM host is a high-value target, plus capacity review cadence and who is paged when ingest stops at 02:00. Record the split in the charter's interfaces section and give the platform its own recovery plan under RC-1: losing the SIEM during an incident means going blind at the worst moment.

Cloud-hosted SIEM: hosting in the cloud buys convenience, elasticity and no hardware ownership, but be clear-eyed that you are shipping your telemetry into a cloud you do not own. Security logs are among the most sensitive data an organisation produces: they contain personal data, which under GDPR requires a processor agreement, residency and a transfer mechanism; they also carry authentication patterns, internal hostnames and, in aggregate, a map of your defences. So decide deliberately which data may leave the estate: classify log sources before onboarding, consider filtering or pseudonymising high-sensitivity fields, check sector and national residency constraints against your national annex, and confirm export and exit terms so the data remains yours in practice, not just in contract; the data-and-exit sections of the MSSP checklist apply almost unchanged to SIEM SaaS. Hybrid patterns, with sensitive sources retained in a local tier and the rest in cloud, are legitimate and common.

CIA mapping

OCDFThis framework's mapping of each capability to confidentiality, integrity and availability.

Capability C I A Rationale
DE-1 Log management ○ ● ○ Log integrity is itself a control objective, since tampered logs destroy investigations and their evidential value.
DE-2/DE-4 Use cases & coverage ● ● ● Exfiltration detections serve C; tampering/ransomware detections serve I/A. Balance the portfolio against your threat profile.
DE-3 Triage ● ● ● Severity matrix should explicitly weigh CIA impact per asset class.
DE-5 Hunting ● ● ○ Hunting finds the quiet, persistent intrusions detections miss, which are mostly espionage and preparation for tampering.
DE-6 Validation ○ ● ○ Proves the detection portfolio does what it claims: the Integrity of the CDC's own output.
DE-7 Integrity monitoring ○ ● ○ Direct Integrity control.

● primary, ○ secondary or indirect. Rows where all three are ○ are enablers: they protect nothing themselves, but the others depend on them.

Roles & staffing

PractitionerStaffing figures are practitioner estimates; the arithmetic is under staffing and cost in Operating models.

  • Analysts — triage and investigation, in tiers or tierless as the operating model decides.
  • Detection engineers — own the use case lifecycle; in small teams combined with the analyst role.
  • Threat hunter — a Level 3 capability and above.

Minimum viable team for business-hours monitoring with on-call: 3–4 FTE. One seat staffed around the clock takes roughly 5.5–6 FTE once leave, sickness and training are counted, so a 24/7 in-house line with daytime capacity on top lands at 8–12 FTE, and even then nights are usually a single analyst. The arithmetic, and what to do about the lone night analyst, is in staffing and cost. Below that, consider hybrid or MSSP models, which is a governance decision; see GOVERN GV-5.

Maturity criteria

OCDFThis framework's criteria. Not a certification standard.

The criteria that score DETECT are kept in one place for all six functions: the maturity self-assessment, DETECT, with the same text in the interactive tool. Its Level 2 criteria include the minimum form of NIS2 Art. 21(2)(b), marked there; see the NIS2 Article 21 crosswalk. How levels are scored is in the maturity model.

EU regulatory hooks

LawParaphrased from the legal texts. Check the article itself and your national law; not legal advice.

  • NIS2 Art. 21(2)(b) — incident handling implies detection capability; Art. 23 reporting deadlines, with early warning within 24h, are only achievable with functioning detection.
  • GDPR Art. 33 — 72-hour breach notification to the supervisory authority starts at awareness; detection speed directly determines compliance feasibility.
  • DORA Art. 10 — financial entities must have mechanisms to promptly detect anomalous activities.
  • GDPR & employee monitoring — security monitoring of user activity must respect data protection: define purpose limitation, retention, and access controls for security logs; involve the DPO. Log data about employees is personal data.

External dependencies

PractitionerTypical dependencies from experience; yours will differ.

Dependency Party Type Agree up front
Log source enablement and forwarding System/application owners [HARD] Onboarding SLA per source; the priority list above as the queue
SIEM hardware and OS layer, self-hosted Infrastructure team [HARD] Ownership split per the SIEM section above; paging path when ingest stops
Network taps/span or NDR sensor placement Network team [HARD] Placement plan tied to segments and blind spots
Approval of privacy-intrusive sources such as endpoint content and mail inspection DPO [GATE] Assessment criteria and turnaround pre-agreed
Business context for tuning: what is normal here? Application owners [SOFT] Named contact per crown jewel

Sources

Open CDC Framework, licensed CC BY 4.0. Credits: References & credits.