Sebastien Meunier* says blockchains, like any other system, are only as secure as you design them.
The idea that blockchains 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 Modernisation Strategy, with plans to build a “Block Chain Cybersecurity Shield” allowing it to “transmit secure messages” and “develop unhackable code”.
It’s important to set the record straight on these complex topics.
But before I get into it properly, let’s begin with a few general points to set the stage:
1) Blockchains are not designed to solve security issues.
They minimise trust.
They allow unidentified users to exchange scarce digital units of value, by preventing double spending without relying on trusted third parties.
If blockchains happen to include security features, it’s not inherently but rather by design, in order to achieve trust minimisation.
2) The words “blockchain” and “distributed ledger” have lost their meaning.
If somebody generalises 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.
Therefore, the link between blockchains and cybersecurity is the same as between the coding language Java and cybersecurity (no link!).
3) Blockchains are regularly hacked.
There have been at least 68 incidents corresponding to nine types of security weaknesses.
4) If blockchains use cryptography, most of them are not encrypted.
The shared data is generally accessible to all the users.
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 features 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 No. 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.
Digging deeper
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 permission-less 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 per cent attacks), precisely because it’s designed to work in adversarial environments.
Why do I say generally?
The more layers you add to the system, the more the attack surface grows.
For instance, Ethereum allows users to execute code on its platform making it vulnerable to uncontrollable flaws.
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 defence!
- 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 — a marketing trap.
They are uninteresting because it’s almost always possible to implement the same services, but cheaper and faster, with regular databases and cryptographic libraries.
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)Some firms, having understood that pseudo blockchains are uninteresting, recommend combining traditional business applications with real blockchains, leveraged as external transaction rails.
There are still some conceptual flaws in this approach, as distributed systems are always slower and more expensive than their centralised 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.
To conclude, blockchains are neither security holes nor miracle security solutions.
They must be considered within their ecosystem and be addressed using standard security methodologies.
Their security must be assessed thoroughly, and security controls must be implemented to fill the identified gaps, based on the organisation’s risk appetite, like for any other system.
* Sebastien Meunier advises financial institutions on their cybersecurity and innovation strategy. He tweets at @sbmeunier. He blogs at finnoworld.com.
This article first appeared at thenextweb.com/podium.
