What is CryptoCurrency Security Standard (CCSS)?
Article Updated July 2022 for CCSS Version 8.0
The word “crypto” was initially used as an abbreviation of cryptocurrency. However, with the growth of cryptocurrency and the creation of new protocols, standards, assets such as NFT and finance services aimed at cryptocurrency such as DEFI. “Crypto” is now used to encompass the entire sector of cryptographic-based assets and services.
The Cryptocurrency Security Standard (CCSS) is an open standard which focuses on the management security of cryptocurrency wallets.
In the world of “crypto” a crypto wallet is the bank account for your crypto assets such as cryptocurrency and NFTs. The crypto wallet also gives you the ability to conduct transactions such as buying products / services with cryptocurrency and transferring cryptocurrency to different wallets.
A crypto wallet stores the private keys used to sign transactions that will be validated and recorded on a blockchain. You don’t have to use a crypto wallet to sign transactions or manage crypto assets, but it becomes a lot more complex exercise if you don’t.
Since a crypto wallet has complete control over the crypto assets managed by it, the security of the wallet is incredibly important – especially if the wallet is under someone else’s control such as an exchange. This is where CCSS comes in.
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”.
What are the CCSS Controls?
CCSS provides a list of requirements that must be implemented to become CCSS compliant. The requirements focus directly on the people, process, and technology components of information systems which make use of cryptocurrencies. The requirements are categorized into “Aspects” with each Aspect providing an objective. The current Aspects and associated objective for Version 8 of CCSS are quoted below:
- 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.
CCSS provides three levels of compliance:
Level 1 CCSS Compliance
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 CCSS Compliance
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.
Level 3 CCSS Compliance
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”.
How Do CCSS Audits Work?
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
The CCSS Committee has provided an auditors guide for CCSS audits. The auditors guide provides guidance for CCSSAs, and entities interested in being audited under CCSS.
Of particular interest, is the certification listing fee that the assessed entity who reaches compliance must pay C4. The CCSSA is responsible for collecting the fee as part of the overall costings for the audit presented to the assessed entity.
The concept of “Merchants” and “Service Providers” is applied to assist in determining the listing fee. Based on the definitions provided for a Merchant and Service Provider we can see that the CCSS Committee has really thought about the different types of entities who would want to be CCSS compliant and tailored the listing fee to match their transaction volume and whether they are responsible for the security of another entity’s cryptocurrency.
For example, based on the definitions provided, we can see that an entity who accepts cryptocurrency for payment of their products only would be required to pay $1000 (I assume USD). However, an exchange that would generate considerable profits providing exchange services would have to pay an initial fee of $10,000 (I assume USD) then apply the scaling table for additional fees since, in our example, an exchange is responsible for the security of another entity’s cryptocurrency AND benefits financially from cryptocurrency transactions undertaken by their customers.
The official CCSS definitions are provided below.
The definition for a Merchant is:
“Merchants are defined as those who accept cryptocurrency payments for goods and services that customers do not use to conduct transactions.
Merchants pay a flat listing fee of $1,000.”
CCSS Service Providers
The definition for a Service Provider is:
“Service Providers are defined as those that provide goods and services that customers use to conduct cryptocurrency transactions. Service providers are separated into 2 types of pay structures: those who DO NOT charge a fee from customer/user transactions, and those who DO charge a fee from customer/user transactions. All service providers pay an initial listing fee of $10,000. Service providers who benefit financially from transactions also pay an additional cost included in the Listing Fee, determined by total clients’ assets custodied. See table 2 for details.” – please refer to the Auditors Guide for the scaling tables.
The auditors guide continues with providing guidance on the auditing process, including that the audit is conducted annually, which means the CCSS compliant entity must undertake an audit every 12 months to retain their certification.
Further, the audit guidance covers the support of sampling, the different types of evidence accepted, the security of evidence collected by the CCSSA, and the peer review process which requires another CCSSA to peer review the audit documentation who is independent from the CCSSA who conducted the audit.
Finally, there is a handy flow chart that provides the flow of the audit process.
Is Anyone CCSS Compliant?
At the time this post was published (July 2022) there is no official registry of CCSS compliant entities to review.
Who Maintains the CCSS?
The CCSS is maintained by the CCSS Steering Committee which has as its members key knowledge matter experts in the field of cryptocurrency such as Dirk Anderson, Petri Basson, Mike Belshe, Stefan Beyer, Jameson Lopp, Joshua McDougall, Michael Perklin, Ron Stoner, and Joe Ventura.
How Does an Organisation Become CCSS Compliant?
Currently an entity seeking to become CCSS compliant must engage an external CCSS certified auditor – a CCSSA. A list of current CCSSA’s can be viewed here. The CCSSA exam is out and details on the exam can be viewed here.
The crypto sector is very much in the early adopter stage with many considering the sector to be a wild west of scams and shady start-up projects where the project members hide their true identities and communicate only through chat applications.
Loss of investors’ funds is an almost daily occurrence either via scams or breaches caused by poor or non-existent information security. Rekt tracks and records breaches within the crypto space. If you review a random sample of the breaches on the site, you can see a majority of them could have been adverted by simply implementing Level 1 security controls from CCSS so that you’re not the subject of a story on Rekt, like the developers who left the private keys to a wallet with minting capability on Github.
CCSS goes some way in providing assurance to investors that at least the basics of wallet security (wallets that will manage their investment funds) have been audited by an external qualified auditor and comply with an open security standard. When CCSS is combined with a base-line information security standard such as PCI DSS or ISO 27001 the risk of an information breach is greatly reduced.
In our next Crypto Corner post, we’ll explore how a baseline information security standard can be used with CCSS.