This CCSS Level 2 requirement builds upon the CCSS Level 1 requirement by adding:
- A task checklist for granting and revoking privileges for access to the cryptographic keys or seeds.
- 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:
- The requirement is focused only on the checklist template NOT the use of the template for each change in a users privilege.
- 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:
- “Least privilege principles” have been considered and applied to the task checklist in relation to the information system(s) for which the privileges impact.
- The CCSSA must ensure that the application of “least privilege principles” has been considered using industry recognized information security best practices.
- 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.
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:
- “A communication channel that provides high confidence of the identities of the communicating parties.”
- Verification of biometrics (“where the sound of their known voice is verified”)
- “Digitally-signed message (using strong encryption such as PGP/GPG or S/MIME)”
- 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:
- The actors involved in the communication must be authenticated, authorized and known to each other.
- 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.
- 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.