DE.AE-03 Event correlation: requirements and evidence

What DE.AE-03 event correlation asks for and why it stalls

DE.AE-03 asks that information from multiple sources is correlated, so that individual log lines and alerts are linked into a picture of adverse activity. The Subcategory sits in the Adverse Event Analysis Category of the DETECT Function in NIST CSF 2.0 (CSWP 29, February 2024). The risk it addresses is simple: an isolated alert about one failed login, one unusual process or one outbound connection often looks harmless on its own. A multi-step attack spreads its activity across identity systems, endpoints, network devices and cloud audit trails, so no single source shows the whole sequence. Correlation is the step that connects those fragments before the organization decides whether an event is an incident. NIST publishes three Implementation Examples for DE.AE-03. The first transfers log data to a small number of log servers, so that analysts search one place instead of many. The second uses event correlation technology such as a SIEM to link events across sources. The third uses threat intelligence to correlate events across log sources. Each example depends on a prior decision: which log sources are in scope, who owns each one, and whether their timestamps are synchronized. In practice these prerequisites stall the work. Many log sources, such as SaaS tenants, network appliances or business applications, have no named owner. Clocks drift between systems, which breaks the time-based links a correlation rule depends on. Teams also find that once alerts flow in, most of them remain unlinked, so the correlation rules never get tuned. The identifier is unchanged from CSF 1.1, where the same outcome was numbered DE.AE-3, so existing assessment records can be carried forward under DE.AE-03 (NIST CSF 1.1 to 2.0 Core Transition Changes). Confirm that mapping against the spreadsheet NIST publishes before you rely on it in a report. Also note that NIST does not offer certifications or endorsements of CSF-related products or services (NIST CSF FAQs). No one can certify that DE.AE-03 is met. An independent assessor can test your evidence against it, and your own log inventory, source owners and correlation rule records are what that assessor will ask to see.

Which log sources and teams fall inside DE.AE-03 scope

DE.AE-03 asks whether information from multiple sources is correlated, so the first scoping work is deciding which sources feed the correlation and who answers for each one. The decisions below change the volume of log work more than any tool choice does, and each one should be settled in writing before a SIEM or log pipeline is sized.

Hosts and endpoints that emit security-relevant logs

Start with the servers, workstations and virtual machines that run in-scope systems, then decide which of them send authentication, privilege, process and service events to the log pipeline. Scoping every host at full verbosity inflates storage and tuning work, while skipping hosts that touch regulated data leaves gaps an assessor will find. Confirm which operating system audit settings are enabled and who maintains the agent on each host.

Network devices and perimeter services

Firewalls, VPN concentrators, load balancers, DNS resolvers and switches often produce the first evidence of a multi-stage intrusion, so they usually belong in scope. The effort lies in normalizing vendor-specific formats and deciding which traffic logs to keep, since flow volume grows quickly. Ask the network team which devices can export syslog and whether any sit outside the monitoring boundary.

Cloud control planes, identity providers and SaaS applications

Cloud audit trails, identity provider sign-in records and SaaS admin logs frequently record the actions that matter most for correlating an account compromise with a host event. Each provider exposes its own export method and retention window, so each one adds an integration to build and maintain. Confirm which tenants, subscriptions and business applications are covered, and whether any log export depends on a plan tier the organization does not hold.

Central log servers and their boundary

NIST's Implementation Example for DE.AE-03 describes transferring log data to a small number of log servers, so the number and location of those collectors defines the scope of the correlation work. Each log server becomes an in-scope system with its own access control, integrity protection and hardening. Document which collectors are in scope, where they run, and which team can change their configuration.

Named owners for each log source

A source without an owner tends to break silently when a vendor changes a log format or an agent is removed during patching. Assign each source to a team, record the expected event types and set a contact for gaps in ingestion. Review the owner list whenever a system is added, retired or moved to a new hosting model, because correlation rules depend on fields that owners control.

Third-party and managed services

Logs held by an MSSP, a managed SOC or a hosting provider may still count as evidence for DE.AE-03, but the organization remains responsible for the outcome. Contracts should state which logs the provider forwards, in what format, how fast, and who can request them during an assessment or incident. Ask for these terms in writing before accepting a provider's monitoring as covering a source.

How an assessor tests DE.AE-03 and what they ask to see

This table lists the test an assessor is likely to run for each part of DE.AE-03, the evidence they will request and the findings that appear most often. Read it as a pre-assessment checklist: if a row cannot be answered with a dated record, the outcome is at risk. The main takeaway is that correlation is judged by traceable evidence from source to finding, not by the presence of a SIEM.

Test area	What the assessor does	Evidence requested	Common finding
Log source centralization	Compares the inventory of in-scope hosts, network devices and cloud services against the log servers that receive their data	Log source inventory, forwarding configuration for each source, and current ingestion status reports	Log sources that never reached the central servers or were added after the inventory was last updated
Correlation rules and tuning	Samples correlation rules and checks each has a stated purpose, an owner and a record of testing and tuning	Rule catalog with owner names, rule change history, and test results showing true and false positive review	Rules with no owner, no test record, or thresholds that were never revisited after deployment
Event trace-through	Picks a sample of events and follows each from the original log entry to the correlated finding and any alert raised	Raw log entries, the matching finding or alert identifiers, and the correlation graph or case record linking them	Events that cannot be traced because a field was not normalized or the link between log types was never configured
Threat intelligence inputs	Reviews which threat intelligence feeds are used in correlation, how they are updated and how matches are recorded	Feed list with source and update dates, rule or detector definitions that use intelligence, and sample matches	No evidence that threat intelligence is used in correlation, or feeds listed but never linked to any rule
Log retention and access	Checks that retention periods for correlated log data are defined and that access to log servers and correlation tools is limited and reviewed	Retention settings, access control lists for log platforms, and periodic access review records	Retention set by default without a documented decision, or administrator access to log servers that no one reviews
Link to incident handling	Confirms that correlated findings reach the people who triage them, and that the relationship to incident response controls is documented	Alert routing configuration, ticket samples, and response procedures referencing correlated findings	Correlated alerts sent to a mailbox or channel with no assigned responder and no escalation path
Ongoing evaluation	Looks for evidence that correlation coverage is reviewed against new systems, incidents and test results	Review minutes, gap lists from tests or exercises, and change records for rules added after incidents	Coverage reviewed once at deployment and never again, even after new platforms were added

Evidence that satisfies DE.AE-03 and how to keep it current

An assessor testing DE.AE-03 wants to see that logs reach a small set of central points, that correlation rules exist and change under control, and that correlated findings trace back to raw events. The cards below name each artifact, how often it should be refreshed between audits, and who should sign off. Refresh intervals are internal governance choices, so confirm them with your auditor before the assessment period starts.

Log source inventory mapped to log servers

This is a register of every host, network device, cloud service and application that produces security-relevant logs, with the central log server each one forwards to. It shows the "small number of log servers" pattern NIST describes for DE.AE-03 and lets an assessor test coverage by picking a system and tracing its logs. Check for sources missing from the list, especially new cloud accounts and SaaS tenants. Refresh it after every change to the estate, and at least quarterly. The system owner signs off, with the security operations lead reviewing gaps.

Correlation rule exports with version history

These are exports of the SIEM or correlation rules, such as Sigma rules in OpenSearch Security Analytics or custom rules in Wazuh, kept under version control with change records. Assessors look for who approved each rule, when it changed and what event sources it depends on. Confirm that disabled or retired rules are recorded, not silently deleted. Export and archive the full set after each approved change and review it monthly. The detection engineering lead approves changes, and the security manager signs off on the monthly review.

Sample correlated findings traced to raw events

Correlated findings are only useful as evidence when each one can be followed back to the individual log lines that produced it. Keep a set of sample findings, including at least one multi-source correlation, with the matched raw events, the rule that fired and the analyst disposition. Confirm that timestamps and host identifiers match across sources. Build a fresh sample set each quarter and before each assessment. The SOC manager signs off on the samples, and the internal audit or compliance lead checks the trace.

Threat intelligence feed configuration and update log

DE.AE-03 includes using threat intelligence to link events across log sources, so assessors will ask which feeds are connected, how indicators reach the correlation engine and whether updates happen on schedule. Record each feed, its source, license terms, the ingestion settings and a dated log of imports and failures. Review the list of feeds against the threats your sector faces. Review the configuration quarterly and check the update log monthly. The threat intelligence lead signs off on the feed list, and the SOC lead signs off on the update log.

Log server configuration and retention settings

This covers the configuration of the central log servers, including ingestion paths, time synchronization, access controls, storage capacity and the retention period set for each log type. Assessors check that logs cannot be silently dropped and that retention matches your own policy and any contractual or regulatory duty. Export the configuration files and retention settings after each change, and compare them against the approved baseline at least quarterly. The platform owner signs off on configuration changes, and the compliance lead signs off on retention.

Access reviews for the correlation platform

The SIEM and log servers hold sensitive security data, and people who can change rules or delete logs can hide activity. Keep a record of who holds administrator, analyst and read-only roles, the review date and the outcome of each review, including removals. Compare role membership with the current staff list and check that service accounts still have owners. Run the review at least quarterly and after staff changes. The identity owner performs the review, and the CISO or delegate signs off on the results.

How to implement DE.AE-03 in sequence

This sequence takes an organization from an unknown set of log sources to a tested position where events from different systems are linked into one finding. Each step produces an artifact that the next step depends on, so an assessor can trace the outcome back to its inputs.

Inventory log sources and their owners
Start by listing every system that produces logs relevant to security: identity providers, endpoints, network devices, cloud control planes, business applications and the security tools themselves. For each source, record the log type, the owner who can change its configuration, the retention the owner applies and whether the logs are currently forwarded anywhere. The owning team of each source should confirm its entry. This step is complete when the inventory is signed off by the owners and gaps, such as sources with no forwarding, are listed with a named owner. The artifact is a log source register that feeds every later step.
Route logs to a small set of central servers
Configure each source in the register to send its logs to a limited number of central log servers, which is the approach the first NIST Implementation Example for DE.AE-03 describes. Confirm that every forwarder uses consistent time sources, because correlation across sources depends on timestamps that agree. Check that the transport is encrypted and that the receiving servers protect log integrity and access. The step is done when a test event generated on each source appears on the central servers with a correct timestamp. The artifact is a log flow diagram with a verification record for each source.
Select and document the correlation technology
Choose the technology that will link events, such as a SIEM, based on the log types in the register, the detection content available for them and the team that will operate it. Evaluate candidates against the inventory rather than against a generic feature list, and confirm with each vendor or project which log types, rule formats and correlation features it supports. Record the reasons for the choice, including the options considered and the operational trade-offs accepted. Open-source options such as OpenSearch Security Analytics and Wazuh can be evaluated on the same basis. The artifact is a signed technology decision record that names the owner of the platform.
Write and test correlation rules across log types
Write rules that link events from at least two different log types, such as an authentication failure followed by a privileged command on a server, or a suspicious cloud API call matched to an endpoint alert. Express the rules in the format the chosen platform supports, and define the time window, the fields used to join events and the severity assigned to a linked finding. Test each rule with recorded or simulated events that are known to be connected, and also with unrelated events to measure false matches. The step closes when each rule has documented test results and a named maintainer. The artifact is a versioned rule set with test evidence.
Add threat intelligence to correlation logic
Connect threat intelligence indicators, such as known malicious addresses, domains or file hashes, to the correlation logic so that an event matching an indicator is linked to other events from the same entity. Document the intelligence sources, how often they are refreshed, and who decides whether a source is trusted. Confirm the licensing terms of any feed before ingesting it into a self-hosted platform. Test that an indicator match produces a linked finding and that stale or unverified indicators do not create alerts without review. The artifact is a threat intelligence integration record listing sources, owners and test results.
Define triage ownership for correlated findings
Assign who receives each correlated finding, who triages it and how a finding moves to incident declaration under DE.AE-08. Define the queue or channel for alerts, the expected handling steps for each severity, and the escalation path when the triage owner is unavailable. Coordinate this with the SOC and incident response roles so that correlated findings are not sent to a mailbox nobody checks. The step is complete when the ownership matrix has been reviewed by the people named in it. The artifact is a triage ownership matrix with routing rules.
Prove a multi-source event is linked end to end
Run a controlled test in which a scenario generates events on at least two sources, and confirm that the platform links them into a single correlated finding that reaches the named triage owner. Record the time from event to finding, the fields that joined the events and any gaps where a link was missed. Repeat the test after any change to log routing, rules or intelligence feeds. Keep the test as a repeatable procedure so an independent assessor can rerun it. The step is complete when the test passes and the results are reviewed by the control owner. The artifact is a test report with the scenario, evidence screenshots or exported findings, and the reviewer's sign-off.

Open-source tools that can produce DE.AE-03 evidence

Correlation evidence comes from the log sources you feed into a central point and the rules that link them. The tools below can each produce part of that evidence, but none of them decides what your correlation design should be. Confirm each fit against your own environment, licensing review and log volumes before you commit to any of them.

OpenSearch Security Analytics

Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can go to channels such as Slack or email. Its correlation engine links findings across log types into a correlation graph, which is the closest artifact to a DE.AE-03 correlation record. Check that your log types have parsers and that the correlation rules you rely on are ones you have reviewed. The Apache-2.0 license permits use without copyleft obligations, but confirm the license terms of any plugins you add.

Wazuh ruleset and alerts

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching alerts are written to alerts.log and alerts.json and mapped to MITRE ATT&CK, then forwarded to the Wazuh indexer for review. These files give assessors a traceable chain from raw event to alert. Review which built-in rules are enabled, since unreviewed defaults will not match your threat model. Wazuh is licensed under GPL-2.0-only, so confirm that the GPL terms fit how you distribute or modify it.

Nextcloud admin_audit logs

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Those entries record administrative actions on a file collaboration platform that often holds sensitive data, so they are useful sources to correlate with identity and network logs. Route the file to your central log server and confirm that it is not overwritten or left on the application host. Nextcloud is licensed under AGPL-3.0-only, which applies to modifications you make and offer to users over a network, so review that obligation with counsel before customizing the app.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256, which lets you correlate a secret access event with an identity or host event without storing the secret itself. This is useful evidence for showing who requested credentials and when. Confirm which audit device you enable, where it writes, and how long your central store keeps these entries. OpenBao is licensed under MPL-2.0, a file-level copyleft license, so review how any changes to its source files are handled in your builds.

What meeting DE.AE-03 costs in money and effort

This table lists the cost components of correlating logs for DE.AE-03, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to decide which items belong in a written scope and which questions to put to any quote. No figures are shown because none were supplied for this topic; a quote follows from a written scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Correlation technology or licenses	Software vendor for commercial SIEM; no license fee for self-hosted open source such as OpenSearch Security Analytics or Wazuh	Commercial: usually recurring. Open source: no license spend, but operating effort remains	Commercial pricing often tracks ingest volume or sources. Open source shifts cost to hosting and staff time
Log routing and parsing engineering	Implementation partner or internal platform engineers	One-time build, with recurring change work as sources are added	Number of log sources, diversity of formats, and whether logs reach a small set of central log servers
Rule writing and tuning	Internal security engineers or an implementation partner under a fixed scope	Initial build is one-time; tuning recurs	Number of detection rules, false-positive rate, and how many log types the correlation logic spans
Threat intelligence feeds (if used)	Feed providers, where subscriptions apply; analysts who integrate indicators	Usually recurring subscription plus integration work	Number of feeds, data volume, and whether feeds are paid or free. Confirm terms with each provider
Central log storage and retention	Cloud or data center infrastructure owner, or storage vendor	Recurring	Log volume per day, retention length set by policy and regulation, and indexing overhead
Evidence upkeep	Control owners, compliance leads and any GRC tooling	Recurring	Frequency of evidence capture, number of correlation use cases documented, and change tickets for rule updates
External testing or review	Independent testers or assessors, paid per engagement	Recurring if scheduled, one-time for a readiness review	Scope of log sources tested, whether detection is tested end to end, and assessor familiarity with the stack
Auditor sampling	Independent auditor, paid under the audit engagement	Recurring per assessment cycle	Number of samples requested, availability of ready-made correlation reports, and the auditor's testing approach

Who owns DE.AE-03 and what an implementation partner handles

DE.AE-03 asks that information from multiple sources be correlated, and the organization remains accountable for that outcome. Ownership sits with the security function and the teams that run the systems generating logs. An implementation partner can design and build the stack, but cannot decide which events matter to the business or accept residual risk on the organization's behalf.

Control ownership: The organization names an accountable owner for event correlation and signs off on the scope of log sources it expects to be correlated.
Log source owners: Application, identity, network and cloud teams confirm that their systems forward the events the rules depend on, and they tell the SOC when a source changes.
Triage decisions: Analysts decide whether a correlated finding is a true positive, a known false positive or a benign change, and they record the reasoning.
Rule approval: A named approver reviews new or changed correlation rules, including Sigma rules and custom detectors, before they run in production.
Retention and access: The organization sets how long correlated data is kept and who may view it.

Confirm that each of these responsibilities has a named person or team and that the role descriptions are in your policies.

Questions buyers ask about DE.AE-03 cost, effort and outside help

How much effort does DE.AE-03 event correlation take?

The effort depends mostly on how many log sources you need to correlate and how well-defined your current logging is. DE.AE-03 asks that information from multiple sources be correlated, and NIST's Implementation Examples describe three building blocks: sending log data to a small number of log servers, using event correlation technology such as a SIEM, and using threat intelligence to link events across log sources. The largest effort usually sits in identifying which hosts, network devices, cloud services and applications produce useful security events, mapping their formats, tuning rules so alerts are actionable, and documenting how the correlation is evidenced. Ask any provider to break the estimate down by log source, rule set and evidence deliverable rather than giving one total.

Can we implement DE.AE-03 in-house?

Yes, many organizations do, provided they have engineers who can operate a log pipeline and a correlation platform and an analyst who owns the alert queue. NIST does not prescribe a product, and the open-source tooling for this outcome is documented publicly, so the decision is mainly about skills and capacity. Teams often keep ownership of the controls and runbooks in-house and bring in outside help for a fixed-scope piece such as the initial architecture, detector tuning or evidence preparation. DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, but the organization remains responsible for its controls and for operating them after handover.

What does DE.AE-03 need from our own team?

Three roles are needed before correlation produces useful outcomes:

Log source owners who can enable audit logging, confirm retention and approve forwarding of events from their systems.
A named triage owner who decides what a correlated finding means and who escalates it to incident response.
A change approval path for new correlation rules, detector changes and log forwarding, so tuning does not silently suppress real events.

Without these, a SIEM or log server can collect data but no one can show that information from multiple sources was actually linked. Confirm these owners and approvals with your team before scoping any external work.

How long does DE.AE-03 take to implement?

NIST does not publish a timeline for DE.AE-03, and no fixed duration applies to every environment. The schedule is driven by the number of log sources in scope, whether a central log server already exists, how much detection content must be written or tuned, the approval cycle for changes, and how much historical data must be onboarded for review. Organizations with mature logging often move faster because the main work is correlation and tuning. Ask for a timeline as a set of milestones tied to named log sources, with the dependencies on your change approval and access requests written out.

Does NIST certify that we comply with DE.AE-03?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. The CSF is voluntary for most organizations, so an assessment of DE.AE-03 is performed by your own team, an internal audit function or an independent assessor, and the result is a documented self-assessment or assessment report, not a NIST certificate. Be wary of any vendor or consultant who sells a NIST CSF certification. Some customers or regulators may still require alignment evidence, so confirm what form of proof they expect before the work starts.

Will an auditor accept self-hosted open-source evidence for DE.AE-03?

An assessor evaluates whether the evidence shows the outcome is achieved, not which vendor produced it. Self-hosted tools can generate the records an assessor typically asks for, such as correlated alerts, rule definitions, alert routing and retained logs. For example, Wazuh writes matching alerts to alerts.log and alerts.json and maps them to MITRE ATT&CK, while OpenSearch Security Analytics records findings and links them in a correlation graph. Whether a specific auditor accepts a given artifact is a question for that auditor. Agree the evidence list, retention periods and sampling approach with them in writing before the implementation is finalized. DeployOpen prepares systems and evidence but does not issue assessment reports.

What should we ask a partner to include in a written scope?

A written scope should make the work and its evidence checkable. Ask the partner to list:

The log sources in scope, by system and by owner, with the forwarding method for each.
The correlation technology, detection content and threat intelligence inputs to be configured, and which rules are excluded.
The deliverables, such as architecture documents, configuration files, runbooks and evidence packs, with the format of each.
The responsibilities split between your team and the partner, including who approves changes and who operates the platform afterward.
Acceptance criteria, the timeline milestones and any ongoing support, which is available as a retainer.

Most engagements are fixed-scope, so the agreed scope is the basis for any quote. Request the written scope before comparing prices.

How DeployOpen scopes and evidences DE.AE-03

DeployOpen plans, implements and documents self-hosted open-source log centralization and correlation inside your own infrastructure for DE.AE-03 Event correlation. Your organization owns the control, and DeployOpen prepares the systems and evidence that an independent assessor can review.

How we scope

Agree in writing which log sources, hosts, network devices and cloud services fall within DE.AE-03 correlation scope.
Define which log servers will receive centralized log data and how transfer paths are secured and monitored.
Confirm whether correlation runs on OpenSearch Security Analytics, Wazuh, or both, and which log types each covers.
Record how DE.AE-03 links to related Subcategories and to any ISO/IEC 27001, SP 800-53 or SP 800-171 mappings you require.

How we build

Configure log forwarding to a small number of central log servers, with time synchronization and access controls documented.
Load prepackaged and custom Sigma rules into detectors, then tune them against your own log baseline to reduce noise.
Set up correlation graphs that link findings across identity, network and application log types for analyst review.
Integrate threat intelligence feeds into correlation logic and test that matched events raise the expected alerts.

How we hand over

Deliver a written record of log sources, retention settings, detector configurations and correlation rules in scope.
Provide test results showing sample events that were ingested, correlated and alerted, with timestamps and rule identifiers.
Document the alert routing to your SOC channels and the steps analysts follow when a correlated finding is raised.
Hand over administrator runbooks so your team can maintain rules, add log sources and review correlation output.

How we support

Offer ongoing support, rule updates and upgrades as a retainer after handover, if your organization wants them.
Schedule continuous testing of correlation coverage as log sources and cloud services change in your environment.
Confirm with your independent auditor which evidence formats they accept before the assessment begins.
Remember that DeployOpen prepares evidence but does not issue audit reports, attestations or certifications.