8 blockchain security risks to weigh before adoption

1. Old software

While enterprise blockchain software is rarely "old," anything that's been around more than a year or two is basically a Stone Age tool in terms of change velocity and improvements.

R3's open source Corda blockchain platform is a good example. In the five years after its initial release in May 2016, Corda had 182 releases, or roughly one every 10 days. Many of them weren't small releases either. Major new capabilities and refactoring or removal of code were commonplace. There's no nice way to say it: In most enterprise projects, there is a real tendency to pick a software version and never upgrade because doing so could break things.

The lesson here: Make sure your software is up to date and can be kept updated.

2. Lack of security vulnerability coverage

Enterprise blockchain software has little to no coverage in security vulnerability databases. This means most users, unless they explicitly track vendor release notes, aren't aware of security updates. This lack of coverage, especially in the Common Vulnerabilities and Exposures (CVE) database and the U.S. National Vulnerability Database (NVD), is a huge problem because, if the vulnerabilities aren't officially recognized, they don't exist for many large organizations. I'm not sure why CVE and NVD coverage of blockchains is so poor, but one possible culprit is the lack of official documentation of specific blockchains' vulnerabilities.

The lesson: Make sure you have the resources to monitor for security vulnerabilities and updates in your blockchain and smart contract software.

3. Inadequate knowledge of security vulnerabilities

Traditional software has well-understood vulnerability types, many of which are documented in the online Common Weakness Enumeration (CWE) dictionary -- for example, the difference between a buffer overflow and an integer overflow as popular weaknesses for hackers to exploit. CWE is a critical resource. Many code-scanning tools use it as the basis for the types of vulnerabilities they try to detect.

Kurt Seifreid

However, CWE doesn't cover blockchain or smart contracts specifically. The good news is there are other efforts to document these issues, including the Blockchain DLT Attacks and Weaknesses Enumeration database from my organization, the Cloud Security Alliance (CSA), with more than 200 entries covering a variety of smart contract languages, blockchain technologies and general concepts. And the Enterprise Ethereum Alliance's EthTrust Security Levels Specification defines requirements for smart contract security audits and names some common vulnerabilities.

The lesson to be learned: Ask which vulnerabilities your code auditors or tools are looking for. They should be able to clearly articulate and explain them.

4. Lack of code scanning and security testing

The current crop of blockchain and smart contract code-scanning tools is not particularly mature for the simple reason that the space is so new. To add insult to injury, many smart contracts are deployed without a security audit. This is starting to change, but numerous security incidents have highlighted the importance of auditing code and generating new secret keys prior to deployment.

I'm not making the last one up. Paid Network, a provider of blockchain decentralized applications for financial transactions, was breached when it deployed a smart contract it had paid a developer to create, but it never removed the developer's secret key. When the developer key was later exposed publicly in a Git commit -- a process for saving program code to a repository -- an attack drained the Paid Network contract.

The contract had passed a security audit. An auditor can't audit the production secret key, which would expose it, so it would have assumed Paid Network would replace it with a securely generated key, which it did not.

Lesson learned: Make sure all smart contract code is scanned and audited and all cryptographic material is generated securely and inserted correctly.

5. Operational risks

Let's assume you have a secure blockchain and well-formed smart contracts without any security flaws. You still have to run the blockchain and smart contract code on something that's well connected and reliable, preferably. If you pick the cloud or third-party hosting, you need to make sure they are also secure.

Look for honesty and transparency beyond the usual statements of SOC 2 compliance. One resource for this is the CSA's Security, Trust, Assurance and Risk registry, where you can directly compare providers' answers.

The lesson here: Ask questions. Vendors and service providers that care about security answer them and aren't evasive.

6. Cryptographic keys and HSM

At the core of every blockchain service and client are cryptographic keys. Keeping important cryptographic keys on a computer is no longer good enough, even when using a dedicated system.

Instead, use a hardware security module (HSM). An HSM basically provides two things a regular computer can't. First, the keys can be set up so they cannot be exported or copied off the HSM. Second, you can more reliably log usage of the keys. This is critical because, if your network is compromised, you are able to ascertain what the attacker used your key for, instead of speculating that they might have done bad things.

The lesson: Crypto-material for sensitive operations must be stored in an HSM and backed up. General-purpose computers or servers -- even air-gapped (physically separated) ones -- aren't enough.

7. Phishing, SIM swap and other shenanigans

Enterprise blockchains are generally not as widely attacked with techniques such as phishing or SIM swaps, which are typically reserved for attacking users of cryptocurrencies. However, ransomware and related attacks are increasingly turning to phishing and spear phishing for a simple reason: They work. The general answer to these types of attacks is to use strong multifactor authentication, ideally based off hardware tokens that prevent users from giving information to the bad guys.

Lesson to be learned: Humans make mistakes. You need both business and technical processes to catch mistakes and malicious behavior.

8. 51% attacks

Finally, there is some encouraging news. Most enterprise blockchain deployments don't use the proof of work (PoW) consensus mechanism. Proof of stake or more traditional voting mechanisms, such as a majority vote, are more common.

A 51% attack, where a single entity takes over a majority of the blockchain hash rate or computing resources in an attempt to disrupt the network, is most useful against a PoW-based system. Even with a simple consensus mechanism, such as majority vote, an attacker would need to hijack 51% of the organizations -- a much harder task than simply marshalling compute resources, which can often be rented.

Lesson learned: Make sure you understand the blockchain consensus mechanisms being used and in what circumstances an attacker is able to subvert them. Building a system that requires more than half of all the organizations to be subverted, for example, is probably an acceptable risk.

Conclusion

Blockchain and smart contract software are more complicated and difficult to secure than virtually anything else.

We want to build such systems knowing that malicious actors are participating maliciously but not allow them to compromise the systems. Solving this problem opens up all sorts of new markets and opportunities.

Ever since Bitcoin came on the scene in 2009, we've been steadily getting there with systems already in production that can withstand high levels of attack and abuse. But, like any new technology, it still requires a lot of expertise to build, deploy and operate blockchain securely.

Kurt Seifried is chief innovation officer at the Cloud Security Alliance.