The idea that blockchains or distributed ledgers may bring benefits in terms of cybersecurity is a widespread myth. Even the US Department of Defense fell for this myth in a recent report “DoD Digital Modernization Strategy” with plans to build a “Block Chain Cybersecurity Shield” allowing to “transmit secure messages” and “develop unhackable code”. It is important to set the record straight on these complex topics.
A few general points to start with:
1/ The terms “blockchain” and “distributed ledger” have lost their meaning. The area is a semantic wasteland as Nic Carter puts it. If somebody generalizes a feature of Bitcoin such as tamper resistance to all the other blockchains, then that person is either ignorant or a fraud. At this stage, for 10 blockchain implementations there are 10 different risk profiles. The link between blockchains and cybersecurity is the same as between the programming language Java and cybersecurity (no link!).
2/ Blockchains weren’t designed to solve security issues, but to minimize trust. Bitcoin and Ethereum allowed unidentified users to exchange scarce digital unit of value, by preventing double spending without relying on trusted third parties. If early blockchains happened to include security features, it’s not inherently but by design, in order to achieve trust minimization.
3/ Blockchains are regularly hacked. This site lists 68 incidents corresponding to 9 types of security weaknesses.
4/ If blockchains use cryptography, the shared data is not encrypted and often the network connections aren’t encrypted with SSL/TLS either (Bitcoin BIP151 was withdrawn).
5/ Blockchains are essentially distributed transaction logs. Even if they were systematically secure, you would only have a secure audit trail: a cryptographic proof that someone did something when. You wouldn’t have any other security feature such as identity and access management, endpoint security or network security; and you wouldn’t be protected against brain hacking (phishing, social engineering, etc.). Back to point 3/
We could almost stop there by saying that blockchains, like any other systems, are as secure as you design them. They must be considered from an ecosystem perspective including users, physical devices, software clients and third-party service providers.
For readers who want to dig deeper, let’s continue.
There are three types of blockchain implementation, with very distinct features: real blockchains, pseudo blockchains and conventional applications leveraging real blockchains as third-party solutions.
a) Real blockchains are public permissionless systems not controlled by anybody. Assuming the network is sufficiently large, the ledger itself is redundant, tamper evident and tamper resistant. The ledger’s attack surface is generally very small (POW systems are only vulnerable to 51% attacks), precisely because it’s designed to work in adversarial environments. Why I say generally? The more layers you add to the system, the more the attack surface grows. For instance, Ethereum allows to execute code on its platform making it vulnerable to uncontrollable flaws, such as the one that wrecked The DAO and led to a fork in Ethereum. In this context, the security audit of the software code must be carried out even more carefully than for a conventional system.
If we consider these blockchains in the typical configuration of a user with a physical client, on which a client software is installed and connecting to the “network”, their characteristics are similar to conventional distributed systems:
- Users must be trained in security – they are the first line of defense!
- Physical clients must be password protected, use hardware encryption, an antivirus, a VPN, a software firewall and a backup solution
- Software clients need to be updated/patched regularly and use two-factor authentication
- Internet connections must be secured (password, browser configuration, physical firewall, etc.)
b) Permissioned blockchains used in a business context are pseudo blockchains. They keep the complex design of real blockchains and remove their key benefit. It’s software by another name. It’s about leveraging applied cryptography within existing business processes, an incremental step in the continuous “software eating the world” journey – the slow moving perpetual “digital transformation” of business processes. In theory a pseudo blockchain audit trail should be more secure than the one from a conventional system, but I wouldn’t trust it because the solution provider is incompetent for suggesting a blockchain in the first place. We cannot say anything a priori about the security of such systems without a detailed evaluation.
c) Having understood that pseudo blockchains are uninteresting, some firms recommend combining traditional business applications with real blockchains, leveraged as external transaction rails. There are still some conceptual flaws with this approach, as distributed systems are always slower and more expensive than their centralized counterparts. From a cybersecurity perspective, the external system should be considered as a third-party solution and a security due diligence should be conducted as for any other third party. The CISO, CRO and CCO will be obstacles on the path of anybody who wants to push that in a bank. For instance, the Ethereum blockchain used by Societe Generale to issue a bond wouldn’t pass DFS part 500.11 cybersecurity requirement in the state of New York.
To conclude, blockchains / distributed ledgers are neither security holes nor miracle security solutions. They must be considered within their ecosystem and be addressed using standard security methodologies such as NIST CSF, FFIEC CAT or ISO27001. Their security must be assessed thoroughly, and security controls must be implemented to fill the identified gaps, based on the organization’s risk appetite, like for any other system.