Connect the Clues: Introduction
You’ve probably seen at least one detective show in your lifetime. Whether it was a grizzled, old-school investigator with a corkboard full of index cards, red string, and newspaper clippings pinned to the wall, or a cutting-edge cybercrime unit staring at a wall of monitors scrolling with live data feeds, what they all have in common is this: they don’t just look at one clue in isolation. They connect them. They correlatethe seemingly unrelated events and find the pattern. That’s how crimes often get solved.
Now, I know what you’re thinking, “Steve, what does a detective show have to do with GRC and Audit Correlation?” Hush, child. All shall soon be revealed. It’s because AU.L2-3.3.5 is, in many ways, a lot like the detective and that corkboard. It’s the requirement that says: “Don’t just collect logs. Don’t just review them. Make sure those efforts work well together as well!”
In today’s blog, I want to dive into NIST SP 800-171‘s 3.3.5 requirement for Audit Correlation. We’ll cover what it means, the risk it addresses, break down its two assessment objectives, walk through what implementation can look like in practice for organizations of different sizes, and close out with the things you’ll want to make sure are in place before your assessment. Let’s get into it!
What in the World Is “Audit Correlation”?
Ok so what does 3.3.5 actually say? The control requirement reads:
“Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.”
What a mouthful! That’s pretty convoluted for a compliance requirement, right? What does “correlate” mean here, and why does the word matter so much? Let me flesh that out.
In the context of audit logging, correlation is the practice of integrating review, analysis, and reporting processes so they inform one another rather than operating as isolated silos. The NIST SP 800-171 Rev. 2 discussion section captures this well, stating that the intent is to ensure these processes operate “collectively” rather than independently. The requirement is also intentionally flexible; it doesn’t prescribe whether correlation happens at the individual system level or across the entire organizational environment. That’s by design, and it’s actually helpful for organizations of varying sizes and complexity.
Now (and this is important, so sit up straight!) 3.3.5 sits in a broader sequence of audit and accountability requirements. If you’ve been working through the Audit and Accountability (AU) domain, you know that 3.3.1 covers what you log, 3.3.2 ensures user actions are traceable, 3.3.3 makes sure you review and update the events you’re logging, and 3.3.4 requires you to alert when the logging process fails. By the time you get to 3.3.5, the expectation is that you’ve got logs, they’re capturing the right stuff, and someone is paying attention. The next question now is, “Are those people talking to each other and connecting what they see across the system?” and “Are they doing things in a way that works together instead of against each other?” That’s 3.3.5. That’s why we’re here.
The Risk on the Other Side of the Corkboard
As I’ve said before and will probably say a hundred more times (gotta earn the chronic yapper title somehow), every security requirement or control exists to mitigate a specific risk. Implementing a requirement without understanding the “why” behind it is kind of like child-proofing your home with electrical caps while trying to make toast in the bathtub. Kids, don’t try that at home.
Let’s say your organization has a perfectly functioning audit logging setup. Your Windows Event Logs are capturing failed login attempts. Your firewall is logging outbound traffic anomalies. Your file server is recording who’s accessing what and when. Beautiful. But here’s the problem: those three sources are being reviewed by three different people who never talk to each other, who focus on just the systems they are responsible for, who are never required to look at the bigger picture collaboratively and across the other relevant sources, and they have absolutely no mechanism or procedure that connects the dots between what each of those sources is telling them.
Now imagine this: on a Tuesday night at 2:47 a.m., there are five failed login attempts on your file server from an internal IP. At 2:52 a.m., one of those attempts, succeeds. And at 2:55 a.m., your firewall logs a large outbound data transfer to an external IP you’ve never seen before. If no one is correlating those three data points, that Tuesday night incident might go completely unnoticed until a customer calls with “Hey, why is someone holding our sensitive data for ransom?” If the person who saw the alert or notification from the firewall that a large amount of data went outbound had received alerts about the failing login attempts prior to the exfiltration, maybe it could’ve been stopped, or at least the damage could have been limited. But, because they’re in totally separate worlds following different processes for reviewing, investigating, and reporting on such activity, things went unnoticed until it was too late.
That is the risk that AU.L2-3.3.5 is designed to mitigate. These uncorrelated processes are, functionally, almost as bad as having no processes or audit logging capabilities at all. You’ve done the work to collect it; now the requirement is to make sure the review, analysis, and reporting processes around that data are designed to catch what individual, siloed processes might miss.
And this isn’t a theoretical risk. It’s the exact kind of threat behavior pattern that sophisticated adversaries use! They blend in, move slowly, and rely on defenders to be disorganized and cursory, and certainly to not be actively connecting the clues. Ladies and gentlemen, your corkboard needs red string!
Gimme’ the Scoop: The Two Assessment Objectives
Like my previous deep-dives on requirements like 3.4.5 and 3.13.16, I want to make sure we break down the assessment objectives (AOs) because that’s where the rubber meets the road in an actual assessment. AU.L2-3.3.5 has two:
[a] Audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity are defined.
This first objective is the administrative/procedural foundation. Before an assessor from a CMMC Third-Party Assessor Organization (C3PAO) is going to evaluate whether your correlation processes are actually working well together, they’re going to look for evidence that those processes have been defined somewhere. Think about documentation that captures the answers to the following questions:
- What are your processes for reviewing logs? How often? By whom? What triggers an escalation or investigation?
- What constitutes suspicious or unusual activity in your environment?
- What are the different tools that can support the review of logs?
- What are some playbook, routine workflows that someone can follow to investigate suspicious activity?
- What are the elements or conditions that must be met in order for the investigation to convert into a declared incident?
- How does someone initially report findings and track progress related to the alerts to their resolution?
These are the kinds of questions your defined processes should answer in detail.
Side note: Defined doesn’t mean a one-liner in your System Security Plan (SSP) that says “we review logs.” Assessors will want to see evidence that the people responsible for this know what they’re doing and have clear guidance to follow. Specificity is your friend here; it always is when writing process and procedure documentation.
[b] Defined audit record review, analysis, and reporting processes are correlated.
This is where the integration piece comes in. Once you’ve defined your processes (objective [a]), objective [b] asks: are those processes working together? Are your review, analysis, and reporting activities designed only to share information across log sources, systems, and repositories, but also to bring the way people perform those activities into sync? Are you making sure that you have all the information you need to investigate, analyze, and report while ensuring those people involved aren’t stepping on each other’s toes? Assessors are commonly going to be looking for mechanisms (technical, procedural, or some combination) that demonstrate the correlation is happening. This is where tools like SIEMs (Security Information and Event Management), log aggregation platforms, or even well-structured manual procedures for cross-referencing logs and tools come into the picture.
The CMMC Assessment Guide for Level 2 notes that the assessor will examine things like “system audit logs and records across different repositories,” and that phrase “across different repositories” is doing a lot of heavy lifting. It’s telling you that siloed log review, even if it’s documented and consistent, likely doesn’t satisfy objective [b] on its own. Translation: if your logs live on separate islands, they still need to come together in a way the people reviewing the state of the entire system can utilize.
Side note: To be clear, there’s no requirement that you can’t use siloed or separate log repositories. Back in the CMMC 1.0 days, there was a Delta 20 requirement that expected logs to be aggregated into one or more centralized repository (AU.3.048). This is no longer the expectation as there are practical reasons why aggregating logs into central repositories may not be feasible (e.g., tools or cloud services that don’t support shipping logs to an aggregator via an API call.). The requirement under 3.3.5 is simply to ensure that your processes cover relevant log reviews, analysis, and reporting sufficiently.
How to Actually Implement 3.3.5
Now for the part that I always enjoy most; the “ok but what do I actually do” section, if you will. And, true to form for this requirement, it depends. It depends on your organization’s size, technical maturity, and the complexity of your environment. Let me break it down into a few tiers.
For Smaller Organizations: The Manual-But-Documented Approach
Not every Defense Industrial Base (DIB) contractor has the budget or technical infrastructure for enterprise-grade log correlation tooling, and that’s ok! The CMMC Assessment Guide acknowledges that smaller organizations “may be able to accomplish this manually with well-defined and managed procedures.” The keywords there are well-defined and managed. Manual correlation can work, but it must be structured and documented. This means:
- Having a clear, documented procedure for log review that explicitly requires the reviewer to cross-reference relevant sources (e.g., endpoint logs, network device logs, and application logs reviewed together during a defined review cycle)
- Documenting what “suspicious activity” looks like across different log types so reviewers have concrete indicators to look for
- Defining a clear escalation and reporting path when correlated indicators are identified
- Maintaining records of your log review activities as evidence of the process being executed
Even for small businesses, it is still my recommendation that you implement any technical automations you can, even if it’s simple scripts kicked off as part of a task schedule or through something like Power Automate Flows or Logic Apps in Azure that group logs together and send an email alert/report. Things like this are cost-effective in most circumstances and can make these processes at least a tad more seamless on a budget. If you’re a cloud-first, cloud-only Microsoft 365 and Azure shop, the cost of Microsoft Sentinel may actually not be as horrendously costly as it would be if you were a larger and more complex operation. It’s a VERY helpful tool to implement if your budget allows it and might be worth checking out.
However, if you’re going the manual route, the discipline of your team in following the procedure and the documentation you maintain proving that it’s happening is going to be everything.
For Mid-Sized and Larger Organizations: Centralized Log Aggregation and SIEM
For organizations with the technical resources to support it, the most robust way to satisfy 3.3.5 is through a centralized log aggregation solution and/or a Security Information and Event Management (SIEM) platform. The CMMC Assessment Guide specifically calls out that larger organizations “will use an automated system for analysis that correlates log data from across the entire enterprise.” Tools like Microsoft Sentinel, Splunk, Elastic SIEM, and a host of other platforms are purpose-built to ingest logs from disparate sources, apply correlation rules, generate alerts, and support investigation workflows all in one place.
Some organizations and their Managed Service Providers (MSPs) are even going further, orchestrating the entire process using Application Programming Interfaces (APIs) to automate collection, correlation, and rule-based response actions. That kind of maturity is fantastic, and if you’re there, you’re probably in really good shape for this requirement. But I want to be clear: a SIEM alone doesn’t satisfy 3.3.5. It just supports the enablement of your documentation. You still need defined processes around how that SIEM is configured, monitored, and used for investigation and reporting. The tool needs to be paired with procedural governance. Both matter.
Side note: If your MSP or MSSP is managing your SIEM or log aggregation on your behalf, you need to make sure you understand how that service is scoped, what their obligations are in your CMMC environment via a document Customer Responsibility Matrix (CRM), and that you’ve addressed them as an External Service Provider (ESP) in your SSP appropriately. I won’t go too deep into the ESP/SPD rabbit hole here, but just know, it matters!
Before Your Assessment: Things to Have in Order
I always want to make sure we close out with something practical. Here’s the summary of things I’d encourage you to have buttoned up before the assessment team comes knocking on 3.3.5:
- Documented Processes Are Non-Negotiable. Don’t let objective [a] be your downfall. You need written, specific processes for audit record review, analysis, and reporting that explicitly address the correlation piece. Vague or fluffy implementation statements won’t work. Your SSP should simply reference and summarize what you’ve documented in more detail in your procedures.
- Know Your Log Sources. You need a clear picture of all the log sources within your environment that are in scope for your assessment: endpoints, servers, network devices, applications, cloud services, etc. You can’t correlate what you don’t have a handle on. My recommendation is that this be one of the first things you document in your procedures and that you build your other processes from there.
- Your Mechanism Needs to Be Evident. Whether you’re using a SIEM, manual review procedures, or both, the mechanism you’re using for correlation needs to be identifiable and demonstrably in use. Tickets, filled-out morning checklists, Incident Response documents, automated alerts, dashboards, and reports are all things that need to be available as evidence for your assessment.
- Document Your Reviews. Maintain records of your log review and analysis activities. If you’ve identified and investigated something, document it. This gives assessors something concrete to evaluate and demonstrates that your processes aren’t just theoretical. Schedule a recurring ticket in your Information Technology Service Management (ITSM) and a calendar invite to show you’re intentional about your audit and accountability processes.
- Think About Your Neighbors. 3.3.5 doesn’t live in isolation. It’s closely related to 3.3.1 (what you’re logging), 3.3.2 (user traceability), 3.3.6 (audit record reduction and report generation), and 3.3.8 (protecting audit information). A mature, well-rounded audit program makes 3.3.5 a natural extension of what you’re already doing. Correlate your other requirements with this one. CORRELATION INCEPTION! Now we’re ‘Meta’.
Final Thoughts on AU.L2-3.3.5
At the end of the day, 3.3.5 is asking your organization to be the detective who actually uses the corkboard, connects the clues, sees the patterns, and responds before the situation gets worse. The individual log sources you’ve set up are the index cards. The red string is your correlation capability. Without it, you’ve got a pile of clues and no way to see the bigger picture.
The good news is that this requirement is scalable. Smaller organizations can implement it with disciplined manual procedures. Larger organizations have access to powerful tooling that can make correlation nearly automatic. Whatever your size, the key is intentionally designing your audit and accountability program from the ground up to ensure that your processes for review, analysis, and reporting are best friends.
If you and your organization are working through the AU domain or preparing your broader audit and accountability program ready for a CMMC Level 2 assessment, we’d love to help! We, at IntelliGRC, are constantly advising and supporting organizations through these exact challenges. Whether you’re an Organization Seeking Certification (OSC) working toward your C3PAO assessment, you’re an MSP trying to understand how audit correlation fits into the services you provide your clients, or you’ve got some other GRC-related challenge in your path, we’re here to help. Feel free to fill out our contact form found here or shoot us an email at sales@intelligrc.com.
As always, Happy Implementing!
— Steven Molter
Connect with me on LinkedIn if you want to keep the conversation going! 
Key Takeaways
- AU.L2-3.3.5 requires organizations to correlate audit record review, analysis, and reporting processes, not just perform them in isolation or in a way that conflicts with each other.
- The requirement has two assessment objectives: defining the processes [a] and ensuring those processes are correlated [b].
- The risk addressed is the failure to detect security incidents that are only visible when log data from multiple sources is analyzed together, and the organization’s ability to investigate and respond to troublesome activity is hindered due to conflicting processes.
- Implementation can be manual or somewhat automated but must be documented well and evident either way.
- 3.3.5 doesn’t live alone, it is closely connected to other AU domain requirements, and a mature audit program makes this requirement a natural extension of existing practices. This should be kept in mind when implementing.