Incident Response - AWS Key Management Service Best Practices

Incident Response

The Incident Response capability focuses on your organization’s capability to remediate incidents that may involve AWS KMS.

Security Automation of AWS KMS

During your monitoring of your CMKs, if a specific action is detected, an AWS Lambda function could be configured to disable the CMK or perform any other incident response actions as dictated by your local security policies. Without human intervention, a potential exposure could be cut off in minutes by leveraging the automation tools inside AWS.

Deleting and Disabling CMKs

While deleting CMKs is possible it has significant ramifications to an organization. You should first consider whether it’s sufficient to set the CMK state to disabled on keys that you no longer intend to use. This will prevent all future use of the CMK. The CMK is still available, however, and can be re-enabled in the future if it’s needed. Disabled keys are still stored by AWS KMS; thus, they continue to incur recurring storage charges. You should strongly consider disabling keys instead of deleting them until you are confident in their encrypted data management.

Deleting a key must be very carefully thought out. Data can’t be decrypted if the corresponding CMK has been deleted. Moreover, once a CMK is deleted, it’s gone forever. AWS has no means to recover a deleted CMK once it’s finally deleted. Just as with other critical operations in AWS, you should apply a policy that requires MFA for CMK deletion.

To help ensure that a CMK is not deleted by mistake, KMS enforces a minimum waiting period of seven days before the CMK is actually deleted. You can choose to increase this waiting period up to a maximum value of 30 days. During the waiting period, the CMK is still stored in KMS in a “Pending Deletion” state. It can’t be used for encrypt or decrypt operations. Any attempt to use a key that is in the “Pending Deletion” state for encryption or decryption will be logged to CloudTrail. You can set an Amazon CloudWatch Alarm for these events in your CloudTrail logs. This gives you a chance to cancel the deletion process if needed. Until the waiting period has expired, the CMK can be recovered from the “Pending Deletion” state and restored to either the disabled or enabled state.

Finally, it should also be noted that if you are using a CMK with imported key material, you can delete the imported key material immediately. This is different from deleting a CMK directly in several ways. When you perform the DeleteImportedKeyMaterial action, AWS KMS deletes the key material and the CMK key state changes to pending import. When the key material is deleted, the CMK is immediately unusable. There is no waiting period. To enable use of the CMK again, you must reimport the same key material. Deleting key material affects the CMK right away, but data encryption keys that are actively in use by AWS services are not immediately affected.

For example, let’s say a CMK using your imported material was used to encrypt an object being placed in an S3 bucket using SSE-KMS. Right before you upload the object into the S3 bucket, you place the imported material into your CMK. After the object is uploaded, you can delete your key material from that CMK. The object will continue to sit in the S3 bucket in an encrypted state, but no one will be able to access it until the same key material is re-imported into the CMK. This flow obviously requires precise automation for importing and deleting key material from a CMK, but can provide an additional level of control within an environment.