An introduction to the Cryptocurrency Security Standard (CCSS)
The Cryptocurrency Security Standard (CCSS)
Good morning everyone, today I bring to you a short post on a relatively new development in the crypto-cyber security world.
First lets level set with everyone so we can understand why we are talking about this topic today.
Crypto currencies, like Bitcoin, Ethereum and tokens like NFTs are blowing up in popularity. However, the industry that supports the creation and exchange of these assets is still a bit like the wild west. From the standpoint of a US citizen, there are several legitimate players in the space, like Coinbase, Gemini, FTX and others, however the US consumer of these services relies mostly on word of mouth to identify a trust worthy vendor.
Security frameworks 101
As a cyber security professional, I recognize that this is an issue of trust. This is old hat to us, with security frameworks like PCI, HIPPA and the various NIST standards, I know that adherence and sometimes certification to a security framework can be a useful tool in the battle to build consumer trust.
So how do security frameworks provide security and ultimately create trust? Every framework is a little different, but there are three general categories.
Control based: Control frameworks, like NIST SP 800-53 identify risks and prescribe controls to mitigate those risks. These are useful because they are generally easy to adopt and provide a significant boost in security compared to no framework at all.
Program based: While more difficult to adopt and implement than a control-based framework, does have a clear benefit. Not only do you get a tangible “program” that you can point to if someone asks, but you are able to clearly and simply articulate your current security state to your leadership. This is an area where we, in cybersecurity, often fall short.
Risk based: Frameworks like ISO27005 and NIST 800-39 address the problem created by control and program based frameworks: Which is they are not able to factor in the context that is specific to each organization, which in turn would prioritize efforts and guide the security program.
With a risk based framework, a risk assessment is performed up front and the results of this assessment drives the development of the program. This results in a prioritized and custom security program, but comes at the expense of simplicity.
I created a more detailed analyses and guide to frameworks, it can be found here:
The Cryptocurrency Security Standard (CCSS)
With all that level setting out of the way, we can finally get into the fun part of the post. What does the crypto world have as a security framework? While you will find exchanges, like Gemini, will hold SOC2 and ISO27001 compliance (which are great!) there was a need for a framework that addresses the specific challenges and risks presented by the crypto currency world.
Enter the Crypto Consortium’s (C4) CryptoCurrency Security Standard or simply the CCSS. According to C4, the CCSS is a security standard that aims to secure the systems that use cyrptocurrencies. This is a very broad definition, but thats good because it won’t limit its application to specific use-cases. What does this all mean? The cryptocurrency space will have a dedicated security standard, purpose built for crypto currency service providers, like exchanges.
Because this space is so new, the standard is in a draft state. This draft can be found on Github (here: https://github.com/CryptoConsortium/CCSS).
The standard itself appears to be a control framework, with ten controls and three implementation tiers, aimed primarily at the security of cryptographic materials. This make sense, since the majority of risk that exists in the crypto world is in the security of transacting data and currency (which relies on cryptography to provide security).
These ten controls are:
- Security of cryptographic Key and Seed generation
- Security of wallet creation
- Security of key storage
- Security of key usage
- Key compromise protocol
- Key holder (granting & revoking permissions) policy
- Audits and pentesting
- Data sanitization policy
- Proof of reserve
- Audit logs
If you want to see the specifics of each control, I encourage you to go to GitHub and check out the repo!
This post was much longer than I anticipated, if you have made it here I thank you!