CMMC NUGGET #12

Securing the Network and Monitoring

SC.L2-3.13.1: Monitor, control, and protect communications at external boundaries and key internal boundaries

This control is the architectural underpinning of everything else in this nugget. Your network boundary protection implementation must include:

• Perimeter firewalls controlling inbound and outbound traffic at the CUI environment boundary
• Defined and documented rules governing what traffic is permitted across the boundary
• Key internal boundaries protected where the CUI enclave meets other network segments
• Regular review of boundary protection rules to remove obsolete entries and verify alignment with current policy

Assessor Reality Check: SC.L2-3.13.1 is frequently treated as a given. Organizations assume their firewall satisfies it and move on. Assessors evaluate this control by requesting your firewall rule sets and comparing them against your network diagrams and SSP boundary description. The most common findings are: outbound rules that permit unrestricted traffic from CUI systems to the internet with no filtering or monitoring; internal boundary controls between the CUI enclave and other network segments that exist in the network diagram but are not technically enforced; and rule sets that have accumulated over years with undocumented, overly permissive entries that no one can justify. Having a firewall is not evidence of boundary protection. Having a documented, current, justified rule set that matches your SSP boundary description is.

Remote access is one of the highest-risk areas in any CUI environment and one of the most heavily scrutinized during assessment. The following five controls work as a system and must all be implemented together.

AC.L2-3.1.12: Monitor and control remote access sessions

Organizations must actively monitor and control all remote access sessions, not simply permit them. This means:

• Logging all remote access attempts, successful connections, session durations, and terminations
• Monitoring active sessions for anomalous behavior. Unusual access times, unusual data volumes, access to systems outside the user’s normal scope, etc.
• Technical access controls ensuring remote users can only reach resources they are authorized to access
• A defined process for investigating and responding to suspicious remote access activity

What assessors look for beyond the basics: Assessors will ask to see remote access logs and verify that they are being reviewed. A VPN log that has never been opened is not evidence of monitoring. Document your log review process and retain records of reviews conducted.

Implementation note: Remote access monitoring is resource intensive. Automated tools that generate alerts for defined anomalies (unusual login times, multiple concurrent sessions, access from unexpected geographies) are the practical solution for most organizations. Build alert review into your documented continuous monitoring process from Nugget #5.

AC.L2-3.1.13: Employ cryptographic mechanisms to protect the confidentiality of remote access sessions

All data transmitted during remote access sessions must be encrypted to prevent interception. Key implementation requirements:

• TLS 1.2 minimum is required for web-based remote access. TLS 1.3 is preferred. SSL, TLS 1.0, and TLS 1.1 are deprecated and their use is a direct finding
• VPN implementations must use strong encryption. IKEv2 with AES-256 is the current standard for IPsec VPNs
• All encryption implementations must use FIPS-validated cryptographic modules, not just strong algorithms. See SC.L2-3.13.11 below for the FIPS validation requirement that governs all encryption in your CUI environment
• Remote desktop and other session-based remote access tools must have encryption enabled and verified

AC.L2-3.1.14: Route remote access through managed access control points

Remote access must not bypass your security perimeter. All remote connections must traverse a managed access control point (VPN gateway, secure remote access server, or equivalent) where authentication and authorization are enforced before access to the internal network is granted.

Key requirements:

• No direct remote connections to internal systems that bypass the managed gateway
• The access control point must enforce authentication before granting any internal network access
• Split tunneling must be disabled (see SC.L2-3.13.7 below) to ensure all traffic routes through the managed point
• The access control point configuration must be documented in your SSP and network diagrams

AC.L2-3.1.15: Authorize remote execution of privileged commands and remote access to security-relevant information

Privileged commands and access to security-relevant information executed during a remote access session require explicit authorization beyond standard remote access permissions. This control addresses a specific risk: a remote user with general access to the network should not automatically be able to execute administrative or security-relevant functions without a separate, documented authorization layer.

Key implementation requirements:

• A defined list of which commands and functions are considered privileged or security-relevant for remote execution purposes
• A separate authorization mechanism for remote privileged command execution, distinct from general remote network access
• Logging of all privileged commands executed during remote sessions, tied to the specific user and session
• This control works in conjunction with AC.L2-3.1.7, which requires logging the execution of privileged functions generally. The remote context adds an additional authorization layer specific to sessions originating outside the network

Assessor Reality Check: Organizations frequently grant remote users the same privileged access they would have locally without considering whether that access should be separately authorized and logged for the remote context specifically. Assessors will ask how your organization distinguishes and controls privileged command execution when it occurs over a remote connection versus a local one.

SC.L2-3.13.7: Prevent remote devices from split tunneling

Split tunneling occurs when a remotely connected device simultaneously maintains the VPN connection to your CUI environment and a direct connection to external networks. This essentially creates a bridge between your protected environment and the internet through the remote device.

Split tunneling must be technically disabled on all VPN configurations. This is not a policy-only control. It must be enforced in the VPN client and server configuration. Assessors will test this by reviewing VPN configuration settings, not just by reading your policy.

Assessor Reality Check: Split tunneling is one of the most commonly misconfigured VPN settings. Many VPN implementations enable split tunneling by default for performance reasons. Verify your configuration explicitly disables it and document the verification.

AC.L2-3.1.16: Authorize wireless access prior to allowing connections

Every wireless connection to your network must be explicitly authorized before it is permitted. This requires:

• A documented wireless access authorization process defining who can connect, with what devices, and under what conditions
• Technical enforcement through WPA3 or WPA2-Enterprise with 802.1X authentication. Connecting to an open network does not constitute authorization
• A maintained list of authorized wireless devices and users
• Guest wireless networks completely isolated from the CUI environment with no pathway between them

AC.L2-3.1.17: Protect wireless access using authentication and encryption

Wireless networks carrying or adjacent to CUI traffic must be protected with both strong authentication and encryption:

• WPA3 is the current preferred standard. WPA2-Enterprise with AES encryption is acceptable. WEP and WPA are deprecated and constitute a direct finding
• Enterprise wireless (802.1X with RADIUS authentication) is the recommended implementation for CUI environments as it provides per-user authentication rather than shared credentials
• Wireless encryption keys must be managed and rotated according to a documented schedule

AC.L2-3.1.18: Control the connection of mobile devices

Your organization must have documented policies and technical controls governing which mobile devices can connect to your network and what access they receive:

• A Mobile Device Management (MDM) solution is the standard implementation mechanism for enforcing mobile device policies at scale
• Policies must address both organization-issued and personal devices (BYOD). If personal devices are permitted to access CUI systems or data, they must meet the same security requirements as organization-issued devices
• Unauthorized devices must be technically blocked from connecting, not just prohibited by policy
• The mobile device policy must be documented in your SSP

AC.L2-3.1.19: Encrypt CUI on mobile devices and mobile computing platforms

CUI stored on any mobile device (laptops, tablets, smartphones, or other portable computing platforms) must be encrypted at rest. Key implementation requirements:

• Full-device encryption must be enabled on all mobile devices that store or access CUI
• MDM solutions can enforce and verify encryption status across managed device fleets
• Organization-issued devices should be encrypted at provisioning, not left to user configuration
• Personal devices permitted to access CUI must have encryption verified before access is granted

Implementation challenge: Device diversity makes consistent encryption enforcement difficult. Standardize on approved devices and platforms where possible, and use MDM to enforce and audit encryption status rather than relying on user self-reporting.

IA.L2-3.5.3: Use MFA for local and network access to privileged accounts and for network access to non-privileged accounts

Covered in depth in Nugget #10, but critically relevant here in the network security context. MFA is the single most impactful authentication control in the CMMC framework. In the network security context specifically:

• MFA must be enforced at the VPN gateway for all remote access connections
• MFA must be enforced for all web-based remote access portals
• MFA at the SSO layer does not automatically satisfy this control unless verified to cover all required access scenarios
• MFA enforcement must be documented in your SSP including which systems, which account types, and how exceptions are managed

MA.L2-3.7.5: Require MFA for nonlocal maintenance sessions and terminate when complete

When maintenance personnel establish remote connections to perform system maintenance (vendor support sessions, MSP remote access, administrator remote maintenance) MFA must be required to establish the connection. Additionally:

• Nonlocal maintenance sessions must be terminated immediately when maintenance is complete. Sessions must not be left open for convenience
• All nonlocal maintenance sessions must be logged with the maintenance activity, who performed it, when it started, and when it was terminated
• Where possible, maintenance sessions should be monitored in real time or recorded
• Third-party maintenance personnel must meet the same MFA requirement as internal staff. Vendor exemptions are not permitted

Assessor Reality Check: This is one of the most commonly failed MA controls. Organizations that allow MSPs or vendors to connect via remote access tools without MFA enforcement fail this control regardless of what their policy states.

MP.L2-3.8.6: Implement cryptographic mechanisms to protect CUI on digital media during transport

CUI stored on digital media such as USB drives, external hard drives, and optical media, must be encrypted when transported outside controlled areas. Physical safeguards (locked containers, secure courier) may serve as an alternative protection measure, but the preferred implementation is encryption because it protects against physical safeguard failures.

Implementation requirements:

• All portable media containing CUI must be encrypted using FIPS-validated cryptographic modules
• Encryption must be applied before the media leaves the controlled environment
• A documented process must exist for approving, logging, and tracking media transport

SC.L2-3.13.11: Employ FIPS-validated cryptography to protect the confidentiality of CUI

This is the overarching encryption requirement that governs every other encryption control in this nugget. The distinction that trips up most organizations:

FIPS-validated is not the same as FIPS-compliant.

• FIPS-compliant means an implementation uses an algorithm defined in a FIPS standard (such as AES-256 defined in FIPS 197)
• FIPS-validated means the specific cryptographic module implementing that algorithm has been tested and validated under FIPS 140-2 or FIPS 140-3 by an accredited laboratory and appears on the NIST Cryptographic Module Validation Program (CMVP) list

An organization can run AES-256 encryption and fail SC.L2-3.13.11 if the software module implementing AES is not on the CMVP list. Before your assessment, verify every encryption implementation in your environment against the CMVP database at:

Common implementations that are typically FIPS-validated include Windows CNG (Cryptography Next Generation), certain versions of OpenSSL with FIPS mode enabled, and hardware security modules (HSMs) from major vendors. Verify your specific product version against the CMVP list and note that validation is version-specific.

SC.L2-3.13.15: Protect the authenticity of communications sessions

This control requires that communications sessions cannot be hijacked, spoofed, or tampered with. Practical implementation includes:

• TLS mutual authentication for web-based communications where both parties verify each other’s identity
• Session token integrity controls preventing session hijacking through token theft or replay
• Anti-replay mechanisms for sensitive communications
• Certificate validation enforced on all TLS connections. Ignoring certificate errors or using self-signed certificates without proper trust chain management is a finding

The controls in this nugget span five families: SC, AC, IA, MA, and MP. Each must be documented under its respective section in your SSP. Network diagrams showing your boundary protection architecture, VPN configuration documentation, MDM policy exports, and encryption implementation records are the primary evidence artifacts assessors request in this domain.

A common documentation failure in this domain: organizations describe their network security controls in narrative form in the SSP but cannot produce the underlying configuration artifacts. Items such as firewall rule sets, VPN configurations, and MDM policy definitions to confirm the implementation matches the description.

For assistance securing your network boundary, configuring remote access controls, or verifying FIPS validation status of your encryption implementations, contact DTC’s C3PAO team.