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.06 Keyholder Grant / Revoke Policies & Procedures

In this article we will explore how an auditor could interpret the CCSS Aspect 1.06 Keyholder Grant/Revoke Policies & Procedures.

Aspect 1.06 Keyholder Grant/Revoke Policies & Procedures addresses user account management for granting and revoking access to keys and seeds that store organizational or end-user funds. The aspects objective defined within the CCSS is provided below.

“This aspect covers the policies and procedures surrounding granting and revoking access to cryptographic keys or seeds that store organizational or end-user funds. Staff typically have greater access to an information system with respect to accessing its information, invoking privilege-restricted actions, and representing the organization to the public. Improper management of the onboarding and offboarding of personnel introduce risks of privileged accounts remaining when staff depart, as well as unrevoked keys that persist signing authority for certain transactions.“

Aspect Controls

There are three controls to this aspect. In this article we will address each control.

  • 1.06.1 Grant/Revoke Procedures/Checklist
  • 1.06.2 Requests made via Approved Communication Channel
  • 1.06.3 Grant/Revoke Audit Trail

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.06.1.1

An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately.

For the CCSSA to have enough assurance that this requirement is in-place the CCSSA will need to use multiple evidence gathering techniques.

The CCSSA should:

  1. Review the policy and procedures for user account management that grant and revoke privileges for access to the cryptographic keys or seeds.
  2. Conduct interviews with personnel who undertake the user account management procedures that grant and revoke privileges for access to the cryptographic keys or seeds to ensure that they understand the documented policy and procedures related to user account management.
  3. Review a sample of change requests that grant and revoke access to the cryptographic keys or seeds to ensure the documented procedures are undertaken correctly.
  4. Inspect the authentication and authorization controls that grant and deny access to the cryptographic keys or seeds to ensure (a) all user accounts are valid (b) the privileges have been correctly assigned to each user account.

By conducting reviews, interviews and inspection of the in-scope people, process and technology, the CCSSA should have a thorough understanding of the user account management processes and have enough assurance to mark this requirement as in-place.

Level 2 Compliance

Requirement 1.06.1.2

The organization maintains checklists that cover all tasks that must be completed when staff vacate or transition into keyholder roles within the organization. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the information system, as well as necessary access where required.

This CCSS Level 2 requirement builds upon the CCSS Level 1 requirement by adding:

  1. A task checklist for granting and revoking privileges for access to the cryptographic keys or seeds.
  2. The checklist has been reviewed by a “knowledgeable personnel to ensure “least privilege principles”” are applied to the information system, as well as necessary access where required”.

The wording for this requirement could be interpreted in two ways:

  1. The requirement is focused only on the checklist template NOT the use of the template for each change in a users privilege.
  2. The requirement is focused on the implementation of the checklist template – meaning each time there is a change in a users privilege the template checklist is used and filled-in for each request.

We believe this requirement is focused our second interpretation. As of July 2022 we have contacted C4 to seek clarification on this requirement and will update this article when clarification is provided.

The CCSSA’s gathered evidence for CCSS Level 1 compliance, as recommended in this article, includes change requests for granting and revoking privileges for access to the cryptographic keys or seeds. To meet CCSS Level 2 requirement the CCSSA must ensure that the task checklist is implemented and completed for each change to the user account(s) covered by the change request.

To address the second part of this CCSS Level 2 requirement the CCSSA must interview the personnel who reviewed the checklists for each of the sample change requests gathered in CCSS Level 1 review. For each task checklist ensure that:

  1. “Least privilege principles” have been considered and applied to the task checklist in relation to the information system(s) for which the privileges impact.
  2. The CCSSA must ensure that the application of “least privilege principles” has been considered using industry recognized information security best practices.
  3. There is a process implemented where the task checklist is reviewed periodically #1 to ensure that the task checklist is updated when required based on changes to the information system for which the privileges impact and changes to industry best practices for the application of “least privilege principles“. For example – any changes to the information system for which the privileges impact will trigger a review of the task checklist. If no changes have been made to the information system for which the privileges impact in 12 months then an annual review of the task checklist is undertaken to take into account any changes to industry best practices for the application of “least privilege principles“.

NOTE: The use of the term “periodically” allows for each assessed entity to define their own schedule to review the task checklist based of the assessment of risk that any changes to the information system may involve changes to the task checklist. For example, the information system may implement a more fine-grained Role-Based Access Control (RBAC) system. However, the current version of the task checklist still enforces privileges that do not take into account the more fine-grained allocation of roles and privileges, leading to the user account having too much privilege based on the requirements of the role.

Requirement 1.06.2.1

All keyholder grant/revoke requests are conducted over Approved Communication Channels.

The CCSS Committee as defined “Approved Communication Channels” as:

“A communication channel that provides high confidence of the identities of the communicating parties. This could be a voice call where the sound of their known voice is verified, a digitally-signed message (using strong encryption such as PGP/GPG or S/MIME), or a combination of multiple separate channels that are unlikely to be simultaneously compromised, such as an email + an SMS message + an instant message via Slack.“

The CCSS Committee’s definition of “Approved Communication Channels” provides a number of components:

  1. “A communication channel that provides high confidence of the identities of the communicating parties.”
  2. Verification of biometrics (“where the sound of their known voice is verified”)
  3. “Digitally-signed message (using strong encryption such as PGP/GPG or S/MIME)”
  4. The use of out-of-band channels (“or a combination of multiple separate channels that are unlikely to be simultaneously compromised,”)

The CCSSA will need to reach their own conclusion if the “Approved Communication Channels” implemented meets the objective of the requirement. This is due to the broad range of protocols and technologies available for communication and the unlimited combinations of communication channels that can be used.

However, the CCSSA could use the following guidance based on our interpretation of the requirement’s objective in assessing the communications used:

  1. The actors involved in the communication must be authenticated, authorized and known to each other.
  2. If the communication is electronic based, then strong encryption (such as those defined in NIST SP 800-131A and NIST SP 800-57) must be used in the transmission of data either at the transmission protocol layer or the data layer or both.
  3. The grant and revoke request information must be split over at least two secure communication channels that use different technology platforms. For example, corporate email using encryption and SMS via corporate registered mobile phone. NOTE: an assessed entity may have a small amount of personnel and all be located within one premise that a grant and revoke request is done verbally. The CCSSA must not consider the use of verbal communication as meeting the objective of the requirement even if a second communication channel used meets the objective of the requirement. At the very least all requests for grant and revoke changes must involve documentation of the request and written management approval. Verbal communication without recording the dialogue breaches the non-repudiation component of information security.

Level 3 Compliance

Requirement 1.06.3.1

The organization’s checklists include auditing information that record the identity of the staff member that performs the grant/revoke operations. Each entry within the audit trail is attested to by the staff member who performed that task.

In order for this requirement to be in-place the CCSSA should gather and review the following evidence:

  1. The audit data must be protected from unauthorized changes. Changes to audit data must be approved by management in writing and the reason for the change must be documented. Audit data is a critical information security control as it provides non-repudiation of events.
  2. For each audit data the date and time of the event must be recorded. The time-zone must be configured for the system(s) which generate audit data based on the time management policy of the assessed entity.
  3. The user account ID which generated the event must be part of each audit data record.
  4. The audit data must be backed up to a centralized log management system as promptly as possible to provide further protection against unauthorized changes at the point of data origin.
  5. All events generated by a user account must be attested by the personnel using the user account which generated the event.
  6. There must be a documented time frame for the life of audit data and enforced by the audit management system(s).

Summary

In this post we explored aspect 1.06 Keyholder Grant/Revoke Policies & Procedures of the CCSS with our auditors hat on to determine how an auditor could approach the evidence gathering required so that an opinion could be reached as to if the assessed entity is compliant to Level 1, Level 2 or Level 3 for this aspect.