AWS KMS Key Compromise: Response Guide

TL;DR

An AWS KMS Customer Master Key (CMK) has been compromised. This guide outlines steps to contain the damage, investigate the incident, and recover securely.

1. Immediate Containment

1. Disable the Compromised Key: The fastest way to stop further misuse is to disable the key. This prevents encryption/decryption operations using it.

   aws kms disable-key --key-id 

2. Revoke IAM Permissions: Immediately revoke all IAM policies granting access to the compromised CMK. This includes users, groups, and roles.
   • Identify all policies allowing kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, kms:DescribeKey permissions on the key.
   • Remove or modify these policies to restrict access. Consider using least privilege principles.
3. Rotate the Key (if possible): If the key is not actively used for critical operations, rotate it immediately.

   aws kms rotate-key --key-id 

   Rotation creates a new version of the key. Old versions remain available (see step 6).

4. Monitor CloudTrail: Increase monitoring frequency on CloudTrail logs for any activity related to KMS and the affected resources.

2. Incident Investigation

1. CloudTrail Log Analysis: Thoroughly review CloudTrail logs leading up to the compromise. Focus on:
   • Identify the source IP address(es) used for unauthorized access.
   • Determine which AWS accounts and resources were accessed using the compromised key.
   • Look for any unusual API calls or patterns of activity.
   • Check for evidence of data exfiltration.
2. Identify Affected Data: Determine what data was encrypted with the compromised CMK.
   • Review application logs and configurations to identify S3 buckets, EBS volumes, databases, or other services using the key.
   • Use AWS Config rules to help identify resources using specific KMS keys.
3. Root Cause Analysis: Investigate how the compromise occurred.
   • Was there a vulnerability in your application code?
   • Were IAM credentials compromised (e.g., leaked API keys, stolen access tokens)?
   • Was there a misconfiguration of KMS permissions or key policies?

3. Data Recovery & Remediation

1. Re-encrypt Affected Data: Re-encrypt all affected data using a new CMK.
   • This is the most secure way to protect your data.
   • Prioritize re-encryption based on data sensitivity and criticality.
2. Create New Key: Create a new KMS key for future encryption operations.

   aws kms create-key --policy '{"Version":"2012-10-17","Statement":[{"Sid":"AllowEncryptionDecryption","Effect":"Allow","Principal":{"AWS":"arn:aws:iam:::root"},"Action":["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey"]}]}'

3. Update Applications & Configurations: Update all applications and configurations to use the new CMK.
   • Test thoroughly before deploying changes to production.

4. Long-Term Security Improvements

1. Implement Key Rotation: Enable automatic key rotation for all KMS keys.
2. Least Privilege IAM Policies: Enforce least privilege principles when granting access to KMS keys.
3. Multi-Factor Authentication (MFA): Require MFA for all IAM users with access to KMS keys.
4. Regular Security Audits: Conduct regular security audits of your AWS environment, including KMS configurations and permissions.
5. Monitor for Anomalous Activity: Implement robust monitoring and alerting for unusual activity related to KMS and the affected resources. Use services like CloudWatch Alarms and Amazon GuardDuty.

5. Legal & Compliance Considerations

Depending on the type of data compromised, you may have legal and compliance obligations (e.g., GDPR, HIPAA). Consult with your legal counsel to determine appropriate actions.

6. Dealing with Old Key Versions

When a key is rotated, old versions are not automatically deleted. These can still be used if permissions allow. Consider disabling or deleting older key versions once you’ve confirmed all data has been re-encrypted using the new key.

aws kms schedule-key-deletion --key-id  --pending-window-in-days 7

This schedules deletion after a 7 day waiting period.