What is a CCSSA?

CCSSA stands for CryptoCurrency Security Standard Auditor. If you pass the CCSS auditor certification exam and are accepted into the CCSSA program, then you can audit systems under CCSS that implement a cryptocurrency wallet.

As of the date of this article (April 2022), the CCSS auditor exam is still in testing.

Their web page provides a little detail regarding the CCSSA program including who would benefit from the certification which include:

  • Information System Auditors
  • Cyber Security Professionals
  • Blockchain Engineers
  • Software Engineers
  • Anyone who wants the formal ability to grade information systems against the CCSS

Auditing is not for everyone and even if you pass the exam, it’s unlikely you will get far (e.g. build a business around auditing under CCSS) unless you have some auditing experience – preferably auditing information security management systems using industry recognized information security management standards such as PCI DSS, ISO27001.

You may know the ins and outs of how Bitcoin or Ethereum works but do you know what good key management policy and procedures look like? Do you have the skill to interview someone who is not the least bit interested in answering your questions and may come across as aggressive or abusive (pro tip: shouting back is not an option)? Or how about meticulously recording interviews, configurations you have reviewed or processes you have observed, then writing up a report on your findings that provides enough clarity and detail to confirm your compliance rating for the assessed entity?

This is auditing 101.

When compared to PCI DSS or ISO27001, CCSS does not provide a substantial number of controls. That is because CCSS is solely focused on the security controls to protect cryptocurrency wallets. The CCSS Steering Committee, which maintains the CCSS, states quite clearly that the CCSS is not a replacement for the basic information security management standards such as PCI DSS and ISO27001. CCSS provides the additional controls to consider when implementing a cryptocurrency wallet.

So as a CCSSA it is your job to assess if the CCSS controls are in-place – meaning the scope is defined correctly, the required controls are correctly implemented, working as intended and meet the CCSS requirements for that control.

Why CCSS Doesn’t Stand Alone

As part of auditing an entity, it is important to check that the entity has implemented more than just the CCSS for the security of information management systems. Just implementing CCSS to protect the information management systems is a bad idea because the CCSS does not cover the absolute basics such as:

  • user management,
  • patch management,
  • change management,
  • vulnerability management,
  • risk management,
  • incident response management,
  • security awareness training,
  • secure custom code techniques, etc.

All of the items in the above list are covered extensively by the baseline standards such as PCI DSS and ISO27001.

As an example, if you don’t have effective vulnerability and patch management in-place then there is a particularly good chance some of the systems are vulnerable to attack and if attacked, then more than likely the underlying systems/servers that the cryptocurrency wallet is running on will be comprised and the wallet’s security will be at risk of failure.

There is no requirement in the CCSS that additional information security management standards should be implemented. That is not the job of CCSS, but not implementing the basic security controls in the system where the cryptocurrency wallet will operate, in our opinion, almost makes CCSS ineffective at protecting the cryptocurrency wallet.

The CCSS defines ten core “aspects” which can be read like “requirements” or “control categories”:

  • Key/Seed Generation,
  • Wallet Creation,
  • Key Storage,
  • Key Usage,
  • Key Compromise Protocol (KCP),
  • Keyholder Grant/Revoke Policies & Procedures,
  • Security Audits / Pen tests,
  • Data Sanitization Policy (DSP),
  • Proof of Reserve (PoR), and
  • Audit Logs

The inclusion of the Proof of Reserve (PoR) aspect is unusual as this is a financial control not an information security management control in our opinion. If the aspect addressing fund reserves defined the protection of the funds from unauthorized access then this would be logical but ensuring that the assessed entity has enough fund reserves does not make sense for an information security management standard such as CCSS. No doubt others feel the same so we assume some clarity and guidance will come out of the CCSS Steering Committee in due course.

Official CCSSA Guidance and Tools

We have not seen any guidance, tools or official communities come out of the CCSS Steering Committee yet, but we are confident the CCSS are working on it. The CCSS standard is reasonably well defined for auditors and the assessed entity to understand what is required. However, some guidance will need to be provided to help research and reach an opinion on some requirements in order to audit the in-scope systems/environment.

An Example of Auditing & Guidance

Aspect 1.01 Key / Seed Generation – Level 3 has this requirement:

“The key or seed is generated using a Deterministic Random Bit Generator (DRBG) that conforms to NIST SP 800-90A, …”.

Firstly, one must understand what the CCSS defines as “conforms“. Currently there is no definition provided by the CCSS Steering Committee but if we refer to a dictionary, we find this: “Comply with rules, standards, or laws.“.

NIST SP 800-90A is a Recommendation for random number generation using deterministic random bit generators. The Recommendation’s abstract is:

“This Recommendation specifies mechanisms for the generation of random bits using deterministic methods. The methods provided are based on either hash functions or block cipher algorithms.“

Therefore, the CCSSA is drawn to the conclusion that key and/or seed generation mechanism must be a DRBG and must meet the requirements in NIST SP 800-90A.

So far, so good.

To continue with our example, the CCSSA finds out that the assessed entity uses the Gnosis Multisig Wallet for their ETH, ERC20 and ERC721 protocols. The key custodians (the users signing the transactions) use MetaMask to generate the wallets and keys used in the signing of transactions.

Applying the CCSS 1.01 Key / Seed Generation – Level 3 requirement: “The key or seed is generated using a Deterministic Random Bit Generator (DRBG) that conforms to NIST SP 800-90A.”. The CCSSA would need to gather the following information before being able to audit for this requirement:

    1. What type of MetaMask installation is used? Mobile? Web browser extension on desktop?
    2. Does the assessed entity have defined requirements on what platform can MetaMask be installed on?
    3. How does MetaMask , on each of the supported platforms, implement the mechanism to generate a seed? Does this mechanism conform to NIST SP 800-90A? Don’t forget the entire process needs to be reviewed for conformance – that includes entropy->mnemonic->binary seed.
    4. The CCSSA then needs to review the mechanism which generates the key using the seed. Does this mechanism conform to NIST SP 800-90A?

If you conduct a little research on MetaMask you will locate this MetaMask support page titled “How does MetaMask generate your keys?” #1 which gives you the impression that all will be answered. However, all the web page provides is a statement that the entropy is generated by the MetaMask installed platform’s implementation of Crypto.getRandomValues(). The web page does not cover the generation of the mnemonic phase, the binary seed, BIP39, what cryptographic modules are used or other important details the CCSSA will need in order to ensure that the seeds and keys conform to NIST SP 800-90A.

So what the CCSSA is left with is to:

    1. Review the official source code for the generation of entropy/ on each of the support platforms – for example where does the function Crypto.getRandomValues() get the random numbers for on Linux, MACOS, Windows?
    2. What is the mechanism to generate the mnemonic, binary seed, and key? Is it different on each supported platform?
    3. What additional factors are added if the assessed entity supports older versions of the platforms that MetaMask is installed on? Note: sometimes the implementation of standards changes in software versions.
    4. Search community forums to see if any information has been provided and make a call if the information contained within that community can be trusted as part of the audit evidence and reach an opinion if MetaMask’s seed and key mechanisms conforms to NIST SP 800-90A.

The CCSSA may be in luck and be provided with all the answers by the assessed entity – in our auditing experience this only occurs rarely and it’s often the job of the auditor to locate the answers.

As you can see from the example above – any guidance from the CCSS Steering Committee will be appreciated by both the CCSSA and the assessed entity.

Summary

Overall, the CCSSA program looks promising. Its early days as the CCSSA exam is still in testing and very little has been released on how the CCSSA program will work – but we believe there will be a significant need for CCSS compliance in order for mainstream adoption (and trust) in crypto platforms.