Mark Warner | Senior Sales Engineer, Thales
To meet various compliance requirements and reduce the risk of your most sensitive data getting compromised you may want to consider changing the encryption key used to protect this data. Thales refers to this changing of encryption keys as “Key rotation” or “Rekey”. Although encryption provides a high level of data security, it is possible that given enough time and resources, a skilled attacker could compromise an encryption key. The best way to limit the effect of this attack is to rotate the keys used to encrypt your data. Key rotation should be included as a regular part of key lifecycle management process.
Important things to consider on the topic of key rotation are
- Key Management – not be a maintenance burden to operations team.
- Re-encryption - how it might impact current systems.
- Types of Key Rotation - understand the different types of key rotation.
- Data Risk Factors – factors to consider in establishing rotation plans.
Key Management
Having an external key manager in place to ensure the keys are created, stored and rotated on a certified device and not on the file system is the first step in becoming compliant. Although most key managers implement a version key capability, which does simplify the management of key rotations, not all systems and vendors support it so be sure to add it to your requirements list when evaluating security vendors. Keeping track of non-current keys should not be a maintenance burden to the operations team and procedures should be in place to retire non-current keys at a reasonable timeframe.
A common question many organization have is deciding on how keys should be assigned to various projects and at what granularity. Should projects teams have just one key for each system, application, database etc? It is important to spend time on this topic as if designed appropriately will help reduce the impact of a potential breach and also help assist with reducing the impact of the operations team when doing tasks like key rotation.
Re-encryption
Re-encryption is the process to re-encrypt the existing data to use a new key. It should happen once the new key is generated for a particular application or system and be automated based on a pre-determined schedule.
- Operations Team - It is critical when this process occurs the impact to the organization should be minimal and the impact to existing systems is minimal.
- Cloud - Most cloud providers who implement native key encryption do not provide an easy method to implement re-encryption and often require customers to submit a formal service request with down time required to implement it.
Key Rotation Types
An understanding of the different types of encryption keys is necessary before an organization security policy can rolled out regarding key rotation.
- The Master Encryption Key is a typically a 256-bit symmetric key that is used to encrypt another key, which can either be a Data Encryption Key (DEK) or another Key Encryption Key (KEY).
- A Data Encryption Key is the key to encrypt sensitive data.
Key Managers use multiple levels of keys to implement proper protection of the Data Encryption Keys. There are a couple of different options for key rotation.
Shallow Key - Master key only
This option will rotate the Master key, which encrypts the Data Encryption Keys. This option may meet the security auditor’s requirements for key rotation. This option requires the least amount of effort and does not impact any existing operations but does not actually re-encrypt the sensitive data.
Non-shallow options
This type of rotation is rotating the Data Encryption Key. It is important to understand the consequences of how this is implemented. Some implementations require the data files to be taken offline which means the data on the device will be inaccessible during the key rotation and re-encryption process. Depending on the solution used to implement re-encryption there are ways to avoid this outage. See link at the end of this blog for more details.
Depending on the classification of data some auditors will consider a shallow key rotation good enough to satisfy an audit and compliance while others require a non-shallow option.
Data Risk Factors
In order to reduce your risk you first have to understand your risk and the first thing to consider is how much risk is associated to your data and the keys to protect the data. The longer a key is in use, the greater the chance of it becoming compromised; therefore, it is important to regularly replace (roll) important keys. In addition to the how long a key is in use, the given lifetime of a key depends on:
- Value of sensitive data (how it is classified) – PII, PCI, HIPA etc.
- Volume of data – for example 1MB vs 1TB. The more data the more risk.
- Frequency of use – data is accessed by many different system 24 by 7 is more vulnerable to an attack then offline data that is only processes once per quarter.
Organizations should discover all their sensitive data and develop a risk factor based on these factors and other criteria the auditors require.
Develop key rotation guidelines
Once you understand your data risk it is important to establish some guidelines on key rotations so the operations team can manage it and the security auditors are satisfied with the results.
- Frequency –Know what your security auditor requires to satisfy an audit. Independent of what the auditors require implement the best method depending on classification of data and budget.
- Timing – not all at once. When implementing key rotation and re-encryption it would be less risky to have keys allocated appropriately so that impact to a system would be controlled from a logging and monitoring perspective. Make sure to spend time on the key assignment management to ensure you have the proper granularity to implement different schedules.
- Audit logs - Ensure proper audit logs are generated to provide auditors proof of rotation.
- Inventory of sensitive data – for each of your systems use the data risk factors to determine proper rotation plan.
Summary
As noted above ensuring keys are created, stored and rotated on a separate device is the first step in obtaining compliance. Companies should work with their risk and security officers to determine the appropriate kind of key rotation for their various classifications of data and develop proper key rotation guidelines based on the data risk factors and classification provided in this blog in order to meet their compliance requirements and reduce the risk of a potential breach.
For more details on key management, implementing key rotation and data classification see following links:
Key Management
https://cpl.thalesgroup.com/resources/encryption/ciphertrust-manager-product-brief
Key Rotation
https://cpl.thalesgroup.com/resources/encryption/ciphertrust-live-data-transformation-product-brief
Data Classification
https://cpl.thalesgroup.com/encryption/data-discovery-and-classification