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

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.

Practice
Practice Title: Public-Access System Separation
Practice Number: SC.L1-3.13.5
Practice: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Assessment Objectives
Determine if:
[a] publicly accessible system components are identified; and
[b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.

Overview of SC.L1-3.13.5

Preface: Throughout this article we reference different types of cloud services. Please note that cloud services that meet the definition of CUI Assets or Security Protection Assets must have the requisite FedRAMP Moderate/High Approval or Equivalency. Whether FedRAMP Moderate or FedRAMP High is required depends on your circumstances considering such factors as the presence International Traffic in Arms Regulations (ITAR) data, the use of end-to-end encryption, or other situation specific facts.

Company networks usually have an internal network and a firewall at boundary that separates and protects the internal network from the public Internet. The firewall should be configured, for example, to block inbound traffic to devices on the internal network.

However, some organizations have a need to allow inbound traffic. For example, a company hosts a web application server on their network to interact with customers. In such circumstances, the firewall would be configured to allow inbound traffic on TCP ports 80 (HTTP) and 443 (HTTPS) and direct all inbound traffic on those ports to the web application server.

Because it is intended to be publicly accessible, the web application server is exposed to the public internet, which is home to honest users as well as threat actors who can, and almost certainly will, attempt to compromise it. If the server is compromised, the threat actor would have a foothold on a server on the company’s internal network that can be used as a staging area to attempt further attacks.

This CMMC practice sets forth networking requirements intended to impede the lateral movement of a threat actor that has already successfully compromised a publicly accessible system or service.

To implement this practice, you must [a] identify your publicly accessible systems and [b] separate them logically or physically from the rest of your internal network.

Identifying Your Publicly Accessible System Components

Most companies will have at least some publicly accessible systems, and we think it’s helpful to put these systems into one of three groups. The nature and complexity of the compliance obligations vary based on the group.

Fully managed, cloud-hosted, services or systems

These are your typical software-as-a-service (SaaS) products and are typically purchased services where the application is developed, hosted, protected, and otherwise managed by the provider on their servers within their datacenters. Typically, users have little or no control over security at the network level.

Examples include:

• Microsoft One Drive
• Dropbox
• Google G-Suite
• Citrix ShareFile

Partially managed, cloud-hosted, services or systems

These are your typical infrastructure-as-a-service (IaaS) products and include cloud systems where you have a great deal more control over the networking and the server operating system itself where you can install software, open and close ports, and implement a firewall and/or a virtual network.

A web application in this model might entail configuring a cloud-based virtual private cloud (VPC) that contains a server to host the web application software, a database server, a backup server, and a virtual firewall in front of the VPC through which all public traffic must travel. You would have a massively increased amount of control and related responsibilities for the server, the software, and the networking.

Examples include:

• Web-based accounting system software you host in Microsoft’s Azure Cloud
• API service you host in the Amazon Web Services (AWS) cloud
• AI models you host in Google Cloud

Self-hosted, on-premises, services or systems

These include any publicly accessible services or systems that are hosted within the same network as non-public services or systems.

Like the previous example, a website in this model might have an application server, a database server, and a database backup server. However, they would be located on the interior of a company’s corporate network where end users, the domain controller, internal file shares, and other non-public systems are located.

Examples include:

• Remote time entry systems hosted on your own network
• Remote collaboration tools hosted on your own network
• Company website hosted on your own network

Separating Your Publicly Accessible System Components from Internal Networks

Once you’ve identified your publicly accessible systems [a], you need to ensure they are logically or physically separated from non-public systems [b] and document your implementation details to support your CMMC Assessment and/or Self-Certification.

In the subsections below, we’ll revisit each of the three broad categories we discussed above and describe methods to logically and physically separate public systems from internal systems.

Fully managed, cloud-hosted, services or systems

Fully managed SaaS products are completely separate from internal corporate networks, and as a result they have the least complex technical and compliance requirements for organizations.  For these types of systems, we simply recommend documenting that the service is fully managed by the cloud provider and is therefore separated from your internal network.

Partially managed, cloud-hosted, services or systems

These systems are also generally going to be fully separated from corporate networks, and only accessible from the corporate networks via a remote administration protocol, like secure shell (SSH). However, there are components of these systems that need to be exposed to the Internet and some that do not. Accordingly, there should be appropriate restrictions to restrict lateral movement from external facing system components to internal system components.

In this illustrative example, we have a web application that is accessible to public users. The application is exposed to the Internet on ports 80 and 443 (HTTP/HTTPS).

User website interactions actions trigger application logic in the Web App Server. When that logic requires reading from or writing to the database, the Web App Server communicates with the App Database on the user’s behalf. Because the Web App users have no need to directly communicate with the App Database, it has been placed into a separate logical security group with the backup server that is separated from the public Internet. Security groups can restrict inbound and outbound traffic to specified ports and protocols and specified sources and destinations, like a firewall. Note that “security group” is not a standard term and may vary from one cloud provider to the next.

The App Database Backup server is configured to only allow inbound connections on UDP port 137 from the internal IP of the App Database.

With the above protections in place, if a threat actor hacks the Web App Server, the only directly available target is the App Database, and the attacker would be limited to TCP port 1433. The threat actor would not have network connectivity to either the App Database Backup or the Internal Corporate Network. If the database software, however, were co-located on the application server, then compromising the application server would result in immediate access to the entire database and line-of-sight to the backup server.

Although this is a simple example, it illustrates that although IaaS can effectively separate an internal corporate network from a publicly accessible system, there may still be opportunities to implement logical separation within and among the assets in the IaaS platform.

Self-hosted, on-premises, services or systems

In our on-premises example the publicly accessible service is not physically separated from the corporate network. There needs to be some connection to the internal network for internal users and administrative activities.

In these situations, the best practice is to implement a demilitarized zone (DMZ). The CMMC Assessment Guides specifically reference DMZs as the key technique to achieve the objective in the practice.

This illustrative example depicts a common DMZ configuration. The Web App Server is sandwiched between two firewalls. The External Firewall only allows inbound connections from the public Internet on the ports required for the web, and those connections are directed to the Web App Server to process the inbound request from the user’s browser. Like the previous example, user interactions require the Web App Server to communicate with the database. When that occurs, the internal firewall is configured to only accept data from the Web App Server on port 1433 with the App Database’s IP address as the destination.

If the Web App Server were compromised, only the App Database would be visible, and only on port 1433. This greatly reduces the attack surface area and increases the difficulty of secondary attacks. If, however, the internal firewall was not in the above diagram, compromising the Web App Server would provide visibility into the entire corporate network, with which a threat actor could scan the network for additional vulnerabilities and potentially escalate privileges, steal data, install backdoors for future use, execute ransomware, and any other variety of cybercrime.

Evidence

Once implemented, we recommend organizations retain diagrams like the ones in this article that depict the desired separation for each publicly accessible system or component. For Level 1 organizations performing a Self-Assessment, we also recommend obtaining and retaining evidence (e.g., configurations, screenshots, etc.) that demonstrate the implementation conforms with the diagram.

Conclusion

It’s a bad day when you discover a breach in an external system. That alone is a nightmare scenario for an organization. However, a single server compromise is a far preferable outcome to an entire corporate network compromise.

SC.L1-3.13.5 – Public-Access System Separation – is intended to help prevent a breach event from going bad to worse. Its requirement to identify publicly accessible systems and separate them from internal systems, usually with some form of DMZ, can prevent an external system breach from turning into a full network breach. Additionally, it’s an uncontroversial long-standing network security best practice.

Not all CMMC requirements are created equally. If MA.L2-3.7.6 – which requires supervising maintenance staff, including custodial staff, plumbers, and others – went the way of the dodo, I wouldn’t expect the candlelight vigil to last long into the night.

In contrast, SC.L1-3.13.5 – Public-Access System Separation, ranks near the top in terms of actual security benefits and we recommend organizations implement this one with rigor.

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.