CCSS - Adding Value to Web3
Marc Krisjanous is one of the first CCSS Auditors and assisted C4 in developing the CCSS auditors program. Marc also conducted the first-ever CCSS audit certifying Fireblocks at CCSS Level 3.
**** Free CCSS Implementation Guide! ****
Marc also co-authored the CCSS Implementation Guide for a Full System - click here to download - it's free!
Overall, the CryptoCurrency Security Standard (CCSS) ensures effective key management is being applied to systems that provide functions for managing all blockchain-managed digital assets, including cryptocurrencies, NFTs and tokenized assets.
However, CCSS requirements can be applied to web3 projects even if the project does not incorporate cryptocurrencies or other token-based assets.
If we consider the standard definitions of what “web3” is, you will likely see the use of a blockchain to store information, such as details of a transaction involving cryptocurrency. However, a blockchain can be used for more than just recording financial transactions. Many web3 projects offer solutions that do not use cryptocurrency or focus on finance.
What is expected, which cannot be avoided at this date, is that adding information to a blockchain requires an entity's private key to prove ownership of the address to which the data will be linked.
The private key used to sign a new transaction or prove ownership of data on the blockchain must be kept private and secured. Access to the private key means access and control of all data on the blockchain signed with that private key.
Adding the Value
Therefore, CCSS provides tremendous value to a web3 project by providing key management information security requirements that have been proven through real-life hacks of cryptocurrency systems to block or reduce the ability of a malicious actor to gain access to the private signing keys.
CCSS provides requirements for information security controls grouped by “Aspects”, which can be considered categories. ?
Key/Seed Generation
Aspect 1.01 Key/Seed Generation addresses the creation of keys and seeds, including the confidentiality of key and seed creation processes and entropy requirements.
Wallet Creation
Aspect 1.02 Wallet Creation addresses the security of cryptocurrency wallet creation and covers the people, process, and technology components for wallet creation.
Key Storage
Aspect 1.03 Key Storage addresses protecting keys and seeds while at rest. The Aspect also addresses the management of key backups and requirements for physical media used to store and transport key backups.
Key Usage
Aspect 1.04 Key Usage addresses the security of keys, including user access requirements such as using multiple authentication factors for access to keys. Security requirements for the environment in which the keys are used are also addressed.
Key Compromise Policy
Aspect 1.05 Key Compromise Policy addresses the processes to respond to a key/seed and operator/holder compromise. These requirements should be added to the existing incident response plan that covers the entire project’s systems.?
Keyholder Grant/Revoke Policies & Procedures
Aspect 1.06 Keyholder Grant/Revoke Policies & Procedures addresses user account management for granting and revoking key access.
There are also additional requirements for security controls that assist in the protection of keys and key management systems:
领英推荐
Security Tests/ Audits
Aspect 2.01 Security Tests/ Audits addresses the importance of an independent (third-party) review of the in-scope people, processes, and technology. The Aspect defines vulnerability scans, penetration tests and security audits.
Data Sanitization Policy
Aspect 2.02 Data Sanitization Policy (DSP) addresses the processes for securely deleting key data from digital media.
Audit Logs
Aspect 2.03 Audit Logs addresses audit log management processes to provide a record of events in the in-scope environment.
Other Control Frameworks
It is evident that CCSS only focuses on the security of keys and key management systems.
CCSS does not address baseline information security controls such as change management, patch management, access management, application software development, vulnerability management, and deployment management for the components of the project. It is expected and stated by the CCSS committee that the entity implements a baseline information security management system (ISMS) such as ISO27001 before implementing CCSS requirements. For example, it’s no use looking at CCSS for key management security controls when the wallet software hasn’t been patched in years.
Some readers may argue that information security management standards such as ISO27001 are only suitable for “centralized” systems, and web3 is all about having your project decentralized. Therefore, different standards are needed. Unfortunately, at present, many of the web3 components and services are on “centralized” hosts such as AWS and Azure [1], especially at the User Interface (UI) layer where centralized web server use is widespread, and to argue the point about the usefulness of current standards for web3, as an example – smart contract code should still be audited. Wallet software should have a patching cycle where both controls are listed in ISO27001.
Summary
The CryptoCurrency Security Standard (CCSS), while in name, appears only to be useful for systems that provide cryptocurrency functions, does provide robust and battle-tested requirements for any system that uses cryptographic keys.
Base-line information security standards such as ISO27001 provide guidance on key management, but CCSS focuses on using cryptographic systems with blockchains. ?
The requirements within the CCSS have been selected and refined based on the ability to block or significantly reduce the attack vectors used in blockchain-based projects. The CCSS contributors who manage the standard continuously review reports on hacks and breaches in the blockchain/crypto sector and ensure the CCSS requirements are enhanced to provide continuous protection.
Further reading on CCSS