“We drive into the future looking into our rear view mirrors” Marshall McLuhan
(The views expressed in this article are entirely my own do not reflect the position of my employer the Federal Reserve Bank of Richmond, the Federal Reserve Board of Governors, or the Federal Reserve System as a whole.)
Or, perhaps the “paid paranoids” across the security community are still wrestling with the decision of which existing security risk management framework applies to this peer-to-peer distributed ledger technology, if any at all.
The very definition and basic characteristics of blockchains challenge many leading security models and in particular leading security risk management frameworks (NIST Risk Management Framework, International Organization for Standardization (ISO)) built on the underlying premise that information systems supporting core business functions and organization missions need to be confined to a virtual “boundary” and with a singularly identified “system owner” to achieve “certification”/”authorization.”
With the widely accepted definition that blockchain is a distributed database with an open ledger implying that data isn’t stored on a single computer but rather on many different computers, known as nodes in a peer-to-peer network, renders the legacy consideration of a ‘boundary’ for an organization’s blockchain quite challenging.
It gets even more complicated when we dive deeper into other key characteristics of blockchain summarized as follows:
- Distributed data ledger used, updated and verified by participants in the blockchain versus centralized database (more on public versus private blockchains shortly)
- Identity verification and authentication executed by the participants
- Logic and rules embedded in the transaction versus in a separate application layer
- Traceability of changes from the beginning
- Documents maintained separate from the ledgers
The aforementioned characteristics further challenges any assertion regarding a clearly defined system boundary under singular control of a distinct system owner.
The ‘security boundary’ and “authorizing official”/”system owner” decision is further complicated by the different blockchain network topology options an organization can choose, for example:
- Cloud-hosted One Network: Each participant owns a number of peer nodes including validating nodes. In this configuration the blockchain network is in a cloud and hosted by a vendor who owns the physical hardware. The participants contractually control the computing resources making the configuration decentralized within a centralized environment.
- Cloud-hosted Multiple Networks: This environment allows participants to have their peer nodes hosted by any cloud provider given that peer nodes can connect via the peer to peer protocol typically https.
- Participant-hosted Intranet: This environment uses networks that are owned by participants with https channel used for peer-to-peer communications
So what model should a practitioner apply to a technology that’s causing so much disruption to legacy business processes and practices globally? Or does any such model exist?
The actual architectural stack of a typical blockchain implementation is also worthy of deeper exploration. This stack can usually be divided into three primary functions described as follows:
- Membership Function – this is where membership registration, identity management and auditability occurs
NB: This function is the key differentiator between private, for example Permissioned Blockchain, and public for example Permissionless Blockchains which rely on “proof of work” mechanisms for node validation
- Blockchain Services Function – this is where your Consensus Management, Distributed Ledger, Peer to Peer Protocol Management and Ledger Storage occurs
- Chain-code Functions – decentralized transactional program running on the validation nodes within Secure Containers and Secure Registry
Layering on top of and across these three primary functions is the application interface layer where APIs, SDKs and other UI interact with the functions.
Cyber Defenders charged with protecting this stack have much to worry about in all three of these functional areas. For Private/Permissioned Blockchains ensuring the technologies providing the membership functions and cryptographic functions from the certificate authority are properly configured. Similarly, for Public/Permissionless Blockchains, ensuring validity and cryptographic integrity in “proof of work” mechanisms will be critical.
There is some paranoia around “Consensus Management” in Permissionless Blockchains that revolve primarily around how agreement is derived since its basically a voting system where more than 50% of the nodes need to agree on a transaction to make it effective.
This 50% agreement therefore implies that when more than half the computing power on a public blockchain mining network is controlled by an entity it can effectively certify false transactions. Of note is that it has been reported that in April 2016 over 70%’ of transactions on the Bitcoin network were flowing through four companies in just one country and most of them flowed through just two of those companies
For the Chaincode services functions, cyber defenders will want to pay particular attention to whether the chaincode relies on a virtual machine, computer language, or something like Docker to contain chaincode execution, each with varying degrees of risk.
In closing, despite the potential lack of ‘fit’ of blockchains into current security risk management paradigms, several core cyber defense tenets and practices should still hold true and perhaps will become even more foundational in blockchain implementations.
Further, the cybersecurity risk ‘lens’ that any particular blockchain implementation must be viewed through will depend on the particulars of the operational model of the blockchain architectural stack and network topology being deployed. This further underscores the urgency of having those charged with organizational cyber protections involved early in any corporate blockchain pilots or proofs of concept.