Skip to main content
Greypike's CMMC Knowledge Base

Welcome to the CMMC Knowledgebase. Search for CMMC, resources, tools, sources, sites, and platforms using the search box below.
We add more to the database weekly, check back often.

If you cannot find an answer then contact us or click the chat button on the lower right..

< All Topics
Print

System and Communications Protection (SC)

System and Communications Protection (SC) is the largest control family in NIST SP 800-171 Revision 2, which forms the foundation of CMMC Level 2 requirements. The SC family focuses on protecting information as it moves through and between systems, implementing network security controls, and ensuring secure communications.

The SC control family contains 16 security requirements (3.13.1 through 3.13.16) that protect the confidentiality and integrity of Controlled Unclassified Information (CUI) during transmission, processing, and storage. These controls establish boundaries, encrypt communications, manage cryptographic keys, and prevent unauthorized information disclosure.

SC requirements address:

  • Boundary protection and network segmentation
  • Encryption of data in transit and at rest
  • Secure remote access and VPN configurations
  • Cryptographic key management
  • Session management and termination
  • Protection against unauthorized information flows

The SC family is critical for CMMC Level 2 compliance, with several requirements designated as critical controls that cannot be placed on a POA&M.

The 16 System and Communications Protection Requirements

3.13.1: Monitor, Control, and Protect Communications at External and Key Internal Boundaries

Requirement: Implement boundary protection to monitor, control, and protect communications at external boundaries and key internal boundaries.

Implementation: Enterprise firewalls at network perimeter, internal firewalls separating CUI networks, network IDS/IPS, web application firewalls, DMZ for publicly accessible systems, traffic logging at all boundaries.

Common Tools: Palo Alto, Fortinet, Cisco Firewall, pfSense, Suricata/Snort

Assessment Objective: Verify boundary protection devices are deployed, configured to policy, and protecting communications.


3.13.2: Employ Architectural Designs and Engineering Principles That Promote Information Security

Requirement: Use security architecture principles like defense-in-depth, least privilege, and secure design patterns.

Key Principles: Defense-in-depth (multiple security layers), least privilege (minimum necessary access), separation of duties, fail-safe defaults, complete mediation (every access checked).

Assessment Objective: Verify system architecture documentation demonstrates security principles are implemented.


3.13.3: Separate User Functionality from System Management Functionality

Requirement: Separate administrative/management functions from normal user functions.

Implementation: Separate administrative accounts, Privileged Access Workstations (PAWs), jump boxes for admin access, management VLANs separate from user VLANs, role-based access control (RBAC).

Assessment Objective: Verify administrators use separate privileged accounts and management functions are segregated.


3.13.4: Prevent Unauthorized Information Transfer via Shared System Resources

Requirement: Prevent data leakage through shared system resources like memory, storage, or network segments.

Implementation: Memory protection and process isolation, secure data deletion, virtual machine isolation, network segmentation, access controls on shared storage.

Assessment Objective: Verify technical controls prevent unauthorized access through shared resources.


3.13.5: Implement Subnetworks for Publicly Accessible Systems Separated from Internal Networks

Requirement: Place publicly accessible systems in a DMZ, physically or logically separated from internal networks.

Implementation: DMZ network segment between external and internal firewalls, public-facing systems in DMZ (web servers, mail relays), firewall rules restricting DMZ-to-internal communication.

Architecture: Internet → External Firewall → DMZ → Internal Firewall → Internal Network

Assessment Objective: Verify publicly accessible systems are in segregated network zones.


3.13.6: Deny Network Traffic by Default, Allow by Exception

Requirement: Configure firewalls to block all traffic by default and only allow explicitly approved traffic.

Implementation: Firewall ruleset ends with “deny all” rule, each allowed connection requires explicit permit rule with justification, regular review of firewall rules, whitelist approach.

Assessment Objective: Verify firewall configurations implement deny-all, permit-by-exception policy.


3.13.7: Prevent Split Tunneling for Remote Access

Requirement: Prevent remote devices from simultaneously connecting via VPN while having direct internet access.

Why It Matters: Split tunneling allows attackers to compromise remote devices and pivot into corporate network, or enables data exfiltration.

Implementation: VPN configured to force all traffic through tunnel, disable split tunneling in settings, endpoint compliance checks, MDM enforcing configuration.

Assessment Objective: Verify VPN configurations prevent split tunneling.


3.13.8: Implement Cryptographic Mechanisms to Protect CUI During Transmission

Requirement: Encrypt CUI when transmitted over networks unless protected by alternative physical safeguards.

Implementation: TLS/SSL for web (HTTPS), IPsec VPN, SSH/SFTP for file transfers, email encryption (TLS transport), encrypted messaging. Minimum: TLS 1.2 or higher.

Assessment Objective: Verify cryptographic protection for CUI transmission meets standards.


3.13.9: Terminate Network Connections After Session End or Inactivity

Requirement: Automatically disconnect network sessions after completion or inactivity period.

Implementation: VPN session timeouts (15-30 minutes), web application session timeouts, SSH/RDP timeouts, network idle timeouts.

Assessment Objective: Verify session timeout configurations are implemented.


3.13.10: Establish and Manage Cryptographic Keys

Requirement: Implement key management processes for generating, distributing, storing, rotating, and destroying cryptographic keys.

Implementation: Key management policy, certificate management for TLS/SSL, Azure Key Vault/AWS KMS or HSMs, automated certificate renewal.

Assessment Objective: Verify key management procedures per NIST SP 800-57.


3.13.11: Employ FIPS-Validated Cryptography to Protect CUI Confidentiality

Requirement: Use Federal Information Processing Standards (FIPS) 140-2 validated cryptographic modules when encrypting CUI.

What This Means:

Cryptographic algorithms and implementations must be validated by the Cryptographic Module Validation Program (CMVP). You cannot use homegrown or unvalidated encryption.

FIPS 140-2 Requirements:

  • Cryptographic modules must have FIPS 140-2 validation certificate
  • Approved algorithms: AES, RSA, SHA-2, ECDSA
  • Minimum key lengths: AES-128, RSA-2048, SHA-256

Where Applied:

  • Encryption of CUI at rest
  • Encryption of CUI in transit
  • VPN implementations
  • Full disk encryption
  • Email encryption

Implementation:

  • Windows BitLocker (FIPS mode enabled)
  • Microsoft 365 GCC High (FIPS 140-2 validated)
  • Cisco VPN with FIPS mode
  • Validated cryptographic libraries

Assessment Objective: Verify FIPS 140-2 validated cryptography is used for all CUI protection and evidence of validation certificates.

Critical Note: This is a critical control that CANNOT be placed on a POA&M for Conditional Status—except if encryption is implemented but not yet FIPS-validated, with a plan to achieve validation.


3.13.12: Prohibit Remote Activation of Collaborative Computing Devices

Requirement: Prevent remote activation of cameras, microphones, or speakers, and provide indication when devices are in use.

Implementation: Physical camera covers, disable when not in use, require explicit user activation, LED indicators showing active status, prohibit background activation.

Assessment Objective: Verify cameras/microphones cannot be remotely activated and indicators show when active.


3.13.13: Control and Monitor the Use of Mobile Code

Requirement: Implement controls for mobile code execution (JavaScript, Java applets, Flash, ActiveX, PDFs with scripts).

Implementation: Disable or restrict mobile code technologies, configure browsers with restricted execution, application whitelisting, web filtering blocking malicious sources.

Assessment Objective: Verify mobile code restrictions are configured.


3.13.14: Control and Monitor the Use of VoIP Technologies

Requirement: Implement controls for Voice over IP communications to prevent eavesdropping and unauthorized access.

Implementation: VoIP encryption (SRTP, TLS), VoIP on separate VLAN, strong authentication, monitor for anomalies, regular firmware updates.

Assessment Objective: Verify VoIP security controls are implemented.


3.13.15: Protect the Authenticity of Communications Sessions

Requirement: Ensure communications sessions cannot be hijacked, spoofed, or tampered with.

Implementation: TLS/SSL with certificate validation, IPsec with authentication, SSH with key-based auth, Kerberos authentication, session tokens with anti-replay protection, MFA for sensitive sessions.

Assessment Objective: Verify session authentication mechanisms protect against hijacking and spoofing.


3.13.16: Protect the Confidentiality of CUI at Rest

Requirement: Encrypt CUI when stored on devices (laptops, servers, removable media, backups) or implement equivalent physical security.

What This Means:

CUI must be encrypted when stored on any media. If devices are lost or stolen, encryption prevents unauthorized access to CUI.

Implementation:

  • Full disk encryption (FDE): BitLocker, FileVault, LUKS
  • File-level encryption: Windows EFS, encrypted containers
  • Database encryption: Transparent Data Encryption (TDE)
  • Backup encryption: Encrypted backup solutions
  • Removable media encryption: Encrypted USB drives

Alternative: Physical security controls for servers in locked, access-controlled facilities may substitute for encryption on those specific systems—but encryption is strongly preferred.

FIPS Requirement: Encryption must use FIPS 140-2 validated cryptography (see 3.13.11).

Assessment Objective: Verify CUI at rest is encrypted using FIPS-validated cryptography or equivalent physical safeguards are documented.

Critical Note: This is a critical control that CANNOT be placed on a POA&M for Conditional Status—except if encryption is implemented but not yet FIPS-validated.


Implementation Considerations

Integrated Approach: SC controls work with Access Control (AC), Identification and Authentication (IA), and Audit and Accountability (AU) to create comprehensive security architecture.

Technology Requirements:

  • Enterprise firewalls with IDS/IPS capabilities
  • VPN solutions with strong encryption
  • Full disk encryption tools (BitLocker, FileVault)
  • Certificate management systems
  • Network segmentation infrastructure
  • FIPS 140-2 validated cryptographic modules

Documentation Requirements:

  • Network architecture diagrams showing boundaries and segmentation
  • Firewall ruleset documentation with justifications
  • Cryptographic standards policy
  • Key management procedures
  • VPN configuration standards
  • System Security Plan (SSP) documenting all SC implementations

Common Challenges:

  • FIPS validation complexity: Ensuring all cryptographic implementations are FIPS-validated
  • Legacy systems: Older systems may not support modern encryption standards
  • VPN split tunneling: Users often request split tunneling for performance
  • Cost of encryption: Enterprise encryption solutions can be expensive
  • Key management: Proper key lifecycle management requires dedicated processes

Assessment Tips:

  • 3.13.1: Network diagrams, firewall configs, boundary protection documentation
  • 3.13.6: Firewall rulesets showing deny-all default policy
  • 3.13.7: VPN client configurations preventing split tunneling
  • 3.13.8: Evidence of encryption in transit (TLS, VPN, SSH)
  • 3.13.11: FIPS 140-2 validation certificates for cryptographic modules
  • 3.13.16: Full disk encryption enabled, encryption key management documented

Key Takeaways

  1. SC is the largest control family with 16 requirements focused on network and communications security
  2. Encryption is fundamental: Both data in transit (3.13.8) and at rest (3.13.16) must be encrypted
  3. FIPS 140-2 validation required: Cryptography protecting CUI must use validated modules (3.13.11)
  4. Boundary protection essential: Monitor, control, protect at all network boundaries (3.13.1)
  5. Deny by default: Network traffic blocked unless explicitly allowed (3.13.6)
  6. No split tunneling: Remote access must route all traffic through VPN (3.13.7)
  7. Critical controls: 3.13.1, 3.13.8, 3.13.11, and 3.13.16 cannot be on POA&M (with limited encryption exception)
  8. Network segmentation required: Separate CUI networks from other networks (3.13.1, 3.13.5)
  9. Session management: Terminate inactive sessions automatically (3.13.9)
  10. Key management: Establish formal processes for cryptographic key lifecycle (3.13.10)

System and Communications Protection controls form the technical foundation of network security, ensuring CUI is protected through encryption, boundary controls, and secure architecture throughout its lifecycle.


Sources:

  • NIST SP 800-171 Revision 2 – System and Communications Protection (3.13)
  • NIST SP 800-171A – Assessment Procedures
  • NIST SP 800-52 – Guidelines for TLS Implementations
  • NIST SP 800-57 – Cryptographic Key Management
  • 32 CFR Part 170.21 – CMMC POA&M Requirements
Table of Contents