CSA CCM CEK-11
Key Purpose | Plerion

Cryptographic keys are powerful tools for securing data but must be managed carefully to be effective. Keys should be provisioned for specific purposes and protected throughout their lifecycle, from generation to distribution to retirement. With proper key management policies and procedures in place, organizations can ensure keys are used as intended while mitigating risks of unauthorized access or misuse.

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 matrix here. The matrix provides a comprehensive set of security controls mapped to various compliance frameworks to help organizations assess the security posture of cloud providers. For more information on cryptographic key management, check out the AWS Key Management Service Best Practices whitepaper.

Who should care?

This control is relevant for:

  • Security engineers responsible for designing key management systems
  • Developers using cryptographic keys to protect application data
  • Compliance officers ensuring adherence to data protection regulations
  • IT managers overseeing secure provisioning of cloud resources

What is the risk?

Improperly managed keys can lead to several adverse outcomes:

  • Unauthorized data access if keys are exposed
  • Inability to decrypt data if keys are lost
  • Regulatory fines for non-compliance with data protection standards
  • Reputational damage from security breaches

While key management cannot prevent all security incidents, it significantly reduces the blast radius when issues occur by limiting key usage and enabling quick key rotation.

What's the care factor?

For any organization handling sensitive data, key management should be a top priority. Crypto keys are high-value targets for attackers since they unlock access to large datasets. Investing effort upfront in proper key hygiene pays off by reducing the frequency and severity of key-related incidents. However, not every key needs Fort Knox level protection - tailor controls to the criticality of each key.

When is it relevant?

Any system using cryptography to protect data at rest or in transit can benefit from this control. This includes:

  • Encrypting databases and filesystems
  • Securing network traffic with SSL/TLS
  • Signing code to verify integrity and authenticity
  • Authenticating to APIs using cryptographic tokens

Some lower risk use cases like encrypting local config files may not need full lifecycle key management. Focus efforts on keys protecting valuable, regulated, or large scope datasets.

What are the trade-offs?

Proper key management comes with costs:

  • Additional engineering effort to design and implement key management systems
  • Overhead of security controls around key generation, distribution, rotation, etc.
  • Reduced agility since key provisioning can slow down deployment pipelines
  • Extra cognitive load on developers interfacing with crypto systems

In most cases, the security benefits outweigh these costs. Start with a minimal viable key management approach and add controls over time as usage expands.

How to Make It Happen?

  1. Define key management policies covering the full key lifecycle from generation to retirement. Document accepted use cases, algorithms, sizes, storage locations, access controls, and rotation schedules for each key type.
  2. Use a key management service (KMS) to handle crypto operations. Cloud KMS like AWS KMS and Google Cloud KMS provide HSMs, automatic key rotation, granular access controls, and audit logging.
  3. Generate keys centrally via KMS and distribute only to authorized systems. For asymmetric keys, distribute only public keys and keep private keys in KMS.
  4. When distributing symmetric keys, use envelope encryption. Generate a data encryption key (DEK) for each dataset and encrypt it with a key encryption key (KEK) from KMS. Store the encrypted DEK with the data.
  5. Protect keys at rest, in transit, and in use as much as possible:
    • At rest: Encrypt keys in storage with a master key. Enable encryption on databases and filesystems storing keys.
    • In transit: Use TLS encryption when transmitting keys over networks. Rotate keys if ever transmitted plaintext.
    • In use: Wipe keys from memory after use. Use HSMs for crypto operations to avoid keys existing in host memory.
  6. Rotate keys periodically and on any indication of compromise. Use automatic key rotation in your KMS where available. Have processes to update application code and data to use new keys.
  7. Monitor key usage via KMS audit logs. Alert on anomalous usage patterns. Periodically review permissions on keys to ensure least privilege.

What are some gotchas?

  • KMS services require granting the KMS permissions to manage keys on your behalf. Ensure KMS can only manage the keys it needs. Overly broad permissions can compromise all keys if KMS is breached.
  • Encrypting DEKs in application code with a KEK bakes the KEK into the code. Rotate KEKs by deploying new code. Consider using KMS APIs to retrieve DEKs on demand instead.
  • Losing keys is catastrophic. Back up keys securely and ensure restoration processes are tested. Have processes to rotate encryption if keys are lost.
  • Encryption code is hard to get right. Use well-vetted encryption libraries where available. Have encryption code audited for flaws.

What are the alternatives?

HSMs (Hardware Security Modules) are a popular alternative to pure software key management. HSMs are physical devices that perform crypto operations and never expose keys outside the device. Useful for high security environments but come with operational complexity and costs. See AWS CloudHSM or YubiKey HSM.

Explore Further

?

Blog

Learn cloud security with our research blog