Protect the authenticity of communications sessions
📖 What This Means
This control ensures that communication sessions (like remote logins or data transfers) are genuine and not hijacked by attackers. Think of it like verifying a caller's ID before sharing sensitive information. For example, when your IT team logs into a server remotely, the system must confirm it's really them and not an imposter. Another example: when two systems exchange data, they use digital 'handshakes' (like TLS certificates) to prove their identities. Without this, attackers could eavesdrop or manipulate communications.
🎯 Why It Matters
Unauthenticated sessions allow man-in-the-middle attacks, where hackers intercept or alter communications. In 2020, a defense contractor lost $6M when attackers impersonated a vendor in email exchanges. The DoD requires this control because compromised sessions can leak classified data or enable ransomware deployment. A single breached session could cost $250k+ in incident response and regulatory fines.
✅ How to Implement
- 1. Enable AWS/Azure/GCP session authentication (e.g., AWS Session Manager with IAM roles).
- 2. Enforce TLS 1.2+ for all APIs (e.g., Azure API Management policies).
- 3. Use cloud-native certificate authorities (e.g., AWS ACM, Azure Key Vault).
- 4. Configure MFA for management consoles (e.g., Google Cloud Identity).
- 5. Log session authentications (e.g., AWS CloudTrail + S3 bucket).
📋 Evidence Examples
TLS certificate inventory
Session authentication logs
Firewall rules for TLS enforcement
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For SC.L2-3.13.15 ("Protect the authenticity of communications sessions"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe your network security architecture, including segmentation, encryption standards, VPN configuration, session management, key management, and monitoring capabilities. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"SC.L2-3.13.15 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to protect the authenticity of communications sessions. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"SC.L2-3.13.15 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to protect the authenticity of communications sessions. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"SC.L2-3.13.15 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Document network architecture with CUI boundary clearly marked
- • Identify all encryption mechanisms (at rest and in transit)
- • Specify network monitoring and IDS/IPS deployment
- • Ensure this control covers all systems within your defined CUI boundary where protect the authenticity of communications sessions applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 System and Communications Protection Policy
- 📄 Network architecture diagram
- 📄 Firewall rule documentation
- 📄 Encryption configuration documentation
- 📄 Evidence artifacts specific to SC.L2-3.13.15
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will review network diagrams for proper segmentation, test encryption settings, verify VPN split tunneling is disabled, and check FIPS 140-2 validation of cryptographic modules.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Do all remote access sessions require certificate- or MFA-based authentication?
Question 2: Are TLS certificates validated for all external communications?
Question 3: Are session authentication failures logged and reviewed?
⚠️ Common Mistakes (What Auditors Flag)
1. Self-signed certificates in production
2. Missing HSTS headers on web apps
3. Logs only stored locally
📚 Parent Policy
This practice is governed by the System and Communications Protection Policy