Establish and manage cryptographic keys for cryptography
📖 What This Means
This practice means that your organization needs to create and maintain cryptographic keys used for encrypting and decrypting data securely. Cryptographic keys are like digital locks and keys that protect sensitive information from unauthorized access. Proper management ensures that these keys are generated securely, stored safely, and rotated or replaced when necessary. For example, if you encrypt customer data stored in your database, you need to ensure the keys used for encryption are not easily guessable and are stored separately from the encrypted data. Another example is managing SSL/TLS certificates for secure web communications, ensuring they are valid and renewed on time.
🎯 Why It Matters
Poor cryptographic key management can lead to data breaches, unauthorized access, and compliance failures. For instance, if cryptographic keys are weak or stored improperly, attackers can decrypt sensitive information, exposing customer data or intellectual property. A real-world example is the 2017 Equifax breach, where attackers exploited weak encryption practices to access sensitive data of 147 million people. From a DoD/CMMC perspective, this control ensures that Controlled Unclassified Information (CUI) remains protected from adversaries. The potential impact includes financial losses, reputational damage, and loss of contracts due to non-compliance.
✅ How to Implement
- Use cloud-native key management services (KMS) like AWS KMS, Azure Key Vault, or Google Cloud KMS.
- Configure key policies to restrict access to authorized users and applications only.
- Enable automatic key rotation (e.g., AWS KMS supports automatic annual rotation).
- Use hardware security modules (HSMs) for added security where available (e.g., AWS CloudHSM).
- Log all key usage and access attempts for audit purposes.
- Ensure keys are stored separately from encrypted data.
- Test key recovery processes to ensure availability during outages.
📋 Evidence Examples
Key Management Policy
Key Inventory
Access Logs
Key Rotation Schedule
Audit Report
📝 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.10 ("Establish and manage cryptographic keys for cryptography"), 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.10 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to establish and manage cryptographic keys for cryptography. 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.10 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to establish and manage cryptographic keys for cryptography. 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.10 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 establish and manage cryptographic keys for cryptography 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.10
- 📄 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 you have a documented key management policy?
Question 2: Are cryptographic keys stored securely using FIPS 140-2 validated modules?
Question 3: Is there a key rotation policy in place?
Question 4: Are key access logs maintained and reviewed regularly?
Question 5: Have you tested key recovery processes?
⚠️ Common Mistakes (What Auditors Flag)
1. Storing keys with encrypted data.
2. Using weak cryptographic algorithms.
3. Not rotating keys regularly.
4. Failing to audit key usage.
5. Insufficient documentation.
📚 Parent Policy
This practice is governed by the System and Communications Protection Policy