CryptoCurrency Security Standard (CCSS) - How Does the Peer Review Process Work?

[Article Updated August 2023 for CCSS Version 8.1]?

Marc Krisjanous is one of the first CCSS Auditors, assisted C4 in developing their auditors program and is a member of the CCSS Steering Committee.

**** Free CCSS Implementation Guide! ****

Marc also co-authored the CCSS Implementation Guide for a Full System - click here to download - it's free!

The CCSS auditor program requires a peer review of audit documentation before an assessed entity can receive CCSS certification.?

The CCSS Audit Guide section 1.3 #1 defines the peer review process. The process at a high level involves:

1. The CCSSA conducting the audit of an entity submits the Intent to Audit form to C4.
2. C4 will provide the CCSSA with a list of other CCSSAs that have been randomly selected by C4 to conduct the peer review process. The list is called the Peer Reviewer Options List (PROL).
3. The CCSSA then selects and engages a CCSSA from the PROL. The selected CCSSA that will conduct the peer review process is referred to as the CCSSA-PR for that audit. It is the responsibility of the CCSSA conducting the audit to perform appropriate vetting and contractual arrangements directly with the CCSSA-PR. There is no contractual relationship between the CCSSA-PR and the assessed entity or C4. An important tip for the CCSSA selecting the peer reviewer from the PROL is to ensure that the CCSSA who will undertake the peer review will be CCSSA certified during the peer review process. CCSSA certification is an annual event and the selected CCSSA cannot undertake the peer review if they are not currently CCSSA certified.
4. Once the audit is complete, the CCSSA conducting the audit submits a redacted version of the Report on Compliance (RoC) as stated in the CCSS Auditor Guide to the peer reviewer.
5. Once the peer review process is complete, the CCSSA then submits audit documentation to C4. NOTE: only specific audit documentation is provided to C4 as defined within the CCSS Audit Guide.

The purpose of this article is to provide a further breakdown of what documentation is to be sent to the CCSSA-PR.

The CCSS committee implemented the selection process for a CCSSA-PR with the aim of providing an independent peer review process from the CCSSA who conducted the audit.

Readers of this article may be raising an eyebrow about the requirement to use another CCSSA as a third-party peer reviewer. The sharing of confidential audit evidence and documentation with another third party external to the assessed entity's environment doubles the risk of an information security breach. Further, the fact that the assessed entity may not have participated in selecting the CCSSA-PR and is ultimately trusting the CCSSA's ability to vet another CCSSA correctly gives further grounds for concern.

The good news is that the peer review process only requires that the CCSSA-PR reviews the evidence gathering techniques applied by the CCSSA conducting the audit NOT the review of the CCSSA's collected audit evidence.

To repeat - the peer review process is the verification by the CCSSA-PR that the CCSSA has applied sufficient evidence-gathering techniques (observation, inspection, review, interview) to have been realistically able to reach the opinion of a CCSS requirement being in place. The audit documentation presented to the CCSSA-PR does not document any evidence that is deemed to be confidential to the assessed entity. The audit documentation defines the types of evidence-gathering techniques used by the CCSSA during the audit for each requirement.

To provide further clarity, I have provided guidance on how Confide CCSSA's would prepare the audit documentation for peer review below.

The audit documentation for peer review should NOT document the following:

1. Names of personnel interviewed. Only provide the role of the interviewee.
2. Filenames or extracts from evidence documentation.
3. Screen captures, configuration details, diagrams, internally identifiable names, versions, descriptions or other private information of hardware devices and software systems.

To define the CCSS Trusted Environment for the CCSSA-PR, which is considered as the "in scope" environment for audit or the "audit boundaries", an example is provided below.

?Scope of the Trusted Environment

The assessed entity’s Trusted Environment definition, which includes the people, process and technology components that transmit, process and store private keys used for cryptocurrencies, was provided to the CCSSA at the beginning of the current audit. The CCSSA compared the Trusted Environment component definitions with the evidence provided during the current audit.

To define what evidence-gathering techniques were applied for a CCSS Aspect Control by the CCSSA, an example is provided below. This example Aspect Control only has one requirement, which is for CCSS Level 1: 1.04.2.1 All keys/seeds are only used in trusted environments.

Example 1: Aspect Control: 1.04.2 Keys are only used in a trusted environment

CCSSA evidence-gathering techniques applied:

Review

The entity's Information Security Policy and Trusted Environment Policy were reviewed to ensure statements are provided that require all private keys and seed phrases to only be transmitted, processed and stored within the trusted environment.

Standards and procedure documents covering all key management activities, including key creation, key distribution, key retirement and key destruction, were reviewed by the CCSSA.

Interview

The CCSSA conducted three interviews of current key custodians. Each interview was between the CCSSA and one of the key custodians in a private room. Interview topics covered the tasks each key custodian undertook in the last key ceremony, the location of the key ceremony, discussion around the key management policy and procedures they must read and acknowledge in writing that the documentation was reviewed.

The CCSSA conducted two interviews with the security operations team to ensure that all private keys are transmitted, processed and stored within the CCSS Trusted Environment. Sufficient monitoring of access to the keys is implemented.

The CCSSA conducted a combined interview with a network administrator and a system architect. The interview topics covered: the review of the network diagrams to identify all systems that transmit, process and store key data to confirm that the Trusted Environment has been correctly defined by the assessed entity, that all systems that transmit, process or store key data have been correctly defined by the assessed entity.

Inspection

The CCSSA inspected the key management server, which stores all of the assessed entity's private keys and is the only system that provides access to the keys, to identify all systems that access the key management server to perform key functions. The list of systems connected to the key management server were compared with the evidence provided to confirm that all systems that transmit, process and store key data were identified and contained within the Trusted Environment.?

Another example is below. NOTE: In this example, Aspect Control has a requirement for each CCSS Level. For our example, the assessed entity is aiming for CCSS Level 2 certification, so the evidence gathered was to cover all requirements in CCSS Level 1 and 2, namely:?2.01.1.1 and 2.01.1.2

Example 2: Aspect Control: 2.01.1 Security Audit

Review

The entity's Information Security policy, Trusted Environment policy, Software Development standards, and Vulnerability Management policy were reviewed to ensure the following principles are addressed:

1. A security assessment is required at least annually.
2. All components within the Trusted Environment have been included in internal and third-party security assessments.
3. A developer is to be assigned to each project that requires custom code that provides cryptocurrency functions or implements a third-party provided solution that provides cryptocurrency functions.
4. An internal assessment must be conducted for each project that requires custom code for any system that provides cryptocurrency functions or implements a third-party solution that provides cryptocurrency functions.
5. The developer involved with security assessment activities is knowledgeable in secure coding techniques for the software languages the assessed entity uses.

Standards and procedure documents covering all security assessment activities, including standards for reference during assessment activities, secure coding techniques, configuration management and deployment management, where reviewed by the CCSSA.

?A total of 1 internal assessment was conducted during the assessed period. The assessment findings report was reviewed and found to be complete. No remediation was required.

?A total of 2 third-party security assessments were conducted during the assessed period. Both reports were reviewed and found to be complete. Remediation activities for the first third-party security assessment were documented, and a remediation plan was created by the assessed entity. The second third-party security assessment required no remediation activities.

Only one project was implemented within the Trusted Environment within the assessed period - referred to as "Project A" for this assessment.

Interview

The CCSSA interviewed the sole developer involved in the development, design and implementation of Project A, which provided custom code software that included functions that use cryptocurrencies. Interview topics with the developer covered secure coding techniques applied in the development of the custom code used by the project, secure coding techniques training undertaken by the developer during the assessed period, and the functions within the software that use cryptocurrencies. Change management, software development life-cycle management, testing and deployment management were also discussed.

An interview was conducted with a senior systems architect responsible for Project A's design. The interview topics included the discussion of the internal assessment activity, the methodology used for the assessment, the assessment findings and the scope of the assessment, which only covered Project A components.

The CCSSA interviewed a member of the assessed entity security operations team responsible for completing the annual security assessment, which covers the entire Trusted Environment, conducted by a third-party service provider. The interview topics covered the suitability of the third-party service provider to conduct the security assessment, the report findings, and the scope of the security assessment.

Inspection

The CCSSA inspected the outputs of the remediation activities from the internal security assessment to ensure that remediation was undertaken and completed. All remediation activities had been completed at the time of the audit activity.

Summary

In this article, we provided detail as to our interpretation of the peer review process by providing examples of how a Confide CCSSA would document audit evidence-gathering techniques applied for two CCSS Aspect Controls as well as how the CCSSA confirmed the CCSS Trusted Environment defined by the assessed entity.?

#1 https://cryptoconsortium.org/cryptocurrency-security-standard-auditor-ccssa-guide/

Other Articles on CCSS and CCSSA

What is CryptoCurrency Security Standard (CCSS)??

What is a CCSSA?

CCSS Audit and Pen-Testing Requirements

CCSS Key Storage Requirements

Confide.co.nz