CSA CCM LOG-11
Transaction/Activity Logging | Plerion

Keeping tabs on the lifecycle of cryptographic keys is crucial for maintaining a secure environment. By logging and monitoring key events like generation, usage, storage, and deletion, organizations can ensure keys are being used appropriately. This also enables auditing and reporting to verify compliance with security policies.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full matrix here.

The Cloud Security Alliance develops the CCM to provide fundamental security principles to guide cloud vendors and assist prospective cloud customers in assessing overall security risk. AWS also provides guidance on managing keys that aligns with this control.

Who should care?

A few roles that should pay particular attention to this control:

  • Security engineers responsible for designing and implementing key management systems
  • Compliance officers who need to ensure crypto keys are being used in accordance with policies and regulations
  • Auditors looking to verify that key lifecycle events are logged and those logs are reviewed
  • Developers integrating encryption into applications who need to use keys securely

What is the risk?

Failing to log and monitor key lifecycle events can lead to several adverse outcomes:

  • Unauthorized use or theft of keys going undetected, enabling an attacker to decrypt sensitive data
  • Inability to detect or prove compliance violations related to key usage
  • Failure to properly rotate or revoke old keys resulting in encryption weaknesses over time

While logging itself can't prevent misuse, it is critical for prompt detection and response. The logs provide valuable forensic evidence to understand the scope of an incident.

What's the care factor?

For organizations dealing with sensitive data (financial, healthcare, PII, etc.), the care factor here should be high. Crypto keys are the linchpin to keeping that data confidential. Any gaps in visibility or oversight of the key lifecycle is a serious liability.

Even for lower sensitivity systems, the care factor shouldn't be zero. At a minimum, organizations should understand where keys are used and have basic monitoring in place. The effort spent should be proportional to the value of the assets being protected.

When is it relevant?

This control is relevant anytime encryption keys are being used, especially in cloud environments where keys may be managed by the CSP. Some specific examples:

  • Anytime a CSP's key management service (KMS) is being used
  • When keys are exported from the KMS for use in applications
  • For customer-managed keys used with a cloud HSM or external key manager

It may be less relevant for uses of encryption where the keys are ephemeral and not explicitly managed, such as TLS sessions with perfect forward secrecy.

What are the trade-offs?

Logging and monitoring key events does come with some costs and considerations:

  • Log storage costs can be significant given the sensitivity of the data
  • Logging can create some performance overhead, especially for high-volume key operations
  • Access to key management logs must be tightly restricted to avoid inadvertent exposure
  • Over-logging can make it harder to identify meaningful events among the noise

Organizations have to strike the right balance of logging enough to maintain security without impacting the business. Careful planning of what to log and setting appropriate log retention periods is important.

How to make it happen?

The exact implementation will depend on what key management tools are being used. At a high level:

  1. Identify all key management components and processes in the environment
  2. Determine which key lifecycle events need to be logged for each component based on risk
  3. Configure logging for each event type, ensuring logs include important metadata (timestamps, identities, key IDs, etc.)
  4. Establish log collection and aggregation to a centralized SIEM
  5. Set up automated parsing and alerting on key events
  6. Restrict access to key management logs and audit that access
  7. Create an audit process to regularly review key lifecycle events
  8. Document all logging procedures as part of the key management policy

For AWS KMS specifically, you'll want to enable CloudTrail logging which will capture all KMS API events. Ensure the CloudTrail is configured to send events to CloudWatch Logs for easier reviewing and alerting.

What are some gotchas?

A few things to watch out for when implementing logging:

  • Ensure you have the necessary permissions configured to actually collect the key management logs. For AWS KMS this means the kms:DescribeKey and [kms:ListAliases] (https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html) permissions.
  • Be cautious about logging actual key material or other secrets. Logs should refer to keys by an ID or handle rather than contain the keys themselves.
  • Have an incident response plan for how to handle logs indicating anomalous key usage. You may need to quickly revoke or rotate keys.
  • Remember that deleting a key in many systems is destructive and makes previously encrypted data unrecoverable. Have checks in place before deleting.

What are the alternatives?

Realistically, there aren't many alternatives to logging key lifecycle events if you are using a key management system. It's a fundamental security control.

One could argue that logging is less critical if you have strong preventative controls and access restrictions around the key management system itself. But this is more security theater than sound practice. Logging provides that critical detection and audit trail.

For some applications, an alternative is to use non-persistent keys that are derived at runtime rather than centrally managed. This shifts the logging burden to the application. But it comes with significant complexity and isn't appropriate for most use cases.

Explore further

?

Blog

Learn cloud security with our research blog