In this series we will review each of the core Aspects in the CCSS and provide our interpretation for each of the Aspect’s requirements and what possible evidence could provide assurance to the auditor that a requirement is in-place. Make sure to read our other in-depth articles on the CCSS Aspects:

CCSS Aspect 1.05 Key Compromise Policy

In this article we will explore how an auditor could interpret the CCSS Aspect 1.05 Key Compromise Policy.

Aspect 1.05 Key Compromise Policy addresses the processes to respond to a key/seed and operator/holder compromise. The Aspects objective defined within the CCSS is provided below.

“This aspect covers the existence and use of a protocol that dictates the actions that must be taken in the event a cryptographic key/seed or its operator/holder is believed to have become compromised. Organizations must be prepared to deal with a situation where a private key has – even potentially – become known, determinable, or destroyed. Proper policies and procedures to govern these events decrease the risks associated with lost funds and disclosed trade secrets, and increase the availability of the information system to its users. Examples of when a KCP would be invoked include the identification of tampering of a tamper-evident seal placed on key material, the apparent disappearance of an operator whose closest friends and family cannot identify their whereabouts, or the receipt of communication that credibly indicates an operator or key is likely at risk of being compromised. The execution of Key Compromise Protocols must make use of Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors.“

Aspects Controls

There are two controls to this Aspect. In this article we will address each control.

  • 1.05.1 KCP Exists
  • 1.05.2 KCP Training + Rehearsals

CCSS Levels

CCSS provides three levels of compliance – Level 1 being the base level of implementing CCSS requirements up to Level 3 being the most in-depth implementation of CCSS requirements. We shall review each compliance level and provide our thoughts on what evidence an auditor should seek to provide assurance that the requirements are in-place.

Level 1 Compliance

Requirement 1.05.1.1

An inventory of all keys/seeds exists and the organization has an awareness of which keys are critical to the successful operation of the information system.

The key/seed (“key”) inventory should provide information about each key that will address the following questions:

  1. What is the purpose of the key?
  2. What types of data is the key encrypting?
  3. How much data has the key encrypted over its OUP?
  4. What is the Originator Usage Period (OUP)?
  5. What is the Recipient Usage Period (RUP)?
  6. What is the impact to the organization if the data is lost or the key is compromised?
  7. Who is accountable for the key?
  8. Who has access to the key?
  9. Where is the key located?
  10. Are there any copies? If so where?
  11. Is the key backed up?
  12. Is the key encrypted by another key? E.g. Key-Encrypting-Key (KEK)?

The Originator Usage Period (OUP), the sensitively of the data and the amount of data the key has encrypted provide some degree of awareness as to the scale of impact of the keys compromise to the organization.

Requirement 1.05.1.2

While no formal KCP documents may exist, there is a staff member who is able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency wallets, and send funds to these newly-generated wallets in the event any operator or keys become compromised.

The requirement does not enforce the need for a formal documented KCP. Therefore, it will be up to the CCSSA to decide if the risk of accepting potentially interview and observation evidence only is within an acceptable risk level to mark this requirement as in-place.

The CCSSA must have enough assurance that the staff member has complete awareness of all processes that must be undertaken during and after a key is compromised and be able to direct other staff members during a time when stress-levels are high and within an incident response event.

Level 2 Compliance

Requirement 1.05.1.3

A Key Compromise Protocol is documented which details: each specific classification of key used throughout the system; a detailed plan of dealing with its compromise that includes the use of Approved Communication Channels during execution; identities of actors via roles (not names), and includes secondary actors in the event any primary actor is unavailable to carry out the KCP.

The requirement defines what should be documented within the KCP.

Additionally, NIST SP 800-57 PART 1 REV. 5 provides the following recommendations for what a KCP should contain:

The compromise-recovery plan should contain:

  1. An identification of the personnel to notify and what the notification should contain (e.g., the scope of the compromise − whether specific keys were compromised or the certificate generation process was compromised);
  2. An identification of the personnel to perform the recovery actions;
  3. The method for obtaining a new key (i.e., re-keying);
  4. An inventory of all cryptographic keys (e.g., the location of all keys and certificates in a system);
  5. The education of all appropriate personnel on the compromise-recovery procedures;
  6. An identification of all personnel needed to support the compromise-recovery procedures;
  7. Policies requiring that key-revocation checking be performed (to minimize the effect of a compromise);
  8. The monitoring of the re-keying operations (to ensure that all required operations are performed for all affected keys); and
  9. Any other compromise-recovery procedures.
  10. Other compromise-recovery procedures may include:
  11. A physical inspection of the equipment;
  12. An identification of all information that may be compromised as a result of the incident;
  13. An identification of all signatures that may be invalid due to the compromise of a signing key; and
  14. The distribution of new keying material, if required

Level 3 Compliance

Requirement 1.05.2.1

The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise. Logs of executed tests exist which outline any/all comments of the test. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.

The requirement comprises of four sub-requirements:

  1. The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise.
  2. Logs of executed tests exist which outline any/all comments of the test.
  3. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained.
  4. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.

Sub-requirement: The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise.

The sub-requirement states that the KCP must be tested periodically. The CCSS Glossary defines “periodically” as “As determined to be sufficient by the auditor”. To assist the CCSSA in the determination of the period we suggest that the assessed entity defines their own testing schedule of the KCP based of the assessment of risk to the organization if a critical key/seed phrase is compromised. The CCSSA should ensure that:

  1. There is a defined test schedule for testing the KCP.
  2. There is testing program material that defines the where, what and who of a test exercise.
  3. All personnel who require training must be defined and a record kept of the training that they attended.

Sub-requirement: Logs of executed tests exist which outline any/all comments of the test.

After each test a log (report/memo etc..) should be created that records the outcomes of the test including: what worked? what didn’t? what needs to be changed? what other actions need to be undertaken? Also, the test scenario is recorded as well as all attendees.

Sub-requirement: Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained.

The CCSSA should request all test result logs for the assessed period and ensure that any improvements stated in a test result log have been incorporated back into the KCP. This can be achieved by interviewing the personnel responsible for updating the KCP with the stated improvements.

Sub-requirement: As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.

For this sub-requirement the CCSSA should ensure there are policy and procedures in-place that address changes to the CCSS Trusted Environment and how any changes will trigger additional procedures to up-date information sources such as policy, standards and procedures.

The CCSSA should interview relevant personnel who are responsible for updating the KCP when there are changes to the CCSS Trusted Environment to ensure the relevant policy, standards and procedures are adhered to.

Summary

In this article we reviewed the requirements for the Key Compromise protocol for the assessed entity. A key that is compromised is a critical risk to an organization as it can lead to lost of funds, lost of control over data that the key protects and brand damage. The CCSSA should seek strong assurance that key compromise policy, standards and procedures are in-place, align with best practice and are implemented and used when required.