Aside from cyptoperiod requirements, in the cryptographic lifecycle, there are two types of events that drive key rotation. The first is when a key custodian or someone with knowledge of original key material leaves the organization. These personnel departures should cause key rotation because that person is no longer under your policy or control. The second is when there is suspicion that the integrity of the original key has been compromised in some way. 

To identify if these types of events have occurred, you must properly monitor key activity – which is easy to accomplish in AWS. Services like AWS KMS and CloudTrail track and log key activity for you, and you can also establish IAM policies for keys. 

Read more about key rotation in NIST SP 800-57 Part 1: Recommendation for Key Management and the AWS best practices for rotating customer master keys.

There are some specific events in the life of an encryption key that drive selection of a new key. Specifically, there is one broad category with the second one maybe being an example of the first, but anytime somebody with knowledge of the key, one of our key custodians, if you’re talking about it in a PCI terminology. When someone with knowledge, maybe a database administrator, an application engineer, somebody like that – who has knowledge of the original key material – leaves the organization, they’re no longer under our policy, they’re no longer under our control. Sure, there may be some nondisclosure agreements and noncompete agreements, things like that, in their employment, but that kind of an event really means that we need to generate a new key associated with that person’s departure. The second event, in a much broader statement, is when we suspect that the original key has been compromised in some way. To suspect that a key has been compromised means that we need to be tracking all of the interactions with that key. 

In an AWS environment, this is actually quite easy. All of those interactions are going to occur through API calls to the Key Management Services, KMS, and CloudTrail, as an Amazon service that is available to all AWS customers, will track all of those interactions for us. We can create those log events and we can also establish IAM policies on those keys, so that the access to those keys is severely restricted to exactly and only the points that should have access. Between IAM policies and CloudTrail event logs, we’ll be able to determine if we suspect that the key, itself, has been compromised. Those are the two critical events that drive the immediate selection of a new key, not based on a cryptoperiod, not based on quantity of data, not based on time, but rather actual events.