What is the CryptoCurrency Security Standard (CCSS)?

The Cryptocurrency Security Standard (CCSS) is an information security management systems standard which focuses on the application of information security controls for “information systems that make use of cryptocurrencies including exchanges, web applications, and cryptocurrency storage solutions”.

• 1.01 Key/Seed Generation – 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: 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.
• 1.02 Wallet Creation – 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.
• 1.03 Key Storage – 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.
• 1.04 Key Usage – 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.
• 1.05 Key Compromise Policy – 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.
• 1.06 Keyholder Grant/Revoke Policies & Procedures – 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.
• 2.01 Security Tests/ Audits – 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.
• 2.02 Data Sanitization Policy – 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.
• 2.03 Proof of Reserve – This aspect covers the proof of control of all funds that should be held by the information system. There have been known cases where information systems that should be operating with a full reserve of user funds have been operating with a fraction of that reserve instead leading to an inability of the system to cover simultaneous withdrawals by all users. These proofs of reserve provide assurance to the public that all funds are available to the system which eliminates the risks of fund loss.
• 2.04 Audit Logs – 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.

The CCSS Committee states that CCSS does not replace baseline information security management system standards such as PCI DSS and ISO 27001 but adds additional cryptocurrency-focused information security requirements. It’s important to note that CCSS does not replace, nor does it purport to be an alternative to baseline security standards. As stated on their website:

CCSS is designed to complement existing information security standards (i.e. ISO 27001:2013) by introducing guidance for security best practices with respect to cryptocurrencies such as Bitcoin. CCSS is not designed to substitute or replace these standards; in fact, following the CCSS to the letter while ignoring standards like ISO 27001:2013 will likely lead to compromise. CCSS is a cryptocurrency standard that augments standard information security practices. As with any standard, knowledgeable and experienced security professionals and/or auditors are necessary when implementing any information system to ensure coverage of all classes of attack as well as the appropriate handling of all potential risks.

Level 1 covers the baseline level requirements provided by CCSS and should be considered the absolute minimum-security controls to implement to meet the requirements’ objective.

When reviewing recent breaches of crypto-related services one can see that even implementing security controls for Level 1 CCSS compliance many attacks would have failed or have dramatically reduced the impact of a breach.

For example, with Aspect 1.03 Key Storage at Level 1 the basics of key storage are addressed in order to protect key data at-rest. How many times have we read in media reports that a major hack resulted in the theft of the private key(s) of a cryptocurrency wallet because they were stored in plain text?

Below are the CCSS Level 1 requirements for protecting key data at rest.

• 1.03.1.1 Cryptographic keys and/or seeds must be stored with the use of strong encryption when not in use.
• 1.03.2.1 A backup of the cryptographic key/seed must exist. The backup can take any form (e.g., paper, digital).
• 1.03.3.1 The backup must be protected against environmental risks such as fire, flood, and other acts of God.
• 1.03.4.1 The backup must be protected by access controls that prevent unauthorized parties from accessing it.

Level 2 offers a higher level of CCSS compliance by adding further rigour to each of the applicable security controls.

Considering Aspect 1.03 Key Storage, at CCSS Level 2 further rigour is required by:

• 1.03.2.2 Requiring a backup of each production key required to spend funds,
• 1.03.3.2 Physical security controls such as physical separation of keys, and
• 1.03.5.1 use of tamper-evident seals for physical copies of key data.

CCSS Level 3 adds even more rigor to the security controls. Aspect 1.03 Key Storage at Level 3 requires:

• 1.03.6.1 Backups of keys must be encrypted at-rest with strong encryption at least equal to the encryption strength used for production keys, and
• 1.03.3.3 “Backups are resistant to electromagnetic pulses”.

When an assessed entity is audited for CCSS compliance the auditor (known as a CCSSA) will review the entities compliance level for each Aspect. Each Aspect has a set of requirements under the three compliance levels. The auditor may find that the assessed entity is at compliance level 3 for some of the Aspects and other Aspects the assessed entity is only at level 1.

NOTE: at the time of writing this article the CCSS Committee has not provided any guidance as to the scaling or determination factors for calculating an entities overall compliance CCS Level. We can assume that if the assessed entity has meet CCSS Level 3 compliance requirements for all Aspects, then the overall compliance level will be CCSS Level 3. However, the “devil is in the detail” where the Aspect compliance CCSS Levels are different for Aspects.

CCSS Auditor’s Guide