read

CMMC Section 3.13: System and Communications Protection

By Dr. Jerry Craig | December 13, 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.
ntiva
We're almost there! This month, we're covering Cybersecurity Maturity Model Certification (CMMC) 2.0 Section 3.13: System and Communications Protection.

This is one of the more challenging families of controls to deal with thanks to the lack of specifics in the documentation about what is expected of you and the additional information that you have to reference to make sure you're meeting the requirements of the controls.

Given the complexity and difficulty of these particular controls and 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.13.1

Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.

Starting with a straightforward control. This is about implementing firewalls, gateways, routers, etc. The particular equipment will vary depending on the physical or virtual setup of your information system.

Restrict external traffic that appears to be spoofing internal addresses. Obviously we don't want anyone pretending to be you from outside your network!

A big part of this is considering dedicated communication lines. If you can segment your traffic from the public and keep your traffic away from public ISPs, you'll be much safer.

Reference Section

  • SP 800-41 for policies and guidance for firewalls
  • SP 800-125B for virtualization support.

 

Section 3.13.2

Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

This is a very broad, general statement, but it's very similar to the system design lifecycle, where you're not putting in a new system or upgrading a system without considering security and putting in the security principles right from the start.

If you're undergoing a major upgrade, that's a great time to think, "Do I need to reconsider my security architecture?"

Whether you're talking about physical, virtual, whatever, layered defense, you want to have that layered defense or defense-in-depth approach or principle. So let's not rely on a single technology or service to prevent an attack.

Make sure that you are incorporating security into the system development life cycle. Delineate between physical and logical boundaries. This is going to come down to cost for a lot of organizations. The smaller the business, the more difficult physical delineation might be, so you may have to rely on logic.

Also, understand and implement the compensating controls. In a lot of cases, you're not going to be able to meet the control outright the way the auditor wants. Maybe you have a business reason or there's a technical limitation. If that comes up, you're going to have to make the argument as to why you can't meet the control the way it's designed. From there, the auditor is going to ask how you're compensating for that. Be prepared.

Reference Section

  • SP 800-160-1 for guidance on systems security engineering

 

Section 3.13.3

Separate user functionality from system management functionality.

I think most of us know about this and are already implementing this in our environment. They consider system management functionality to be database, workstation, and server administrative accounts. Your normal user should absolutely not have one of these accounts.

Once again, make the separation physical or logical, and consider your entire network. The idea behind this is that it's more work for you to implement two different types of systems, but it's also more work for any potential criminals.

If you're attacked and someone moves laterally, the amount of damage they can do is limited. Just using different authentication methods can do that! If someone gets past multi-factor authentication, but you have a separate, different type of authentication method for a different system, they're going to be limited only to where the MFA is being used.

 

Section 3.13.4

Prevent unauthorized and unintended information transfer via shared system resources.

This one's going to be challenging, depending on what type of assets you have. Folks are very familiar with hard disks and information that's stored on a hard disk, but making sure that you can clear memory, cache memory in devices like printers and copiers is crucial.

When you're in a classified space, for example, and you have a copier, how do you flash the memory cache on that copier so that you can't go reproduce what someone else had just copied on?

You're going to have to look at your environment, see what type of assets fall into this category, and then see if you have the expertise to manage it, or do you need to reach out for help?

Again, this is one of those areas where we're starting to move into controls that I think third-party support may be a requirement for a lot of folks, especially if you're smaller and new to this space.

 

Section 3.13.5

Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

The term DMZ has been out for years. I don't hear it as often anymore, but the idea of building a private subnet to provide a gateway or proxy to make requests on behalf of users without letting them directly into the resource is quite common.

So once again, go out, look at the two special pubs that are here for additional guidance on doing it, but this one's a pretty straightforward one. Create a subnet and segregate as much as possible.

You can also do this from a tenancy space if you're dealing with more than one client's data. Each can have their own tenant space. If you're a developer, look at things like non-production and production, and maybe even different levels within non-prod. Each one of those can be a logical separation from another network.

Reference Section

  • SP 800-41 for policies and guidance for firewalls
  • SP 800-125B for virtualization support

 

 

Section 3.13.6

Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).

This one is really simple. You want to have a permanent denial in place, and permit only based on a need.

Every time you permit, you're poking a hole in a firewall. You have to be very careful that the devices that you have implemented don't do the opposite and allow all and then deny by exception. I've noticed this especially in lower-end equipment, your home office and small business type equipment.

Many vendors will start with an "allow all," because it's plug and play. You absolutely must go in and start with a denial and then configure acceptable traffic.

 

Section 3.13.7

Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).

This section is all about split tunneling. They want you to prevent a simultaneous connection to a corporate and non-corporate resource.

Let's say you have a corporate-furnished laptop in a hotel. You connect to work via VPN, but need to print something. Ideally, if the organization allows it, you would download the file from your corporate network to the local machine and connect to your hotel wifi to print the file.

But without the proper technical controls in place, there are ways that you could be connected to the corporate environment and then use your laptop as a pass-through to print to the hotel. In doing so, anybody who's then on the hotel network who could potentially access your device then have access to the corporate network.

There are tons of options to put in place to prevent scenarios like this, but it's the type of thing that you need to be considering and routinely checking.

Pay special attention to the fact that not everyone uses corporate-furnished laptops or equipment. What if they're connecting with a phone? What if they have a BYOD device? If they can make a connection to your data, you have to ensure that that data cannot be funneled off to another network.

 

Section 3.13.8

Implement cryptographic mechanisms to prevent unauthorized disclosure of Controlled Unclassified Information (CUI) during transmission unless otherwise protected by alternative physical safeguards.

We're going to get into a few controls here that deal with cryptography, especially as we move more into CUI.

This control applies to any device that can transmit CUI. So do not limit yourself and say, "Well, here's how I want people with our workstations or servers to behave." Do you allow anything else that could potentially see CUI?

This is where, again, going back to your telecommunication provider and look at what type of offering they have. Some of them will be fully dedicated, while many are simply add-ons. But, for varying price levels, and depending on which provider you have, you're going to have options out there to help meet this control. It may just come down to cost.

Reference Section

  • NIST CRYPTO for additional information on this section

 

Section 3.13.9

Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.

How are you timing things out and removing the user's access, any connection, any data tied to that connection?

If you have a laptop that locks when you walk away, that's great. But what if you're connected to your organization's VPN and running a process?

We see these situations often, where you're running long backup jobs and you need to stay connected, and then the DOD's communication session would terminate after, say, 15 minutes of inactivity. Well, you need that connection so that you can run certain jobs for backups, so they would have to tweak the rules.

You'll need to address this based on what your business needs. Can you model your work in a way that doesn't require a constant connection? Do you need to adjust your timeouts to fit the controls? And don't forget, any time you deviate from what's expected of you, you're going to have to document and be able to defend it.

 

Section 3.13.10

Establish and manage cryptographic keys for cryptography employed in organizational systems.

Managing crypto keys can't all be done manually, but your team will need to decide if a fully automated process can be done in-budget.

A couple of things to remember about this control: Consult 800-56A and 800-57-1 to make sure the cryptography solution you're looking at meets their needs. Also don't overlook the process of creation, storage, and disposal. Someone needs to manage key storage and you need to have processes and procedures in place to provide evidence that you're following them.

Reference Section

  • SP 800-56A and SP 800-57-1 for guidance on cryptographic key management and key establishment

 

Section 3.13.11

Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.

FIPS finally makes an appearance. Many large companies, like Microsoft, will say "We may have combined four different solutions. Each of these four solutions in and of themselves were validated, but the package or suite of packaged tools together has not been validated." Is this good enough for CMMC? We're all waiting to find out.

For now, the rules say everything must be validated, so be very careful.

Reference Section

  • NIST CRYPTO, NIST CAVP, and NIST CMVP for additional guidance

 

 

Section 3.13.12

Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.

This control is very interesting. If you look at the NIST documentation, you'll see that they talk about things like white boards, cameras, microphones. They want to know about all of these peripherals, which means you have to know about all the peripherals in your location, and then setup a mechanism that identifies when a device is in use.

For example, conference room cameras. Most of these will light up with a blue ring around their camera, or they'll go through a process where they pan and tilt as part of a setup. That at least tells you they're on. From there, the color of the ring could tell you when it's in use.

Some devices, may not be that easy. Some smart whiteboards may have a power indicator light, but no "in use" light. Be very careful with any new devices you purchase around the office.

 

Section 3.13.13

Control and monitor the use of mobile code.

The biggest thing I can say about mobile code is, you are going to be using mobile code. I don't know of anyone that operates without it.

You're going to need the support of the business and documentation surrounding the the business decision to use these things.

Whenever possible, make sure the code is digitally signed by a trusted source. You'll also need to make some serious decisions on how it's treated on your servers. Can it be on the server, but not downloadable? Can it be downloaded but not executed on a workstation?

There's a guide, 800-28, which provides guidance on mobile code, but this is mostly a business decision. You know what your business needs to operate. From there, you can figure out how to control the mobile code and what compensating controls you need.

I would recommend against trying to implement controls if you haven't at least done the business decision making portion of the process.

Reference Section

  • SP 800-28 for guidance on mobile code

 

Section 3.13.14

Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.

VoIP provides a huge upticks in your business's transmission speed and bandwidth. These VoIP lines are essentially the same as all other traffic.

If you're going over ethernet like in an office, you're not on a dedicated phone line, so there's going to be new threat vectors that exist, and the fact that it's happening at much greater speeds makes it more difficult to catch and stop and prevent before there's a problem.

The solution is to treat all VoIP devices just like any other network device. This can be a little more challenging, because VoIP is finicky. Once you start putting security controls in place, you may get dropped calls. You may get quality going down. This section is going to require some testing.

 

Section 3.13.15

Protect the authenticity of communications sessions.

This section is really about protecting against man-in-the-middle attacks, especially when MFA is involved.

Here's the important part of this section: implement controls that protect communications at the session level versus the packet level.

Hopefully you're familiar with the OSI model and the seven layers. Certain devices and networking appliances are going to operate at certain levels. Some will be more restrictive than others. If you're operating at layer seven, then you're obviously looking at all layers. You have the most visibility and the most capability for security. If you're only dealing at the packet level, layer three, it might be faster ,because you're just dealing with packets and more routing, but there may be less security involved.

Look at what your appliances are capable of and what exactly you're trying to protect. Make sure that you have the right device, appliance, and vendor for what you're trying to implement. It may come down to what you own simply is just not capable of providing something at the session level, in which case you have to consider changing devices.

Reference Section

  • SP 800-77, SP 800-95, and SP 800-113 for additional guidance on secure communication sessions

 

Section 3.13.16

Protect the confidentiality of CUI at rest.

We'll end with an easier one. Consider implementing file share scanning. Make sure the files are encrypted and that the encryption requirements are met, not just simply anything that's encrypted with any algorithm.

One thing of note: "If adequate protection of information at rest cannot be achieved, or continuous monitoring to identify malicious code at rest couldn't be achieved, there are options to use secure offline storage."

While they haven't gone into detail of what the requirements were or how that would be evaluated, it's good know you do have an alternate path.

I know we all immediately drift toward file encryption, but think about how, in what layer, what algorithm. How secure is it? Does it meet the requirements of the DOD?

Again, the last thing you want to do is buy a product, go out and encrypt all your files, and then have to rip that product out of your environment and then replace it with something else.

Reference Section

  • NIST CRYPTO for additional guidance

 

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!

 


Explore Our Managed Security Services

Tags: Cybersecurity