[Please note these are my personal views and should not be assumed to be the offical position of my employer]

This is an exciting time for Blockchain and there is no shortage of hype. Over the past few months there has been a barrage of blockchain news and the BitCoin price has made it into the coverage of the traditional media.

There’s also been interesting practical developments such as Axa announcing a trial for a rather elegant approach to travel compensation with blockchain based smart contracts and last week a number of European banks announcing a blockchain energy trading and settlement platform. To some extent this a typical period, as research from the Cambridge Centre for Alternative Finance reports that 67% of central banks are currently working with blockchain. When the central bank is engaged it makes sense for all other banks to take a close interest.

As the technology starts to mature, now seems to be a good time for the financial services industry to think more holistically how to secure blockchain and distributed ledger designs. To keep the article short (and perhaps a bit more readable), this will look at some of the principles of security and blockchain as a technology, especially in an enterprise context, and not dive too much into the specifics of Bitcoin, Ethereum, ICOs and public vs private blockchains.  If you’re not clear on the distinctions between blockchain and distributed ledger and how these design considerations have huge implications for system security, then I cannot recommend highly enough the work of Richard Gendall Brown, a fellow former IBMer, now chief architect for R3, and one of the best thinkers on blockchain architecture.

A challenge I’ve seen is a number of voices who argue that the blockchain does not need much security, as it offers security by design. These voices point out that blockchain is a permissioned distributed ledger, so access is restricted and the consensus nature of distributed ledgers provides some immunity against individual nodes being corrupted. Furthermore, the whole idea of a distributed ledger is to ensure that if one copy of the ledger fails or is corrupted, then all the other ledgers offer a way of restoring the truth. In this environment, I have seen it argued, security is of limited concern, a legacy component and one of the costs that the blockchain will remove.  

To me, incidents like the DAO ( Decentralized Autonomous Organization) hack in June 2016 suggests that implementations, even on top of a blockchain concept like Ethereum, are potentially no less vulnerable to bugs than legacy IT. Looking at the problems Parity has had this week with $280m potentially destroyed and then with $30m stolen in June, it's clear that security is hugely important at all levels of blockchain and cryptocurrency.

I would suggest that to date the blockchain reputation has been partly protected by the design of its most well-known implementation (bitcoin) and partly because so far only comparatively limited value has been stored on the blockchain outside of bitcoin. This has naturally tended to made the blockchain a lower priority target for attack than some of the more traditional repositories of value. As blockchain implementations develop and the value on them increases rapidly (as is happening at the moment) then they will be targeted more aggressively for vulnerabilities. The strengths of the blockchain architecture and its resiliency are real, but this does not mean security is redundant.

The problem has two elements. First, hackers are ingenious, creative people. They like a challenge and in the current world they have a wide range of motives beyond the traditional efforts of stealing data or money. Simply because you can’t envisage a threat today doesn’t mean that a clever teenager or organized crime group can’t identify an attack option.

Secondly, what is secure today may not be as secure tomorrow. Businesses evolve, adapt and change. Core bank mainframes (where I first worked) and payment systems are hugely secure by design for the operating model of 70s and 80s. Yet once a mainframe is connected to a call centre, to internet banking and so on, while the mainframe itself remains a very secure environment, the security profile and complexity of the overall system security has somewhat changed. A programing decision might make perfect sense in one environment but leave significant vulnerabilities if that environment were to change.

So what should we be thinking about for securing the blockchain?  The list below is a far from exhaustive list, but as a couple key areas I’d suggest looking at:

Endpoint and data ingress

I’ve no argument with the idea that the distributed ledger is a good way of both securing data and building resilience into the ledger system. (Whether you can then have privacy is a separate discussion). The blockchain is a good way of managing ledgers where participants cannot fully trust each other. Once data is onto the blockchain and distributed, then it provides a very powerful way of demonstrating truth (and the irrevovcable nature of the blockchain is a very powerful element of its data security). The issue around where data first gets onto the blockchain, though tends to be less focused on.

While the great thing about blockchain is its irrevocability, the challenge is what then happens if “bad” data gets on. I’ve blogged on this before (See: “Law, territory and the Blockchain in Financial Services” from back in 2015), but unpicking a corrupted or compromised piece of data in a blockchain system is non-trivial undertaking. Equally, if it is possible to unpick a blockchain, then the immutable and irrevocable nature is somewhat challenged. All of which suggests that securing the endpoints from which data gets onto the blockchain is critical.  In theory, if you could take control of an endpoint for long enough (and “long” depends on the blockchain implementation) it is possible to steal the value in the ledger, and at this point the immutability of blockchain can work against the legitimate owner. We already see this type of attack on mobile bitcoin wallets, as the physical device can be the easiest point to target (see for example the NY Times: “Identity thieves hijack mobile accounts to go after crypto currency”) and there is no reason to think similar principles could not be used to target endpoints on corporate implementations of blockchain technology.

Securing the ledger

It is very difficult to alter a distributed ledger once data has been distributed, but that does not mean that the only intent amongst hackers is to steal. Hacker motivations are many and varied and direct thesft is only one. An indirect attack or disruption to access value (such as Ransomware) can be very powerful.  In theory, a distributed ledger technology offers protection against Ransomware, as if your ledger was encrypted or otherwise taken off-line, you would be able to build a new one from the shared ledgers of the other participants in the network. In practice, the idea of doing this type of rebuild at scale in a corporate environment whilst (presumably) also investigating and remediating how the original ledger was compromised, seems a stretch for any IT team, not to mention the legal and regulatory issues that would need to be resolved before putting a rebuilt ledger into production. Finally, many assume that hackers are intending to steal from the ledger, whereas hacker motivations are varied and disruption or destruction might be hacker objectives rather than theft.

Distributed ledger increases resiliency but prevention is still better than cure, and in securing the ledger is still vital.

Disruption and DDoS

Looking at cyber threats today, one of the biggest potential threats to a blockchain based distributed ledger technology is disruption of the network. The way blockchain works is to require transactions to be added to the blockchain and distributed.  As other blocks are then built on top, these transactions are harder and harder to re-write.

Disrupting the network (even if the hackers can’t penetrate the transaction cryptography or access the ledgers), could have a huge impact on a blockchain based system.  Defense against DDoS (Distributed Denial of Service) attacks is probably an article in itself, but protecting the network from disruption and each nodes access to the network is essential.

Although DDoS is not one of the most sophisticated cyber threats, it can still be very effective against organisations with a distributed network or who have time sensitive traffic. A recent example was October’s 90min DDoS attack against the UK national lottery, targeted at the time of peak demand for ticket sales. While the lottery can run the following week, the implications for a blockchain settlement network could be significant.

Deception:

Identity and authentication is a huge topic, but (as with the DAO hack) attacking the softer areas of a blockchain implementation may well be easier than attacking the actual blockchain itself. The $500,000 attack on Enigma in August (for details see the International Business Times or TechCrunch) was done through attacking the company’s website and Slack channel.  This was a deception/ impersonation attack, where the attackers posted Slack messages, altered the company’s website and spoofed emails to point towards their own crypto wallet. The longer term implications for what that attack did to trust in the protocol and the basis of smart contracts are still being felt.

Some of this could perhaps have prevented through password security measures, two factor authentication and protected endpoints.

I've looked at a a couple of areas above, but there are many more that can be explored. In short, distributed ledgers and blockchain projects need security as much as the previous generation of IT systems, but with some different thinking as to the risks. Good design is imperative but so is an understanding of security basics and that older forms of attack may not have ceased to be effective against newer systems.