Skip to main content

⭐ Repository → 📁 Compliance Engine → 📁 CloudAware → 📁 AWS → 📁 KMS

🛡️ AWS KMS Symmetric CMK Rotation is not enabled🟢

Logic​

Similar Policies​

Similar Internal Rules​

RulePoliciesFlags
✉️ dec-x-4d6fee7a1

Description​

Open File

Description​

AWS Key Management Service (KMS) allows customers to rotate the backing key which is key material stored within the KMS which is tied to the key ID of the customer-created customer master key (CMK). It is the backing key that is used to perform cryptographic operations such as encryption and decryption. Automated key rotation currently retains all prior backing keys so that decryption of encrypted data can take place transparently. It is recommended that CMK key rotation be enabled for symmetric keys. Key rotation can not be enabled for any asymmetric CMK.

Rationale​

Rotating encryption keys helps reduce the potential impact of a compromised key as data encrypted with a new key cannot be accessed with a previous key that may have been exposed. Keys should be rotated every year, or upon event that would result in the compromise of that key.

Impact​

Creation, management, and storage of CMKs may require additional time from an administrator.

Audit​

From Console​
  1. Sign in to the AWS Management Console and open the KMS console at: https://console.aws.amazon.com/kms.

... see more

Remediation​

Open File

Remediation​

From Console​

  1. Sign in to the AWS Management Console and open the KMS console at: https://console.aws.amazon.com/kms.
  2. In the left navigation pane, click Customer-managed keys.
  3. Select a key where Key spec = SYMMETRIC_DEFAULT that does not have automatic rotation enabled.
  4. Select the Key rotation tab.
  5. Check the Automatically rotate this KMS key every year checkbox.
  6. Click Save.
  7. Repeat steps 3–6 for all customer-managed CMKs that do not have automatic rotation enabled.

From Command Line​

  1. Run the following command to enable key rotation:
aws kms enable-key-rotation --key-id <kms_key_id>

policy.yaml​

Open File

Linked Framework Sections​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 APRA CPG 234 → 💼 4 Cryptographic key management refers to the generation, distribution, storage, renewal, revocation, recovery, archiving and destruction of encryption keys. Effective cryptographic key management ensures that controls are in place to reduce the risk of compromise of the security of cryptographic keys. Any compromise of the security of cryptographic keys could, in turn, lead to a compromise of the security of the information assets protected by the cryptographic technique deployed.67no data
💼 APRA CPG 234 → 💼 4 Regulated entities would typically put in place processes to ensure that identities and credentials are issued, managed, verified, revoked and audited for authorised devices, users and software/processes.88no data
💼 APRA CPG 234 → 💼 36e hardware and software asset controls —appropriate authorisation to prevent security compromises from unauthorised hardware and software assets;1616no data
💼 APRA CPG 234 → 💼 44c loss of, or unauthorised access to, encryption keys safeguarding extremely critical or sensitive information assets.810no data
💼 APRA CPG 234 → 💼 d. predefined activation and deactivation dates for cryptographic keys, limiting the period of time they remain valid for use. The period of time a cryptographic key remains valid would be commensurate with the risk;34no data
💼 CIS AWS v1.2.0 → 💼 2.8 Ensure rotation for customer created CMKs is enabled11no data
💼 CIS AWS v1.3.0 → 💼 3.8 Ensure rotation for customer created CMKs is enabled11no data
💼 CIS AWS v1.4.0 → 💼 3.8 Ensure rotation for customer created CMKs is enabled11no data
💼 CIS AWS v1.5.0 → 💼 3.8 Ensure rotation for customer created symmetric CMKs is enabled - Level 2 (Automated)11no data
💼 CIS AWS v2.0.0 → 💼 3.8 Ensure rotation for customer created symmetric CMKs is enabled - Level 2 (Automated)11no data
💼 CIS AWS v3.0.0 → 💼 3.6 Ensure rotation for customer-created symmetric CMKs is enabled - Level 2 (Automated)11no data
💼 CIS AWS v4.0.0 → 💼 3.6 Ensure rotation for customer-created symmetric CMKs is enabled (Automated)1no data
💼 CIS AWS v4.0.1 → 💼 3.6 Ensure rotation for customer-created symmetric CMKs is enabled (Automated)1no data
💼 CIS AWS v5.0.0 → 💼 3.6 Ensure rotation for customer-created symmetric CMKs is enabled (Automated)1no data
💼 CIS AWS v6.0.0 → 💼 4.6 Ensure rotation for customer-created symmetric CMKs is enabled (Automated)1no data
💼 Cloudaware Framework → 💼 Expiration Management12no data
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)61432no data
💼 FedRAMP High Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)1911no data
💼 FedRAMP High Security Controls → 💼 SC-28(1) Cryptographic Protection (L)(M)(H)514no data
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)132no data
💼 FedRAMP Low Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)11no data
💼 FedRAMP Low Security Controls → 💼 SC-28(1) Cryptographic Protection (L)(M)(H)14no data
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)432no data
💼 FedRAMP Moderate Security Controls → 💼 SC-12 Cryptographic Key Establishment and Management (L)(M)(H)11no data
💼 FedRAMP Moderate Security Controls → 💼 SC-28(1) Cryptographic Protection (L)(M)(H)14no data
💼 GDPR → 💼 Art. 25 Data protection by design and by default1010no data
💼 ISO/IEC 27001:2013 → 💼 A.9.2.4 Management of secret authentication information of users810no data
💼 ISO/IEC 27001:2013 → 💼 A.10.1.2 Key management911no data
💼 ISO/IEC 27001:2022 → 💼 5.33 Protection of records1015no data
💼 NIST CSF v1.1 → 💼 DE.AE-2: Detected events are analyzed to understand attack targets and methods1823no data
💼 NIST CSF v1.1 → 💼 DE.AE-3: Event data are collected and correlated from multiple sources and sensors1837no data
💼 NIST CSF v1.1 → 💼 DE.DP-4: Event detection information is communicated2932no data
💼 NIST CSF v1.1 → 💼 ID.SC-4: Suppliers and third-party partners are routinely assessed using audits, test results, or other forms of evaluations to confirm they are meeting their contractual obligations1519no data
💼 NIST CSF v1.1 → 💼 PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes1930no data
💼 NIST CSF v1.1 → 💼 PR.AC-7: Users, devices, and other assets are authenticated (e.g., single-factor, multi-factor) commensurate with the risk of the transaction (e.g., individuals' security and privacy risks and other organizational risks)1923no data
💼 NIST CSF v1.1 → 💼 PR.DS-1: Data-at-rest is protected1528no data
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected1631no data
💼 NIST CSF v1.1 → 💼 PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy1632no data
💼 NIST CSF v1.1 → 💼 RS.AN-1: Notifications from detection systems are investigated1823no data
💼 NIST CSF v1.1 → 💼 RS.CO-2: Incidents are reported consistent with established criteria1922no data
💼 NIST CSF v2.0 → 💼 DE.AE-02: Potentially adverse events are analyzed to better understand associated activities31no data
💼 NIST CSF v2.0 → 💼 DE.AE-03: Information is correlated from multiple sources46no data
💼 NIST CSF v2.0 → 💼 DE.AE-06: Information on adverse events is provided to authorized staff and tools32no data
💼 NIST CSF v2.0 → 💼 DE.AE-07: Cyber threat intelligence and other contextual information are integrated into the analysis37no data
💼 NIST CSF v2.0 → 💼 GV.SC-07: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship26no data
💼 NIST CSF v2.0 → 💼 ID.RA-10: Critical suppliers are assessed prior to acquisition26no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization38no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated32no data
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties91no data
💼 NIST CSF v2.0 → 💼 PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected117no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected97no data
💼 NIST CSF v2.0 → 💼 RC.CO-04: Public updates on incident recovery are shared using approved methods and messaging22no data
💼 NIST CSF v2.0 → 💼 RS.CO-02: Internal and external stakeholders are notified of incidents30no data
💼 NIST CSF v2.0 → 💼 RS.MA-02: Incident reports are triaged and validated24no data
💼 NIST SP 800-53 Revision 4 → 💼 AC-2 (7) ROLE-BASED SCHEMES22no data
💼 NIST SP 800-53 Revision 4 → 💼 AC-6 (10) PROHIBIT NON-PRIVILEGED USERS FROM EXECUTING PRIVILEGED FUNCTIONS11no data
💼 NIST SP 800-53 Revision 4 → 💼 AU-6 AUDIT REVIEW, ANALYSIS, AND REPORTING1022no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-28(1) Protection of Information at Rest _ Cryptographic Protection1014no data
💼 PCI DSS v3.2.1 → 💼 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.1821no data
💼 PCI DSS v4.0.1 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.221no data
💼 PCI DSS v4.0 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.2921no data
💼 SOC 2 → 💼 CC6.1-10 Uses Encryption to Protect Data611no data
💼 SOC 2 → 💼 CC6.1-11 Protects Encryption Keys69no data