1Overview
SC.L2-3.13.5 requires that publicly accessible systems be walled off from the internal network. It requires that subnetworks for publicly accessible system components be physically or logically separated from internal networks, so that the systems the public can reach cannot serve as a bridge into the internal environment. It is a five-point requirement that cannot be deferred on a plan of action.
Publicly accessible components, web servers and other internet-facing systems, are exposed to attack by design, and if they sit on the internal network, a compromise of one reaches everything else. This control requires that such components be placed in subnetworks physically or logically separated from internal networks, the demilitarized zone pattern, so that a breach of a public-facing system is contained away from the internal environment. The two assessment objectives are identifying the publicly accessible components and separating their subnetworks from internal networks.
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
The requirement is to place publicly accessible components in subnetworks separated, physically or logically, from internal networks. The assessment objectives add identifying those components first. Separation may be physical, on distinct network segments, or logical, through segmentation and firewall rules, so long as the public-facing subnetwork cannot freely reach the internal network. This contains the exposure that public accessibility inevitably creates. Where there are no publicly accessible components in scope, this requirement may be assessed as not applicable.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.13.5 into two objectives: identify publicly accessible components and separate their subnetworks.
Publicly accessible system components are identified. The internet-facing systems are known.
Subnetworks for publicly accessible components are physically or logically separated from internal networks. Public-facing systems are walled off.
The two objectives are identification and separation. The common failure is at objective [b], where a public-facing system shares the internal network, so its compromise reaches internal resources. The assessor looks for identified public components in separated subnetworks.
3Failure Patterns
The failures are about public-facing systems that bridge to the interior.
Public server on the internal network
An internet-facing system on the internal network lets a compromise reach internal resources directly. Separating it into its own subnetwork contains the exposure.
Separation without restriction
Placing public systems in a subnetwork that can still freely reach the internal network is separation in name only. The separation has to restrict access to the internal network.
Components not identified
Without identifying which components are publicly accessible, the separation cannot be applied to the right systems. Identification comes first.
4Ownership
This is a network and IT-owned control.
| Role | Responsibility for this control |
|---|---|
| Network and IT | Identifies public-facing components and separates their subnetworks. Owns the segmentation evidence. |
| System architects | Design the separated network architecture. |
| Security or compliance lead | Confirms public subnetworks are separated from internal networks. |
5Tooling
The control is delivered by network segmentation separating public and internal systems.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Component inventory | Identification of publicly accessible systems. |
| [b] | DMZ, VLANs, firewall segmentation | Separation of public subnetworks from internal networks. |
The caveat is that the separation has to restrict access to the internal network, not merely place systems in a different segment. A subnetwork that can still reach internal resources does not contain the exposure. The assessor examines identification and effective separation, so both objectives have to hold.
6Evidence
The satisfied version of 3.13.5 shows public systems in separated subnetworks.
| Evidence | What it demonstrates |
|---|---|
| Network diagram and component inventory | Objective [a]. Public-facing components identified. |
| Segmentation and firewall configuration | Objective [b]. Public subnetworks separated from internal networks. |
The evidence should show publicly accessible components identified and placed in subnetworks separated from internal networks. The network diagram together with the segmentation configuration is the clearest demonstration, and because this control cannot sit on a plan of action, the separation has to be real at the time of assessment.
A public system on the internal network is a bridge inward
Internet-facing systems are exposed by design, so leaving them on the internal network turns expected exposure into a path inside, and this five-point control asks that their subnetworks be separated. Building that separation is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.13.5. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.13.5[a] and 3.13.5[b]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing SC.L2-3.13.5 among the five-point derived security requirements, and noting it may be assessed as not applicable where no publicly accessible components are in scope. ecfr.gov