CMMC 3.14: System and Information Integrity

Friendly reminder that if you're feeling overwhelmed by these CMMC requirements, I highly recommend going through a third-party CMMC assessment. Now, on to the controls!

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!

Section 3.14.1

Identify, report, and correct system flaws in a timely manner.

The term "system flaws" is a bit ambiguous here. It depends on how you read it, what type of work you're in, what you're used to. Some folks will look at this as coding flaws. Some will look at it as misconfigurations in the system. Some could be vendor related. So there's a wide variety of really what constitutes a system flaw.

For clarity's sake, here are the three most common "flaws."

• Security vulnerabilities
• Missing patches or updates
• Common vulnerabilities and exposures (CVEs)

CVEs are the most probably common of any of these. You're going to need to address how you can identify these flaws. Vulnerability scan reports, penetration testing, risk assessments, those are some of the easy ones, because you can either do them internally or pay a third-party company to come in basically by outsourcing this.

Incident response activities are especially nice to have because they can help pinpoint the flaw that potentially caused an incident to happen.

Addressing these issues tends to be fairly low cost, you'll just need to determine the frequency at which you're going to run the scans and how you're going to manage the flaws that you find.

Section 3.14.2

Provide protection from malicious code at designated locations within organizational systems.

From a NIST perspective, "designated locations" are entry and exit points. Here are some of the most common:

• Firewalls
• Remote access servers
• Workstations
• Mail servers
• Web servers
• Proxy servers
• Mobile devices

These are clearly not every entry and exit point for every organization, but they're the most common, and you're likely to have one or more.

Look at your organization specifically, and then determine which ones are applicable. Moving forward, once you have that list, it's going to make it a lot easier to log, monitor, and combat these designated locations.

Section 3.14.3

Monitor system security alerts and advisories, and take action in response.

This is a unique one, because there's no specific guidance about the number of alerts you should get, the frequency you should review them, or how you should take action.

I recommend looking at the contract you're working under, and act accordingly. Has someone dictated a specific response timeline or plan of action? Use that as guidance so you're in compliance with your contract. Combine that with some common sense and logic, and you're in good shape!

Also, don't forget to take advantage of the tools you have. Setup alerts for your SIEMs, endpoint protection software, etc. Look at your current setup and see if there's anything available to help meeting this control.

Section 3.14.4

Update malicious code protection mechanisms when new releases are available.

This is a pretty cut and dry section. Antivirus signatures typically update on their own or are pushed from a console when they're a managed service at an enterprise level.

But some products don't rely on signatures. Some are reputation-based. Some are mathematical algorithms. So what you're really looking for here is, are my agents and my technologies and my signatures up to date? Is the operating system patched up to date? My vendor security patches, are they applied?

Now, I did want to throw a note in here that we're typically cautious in both the IT and cybersecurity fields of going to the newest release of any piece of software as it comes out, because it hasn't necessarily been tested long enough to find vulnerabilities. Even after the proper testing has been done, you'll often find that when you upgrade a piece of software because you want to close a security vulnerability, the upgrade will often open a new one. You may not know what the new one is when it's being upgraded, but it'll be found later.

Finding a solution to this problem is tricky, but most organizations apply the N-1 technique. "N" is your newest available release, and the numbers after tell you how many release versions away from current you'll allow.

Every organization is different, and you'll have to devide if you're an N-2 or maybe N-5 company. Adjust for what your contract allows, the frequency of software updates, and what is feasible to maintain for your team.

Section 3.14.5

Perform periodic scans of organizational systems and real-time scans of files from external sources as files are downloaded, opened, or executed.

This section is fairly simple and common with today's endpoint protection services. Most businesses use software that runs all the time in a monitoring mode, and as soon as you download something, it immediately activates and scans the file.

Periodic scans, however, speak more to the vulnerability scans, where you're catching your outdated software and missing patches. Most organizations now perform penetration testing annually through a third party thanks to cyber insurance and client contract requirements.

You can also use vendor configuration scans and tools to find vulnerable security configurations. As an example, Microsoft offers one for Office which allows you to see how your licensing is configured. What's an available security option for you at each license package? Do you have it enabled? The tool gives you a score so you can see how well or how poorly you're doing.

Dependent on vendors and the size of your organization, there are plenty of different choices available for you at a relatively low cost to meet this control.

Section 3.14.6

Monitor organizational systems, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.

The easiest method to look for attacks would be monitoring system boundaries for any security events. If you're an organization who deals with having a website that brings a lot of traffic and maybe e-commerce, like Amazon for example, and you're leading up to a Black Friday sale, you're going to want to make sure that they pay for both a physical appliance and/or software that can help with load balancing and blocking denial of service attacks, so the website doesn't go down.

But you also want to be monitoring for these types of things in advance to see if maybe today the hardware that you have can handle the amount of traffic that's being sent to the website.

You're going to have to look for these specific types of use cases, your organization, to see if any apply. For most, this control is just about monitoring and closing ports and making sure that everything is configured. Maybe you're doing minor things like geo-blocking to take care of external protections.

As for internal traffic, you need to review audit logs and have your SIEM alert you to any potential trouble at a minimum. You may want to consider going a step further and implement a true intrusion detection system (IDS) or prevention system (IPS). These systems will copy traffic and alert you to potential hazards, or can be setup to automatically block websites and traffic on your behalf. These can be expensive to implement but would improve your security posture DRAMATICALLY.

Section 3.14.7

Identify unauthorized use of organizational systems.

Here are some potential problems to look for to cover the final control of this section.

• Access to wireless access points
• Rogue devices on the network
• Remote connections from external users/devices
• Backdoors into the environment
• Partially authorized users with access to unauthorized assets

We've discussed the tools to prevent these types of problems already in 3.14.5 and 3.14.6. Again, you'll need to judge what your organization needs based on budget, time, and compliance needs.

Most of these types of issues would be anticipated and expected, but you need to make sure you're identifying them and are able to rule out which ones are authorized as well as the back doors into the environment.

On that note, we're done! We've now covered all of the domains of CMMC NIST 171 R2. I'd like to personally thank everybody that's stuck with me through this sessions, and wish you luck in meeting the compliance regulations in the coming year!

Does Your Business Need Help Achieving CMMC Compliance?

Be sure to catch up on our past CMMC blogs to find out all you need to know, and then reach out to our cybersecurity experts about a third-party assessment. We'll be happy to help your business reach the security requirements you need for CMMC compliance!