CMMC Section 3.3: Cybersecurity Audit and Accountability

By Dr. Jerry Craig | May 3, 2022
Jerry is Ntiva’s Sr. Director of Security and CISO, offering more than 20 years in the IT and cybersecurity industry. Certified CISO, CISSP and CCSP, Jerry also serves part-time as Adjunct Professor in the University of Maryland Global Campus.

The Cybersecurity Maturity Model Certification 2.0 (CMMC) includes practices and controls that fall under the category of “Audit and Accountability.”

Unlike with other areas of CMMC, this section has a smaller number of family resources to review, so it’s easier to discover what the CMMC requirements are, and what's expected of you.

But you are still going to have lots of questions—from taking stock of where you’re at now, to your capabilities for conducting an audit properly, to whether you’ll need additional tools, resources or outside expertise.

Table of Contents:

What You Need to Know About CMMC Audit and Accountability
Section 3.3.1
Section 3.3.2
Section 3.3.3
Section 3.3.4
Section 3.3.5
Section 3.3.6
Section 3.3.7
Section 3.3.8
Section 3.3.9
Your Guide to CMMC Compliance Success



Don't want to read the article? Watch the full recording below.
Be sure to register here for the Cybersecurity for the Rest of Us webinar series!



What You Need to Know About CMMC Section 3.3: Audit and Accountability

Cybersecurity Audit and Accountability fall under section 3.3, with nine individual practices to consider:


3.3.1: Create and retain system audit logs to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.

Notice that this control says, “to the extent needed.” It's not prescriptive enough to simply ask, “Do we have Windows logs?” After all, do you have endpoint logs?

Typically, this control involves using log ingestion as a task for a System Information and Event Management (SIEM) tool.

At Ntiva, we call it IDR, because it's performing both intrusion and detection while functioning as an SIEM. But the concept is the same: You identify all the types of logs and all of the devices that you have, physical and virtual.

Your goal is to point all these logs to one ingestion point, which is the SIEM. The SIEM then parses and makes use of that data. And then, depending on the size of your organization, one or more of your analysts take that data and turn it into something relevant with alerts, dashboarding, triggering and so on.



3.3.2: Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.

This control is more difficult. Most of your logs will show things like, “Someone logged in to the VPN at this time,” and “Someone disconnected from the VPN at that time.” You might be able to combine a VPN log with a Windows host log, and be able to say, “I saw the individual log in at 08:00, and I saw them log in to their workstation 07:45, which is how they got on it to create the VPN connection.”

But what did the user do from that point on?

They may have logged off at 16:00, so you can validate they were on the network. But were they working? What were they doing? What were they touching?

It's all being logged … somewhere.

Your challenge is, are you capturing those logs or are they just being generated and then lost on the end device? Are you capturing host logs, network logs and user logs? There are applications that help you make use of that data, but someone has to identify it first.



3.3.3: Review and update logged events

What are you capturing and reviewing? How frequently are you reviewing your logs? How are you documenting the processes you follow? Where's the evidence?

This is probably the most important control, even though it's the shortest and looks the simplest. You must determine all of this in advance.

You have to document what your processes are so that you can show them to your auditor. Then, the auditor's going to check if you're actually following your own documented processes.

So, where's that evidence? Be assured that the time to figure this out is not in the middle of an audit. So, any testing, any type of reviews you can do in advance, the better.



3.3.4: Alert in the event of an audit logging process failure.

Most organizations overlook this control. They set up their devices to send the logs, but if something happens and a device stops sending logs, the organization never notices.

One of the ways to solve this oversight is to create a dashboard. For example, if you have five firewalls, and if you want to see the total amount of traffic per day that the firewalls are producing, you use a dashboard to render that data as a bar chart.

You're obviously going to have some fluctuations day to day, but let's say that a 10% fluctuation in traffic is your threshold. If, all of a sudden, you see a 40% drop in logs for the day, you don't even need to be alerted in any other way. You know that a firewall is down, or that it’s not sending you the logs. You can then go look at it.

You must figure out these types of scenarios. You also need to decide if you will be putting this into a dashboard (assuming you have a person to monitor it live), or if you need to create a rule that automatically triggers an alert or a ticket.



3.3.5: Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.

Do you even know what unusual activity looks like on your network?

That may sound like a silly question, but “unusual activity” is something you must define. What’s unusual activity in one network is commonplace in another, depending on the global environment, country, region, culture and more—they are all different. Users work in multiple time zones. Their behavior for them may be normal, but abnormal to you. And if you work in multiple environments, you have to know what unusual and usual looks like for each of those environments, and then build out your solution accordingly.

This control is serious: If any of this activity is such that you may need to bring in law enforcement, it’s crucial to have iron-clad evidence. Do you have the qualified personnel who are available to review and analyze criminal behavior?




3.3.6. Provide audit record reduction and report generation to support on-demand analysis and reporting.

Consider the reporting that is available to you: Each product out of the box has some canned solution, but will that canned solution meet your needs, or do you need to customize? Maybe you need to send your user logs to another application that lets you customize the data a little more.

Are the reports in the process in line with a compliance certification you're required to adhere to? You may be doing audit log collection and reporting and reviews, but will these activities meet the certification requirement (of CMMC, for instance) versus just meet industry best practice?

What are you doing with the data presented in your reports? If you hold after-action meetings that identify failures, how many times do you actually implement fixes versus just record them as to-do items? If the same recommendations keep popping up at after-action meetings but are never implemented, this doesn’t show maturity from a certification perspective. You may have a well-documented security program, but what’s important is your level of maturity, and improvements you make to that maturity.



3.3.7. Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

This control is another one that organizations often overlook because organizations use various network time-synchronization protocols. You may allow Windows to do time-synchronization itself, for example. You might have your own NTP server. You might point things out to servers on the internet.

Now, imagine if you're trying to capture logs from a hundred devices … but your users and their timestamps aren't synchronized. It will be difficult to figure out who did what and in what order, if the times are all off.

In a lot of cases, this is not a big issue because users are unable to move around and do things in under a second. So, if timestamps are off by a second or two, this is not an issue. But, ideally, you want everything to synchronize. Time synchronization has a major impact on operations outside of security. You should do time synchronization for everything outside of security, and then offer that kind of integrity and accuracy that you would be looking for in an investigation.



3.3.8: Protect audit information and audit logging tools from unauthorized access, modification, and deletion.

How do you protect your audit information, audit logs and auditing tools from unauthorized access? Your IT staff may wear multiple hats, but this is one time when separation of duties and least privilege come into play. You don't want the individuals who audit your environment to also be the ones doing the work.

Otherwise, it's easy for someone to enter an environment and modify the tools or the logs to cover their tracks, so that you don't see that they have done something.

A good example of this is your vulnerability remediation program. You don’t want the same folks who do the scanning to then also do the patching remediation, because if they get busy, something happens and they don't want to look bad, what's to stop them from modifying the results? How do you make sure admins can't erase logs? (And even in the best-case scenario, hitting that delete button could be an innocent accident, but still has impact.)



3.3.9: Limit management of audit logging functionality to a subset of privileged users.

How do you limit access to files from a permissions perspective? How do you make sure no one with access modifies the logs? And then, how do you audit user access over time?

Auditing user access over time is probably the most difficult task because it's the most time consuming. It creates a ton of overhead that (to be frank) most organizations aren't capable of managing. Reports get sent, but no one reviews them.

This works until you get audited. You tell the auditor you have a process, but then the auditor asks, “What have you done with the data?”

The biggest thing to remember here is that what you do with your data is probably defined by the scope of your audit. So, the more you can do to reduce the scope, the easier your job is.


Your Guide to CMMC Compliance Success

The nine family controls under the CMMC category of Audit and Accountability may be easy to understand, but meeting these controls satisfactorily is another matter altogether. You’ll need to ask yourself a lot of questions around where you are now, and what you need to do (or who you need to bring in) to help you hit the mark.

And if all this sounds daunting, we’re happy to help out.


New call-to-action

Tags: Cybersecurity