Key deactivation is a critical process to ensure that cryptographic keys are properly taken out of active use when they expire or are no longer needed. This involves establishing procedures and technical controls to transition keys to a deactivated state where they can no longer be used for encryption, while still allowing decryption of previously encrypted data if necessary. Proper key deactivation is important for meeting compliance requirements and maintaining the security of encrypted data.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full CCM framework at https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4. The CCM provides a comprehensive set of security controls tailored for cloud computing environments. For more information on managing encryption keys in the cloud, check out the AWS Key Management Service Best Practices whitepaper.

Who should care?

This control is relevant for:

• Security engineers responsible for designing and implementing key management solutions
• Compliance officers who need to ensure cryptographic practices meet regulatory requirements
• Auditors assessing the effectiveness of key management practices
• Developers who use encryption in their applications

What is the risk?

Failing to properly deactivate expired or unneeded encryption keys can lead to several risks: - Unauthorized decryption of data: If old keys are not properly deactivated, an attacker who gains access to them could decrypt sensitive data.
- Compliance violations: Many security standards require proper key deactivation procedures. Failing to meet these could result in audit findings or fines. - Weakened security posture: Unused keys floating around expand the attack surface. Deactivation helps maintain a lean, focused set of active keys.

What's the care factor?

For organizations subject to strict data security compliance requirements (e.g. financial institutions, healthcare providers), implementing proper key deactivation procedures should be a high priority to avoid costly audit findings and maintain customer trust. Even for lower-regulated industries, it's still an important practice to uphold security hygiene and protect sensitive data. However, the urgency and sophistication of implementation can be tailored based on the risk profile.

When is it relevant?

Key deactivation is relevant whenever encryption is used to protect data, which is common in cloud environments. Some specific examples:

• Encrypting data at rest in cloud storage (e.g. AWS S3 server-side encryption)
• Encrypting data in transit over the network (e.g. TLS, VPN tunnels)
• Encrypting application secrets (e.g. API keys, database credentials)

It may be less relevant for use cases where keys are very short-lived (e.g. per-session encryption) or where secure key deletion is not possible (e.g. exported to a hardware security module).

What are the trade-offs?

Implementing key deactivation has some costs to consider:

• Added complexity in key management processes and tools
• Some performance overhead for archiving and managing deactivated key metadata
• Potential challenges in recovering data if keys are deactivated prematurely and backups are not available
• Time and effort to implement proper logging and access controls around deactivation

How to make it happen?

1. Establish a clear key lifecycle policy specifying when keys should be deactivated (e.g. expiration time, project completion).
2. Use a centralized key management system (e.g. AWS KMS, HashiCorp Vault) that supports key deactivation.
3. Generate keys with a defined expiration time after which they are automatically deactivated.
4. Implement processes to verify no keys are used past expiration (e.g. scan logs for old key IDs).
5. Ensure deactivated keys can still be used to decrypt previously encrypted data if needed for recovery. Test this!
6. Tightly control permissions for the key deactivation operation (e.g. separate from admins).
7. Log all activity around key state transitions in a tamper-evident way.
8. Schedule periodic audits to verify proper functioning of deactivation procedures.

What are some gotchas?

• Some compliance regimes (e.g. PCI-DSS) require a split-knowledge/dual-control process for key deactivation, enforcing segregation of duties.
• Key management tools often use different terminology (e.g. "disabling" vs "deactivating"). Be clear on meanings.
• If you manage a lot of keys, deactivation can get noisy. Invest in good alerting and reporting to surface issues.
• If you're using AWS KMS, understand the nuances of disabling vs deleting and scheduling key deletions. More info: https://docs.aws.amazon.com/kms/latest/developerguide/deleting-keys.html

Example KMS permissions for controlled deactivation:

What are the alternatives?

If you're not using a cloud key management service, you can also implement key deactivation in other ways:

• Key deletion: Securely delete expired keys from all systems and backups. More info: https://www.nist.gov/publications/nist-special-publication-800-88-revision-1-guidelines-media-sanitization
• Hardware security modules (HSMs): Many support time-based key deactivation and tamper-proof logging. Example: https://www.entrust.com/digital-security/hsm
• Application-layer key management: Implement tracking of key state and prevent use of inactive keys in your application logic.

Explore further

• CIS Controls v8 Control 3: Data Protection - Outlines best practices for protecting sensitive data including encryption key management
• OWASP Key Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
• NIST SP 800-57 Pt 1 Rev 5 - Recommendation for Key Management: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

?