What is the CCSSA-PR Processs?

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

The peer review process is defined within the CCSS Audit Guide section 1.3 #1. 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 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 known 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.
  4. Once the audit is complete the CCSSA conducting the audit submits audit documentation to the CCSSA-PR for peer review.
  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.

What is the Purpose of the Peer Review Process?

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 at this stage as to the requirement to use another CCSSA as a third-party peer reviewer. The sharing of confidential audit evidence and documentation with yet another third-party external from the assessed entities environment and its information security controls doubles the risk of an information security breach. Further, the fact that the assessed entity may not have participated in the selection of the CCSSA-PR and is ultimately trusting the CCSSA’s ability to correctly vet another CCSSA 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 as to how Confide CCSSAs would prepare audit document for peer review below.

How is Sensitive Information Protected?

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.

Examples

Defining the Trusted Environment

 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.

Examples of Evidence Gathering

To define what evidence gathering techniques were applied for a CCSS Aspect Control by the CCSA, an example is provided below. This example Aspect Control only as 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 entities 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 3 interviews of current key custodians. Each interview was between the CCSSA and one of the key custodians in a private room. Interview topics discussed 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 are required to read and acknowledge in writing that the documentation was reviewed.

The CCSSA conducted 2 interviews with the security operations team to ensure that all private keys are transmitted, processed and stored within the CCSS Trusted Environment and 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 which transmit, process or store key data has been correctly defined by the assessed entity.

Inspection

The CCSSA inspected the key management server which stores all of the assessed entities private keys and is the only system that provides access to the keys, to identify all systems which access the key management server to perform key functions. The list of systems which 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.

Example 2: Aspect Control: 2.01.1 Security Audit

NOTE: 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

Review

The entities 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 which 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 provided solution that provides cryptocurrency functions.
  5. The developer involved with security assessment activities is knowledgeable in secure coding techniques for the software languages used by the assessed entity.

Standards and procedure documents covering all security assessment activities including standards to be used 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 conducted an interview with the sole developer that was involved in the development, design and implementation of Project A, that 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, the functions within the software that make use of cryptocurrencies. Change management, software development life-cycle management, testing and deployment management were also discussed.

An interview was conducted with a senior systems architect who was responsible for the design of Project A. 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 conducted an interview with a member of the assessed entities security operations team who was responsible for the completion of 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, 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. At the time of the audit activity all remediation activities had been completed.

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 CCSS Trusted Environment defined by the assessed entity was confirmed by the CCSSA.

This post is part of our series on auditing against the CCSS. If you haven’t already, we recommend these other posts in the series.