| Category | Aspect | Aspect Objective | Aspect Control | Level I Requirement | Rationale | Level II Requirement | Rationale | Level III Requirement | Rationale |
|---|---|---|---|---|---|---|---|---|---|
| Aspect | Aspect Objective | Aspect Control | Level I Requirement | Rationale | Level II Requirement | Rationale | Level III Requirement | Rationale | |
| Cryptographic Asset Management | 1.01 Key Material Generation | This aspect covers the generation of key material that will be used within a digital asset and blockchain protocol. The secure generation of key material requires two things to be secure: confidentiality and unpredictable numbers. Confidentiality is required to ensure that the newly generated key material is not read/copied by an unintended party. Nondeterministic and unpredictable numbers are required to ensure the newly generated key material cannot be guessed or determined by an unintended party. Each of the goals listed provide assurance that the key material is generated in a confidential and unguessable manner. | 1.01.1 Actor-generated Key Material | 1.01.1.1 Key material is generated by the actor who will be using it. | This is an attempt to protect the confidentiality of key material. Any Key Management System that requires one actor to transfer key material to another actor after generating it will fail to achieve Level I, with the exception of the initial configuration of an automated signing agent. | 1.01.1.3 A digital signature for the key material generation mechanism is generated, published, and validated prior to each execution. | This ensures the key material generation mechanism has not been altered. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. |
| 1.01.1.2 Where an automated signing agent will use key material, and the place of generation of key material is different from the place of use. The following criteria are addressed: 1. The key material is generated within a secure Key Management System that meets applicable CCSS requirements. 2. The key material is transferred securely to the automated signing agent from the place of generation that meets applicable CCSS requirements. 3. The key material is securely removed from the place of generation that meets applicable CCSS requirements. | This is an attempt to protect the confidentiality of key material for any system using an automated signing agent. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | ||||
| 1.01.2 Validation of Generation Methodology | Not required for level 1. | Not required for level 1. | 1.01.2.1 The methodology for generating key material is validated prior to use. Software does not include features that restrict which values can be used. Software does not include features that store or transmit data to another actor, unless that feature enhances security. | Features that restrict the entropy of key material and don't protect the transmission of data result in decreased security. An example of a feature that enhances security is DRBGs. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| Not required for level 1. | Not required for level 1. | 1.01.2.2 In cases where key material is generated without the use of software, the generation methodology is validated to ensure determinism is not present. | Features that restrict the entropy of seed generation and/or are deterministic result in decreased security. When generating without the use of software, ensure there are no weighted dice, each card in the deck is unique, etc. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | ||||
| 1.01.3 Deterministic Random Bit Generator (DRBG) Compliance | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.01.3.1 The generation mechanism for key material conforms to NIST SP 800-90A. | NIST SP 800-90A is a recommendation that ensures that deterministically-generated numbers follow a random distribution with respect to a deterministic seed. Thus, the ability to determine these random numbers is reducible to the ability to discover the DRBG’s seed. | |||
| Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.01.3.2 The key material generation process has been documented and addresses the following: 1. The key material generation process must be conducted in a secure environment. 2. The physical environment that will be used for the key material generation process is checked before use for any unauthorised recording/surveillance equipment, windows allowing the key material generation process to be viewed by external personnel, poor physical separation of the area from the main working areas, effective physical access controls to restrict unauthorised access of personnel, backup power supply, environmental controls to protect against electromagnetic interference, sound leakage, or other vulnerabilities that could compromise the process. 3. All equipment and software used for the key material generation process must be checked before use for updates such as new software versions, any signs of tampering, and be in good working order. 4. All moveable equipment such as hardware devices, laptops, and key material is secured from unauthorized access when not in use. 5. A detailed runbook defines all steps performed during the key material generation process. After the completion of each step, the participating actors sign off in the runbook stating that the step was performed and checked. 6. All roles participating in the key material generation process must be defined and utilized. Segregation of duties must be considered when allocating personnel to roles. 7. Each actor involved in the key material generation process must independently generate their own discrete key material. In a multi-signer scheme, no single actor is permitted to generate key material that will be used by another actor unless the actor is an automated signing agent. (Refer to requirements 1.01.1.1 and 1.01.1.2.) | The key material generation process is documented to include key tasks and roles for ensuring that a key is generated in a secure environment, free from unauthorized surveillance, using trusted equipment, and reducing the possibility of malicious actors controlling the process. | ||||
| 1.01.4 Entropy Pool | 1.01.4.1 Key material is generated on a Key Management System with sufficient entropy to ensure key material is not generated with any bias towards a reduced range of values, or other deterministic properties. | This is to create key material in an unguessable and unrepeatable manner. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.02 Wallet Generation | This aspect covers the generation of wallets or addresses that can receive digital assets. Wallets are generated using cryptographic signing methodologies that can support single-signer and multi-signer mechanisms. Furthermore, wallets can be generated individually (commonly referred to as “Just a Bunch Of Keys” or JBOK wallets) or in a deterministic way that allows a set of addresses/key pairs to be generated from a single master seed. Security of wallet generation is derived from the integrity of the wallet in the face of various risks such as a lost/stolen/compromised key material and the confidentiality of the wallet that would make it difficult to associate a wallet with a particular actor. | 1.02.1 Signing Configuration | Not required for level 1. | Not required for level 1. | 1.02.1.1 When considering the application of a single-signer mechanism to a wallet, the following criteria are addressed: 1. The criticality of the wallet to the CCSS Trusted Environment. 2. The impact of loss of customer funds controlled by the wallet. 3. The risk of a wallet compromise is included in the threat model defined in requirement 2.03.2.1. 4. The effectiveness of the security controls implemented to protect the wallet. | Applying a multi-signer mechanism to a wallet is considered best practice and implemented where appropriate. While considered best practice, implementing a multi-signer mechanism to a wallet can impact the speed at which funds can be managed. Implementing a single-signer mechanism to a wallet is often implemented by full custody providers because it provides efficient and expeditious functions to manage the funds. However, wallets that manage the bulk of customer's funds must implement a multi-signer mechanism. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 1.02.2 Key Material Redundancy | Not required for level 1. | Not required for level 1. | 1.02.2.1 A wallet that has implemented a multi-signer mechanism has at least one redundant key for recovery purposes. | This ensures that the funds are still available in the event one of the operational keys becomes inaccessible for any reason. One common method of achieving this goal is to create a wallet that requires any 2 of 3 possible signatures in order to spend funds (i.e., there is 1 redundant key) | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.02.3 Geographic Key Material Distribution | Not required for level 1. | Not required for level 1. | 1.02.3.1 Key materials for a wallet that implements a multi-signature mechanism are stored in different locations. | By separating key material for a wallet that implements a multi-signer mechanism across multiple locations, the risks associated with localized disruptions to business (e.g., fire, flood, earthquake, break-ins) do not affect the entity's ability to spend funds. Locations could be in the same city, region or country. However, it is recommended that a risk assessment be undertaken to identify the risks of storing key material for a single wallet that implements a multi-signer mechanism in the same city, region or country. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.02.4 Entity Key Material Distribution | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.02.4.1 Key material for a wallet that implements a multi-signer mechanism is stored by distinct operators within the entity or separate entities. | By giving key material to separate business units and legal entities (such as lawyers, accountants, or other businesses), legal risks that can disrupt your business will not necessarily disrupt your funds. Note that this does not violate requirement 1.01.1.1, as the separate entities fail to meet the definition of an actor. | |||
| 1.02.5 Wallet Generation Policy Documentation | Not required for level 1. | Not required for level 1. | 1.02.5.1 The entity has a documented policy in place which details the company’s internal policies and procedures and covers the relevant areas of wallet generation. | A documented custody policy provides transparent consistency and limits errors. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.03 Key Material storage | This aspect covers the separation of the wallet’s Key Material across multiple locations, ensuring that the risks associated with localized disruptions (e.g., fire, flood, earthquake, break-ins) do not compromise the entity's ability to access or spend funds. | 1.03.1 Encryption of Operational Key Material | 1.03.1.1 Key material is stored with the use of strong encryption when not in use. | Strong encryption provides key material security. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 1.03.2 Key Material Backup(s) | 1.03.2.1 A backup(s) of the operational key material exists. | A backup(s) of the operational key material reduces risk of key material loss. | 1.03.2.2 A backup(s) exists for all key material used in the wallet. The backup can take any form (e.g., paper, digital, metal). | A backup(s) of the key material used in the wallet reduces the risk of inability to access assets. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.03.3 Environmental Protection for Key Material Backup(s) | 1.03.3.1 The backup(s) is protected against environmental risks. | Protection against environmental risks reduce likelihood of key material loss. Common methods to achieve this include a water-tight bag for flood protection and a safe or firebox for fire protection. Specific mechanisms of environmental protection may change depending on the type of medium used for backup. | 1.03.3.2 The backup(s) of key material is stored in a geographically separate location(s) from the storage and usage of operational key material. | Protection against environmental risks reduce likelihood of Key Material loss. Environmental risks include but are not limited to fire, flood, earthquake, and electrical surges. Common methods to achieve risk reduction include a water-tight bag for flood protection and a safe or firebox for fire protection. Specific mechanisms of environmental protection may change depending on the type of medium used for backup(s). | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.03.4 Key Material Backup(s) Have Access Control | 1.03.4.1 The backup(s) is protected by access controls that prevent unauthorized parties from accessing it. | Access-controlled protection reduces risk of unauthorized use of backup key material. Examples of this include safes, safe deposit boxes, or locked drawers where only the operator holds the key/combination for the lock. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.03.5 Tamper-evident Key Material Backup(s) | Not required for level 1. | Not required for level 1. | 1.03.5.1 The backup(s) implements some form of tamper-evident mechanism that allows an operator to determine if it has been accessed. | Reduces risk of backup(s) Key Material compromise. For physical backups, a secure method of achieving this involves a serial-numbered tamper-evident bag; however, properly sealed paper envelopes with handwritten signatures over the seal could also suffice, provided the specific envelopes in use are able to reveal evidence of tampering. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.03.6 Key Material Backup(s) Encryption | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.03.6.1 Backups of key material are stored with the use of strong encryption that is equal or greater to the security prescribed for the operational key material. | Storing backups with strong encryption increases security. | |||
| 1.04 Key Material Access | This aspect covers the policies and procedures surrounding granting and revoking access to key material. Personnel typically have greater access to the CCSS Trusted Environment with respect to accessing its information, invoking privilege-restricted actions, and representing the entity to the public. Improper management of the onboarding and offboarding of personnel introduces risks of privileged accounts remaining when personnel depart, as well as unrevoked key material that persists in signing authority for certain transactions. | 1.04.1 Grant/Revoke Documentation | 1.04.1.1 The entity maintains checklists that cover all tasks that are completed when personnel vacate or transition into key holder roles within the entity. These checklists have been reviewed by knowledgeable personnel to ensure “least privilege principles” are applied to the system, as well as necessary access where required. | This reduces the risks associated with missed privileges and the possession of un-revoked Key Material. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 1.04.2 Approved Communication Channel | Not required for level 1. | Not required for level 1. | 1.04.2.1 All key holder grant/revoke requests are conducted over Approved Communication Channels. | This provides high confidence of the identities of the communicating parties. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.04.3 Grant/Revoke Audit Trail | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.04.3.1 The entity's checklists include auditing information that record the identity of personnel that perform the grant/revoke operations. Each entry within the audit trail is attested to by personnel who performed that task. | Documentation of the checklists and audit trail further verifies identities and ensures grant/revoke processes are completed. | |||
| 1.05 Key Material Usage | This aspect covers the secure use of key material that minimizes the risks to the confidentiality of key material and the integrity of funds. This section does not cover the usage of key material backup(s) which are only used in the event operational key material is lost/damaged/inaccessible. A variety of risks are present when using key material that can lead to the loss of funds, including dirty signature vulnerabilities (i.e. re-used ‘R’ values), the opportunity for malware to copy or modify key material, and malicious insiders who use their authorized access to send unauthorized transactions. | 1.05.1 Access Authentication to Key Material | 1.05.1.1 Access to the operational key material requires an identifier and at least 2 (two) distinct types of authentication factors. | Multi-factor authentication restricts access and thus increases security. Examples of identifiers are username, email, GUID, etc. Examples of additional factors of authentication include Google Authenticator tokens, digital signatures from a private key, in-person ID verification, possession of a physical key or token, or a countersigning entity who can remotely attest to the authenticity of the key holder. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.05.1.2 Access to Key Material requires an identifier (e.g., username, email, GUID) and at least 3 (three) distinct types of authentication factors. | Additional factors of authentication restricts access and increases security. Similar to the requirement of 2 (two) additional factors in Level I, the other 3 (three) factors of authentication in Level III can take any form that provides confirmation of an authorized user’s identity. | |
| 1.05.2 Operational Key Material Environment | 1.05.2.1 Key material is only used within the CCSS Trusted Environment. | This decreases/reduces the risk of unauthorized copies being made by malware, as well as mitigating the risk of storing (even inadvertently) key material on a machine, allowing it to be recovered by another user or intruder. The CCSS Trusted Environment guards against unauthorized access to key material, passwords, or other sensitive information. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.2.2 The key material is isolated from other operating systems and application processes to avoid unauthorized access or leakage of key material. | Isolating operations involving key material such as signing transactions from other operating system and application processes ensures no compromised operating system or application process can impact the security of key operations. Use of Hardware Security Modules (HSM) and Trusted Execution Environments (TEE) are examples of mechanisms that isolate Key operations from other system processes. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.05.2.3 The key material is isolated from other operating system and application processes to avoid unauthorized access or leakage of key material. CCSS Level 3 requires FIPS 140 or equivalent. | Isolating operations involving key material such as signing transactions from other operating system and application processes ensures no compromised operating system or application process can impact the security of key management operations. Use of Hardware Security Modules (HSM) and Trusted Execution Environments (TEE) are examples of mechanisms that isolate key operations from other system processes. | ||||
| 1.05.3 Operator Reference Checks | 1.05.3.1 All individual actors involved in operations with key material, or with the ability to impact the security of key generation, management, or usage have had their references checked prior to the actor being trusted with access to key material or operations. | This helps ensure the person is being truthful about their past and were not dismissed from prior employment for reasons that would represent a risk to the entity. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.4 Operator ID Checks | 1.05.4.1 All actors involved in operations with key material, or with the ability to impact the security of key generation, management, usage, or storage have undergone identity verification to ensure they are who they say they are. These checks are conducted prior to the actor being trusted with access to key material. | This reduces the risks associated with impersonation and social engineering attacks which may result in access to entity or customer funds. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.5 Operator Background Checks | 1.05.5.1 All individual actors involved in operations with key material, or with the ability to impact the security of key generation, management, usage, or storage have had background checks performed by law enforcement personnel or investigative firms. These checks are conducted prior to the actor being trusted with access to key material or operations and periodically; as allowed by local laws and regulations. | This verifies that each key holder's identity has been confirmed and that their background shows no evidence of risk to the entity, if they held signing authority over the entity’s or users’ funds. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.6 Key Management Training | 1.05.6.1 All individuals involved in key management operations, or with the ability to impact the security of Key Material, complete specific applicable training. This training is to be conducted on hire, and conducted before the actor being trusted with access to Key Material, and then annually. | All individuals involved in key management operations includes key holders, operators, or other actors. This is in addition to any general security training required of all personnel, and should include any appropriate threats, risks, and controls related to the CCSS. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.7 Key Management Responsibilities | 1.05.7.1 Key management roles and responsibilities are formally acknowledged in writing by each person who has access to key material. This includes personnel who have been delegated key management responsibilities. | Any person who has access to key material must formally define and acknowledge their roles and responsibilities in writing. This ensures that each person with access to Key Material understands their roles and responsibilities to protect key material from unauthorized access and use. If a role or responsibility for key material is delegated to another person, then the person who has been delegated part or all of the roles and responsibilities also formally acknowledges their key management responsibilities. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.8 Spend Verification | Not required for level 1. | Not required for level 1. | 1.05.8.1 Verification of fund destinations and amounts is performed via Approved Communication Channels prior to the use of key material. | This verifies that fund destinations and amounts are accurate prior to sending funds. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.9 Multi-Signer Mechanism Usage | 1.05.9.1 Key material for a wallet that implements a multi-signer mechanism is stored and used on different logical or physical devices. | Storing key material for the same wallet that implements a multi-signer mechanism on the same logical or physical device exposes the key material to information leakage by either a malicious actor or malicious software. Ensuring each piece of key material of a wallet is stored and used on different logical or physical devices reduces these risks, thereby increasing security. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.05.10 Deterministic Random Bit Generator (DRBG) Compliance | 1.05.10.1 Digital signatures follow best practices for the algorithm(s) implemented by the Key Management System. | This ensures that all signing operations are performed correctly and that critical values used by the algorithm are unpredictable, preserving the integrity and security of the signatures. For example, in DSA, the 'k' value must be generated securely. Compliance can be achieved through the use of a deterministic random bit generator (DRBG) compliant with NIST SP 800-90A, a deterministic scheme compatible with RFC 6979, or other mechanisms that align with cryptographic best practices for the algorithm(s) used by the Key Management System. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 1.06 Data Sanitization Documentation | This aspect covers the removal of key material from digital media. Due to the manner in which file systems allocate data on digital media, digital forensic techniques can be employed to read old data that has previously been sanitized. Proper sanitization of digital media ensures the proper removal of all key material, eliminating the risk of information leakage from decommissioned devices like servers, hard disk drives, and removable storage. | 1.06.1 Data Sanitization Policy Existence | 1.06.1.1 Policy and procedure document(s) exist that conform to NIST 800-88 by defining the requirements for sanitizing and the destruction of media that holds key material. The policy and procedure documentation is read/understood by all staff who have access to key material. | Implementation of a detailed policy of digital sanitization and physical destruction reduces error and the risk of information leakage. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 1.06.2 Media Sanitization Audit Documentation | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 1.06.2.1 An audit trail is maintained for every piece of sanitized media conforming to the NIST SP 800-88 recommendation. These audit documents identify personnel who performed the sanitization, the specific identifiers of the media that was sanitized, which tool and configuration was used to perform the sanitization, and all other relevant pertinent information. | An audit trail provides evidence of media sanitization being performed. | |||
| Operations | 2.01 Security Tests/ Audits | This aspect covers third-party reviews of the security systems, technical controls, and policies that protect the CCSS Trusted Environment from all forms of risk as well as vulnerability and penetration tests designed to identify paths around existing controls. Regardless of the technical skills, knowledge, and experience of personnel who build and maintain the CCSS Trusted Environment, it has been proven that third-person reviews often identify risks and control deficiencies that were either overlooked or underestimated by personnel. For the same reasons that development companies require different people to test a product from those who write it, different people than those who implement a cryptocurrency system should assess its security. Third parties provide a different viewpoint and are independent of the technical controls and can be objective without risk of retaliation. | 2.01.1 Security Development and Documentation | 2.01.1.1 An individual with expertise in information security must be engaged in all stages of the design, development, deployment, and ongoing maintenance of systems providing cryptocurrency functions. This ensures that information security principles are integrated into every phase of the system's lifecycle. | Information security must be considered in all aspects of the CCSS Trusted Environment, from initial concept to design, development, testing, deployment, and ongoing maintenance of the CCSS Trusted Environment's people, processes and technology components. Attempting to implement security controls once the system is in production is not recommended and is seldom effective. | 2.01.1.2 A regular security assessment that includes vulnerability and penetration testing has been completed by an independent, qualified third-party. Documentation shows that all concerns raised by the assessment have been evaluated for risk and addressed by the entity. | Security audits, in addition to regular vulnerability and penetration tests, not only reduce the risks of unknown deficiencies in security but also reduce the overall cost of security as each audit builds on top of the last one’s results, allowing for a more focused and cost-effective assessment. Vulnerability and penetration tests decrease the risks associated with institutional blindness and provide confidence in the entity's controls and procedures. | 2.01.1.3 A regular security audit at a level similar to SOC 2, ISAE3402, or ISO 27001, that includes vulnerability, penetration testing, and code audit (if applicable) has been completed by an independent qualified third-party. Documentation shows that all concerns raised by the audit have been evaluated for risk, addressed by the entity, and known vulnerabilities have been removed from the CCSS Trusted Environment. Ongoing audits are scheduled on a (minimum) yearly basis. | Security audits, in addition to regular vulnerability and penetration tests, not only reduce the risks of unknown deficiencies in security but also reduce the overall cost of security as each audit builds on top of the last one’s results, allowing for a more focused and cost-effective assessment. Vulnerability and penetration tests decrease the risks associated with institutional blindness and provide confidence in the entity's controls and procedures. Completing these regularly increases security. |
| 2.01.2 Smart contract software code audit documentation | 2.01.2.1 All smart contract software code versions deployed to the environment(s) where the entity stakeholders interact with the smart contract have been audited by an external third-party auditor skilled in the development languages used for the smart contract software. NOTE: the requirement is not applicable to any environments used for development, testing, or staging. This requirement applies to smart contracts deployed to the "production" network or the like. | It is well documented that many breaches of cryptocurrency platforms occur through a smart contract due to poor secure coding techniques. By ensuring the smart contract software code is audited by an external third party skilled in the development languages used, the risk of an exploitable vulnerability is reduced. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 2.01.2.2 All smart contract software code audit reports are accessible to the entity stakeholders. The audit reports cover the currently deployed versions to the environment(s) where the entity stakeholders interact with the smart contract. NOTE: the requirement is not applicable to any environments used for development, testing, or staging. This requirement applies to smart contracts deployed to the "production" network or the like. | A common issue is that a particular version of the code is audited by an external third-party auditor who approves the code, and the audit report is published, providing assurance to the stakeholders that the smart contract code has passed the audit. However, a newer version of the smart contract is deployed without being audited and may have unidentified vulnerabilities. This action causes a false sense of security for the entity stakeholders. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | ||||
| 2.01.2.3 All issues with a severity of medium or higher identified in a code audit of the smart contract software are addressed by the entity before deployment to the environment(s) where the entity stakeholders interact with the smart contract. NOTE: the requirement is not applicable to any environments used for development, testing, or staging. This requirement applies to smart contracts deployed to the "production" network or the like. | It is not recommended that a smart contract with known vulnerabilities be deployed and remediation completed after deployment. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | ||||
| 2.02 Log and Monitor | This aspect covers monitoring the CCSS Trusted Environment's technical components audit logs for suspicious activity. When suspicious activity is identified, alerts must be generated so that personnel can triage and respond to the event to detect and respond to suspicious activity proactively. | 2.02.1 Application Audit Logs | 2.02.1.1 Audit trails exist for a subset of actions performed within the CCSS Trusted Environment. | Audit trails reduce the risks associated with operational awareness and increase the CCSS Trusted Environment's technical component's ability to correct any inaccuracies. Examples of this would include recording transaction information generated by the Trusted Environment. | 2.02.1.2 All actions performed by all users within the CCSS Trusted Environment are logged. Audit logs are retained for at least one year in a trusted environment. | These records provide significant assistance to investigations into unexpected behavior of the CCSS Trusted Environment's technical components and can help identify malicious actors and responsible technical components or persons. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 2.02.2 Audit Log Backup | Not required for level 1. | Not required for level 1. | 2.02.2.1 In addition to recording all actions performed within the CCSS Trusted Environment, this audit information is periodically backed up to a separate server. | This action helps preserve valuable investigative information in the event the audit log is altered or destroyed during an attack on the CCSS Trusted Environment. | 2.02.2.2 In addition to recording all actions performed within the CCSS Trusted Environment, this audit information is continually backed up to a separate server. | This action helps further preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the CCSS Trusted Environment. | |||
| 2.02.3 Audit Log Monitoring | 2.02.3.1 The CCSS Trusted Environment's audit logs are monitored for suspicious activity, and alerts are generated when suspicious activity is detected. Appropriate personnel address the alerts generated. The monitoring frequency is defined by the entity and meets all components of requirement 2.03.2.1. | Audit logs are only useful for detecting suspicious activity if they are monitored and alerts are generated for personnel to respond. | 2.02.3.2 The CCSS Trusted Environment's audit logs are continuously monitored for suspicious activity, and alerts are generated in real time when suspicious activity is detected. Appropriate personnel address the alerts generated. | By monitoring audit logs continuously and generating alerts in real time, possible threats can be detected immediately and responded to, reducing the impact of a threat to the CCSS Trusted Environment. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 2.02.4 Blockchain State Monitoring | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 2.02.4.1 Relevant blockchain state (confirmed and unconfirmed) as it relates to the CCSS Trusted Environment are continuously monitored for anomalous behavior, generating alerts. Appropriate personnel address the alerts that are generated. | By monitoring blockchain state for anomalous behavior, the entity has a good chance to detect and respond to incidents quickly, thereby reducing the impact of an attack. | |||
| 2.03 Governance and Risk | This aspect covers the governance policies, standards, and procedures that guide and control an entity to ensure its CCSS Trusted Environment is effective, efficient, and secure. It also includes the requirements for a comprehensive risk management program to identify potential risks to the CCSS Trusted Environment and apply appropriate risk treatments. | 2.03.1 Governance | 2.03.1.1 A member of executive management is responsible for the security of the system and formally acknowledges their responsibilities in writing. | Executive management establishes the security vision and strategy for the system by ensuring policies are in place, resources are properly allocated to the system's security, security awareness is promoted throughout the entity, and continuous improvement of the system's security is driven. An executive member is always assigned to this role. For instance, if the assigned executive cannot fulfil the role due to extended leave or termination of employment, another executive must take over the role immediately. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 2.03.2 Risk Management | 2.03.2.1 The entity has identified security threats to the CCSS Trusted Environment and have defined and implemented controls to reduce the residual risk of an attack to an acceptable level using a threat model. The following considerations are addressed: 1. The entity reviews the threat model periodically to ensure it is up-to-date, the controls currently implemented are still effective, and the risk of an attack is reduced. 2. If a procedure requires a defined frequency to perform tasks for a control, such as reviewing audit logs, the threat model specifies the task frequency. | Unless the entity identifies security threats, e.g., those who wish to harm the CCSS Trusted Environment, it cannot fully protect the CCSS Trusted Environment against threats. | 2.03.2.2 The entity implements a risk management program based on industry recognized risk management standards and frameworks such as ISO/IEC 27005 and NIST SP 800-37. | Utilizing an industry-recognised risk management program ensures the entity is using best practices to manage risk for the CCSS Trusted Environment. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 2.03.3 Service Provider Management | 2.03.3.1 Service provider management is implemented for any vendor or service provider that could impact the security of the CCSS Trusted Environment and addresses: 1. Procurement processes to ensure any vendor or service provider meets applicable CCSS requirements before contractual engagement. 2. Annual review of the vendor or service provider's compliance with applicable CCSS requirements. The frequency of review may increase from at least annually based on the entity threat model as defined in requirement 2.03.2.1. | Before a service provider is granted access to key material or has access to the CCSS Trusted Environment, the entity undertakes a due diligence process to ensure the service provider's security posture meets the entity's security policy and procedures requirements. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |||
| 2.04 Key Compromise Documentation | This aspect covers the existence and use of documented policies and procedures that define the actions that must be taken in the event key material or its operator/holder are believed to have become compromised. Entities must be prepared to deal with a situation where key material has – even potentially – become known, determinable, or destroyed. Policies and procedures to govern these events decrease the risks associated with lost funds and increase the availability of the system to its users. Examples of when a Key Compromise Policy (KCP) would be invoked include the identification of tampering of a tamper-evident seal placed on the media that stores 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 material is likely at risk of being compromised. The execution of KCP must make use of Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors. | 2.04.1 Key Compromise Policy Existence | 2.04.1.1 An inventory of all key material exists and the entity has an awareness of which key material is critical to the successful operation of the CCSS Trusted Environment. | This decreases the risks associated with lost funds. | 2.04.1.3 The key material inventory is reviewed at least annually to ensure that all key material has been recorded and that the recorded information for key material is accurate and up-to-date. | The key material inventory must be kept updated to ensure that all records of key material is accurate and up-to-date. An accurate key material inventory is vital when dealing with an incident involving key material as it provides the incident response personnel with critical information to assess the impact of a breach involving key material. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | |
| 2.04.1.2 A Key Compromise Policy and procedures are documented that detail: each specific classification of key material used throughout the CCSS Trusted Environment; 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. | This further decreases the risks associated with lost funds. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 2. | There are no additional requirements beyond those specified for Level 2. | ||||
| 2.04.2 Key Compromise Policy Training and Rehearsals | Not required for level 1. | Not required for level 1. | There are no additional requirements beyond those specified for Level 1. | There are no additional requirements beyond those specified for Level 1. | 2.04.2.1 The Key Compromise Policy and procedures are tested at least annually to ensure their viability and to ensure personnel remain trained to use them in the event of a compromise. The following is addressed: 1. The testing exercise is documented and includes the attendees, scenarios tested, outcomes of testing, remediation required, actions, and the next testing date. 2. Any improvements identified from the test are updated in the Key Compromise Policy and procedures. 3. The testing includes ensuring backup(s) containing key material are reviewed and tested where applicable. 4. Any changes to the system's people, processes, and technology components trigger a test of the Key Compromise Policy and procedures. | This ensures that any potentially compromised key material is quickly and efficiently handled. The frequency of testing may increase from at least annually based on the entity threat model as defined in requirement 2.03.2.1. | |||
| CCSS Matrix Version 9 |