AU.L2-3.3.5

AU.L2-3.3.5: Audit Correlation

Correlate audit data from multiple sources to identify patterns and complex attack sequences that individual logs cannot detect.

A single log entry tells you what happened at one moment on one system. An attacker over two days making three failed login attempts, then stealing credentials, then accessing sensitive data, then exfiltrating files, generates dozens of log entries across four different systems. If you only look at logs in isolation, you see four small problems. If you correlate them, you see an intrusion.

AU.L2-3.3.5 requires you to connect the dots across systems. This is where a SIEM or log aggregation platform becomes critical to your security posture. You feed it logs from identity systems, endpoints, networks, and applications. Then you configure it to look for patterns that indicate a real attack. This is the skill that turns AU.L2-3.3.3 (log review) from checking boxes into actual threat detection.

Family Audit and Accountability
Practice AU.L2-3.3.5
Difficulty Hard
Key evidence SIEM correlation rules, analysis showing multi-source events, incident examples, correlation methodology

What the assessor is actually evaluating

The assessor is looking for evidence that you use logs from multiple sources to detect complex attack patterns. They’ll ask: “Show me an example of an incident you detected where correlation mattered. What would you have missed if you only looked at one log source?”

The answer matters. If you say “We looked at failed login attempts on our identity system and found a brute force attempt,” that’s one log source. That’s not correlation. If you say “A user had three failed logins on Tuesday, then someone logged in with their credentials from an unusual IP on Wednesday, then we saw that IP accessing the file server Thursday morning,” now you’re correlating identity logs, VPN or network logs, and file server logs. That’s this practice. This is also where your incident response team from IR.L2-3.6.1 gets visibility into the scope of a breach.

The assessor also wants to know your correlation approach. Are you using built-in SIEM rules, custom rules you built, statistical analysis, or a combination? Do your analysts know how to search for related events across systems? Is correlation part of your standard incident response procedure?

What a realistic SSP definition looks like

Example SSP Language: AU.L2-3.3.5
"Our organization correlates audit logs from multiple sources to identify coordinated attacks and complex security incidents. We aggregate logs from the following sources into our centralized SIEM:
  • Identity management and directory services (authentication attempts, group changes, privilege escalations)
  • Endpoint detection and response (process execution, file access, network connections)
  • Network security (firewall, intrusion detection, VPN access)
  • Email gateway (phishing, malware, unusual recipients or attachment types)
  • File servers and databases (access logs, modification logs, unusual query patterns)

Our SIEM is configured with correlation rules that detect patterns including:

  • Multiple failed login attempts followed by successful login from an unusual location or time
  • Process execution on an endpoint immediately after suspicious email receipt
  • Unusual file access patterns following privilege escalation events
  • Data transfer to an external IP following successful compromise indicators
  • Account activity during hours when that user is not normally active

Correlation rules are reviewed and updated quarterly. Analysts conducting audit log review use correlation to investigate incidents and identify the full scope of compromise. When correlation reveals a multi-system incident, it is immediately escalated to incident response for investigation and containment."

The key elements: multiple source systems, specific correlation scenarios, regular updates, integration with incident response.

How to present your evidence

Evidence checklist
  • SIEM correlation rules or query documentation
  • Example incidents (2-3) showing correlation across multiple log sources
  • Analyst documentation or incident templates showing correlation methodology
  • Monthly audit summaries noting incidents detected through correlation

Gather four types of evidence:

  1. SIEM correlation rules or queries. Export or screenshot your correlation configurations. Document what they look for. This can be a SIEM rule export, a list of saved searches, or documentation of your correlation methodology. Include the rationale for each rule or pattern.

  2. Example incidents showing correlation in action. Find two or three cases from the past 12 months where you detected an incident that involved multiple log sources. Document the timeline. For example: “Identity logs showed three failed logins for user X on 2025-11-15. Endpoint logs showed credential theft malware executing on that user’s machine on 2025-11-16. File server logs showed unusual access from that user’s account to sensitive directories on 2025-11-17. Correlation of these three events revealed the scope of the intrusion.”

  3. Analyst documentation. Show how your security team documents and investigates correlated events. This might be an incident report template that explicitly calls for investigating related events across systems, or a procedure that describes how analysts query the SIEM for correlated data.

  4. Evidence that correlation is ongoing. Alert logs or review summaries showing that correlation is part of your regular analysis, not a one-time event. This might be a monthly audit review summary that notes “3 multi-system incidents identified through correlation and escalated to IR” or specific tickets documenting correlated investigations.

Get assessment room tips in your inbox

Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.

Assessment room tips

Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.

Q: "Walk me through a real incident where correlation was important. What would you have missed without it?"
Tell a specific story. Identify the log sources, the timeline, the individual events, and how correlation revealed that they were part of the same attack. "If we only looked at the firewall, we would have seen traffic to a suspicious IP but not known why that user was accessing it. Correlating that with the endpoint logs showing malware execution told us the user was compromised."
Q: "How are your correlation rules maintained? How do you know they're detecting what you want?"
Explain your update process. Quarterly review is standard. New attack patterns prompt rule additions. Quarterly testing confirms rules are working. Mention that you tune rules based on false positive feedback from analysts.
Q: "Are all your analysts trained to use correlation? How do they know what to look for?"
Explain your team's training. New analysts should understand the correlation approach and how to construct queries across multiple data sources. Documentation or playbooks help. This is a technical skill that requires practice.

Common failures

SIEM without correlation: You have a SIEM that aggregates logs from multiple sources, but correlation rules are never configured. Logs sit there and analysts run ad-hoc queries. The system isn't helping you detect complex attacks. This is expensive log collection with minimal security benefit. Start with correlation rules. Even simple ones (three failed logins plus successful login from unusual IP) are better than none.
Examples that aren't really correlation: You show the assessor a single incident like "We detected a brute force attack" and call that correlation. Brute force on an identity system is correlation worthy only if you also saw the attacker trying to access other systems with the compromised credentials. Stick with true multi-source examples.
Incident-correlation feedback loop: Your incident response team documents which correlated events led to important discoveries. That feedback drives rule tuning and the creation of new correlation patterns. This creates an evidence trail showing that correlation is actively improving your detection.
Correlation in your IR process: Your incident response playbook explicitly includes a step to "Correlate initial indicators across log sources to determine scope." This ensures analysts consistently use correlation and creates documentation that they did so.

If you use an MSSP

Your MSSP owns correlation configuration and rule maintenance. They build and tune correlation rules based on threat intelligence and their observation of your environment. They use correlation during their daily analysis work to identify multi-system attacks. What they provide to you is documentation of the correlation rules they’re running and specific examples of incidents they detected through correlation.

An MSSP that doesn’t correlate is just aggregating logs. A good one builds rules, tests them, and actively looks for patterns across systems. Your role is to review their correlation approach, understand what they’re looking for, and approve changes to the correlation strategy. They execute the technical work. You oversee it.

Review MSSP correlation rules and findings

Request documentation of your MSSP's correlation rules and ask them to walk through a specific incident they detected through correlation. Their monthly or quarterly summary should note incidents detected through correlation and the systems involved. This documentation becomes your evidence of active correlation implementation in practice.

Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.

New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.

← AU.L2-3.3.6: Audit Reduction and Report Generation All Practices AU.L2-3.3.4: Audit Failure Alerting →