CCSS Details

Table of Contents

CCSS Version 8.1

CCSS Matrix Version 8.1

Category

Cryptographic Asset Management

Aspect

1.01 Key/Seed Generation

Aspect Objective
This aspect covers the generation of cryptographic keys and seeds that will be used within a digital asset and blockchain protocol. The secure creation of cryptographic keys and seeds requires two things to be secure: confidentiality and unpredictable numbers. Confidentiality is required to ensure that the newly created keys or seeds are not read/copied by an unintended party. Nondeterministic and unpredictable numbers are required to ensure the newly created key cannot be guessed or determined by an unintended party. Each of the goals listed provide assurance that the keys and/or seeds are created in a confidential and un-guessable manner.
Aspect Control
1.01.1 Operator-created Key / Seed

Level I

1.01.1.1

Requirement
1.01.1.1 The cryptographic keys and seeds are created by the actor who will be using it.
Rationale
This is an attempt to protect the confidentiality of the key. Any system that requires one actor to transfer a key or seed 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.2

Requirement
1.01.1.2 In cases where an automated agent will make use of a cryptographic key/seed, it is required that the administrator of that system generate the key/seed on a suitable offline system with sufficient entropy, have this key/seed transferred securely onto the target device, and then securely deleted using CCSS-compliant data sanitization techniques to protect the confidentiality of the key/seed.
Rationale
This is an attempt to protect the confidentiality of the key for any system using an automated signing agent.
Aspect Control
1.01.1 Operator-created Key / Seed

Level II

1.01.1.3

Requirement
1.01.1.3 A digital signature for the key creation software is generated, published, and validated prior to each execution.
Rationale
This ensures the software has not been altered.

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.01.2 Creation methodology is validated

Level I

NOTHING REQUIRED FOR LEVEL I

Aspect Control
1.01.2 Creation methodology is validated

Level II

1.01.2.1

Requirement
1.01.2.1 The key or seed generation methodology 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 (e.g. DRBGs)
Rationale
Features that restrict the entropy of seed generation and don't protect the transmission of data result in decreased security.

1.01.2.2

Requirement
1.01.2.2 In cases where keys or seeds are created without the use of software (e.g., dice, a deck of cards, or other non-digital source of entropy), the creation methodology must be validated to ensure determinism is not present (e.g., there are no weighted dice, each card in the deck is unique).
Rationale
Features that restrict the entropy of seed generation result in decreased security.

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.01.3 DRBG Compliance

Level I

NOTHING REQUIRED FOR LEVEL I

Aspect Control
1.01.3 DRBG Compliance

Level II

NOTHING REQUIRED FOR LEVEL II

Aspect Control
1.01.3 DRBG Compliance

Level III

1.01.3.1

Requirement
1.01.3.1 The key or seed is generated using either a 1) Deterministic Random Bit Generator (DRBG) that conforms to NIST SP 800-90A, and has been seeded with at least two separate cryptographically secure sources of entropy that have been combined in a cryptographically secure manner (e.g., SHA256[UnguessableFactor1 + UnguessableFactor2]) or 2) a Non-deterministic Random Bit Generator (NRBG), or a “True Random Number Generator” (TRNG) that passes industry-standard statistical tests for randomness such as DIEHARD, Crypt-X, or NIST STS. The Dual_EC DRBG has been demonstrated to be vulnerable and thus must not be used.
Rationale
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.

1.01.3.2

Requirement
1.01.3.2 The key/seed generation process has been documented including a detailed run book showing all steps performed and signed-off by different parties that each procedure was performed and checked. The documentation shows clear segregation of duties and/or the presence of an independent third party to observe and validate the procedures.
Rationale
Documentation and sign-off of the key/seed generation process ensures consistency in the process and segregation of duties and/or the presence of an independent third party to observe and validate the procedures prevents an individual from manipulating the process.
Aspect Control
1.01.4 Entropy Pool

Level I

1.01.4.1

Requirement
1.01.4.1 The cryptographic keys and seeds are created on a system with sufficient entropy to ensure the keys are not created with any bias towards a reduced range of values, or other deterministic properties.
Rationale
This is to create seeds in an unguessable and unrepeatable manner.

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect

1.02 Wallet Creation

Aspect Objective
This aspect covers the creation of wallets or addresses that can receive digital assets. Wallets are created using key signing methodologies that can require a single key’s signature, multiple keys’ signatures, or a minimum number of signatures from many keys. Furthermore, wallets can be created individually (commonly referred to as JBOK wallets, or “Just a Bunch Of Keys”) or in a deterministic way that allows a set of addresses/key pairs to be created from a single master seed. Security of wallet creation is derived from the integrity of the wallet in the face of various risks such as a lost/stolen/compromised key, and the confidentiality of the wallet that would make it difficult to associate a wallet with a particular actor.
Aspect Control
1.02.1 Multiple keys for signing

Level I

1.02.1.1

Requirement
Not required for level I
Rationale
Not required for level I
Aspect Control
1.02.1 Multiple keys for signing

Level II

1.02.1.2

Requirement
1.02.1.1 Any address generated by a wallet must require a minimum of 2 signatures (commonly referred to as a multi-sig wallet) in order to spend funds, where a separate actor holds each signing key. The actors can either be human or system (i.e. two humans, two systems, or one human and one system) but must be separate entities that each manage their own key for the wallet.
Rationale
Requiring 2 or more signatures on a wallet increases the integrity of funds by reducing the risk of theft associated with a compromised key or key holder.
Aspect Control
1.02.1 Multiple keys for signing

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.02.2 Redundant key for recovery

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.02.2 Redundant key for recovery

Level II

1.02.2.1

Requirement
1.02.2.1 Redundant keys are assigned to each wallet for recovery purposes.
Rationale
This ensures that the funds are still available in the event one of the primary 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)
Aspect Control
1.02.2 Redundant key for recovery

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.02.3 Geographic distribution of keys

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.02.3 Geographic distribution of keys

Level II

1.02.3.1

Requirement
1.02.3.1 Any keys that have signing authority on a single wallet must be stored in different locations.
Rationale
By separating the wallet’s keys across multiple locations, the risks associated with localized disruptions to business (e.g., fire, flood, earthquake, break-ins) do not affect the organization’s ability to spend funds.
Aspect Control
1.02.3 Geographic distribution of keys

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.02.4 Organizational distribution of keys

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.02.4 Organizational distribution of keys

NO ADDITIONAL REQUIREMENTS FOR LEVEL II

Aspect Control
1.02.4 Organizational distribution of keys

Level III

1.02.4.1

Requirement
1.02.4.1 Any keys that have signing authority on a single wallet must be stored by multiple organizational entities/business units.
Rationale
By giving keys 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 the Key/Seed Generation Level I requirement, as the separate organizations fail to meet the definition of an actor.
Aspect Control
1.02.5 Documented wallet creation policy

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.02.5 Documented wallet creation policy

Level II

1.02.5.1

Requirement
1.02.5.1 The organization has a documented custody policy in place which details the company’s internal policies and procedures and covers the relevant areas of wallet creation.
Rationale
A documented custody policy provides transparent consistency and limits errors.
Aspect Control
1.02.5 Documented wallet creation policy

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect

1.03 Key Storage

Aspect Objective
By separating the wallet’s keys across multiple locations, the risks associated with localized disruptions to business (e.g., fire, flood, earthquake, break-ins) do not affect the organization’s ability to spend funds.
Aspect Control
1.03.1 Primary keys are stored encrypted

Level I

1.03.1.1

Requirement
1.03.1.1 Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use.
Rationale
Strong encryption provides key security.
Aspect Control
1.03.1 Primary keys are stored encrypted

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.03.2 Backup key exists

Level I

1.03.2.1

Requirement
1.03.2.1 A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital).
Rationale
A backup of the key/seed reduces risk of key/seed loss.
Aspect Control
1.03.2 Backup key exists

Level II

1.03.2.2

Requirement
1.03.2.2 A backup must exist for at least as many keys as are required to spend funds.
Rationale
A backup of as many key/seed as is required to spend funds reduces risk of inability to access assets. For example, in a 2-of-3 signing setup where any two of three keys are required to spend funds, backups must exist for at least 2 of these keys. In a 5-of-9 setup, backups must exist for at least 5 keys.
Aspect Control
1.03.2 Backup key exists

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.03.3 Backup key has environmental protection

Level I

1.03.3.1

Requirement
1.03.3.1 The backup must be protected against environmental risks such as fire, flood, and other acts of God.
Rationale
Protection against environmental risks reduce likelihood of key/seed 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.
Aspect Control
1.03.3 Backup key has environmental protection

Level II

1.03.3.2

Requirement
1.03.3.2 The backup key/seed must be stored in a location that is geographically separate from the usage location of the primary key/seed. For example, if the primary key is kept at an office, the backup key could be in escrow with a trusted 3rd party.
Rationale
Further reduces risk of backup key/seed loss.
Aspect Control
1.03.3 Backup key has environmental protection

Level III

1.03.3.3

Requirement
1.03.3.3 Backups are resistant to electromagnetic pulses that could induce currents in electronics and damage the data stored within.
Rationale
Resistance to devices from outside signals prevents data from being altered and reduces risk of backup key/seed manipulation. A common methodology to secure against this risk is to store a seed or key on paper, wood, metal, or on another non-digital medium, or to place the digital medium within a sealed faraday bag designed to protect contents from electro-magnetic interference.
Aspect Control
1.03.4 Backup key is access-controlled

Level I

1.03.4.1

Requirement
1.03.4.1 The backup must be protected by access controls that prevent unauthorized parties from accessing it.
Rationale
Access-controlled protection reduces risk of unauthorized use of backup key. Examples of this include safes, safe deposit boxes, or locked drawers where only the operator holds the key/combination for the lock.
Aspect Control
1.03.4 Backup key is access-controlled

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.03.5 Backup key has tamper-evident seal

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.03.5 Backup key has tamper-evident seal

Level II

1.03.5.1

Requirement
1.03.5.1 The backup must employ some form of tamper evident mechanism that allows an operator to determine if it has been accessed.
Rationale
Reduces risk of backup key/seed compromise. 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.
Aspect Control
1.03.5 Backup key has tamper-evident seal

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.03.6 Backup key is encrypted

NO ADDITIONAL REQUIREMENTS FOR LEVEL I or II

Aspect Control
1.03.6 Backup key is encrypted

Level III

1.03.6.1

Requirement
1.03.6.1 Backups of cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use that is at least equal to the security prescribed for cryptographic keys/seeds above.
Rationale
Storing backups with strong encryption increases security.
Aspect

1.04 Key Usage

Aspect Objective
This aspect covers the use of cryptographic keys and/or seeds to ensure they are used in a secure manner that minimizes the risks to the confidentiality of private keys and integrity of funds. This section does not cover the usage of key backups which are only used in the event the primary key is lost/damaged/inaccessible. A variety of risks are present when using keys that can lead to the loss of funds including dirty signature vulnerabilities (i.e. re-used ‘R’ values), opportunity for malware to copy or modify keys, and malicious insiders who use their authorized access to send unauthorized transactions.
Aspect Control
1.04.1 Key access requires user/pass/nth factor

Level I

1.04.1.1

Requirement
1.04.1.1 Access to the primary key/seed requires an identifier (e.g. username, email, GUID, etc.) and at least 2 (two) other factors of authentication, which restricts access to the authorized operator.
Rationale
Multi-factor authentication restricts access and thus increases security. 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 organization who can remotely attest to the authenticity of the key holder.
Aspect Control
1.04.1 Key access requires user/pass/nth factor

NO ADDITIONAL REQUIREMENTS FOR LEVEL II

Aspect Control
1.04.1 Key access requires user/pass/nth factor

Level III

1.04.1.2

Requirement
1.04.1.2 Access to the key/seed requires an identifier (e.g., username, email, GUID) and at least 3 (three) other factors of authentication.
Rationale
Additional factors of authentication restricts access and increases security. Similar to the requirement of 2 additional factors in Level I, the other 3 factors of authentication in Level III can take any form that provides confirmation of an authorized user’s identity.
Aspect Control
1.04.2 Keys are only used in a trusted environment

Level I

1.04.2.1

Requirement
1.04.2.1 All keys/seeds are only used in trusted environments.
Rationale
This decreases/reduces the risk of unauthorized copies being made by malware, as well as mitigating the risk of storing (even inadvertently) a key on a machine, allowing it to be recovered by another user or intruder. An effective trusted environment guards against unauthorized persons learning private keys, passwords, or other sensitive information.
Aspect Control
1.04.2 Keys are only used in a trusted environment

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.04.3 Operator reference checks

Level I

1.04.3.1

Requirement
1.04.3.1 All key/seed holders have had their references checked prior to being trusted to hold one of the organization’s keys/seeds.
Rationale
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 organization.
Aspect Control
1.04.3 Operator reference checks

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.04.4 Operator ID checks

Level I

1.04.4.1

Requirement
1.04.4.1 All key/seed holders (individuals and organizations) have undergone identity verification to ensure they are who they say they are.
Rationale
This reduces the risks associated with impersonation and social engineering attacks which may result in access to organizational or customer funds.
Aspect Control
1.04.4 Operator ID checks

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.04.5 Operator background checks

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.04.5 Operator background checks

NO ADDITIONAL REQUIREMENTS FOR LEVEL II

Aspect Control
1.04.5 Operator background checks

Level III

1.04.5.1

Requirement
1.04.5.1 All individual key/seed holders have had background checks performed by law enforcement personnel or investigative firms.
Rationale
This verifies that each key/seed holder is who they say they are and does not have evidence in their past of actions that would represent a risk to the organization if they had signing authority on organization or user funds.
Aspect Control
1.04.6 Spends are verified before signing

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.04.6 Spends are verified before signing

Level II

1.04.6.1

Requirement
1.04.6.1 Verification of fund destinations and amounts is performed via Approved Communication Channels prior to key/seed use.
Rationale
This verifies that fund destinations and amounts are accurate prior to sending funds.
Aspect Control
1.04.6 Spends are verified before signing

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.04.7 No two keys are used on one device

Level I

1.04.7.1

Requirement
1.04.7.1 No two master keys/seeds of the same multi-signature wallet are ever present on the same device.
Rationale
Placing two keys of the same wallet on a single device exposes the keys to information leakage by either a malicious operator or malicious software. Ensuring every key of a wallet is used on dedicated devices reduces these risks, thereby increasing security.
Aspect Control
1.04.7 No two keys are used on one device

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect Control
1.04.8 DRBG Compliance

Level I

1.04.8.1

Requirement
1.04.8.1 Digital signatures must use a ‘k’ value that is never repeated.
Rationale
This is to create seeds in an unguessable and unrepeatable manner. This can be accomplished through the use of a deterministic random bit generator (DRBG) that is compliant with NIST SP 800-90A, or a deterministic scheme compatible with RFC 6979. A common implementation of this is to use the pseudo-random number generator (PRNG) supplied by popular operating systems, or an RFC 6979-compatible scheme.
Aspect Control
1.04.8 DRBG Compliance

NO ADDITIONAL REQUIREMENTS FOR LEVEL II or III

Aspect

1.05 Key Compromise Policy

Aspect Objective
This aspect covers the existence and use of a protocol that dictates the actions that must be taken in the event a cryptographic key/seed or its operator/holder is believed to have become compromised. Organizations must be prepared to deal with a situation where a private key has – even potentially – become known, determinable, or destroyed. Proper policies and procedures to govern these events decrease the risks associated with lost funds and disclosed trade secrets, and increase the availability of the information system to its users. Examples of when a KCP would be invoked include the identification of tampering of a tamper-evident seal placed on 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 is likely at risk of being compromised. The execution of Key Compromise Protocols must make use of Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors.
Aspect Control
1.05.1 KCP Exists

Level I

1.05.1.1

Requirement
1.05.1.1 An inventory of all keys/seeds exists and the organization has an awareness of which keys are critical to the successful operation of the information system.
Rationale
This decreases the risks associated with lost funds and disclosed trade secrets.
Aspect Control
1.05.1 KCP Exists

1.05.1.2

Requirement
1.05.1.2 While no formal KCP documents may exist, there is a staff member who is able to direct operators in the procedures necessary to regenerate cryptographic keys, regenerate cryptocurrency wallets, and send funds to these newly-generated wallets in the event any operator or keys become compromised.
Rationale
This decreases the risks associated with lost funds and disclosed trade secrets.
Aspect Control
1.05.1 KCP Exists

Level II

1.05.1.3

Requirement
1.05.1.3 A Key Compromise Protocol is documented which details: each specific classification of key used throughout the system; 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.
Rationale
This further decreases the risks associated with lost funds and disclosed trade secrets.
Aspect Control
1.05.1 KCP Exists

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.05.2 KCP Training + Rehearsals

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.05.2 KCP Training + Rehearsals

NO ADDITIONAL REQUIREMENTS FOR LEVEL II

Aspect Control
1.05.2 KCP Training + Rehearsals

Level III

1.05.2.1

Requirement
1.05.2.1 The Key Compromise Protocol is tested periodically to confirm the viability of the procedures and to ensure staff remain trained to use them in the case of a compromise. Logs of executed tests exist which outline any/all comments of the test. Improvements identified during the tests are written back into the protocol to ensure the most effective and efficient protocol is always maintained. As changes are made to the information system, the Key Compromise Protocol is revisited to assure it is updated with any new class of key.
Rationale
This ensures that any potentially compromised keys are quickly and efficiently handled. The regularity of testing may be based on the classification of the keys as called out in 1.05.1.2
Aspect

1.06 Keyholder Grant/Revoke Policies & Procedures

Aspect Objective
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 Control
1.06.1 Grant/Revoke Procedures/Checklist

Level I

1.06.1.1

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.
Rationale
This reduces the risks associated with the possession of un-revoked keys.
Aspect Control
1.06.1 Grant/Revoke Procedures/Checklist

Level II

1.06.1.2

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.
Rationale
This reduces the risks associated with missed privileges and the possession of un-revoked keys.
Aspect Control
1.06.1 Grant/Revoke Procedures/Checklist

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
1.06.2 Requests made via Approved Communication Channel

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.06.2 Requests made via Approved Communication Channel

Level II

1.06.2.1

Requirement
1.06.2.1 All keyholder grant/revoke requests are conducted over Approved Communication Channels.
Rationale
This provides high confidence of the identities of the communicating parties.
Aspect Control
1.06.2 Requests made via Approved Communication Channel

Level III

Requirement
No additional requirements for Level III
Rationale
Not required for Level III
Aspect Control
1.06.3 Grant/Revoke Audit Trail

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
1.06.3 Grant/Revoke Audit Trail

Level II

Requirement
Not required for level II
Rationale
Not required for level II
Aspect Control
1.06.3 Grant/Revoke Audit Trail

Level III

1.06.3.1

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.
Rationale
Documentation of the checklists and audit trail further verifies identities and ensures grant/revoke processes are completed.

Category

Operations

Aspect

2.01 Security Tests/ Audits

Aspect Objective
This aspect covers third-party reviews of the security systems, technical controls, and policies that protect the information system 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 staff who build and maintain an information system, it has been proven that third-person reviews often identify risks and control deficiencies that were either overlooked or underestimated by staff. 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.
Aspect Control
2.01.1 Security Audit

Level I

2.01.1.1

Requirement
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 organization.
Rationale
Having this knowledge available during the design and implementation stages helps ensure best practices are followed to minimize risk. Examples of evidence of this knowledge might look like checking if the developer has attended any training for digital asset security including smart contract coding if applicable; asking developer to describe what they learnt from the training; checking that the assessed entity has secure coding policies and standards.
Aspect Control
2.01.1 Security Audit

Level II

2.01.1.2

Requirement
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 organization.
Rationale
Security audits, in addition to regular vulnerability and penetrations test, 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 organization’s controls and procedures.
Aspect Control
2.01.1 Security Audit

Level III

2.01.1.3

Requirement
2.01.1.3 A regular security audit at a level similar to SOC2, 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 organization, and known vulnerabilities have been removed from the system. Ongoing audits are scheduled on a (minimum) yearly basis.
Rationale
Security audits, in addition to regular vulnerability and penetrations test, 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 organization’s controls and procedures. Completing these regularly increases security.
Aspect

2.02 Data Sanitization Policy

Aspect Objective
This aspect covers the removal of cryptographic keys 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 deleted. Proper sanitization of digital media ensures the proper removal of all keys, eliminating the risk of information leakage from decommissioned devices like servers, hard disk drives, and removable storage.
Aspect Control
2.02.1 DSP Exists

Level I

2.02.1.1

Requirement
2.02.1.1 The organization’s staff is aware of how data persists on digital media after deletion. Staff also have access to tools that perform secure deletion of data and understand when to use such tools to permanently destroy any transient copies of cryptographic keys that may be required during the maintenance of the information system.
Rationale
Awareness of why digital sanitization is important and how to conduct digital sanitization reduces the risk of information leakage.
Aspect Control
2.02.1 DSP Exists

Level II

2.02.1.2

Requirement
2.02.1.2 A detailed policy that aligns to NIST 800-88 by outlining the requirements for sanitization of digital media that holds/held cryptocurrency keys exists is read/understood by all staff who have access to cryptographic keys. Procedure documents outline where sanitization is required in their processes.
Rationale
Implementation of a detailed policy of digital sanitization reduces error and the risk of information leakage.
Aspect Control
2.02.1 DSP Exists

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
2.02.2 Audit Trail of all media sanitization

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
2.02.2 Audit Trail of all media sanitization

NO ADDITIONAL REQUIREMENTS FOR LEVEL II

Aspect Control
2.02.2 Audit Trail of all media sanitization

Level III

2.02.2.1

Requirement
2.02.2.1 An audit trail is maintained for every piece of sanitized media conforming to the NIST 800-88 recommendation. These audit documents identify the staff member 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.
Rationale
An audit trail provides evidence of media sanitization being performed.
Aspect

Aspect Objective
Aspect Control

Level I

2.03.1.1

Requirement
Rationale
Aspect Control

Level II

2.03.1.2

Requirement
Rationale
Aspect Control

Level III

2.03.1.3

Requirement
Rationale
Aspect

2.03 Audit Logs

Aspect Objective
This aspect covers the information system’s maintenance of audit logs that provide a record of all changes to information throughout the system. In the event of unexpected behavior or security incidents, audit logs are an extremely valuable tool that can help investigators understand how the unexpected symptoms occurred and how to resolve the inconsistencies to return the information system to a consistent state. The maintenance of audit logs significantly reduces the risks associated with operational awareness and increases the information system’s ability to correct any inaccuracies.
Aspect Control
2.03.1 Application Audit Logs

Level I

2.03.1.1

Requirement
2.03.1.1 Audit trails exist for a subset of actions that are performed within the information system.
Rationale
Audit trails reduce the risks associated with operational awareness and increase the information system’s ability to correct any inaccuracies. Examples of this would include recording audit information of all withdrawals and deposits made with the system.
Aspect Control
2.03.1 Application Audit Logs

Level II

2.03.1.2

Requirement
2.03.1.2 All actions by all users are logged. Audit logs are retained for at least 1 year in a trusted environment.
Rationale
These records provide significant assistance to investigations into unexpected behavior of the information system and can help identify malicious actors and responsible systems or persons.
Aspect Control
2.03.1 Application Audit Logs

NO ADDITIONAL REQUIREMENTS FOR LEVEL III

Aspect Control
2.03.2 Backup of Audit Logs

NO ADDITIONAL REQUIREMENTS FOR LEVEL I

Aspect Control
2.03.2 Backup of Audit Logs

Level II

2.03.2.1

Requirement
2.03.2.1 In addition to recording all actions performed within the system, this audit information is periodically backed up to a separate server.
Rationale
This action helps preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the information system.
Aspect Control
2.03.2 Backup of Audit Logs

Level III

2.03.1.3

Requirement
2.03.2.2 In addition to recording all actions performed within the system, this audit information is continually backed up to a separate server.
Rationale
This action helps further preserve valuable investigative information in the event the audit log is altered/destroyed during an attack on the information system.

The CryptoCurrency Security Standard (CCSS) has been updated to version 9.0. See the updated CCSS here.

Systems certified under 8.1 are still valid.

View Now