SAMMY UI is optimized for resolutions with a width 1024px and higher.
Cloud Controls Matrix
Browse Cloud Controls...
CEK-19: Key Compromise
Key Compromise
CEK-19: Are processes, procedures, and technical measures to encrypt information in specific scenarios (e.g., only in controlled circumstances and thereafter only for data decryption and never for encryption) being defined, implemented, and evaluated to include legal and regulatory requirement provisions?
Compromised keys/states are keys that may be waiting for the performance of an investigation to determine the appropriate disposition. Compromised keys should be revoked using the organization’s emergency revocation policy.

When appropriate, relevant stakeholders should be notified that keys previously used to encrypt their data have been compromised and that those keys are no longer used for encryption.

These compromised keys should be notated in the organization’s “Compromised Key Lists (CKLs)” along with a summary of users notified, notification timeframes, or reasons that notifications were not made to compromised key users.

Compromised keys await an investigation to determine disposition.
a. Perform emergency revocation when keys are lost or compromised.
b. A compromised status must be available to all who have relied on the key.
c. Use CKLs to inform stakeholders.
d. Compromised status is also reflected in the inventory management system.
e. Use audits to uncover undetected compromised keys.
f. Analyze events to support recovery from compromises.
g. Detail the method for revoking and re-keying compromised keys.
h. Use cryptoperiods to limit compromised key damage.
i. A compromised key should only be used to process data it has protected for the sole purpose of de-encrypting the data.
j. All transitions/activity shall be recorded (logged) and the key state updated in the inventory management system (CKMS).
Control implemented
Not applicable - A “N/A” answer indicates that the portion of the control in question is out of scope of the assessment. The “SSRM control ownership” column is to be left blank (e.g., greyed out), and optionally the CSP may explain why it is the case (“CSP Implementation Description”).
No - A “No” answer indicates that the portion of the control in question is not implemented, while in scope of the assessment. The CSP has to assign the implementation responsibility of the control to the relevant party under column “SSRM control ownership”, and optionally elaborate on the “why” (has not been implemented), and “what” has to be done for its implementation by that party.
Yes - A “Yes” answer indicates that the portion of the control in question is implemented. The CSP indicates the responsible and accountable parties (SSRM control ownership), and optionally elaborates on the implementation “how-to” per relevant party CSP and/or CSC.
Control ownership
CSP-owned - The CSP is entirely responsible and accountable for the CCM control implementation.
CSC-owned - The Cloud Service Customer (CSC) is entirely responsible and accountable for the CCM control implementation.
Third-party - The third-party CSP in the supply chain (e.g., an IaaS provider) is responsible for CCM control implementation, while the CSP is fully accountable.
Shared CSP and CSC - Both the CSP and CSC share CCM control implementation responsibility and accountability.
Shared CSP and third party - Any CCM control implementation responsibility is shared between CSP and the third party, but the CSP remains fully accountable.
Description

Define, implement and evaluate processes, procedures and technical measures to use compromised keys to encrypt information only in controlled circumstance, and thereafter exclusively for decrypting data and never for encrypting data, which include provisions for legal and regulatory requirements.