The Cryptocurrency Security Standard (CCSS) focuses on the information security of systems that use cryptocurrencies. Recently we covered the basics of CCSS and who needs it. Here’s what you can expect in this article:
- CCSS components and requirements
- CCSS compliance levels
- Why CCSS audits and what is a CCSSA?
- Who manages CCSS?
The Cryptocurrency Security Standard is at version 8. However, there are no previous versions. For example, there is no version 2, 3, 4, 5, 6, or 7. The CCSS Committee went from an initial “draft” version published in 2015 to version 8 as a nod to how long the standard has been around.
What are the CCSS Aspects and Requirements?
CCSS provides two categories of controls: Cryptographic Asset Management and Operations. Each category then breaks down further into 10 Aspects that can be thought of in terms of high-level requirements. Then, each Aspect contains several requirements. The 10 Aspects and their associated objective is documented below.
1.01 Key/Seed Generation
The key/seed generation component 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
Confidentiality is required to ensure that the newly created keys or seeds are not read/copied by an unintended party.
Unpredictable numbers
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 provides assurance that the keys and/or seeds are created in a confidential and un-guessable manner.
1.02 Wallet Creation
This component of the CCSS covers the creation of wallets or addresses that can receive digital assets. Wallets are created using key signing methodologies requiring 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
Key usage 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 the 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.
Various risks are present when using keys 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 keys
- Malicious insiders who use their authorized access to send unauthorized transactions
1.05 Key Compromise Policy (KCP)
The key compromise policy component of CCSS 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 with 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
Key Compromise Protocols must be executed using Approved Communication Channels to ensure KCP messages are only sent/received by authenticated actors.
1.06 Keyholder Grant/Revoke Policies & Procedures
The keyholder grant/revoke policies & procedures part of the CCSS 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 concerning accessing its information, invoking privilege-restricted actions, and representing the organization to the public.
Improper management of the onboarding and offboarding of personnel introduces risks of privileged accounts remaining when staff departs and unrevoked keys that persist signing authority for certain transactions.
2.01 Security Tests/Audits
The security tests/audits cover third-party reviews of the security systems, technical controls, policies that protect the information system from all forms of risk and 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, are independent of the technical controls, and can be objective without risk of retaliation.
2.02 Data Sanitization Policy
The data sanitization policy covers removing cryptographic keys from digital media. Due to how 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
With the proof of reserve aspect of the CCSS, the information system should hold the proof of control of all funds. 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 the reserve assure the public that all funds are available to the system, eliminating the risks of fund loss.
2.04 Audit Logs
Audit logs cover 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 a special 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.
CCSS Compliance Levels
What are the three levels of CCSS Compliance?
Level 1 CCSS Compliance
Level 1 covers the baseline level requirements provided by CCSS and should be considered the absolute minimum of security controls to implement to meet the objective of the requirement.
When reviewing recent breaches of crypto-related services, you can see that even with just 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, key storage basics are addressed to protect key data at rest.
How many times have we read in media reports that a significant hack resulted in the theft of a cryptocurrency wallet’s private key(s) 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 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 rigor to the applicable security controls.
Considering Aspect 1.03 Key Storage at Level 2, further rigor is required. By requiring a backup of each production key needed to spend funds (requirement 1.03.2.2) and physical security controls such as physical separation of keys (requirement 1.03.3.2) and use of tamper-evident seals for physical copies of key data (requirement 1.03.5.1).
Level 3 CCSS Compliance
CCSS Level 3 adds even more rigor to the security controls. Aspect 1.03 Key Storage at Level 3 requires backups of keys must be encrypted at rest with strong encryption at least equal to the encryption strength used for production keys (requirement 1.03.6.1) and “Backups are resistant to electromagnetic pulses” – requirement 1.03.3.3.
The Process of CCSS Audits
The auditor (a CCSSA) will evaluate the entity’s compliance level for each aspect when an assessed entity is audited for CCSS compliance.
The three compliance levels have a set of standards for each aspect. According to the auditor, the assessed entity may be at compliance level 3 for some parts, but only at level 1 for others.
Note: When this article was written, the CCSS Committee had not offered any recommendations for the scale or determining variables used to determine an entity’s overall compliance level. We anticipate that the overall compliance level will be CCSS Level 3 if the examined entity complies with all level 3 compliance standards. However, the “devil” is in the details regarding aspect compliance levels. Hence the CCSS Committee must provide direction on determining the overall compliance level.
Is anyone following the CCSS?
No entity is CCSS compliant at any CCSS Level, according to the CCSS Committee, in response to a question. Additionally, it should be mentioned that an organization cannot self-evaluate and claim to be CCSS certified.
The entity must work with an independent CCSSA and participate in a CCSS audit with the CCSSA to receive CCSS certification. Let’s say the CCSSA determines that the assessed entity complies. In that instance, C4 will issue the evaluated entity a Certificate of Compliance after receiving the SROC and Appendix 1 from the CCSSA (COC).
A Baseline Information Security Standard Is Not CCSS
The CCSS Committee claims that CCSS offers extra cryptocurrency-focused information security requirements for systems that employ cryptocurrencies but do not replace baseline information security management system standards like PCI DSS and ISO 27001.
The CCSS is maintained by whom?
The CCSS Steering Committee, which contains well-known specialists in the field of cryptocurrencies as PCI DSS members, is responsible for maintaining the CCSS.
How Can an Organization Become Compliant with the CCSS?
An organization that wants to be CCSS compliant must hire a CCSSA, an external CCSS-certified auditor. The CCSS Auditors Guide provides a detailed description of the audit process flow here.
It should be noted that C4 requires a listing fee from any organization applying for CCSS accreditation. The CCSS Auditors Guide addresses the listing cost. However, a brief explanation is given here. Any organization that accepts cryptocurrencies and is not accountable for any other organization’s cryptocurrencies is regarded as a merchant and must pay an annual charge of USD 1,000.
The assessed entity is regarded as a service provider if it manages another entity’s cryptocurrencies or private keys (for example, if it operates an exchange or offers custody services). A service provider’s base price is $10,000.
The base cost increases from USD 10,000 to USD 15,000, and an additional fee is necessary if the service provider makes money off their customers’ transactions. This extra cost varies according to the total customer assets that the service provider is keeping under custody.
Summary
Any organization using cryptocurrencies should certify against the Cryptocurrency Security Standard (CCSS), a crucial information security standard.
Let’s say you examine a selection of cryptocurrency hacks that have happened. In such an instance, it is obvious that even if the organization had opted for CCSS Level 1, most of the hacks would have been greatly curtailed or completely stopped.
Only if the general public believes that businesses providing goods and services in this area take information security seriously will cryptocurrencies become widely accepted.
Anyone would never allow their bank to violate any information security guidelines or rules; the same goes for the bitcoin industry.
