DoD Contractor Considerations for CMMC Practice Guide SC.L1-3.13.1

Editor’s note: This article is one of a series of articles about the CMMC Level 1 Practices. In these articles we dive into the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC Level 1 resource.

Overview of SC.L1-3.13.1

This is the first practice in the System and Communications Protection domain, and if you were to identify which of the CMMC practices requires a firewall, this is the one. With eight assessment objectives and the many methods to defend a system boundary, it’s no surprise then that there is far more to this practice than simply having a firewall.

In summary, SC.L1-3.13.1 requires that you define your external network boundary and key internal network boundaries. Those boundaries must also be monitored, controlled, and protected. If we were talking about physically protecting a house, these practices could be summarized as:

• Identify all your doors and windows [a, b]
• Implement a security system (monitor) [c, d]
• Only open the door for allowed people (control) [e, f]
• Keep the doors and windows locked (protect) [g, h]

The house metaphor, however, starts to break down when we talk about internal boundaries. Although motion detectors and internal cameras are not uncommon with home security systems, most people do not put a lock on their pantry (though that could curb the midnight snacking). Sadly, in the world of cybersecurity, we can’t rely exclusively on protections at the network perimeter.

Define External [a] and Internal [b] Boundaries

This practice focuses on “system boundaries.” A system boundary is the logical (rather than physical) perimeter of the system. It includes all barriers (devices, services, and software) through which traffic flows before a connection is made to another system or device on the other side of the boundary. The practice speaks to both internal and external boundaries.

External System Boundaries

The external boundary is the system boundary that surrounds your enclave. For most organizations, this is likely to include your corporate firewall that connects your corporate network users to the Internet. All inbound and outbound requests to and from your network pass through your firewall.

Although the firewall is the most obvious external system boundary, it is usually not the only one. Your users’ computers (or other devices) might also be part of the boundary. If your users are:

• able to access the internet directly from their computers without the traffic passing through your corporate firewall, and
• their computers also process, store, or transmit Federal Contractor Information (FCI) or Controlled Unclassified Information (CUI)

This commonly occurs with companies that allow remote work. For example, your remote team members access a cloud document sharing platform. A software agent on the user’s computer syncs the cloud files with FCI or CUI back to the user’s computer. In that case, the user computer “stores, processes, or transmits” covered information and are part of your external boundary.

Internal System Boundaries

Internal system boundaries follow the same basic principle and are expected in zero-trust environments.  Internal system boundaries are common if a company has internally hosted systems that store, process, or transmit FCI or CUI. For example, a company uses an internally hosted web-based contracting system that contains FCI. It has an application server and a database server. The company determines that those servers should reside within their own boundary and implement a firewall through which all traffic must pass before reaching the application server and the database server.

Defining the Boundaries

Okay, now we know some of the common things to look for with respect to system boundaries, but assessment objectives [a] and [b] require that they are defined. Ultimately, this means that the boundaries need to be documented. The CMMC assessment guide is not opinionated as to the form of the documentation. So, although you could document your internal and external system boundaries in iambic pentameter or in a diorama, we recommend a network diagram or topology. The illustration below shows a basic illustration of a network that has:

• internally hosted applications
• separate vLANs for administrators and normal users
• remote users
• defined network boundaries for the above

Monitor External [c] and Internal [d] Boundaries and Protect External [g] and Internal [h] Boundaries

Monitoring and protecting system boundaries are usually so closely related to each other that they should be discussed together. Most commonly, monitoring is an automated process where a device is listening to some type of network traffic coming into a boundary, and if that monitoring identifies a threat, it automatically blocks the threat, protecting the system(s) internal to the boundary.

For example, corporate firewalls are typically configured to automatically detect malicious traffic patterns and drop data packets if malicious traffic is detected. Detected threats that meet a specific threshold may result in automated blocking of the IP address.

If a boundary monitoring mechanism is not capable of automatic actions to protect in response to detected threats, it is likely capable of automatically notifying your administrator or writing security events to a log that can be manually reviewed on a periodic basis (e.g., daily or weekly).

Monitoring can also occur on outbound traffic. For example, automated ransomware payloads may attempt to access the internet on obscure ports to download the public key being used to encrypt data. If a user attempts to access the internet on a blocked port, that may trigger an alert as well. Additionally, data loss protection (DLP) systems may inspect outbound packets for sensitive information leaving the network.

What about remote users who might have CUI or FCI on their computers? To meet this requirement their computers could be fitted with:

• Endpoint detection and response software
• Web filter software
• Host-based firewalls

Control External [e] and Internal [f] Boundaries

Controlling is part management process and part technology implementation.

In the previous sections, we’ve discussed various tools that an organization may use to help protect and monitor a network boundary. Those tools, however, should be configured based on the needs of the organization for the given boundary device. Firewalls should be configured to deny all traffic and allow traffic by exception[1], i.e., control which data is allowed to pass through them to their destination and which data is blocked. The process to identify the types of data (ports and protocols) to allow at each boundary is a management process. The technology implementation is the deployment of the rules borne out of the management process.

Consider the above diagram. It has three firewalls: one internal firewall, an external firewall, and host-based firewalls installed on the endpoints. They might be configured as follows[2]:

• Internal Firewall
  • Inbound requests for the application on TCP port 443 (HTTPS) are allowed from the user vLAN and the admin vLAN
  • Inbound requests for the database on TCP port 443 (HTTPS) are only allowed from the admin vLAN, because users have no need for their computers to communicate directly with the database
  • Outbound – Block all
• External Firewall
  • Inbound – VPN requests on ports UDP port 500 and UDP port 4500
  • Outbound – TCP port 443 (HTTPS) and UDP port 53 (DNS)
• Endpoint Host-based Firewall
  • Inbound – Block all

Allowing only required ports and protocols is only one very small piece of the puzzle. Some of other considerations based on the technologies discussed in this article are:

Network Firewalls

• Geo-IP blocking – Block all inbound and outbound communications to countries you do not do business with
• Aggressiveness level of detection and blocking – More aggressive settings block more but are more prone to false positives
• Whitelist inbound IPs – If you have exposed services, only allow connections from specific IP addresses (if possible)
• Modern ciphers for VPNs – Avoid ciphers with known weaknesses
• Configure to notify IT administrators of specific circumstances (e.g., login attempts to the firewall or high threat level attack is detected)

Web Filters

• Block foreign domain extensions and foreign hosted sites
• Block categories as deemed necessary (e.g., adult, gambling, etc.)
• Configure HTTPS traffic inspection – requires an agent-based filter rather than a DNS-based filter
• Block downloads of executable files
• Block downloads of malicious files
• Block unapproved file sharing sites
• Configure to notify IT administrators of specific circumstances (e.g., a user attempts to download a malicious file)

Host-Based Firewalls

• Configure to block all inbound and outbound connections with the exception of necessary network services from authorized IP addresses. This can impair a threat actor’s ability to move laterally through the network. This is especially helpful for remote workers when little Timmy’s unpatched Minecraft server gets hacked

Endpoint Detection and Response (EDR) Software[3]

• Configure to deactivate the computer’s network interface and notify IT administrators of specific circumstances (e.g., ransomware detected)
• Aggressiveness level of detection and blocking – More aggressive settings block more but are more prone to false positives

Conclusion

SC.L1-3.13.1 – Boundary Protection is one of the more technologically complex CMMC Level 1 requirements. It may require expertise in networking and multiple commercial solutions. Conceptually, however, it is fairly straightforward. Put plainly, organizations should know where their internal and external boundaries are and implement technologies to prevent bad guys from getting in and stopping them if they do.

The other good news is that the technological complexity usually scales with complexity of the IT environment. And the more complex your environment, the more likely you are to have team members that understand the requirements in SC.L1-3.13.1 and possess the skills to implement them in your environment.

Many DoD contractors will not have the expertise or resources needed to perform a CMMC readiness assessment, identify the gaps, and develop corrective action plans. In these cases, the contractors are turning to cybersecurity consultants with knowledge of NIST and the CMMC framework. If you want to learn more about CMMC, Keiter’s team of cybersecurity specialists can help you. Email | Call: 804.747.0000.

Our team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.

[1] Deny all, allow by exception is a CMMC Level 2 requirement (SC.L2-3.13.6 – Network Communication by Exception); however, we strongly recommend all organizations adopt this posture where possible. It is a potent cyber defense posture.

[2] This is an extremely simplistic example. An actual configuration would need more rules. For example, the internal firewall and host-based firewalls would need to allow other ports to facilitate system administration, domain controller communications, and offsite backups.

[3] It may be more appropriate to document your EDR configuration and solution in your System Security Plan (SSP) documentation for SI.L1-3.14.2 – Malicious Code Protection. If so, we recommend referencing that documentation in your SSP documentation of SC.L1-3.13.1 – Boundary Protection.