In basic terms, a blockchain formation is a continuously growing list of records, called blocks, which are linked and potentially secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp and transaction data.
By design, a blockchain is inherently resistant to modification of the data and in effect forms a distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way. These properties lend themselves to several enterprises and a few security applications but the most useful are within access control, identity management, auditing and traceability.
At its core a blockchain can act as a shared distributed ledger with strict, yet customisable rules detailing how to place information into the ledger. This is as simple as it sounds. It is a ledger, beloved by accountants and the key detail of a ledger is that you can't go back and change a single item without having to rewrite the entire ledger. In a security context, creating a blockchain that records every access to an application along with every change to configuration files provides a valuable and immutable log. This use case could allow organisations to discover and assign culpability for security failures or even prove that they have followed security best practice to regulatory bodies.
Let's agree not to differ
The structure and shared nature of blockchains means the amount of work required to falsify information is immense making them as close to 100 percent verifiable as has been seen in the IT industry. Take a trusted process example such as a digitally secure contract transfer and signing process. In this scenario, if each party has a copy of the contract, either could tamper with it and claim their copy is the correct copy, but with a notary having a third party copy which cannot be changed suddenly we have created a case of irrevocable proof. This is ultimately the end goal of blockchain.
Blockchain implementations rely heavily on the concept of consensus, as it is the determining factor for who can write a piece of history to the blockchain. For Bitcoin, this must be done in a distributed manner as no single person can own the entire blockchain, else it is not actually shared. Within the enterprise, consensus may look a lot like voting, or even a request for approval and a sign-off approving said request. It could be a group vote where a quorum is required or even something more like a two-thirds vote. A simple security benefit could be in assigning permissions for application or data set access along with consensus-based proof as to who was allowed access to what, and when – along with proof as to what data was accessed.
Just because you can
There are many security applications for which blockchain could theoretically be used, but in practical terms, the technology has so many limitations that other existing solutions are simply more well equipped to support them. For example, current Security Information Event Management (SIEM) platforms that collate data from multiple sources could theoretically store these logs within a blockchain to ensure tamperproof data. However, there is no benefit when it comes to using blockchain to correlate anomalies within a mass of different historical and real time data elements.
For public blockchains, as they grow in length, the ability to add, check and verify transaction validity also grows in complexity. However, in private blockchains, a simpler consensus model negates this issue. In a real-time security application like Intrusion Detection Systems (IDS), where blockchain gains merit for ensuring veracity, a public blockchain is potentially weak due to the impact on the performance of the transaction.
More than blocks
Blockchain by itself is not inherently a security technology so it should be considered as an element within a wider data storage and transaction architecture. The useful properties it exhibits such as; distributed ledgers, consensual transactions and veracity can offer security professionals some useful building blocks to help create more effective security controls and logs.
However, the ability to direct the processing and analysing of files, tables, and event streams that are inherent within many security applications is not inherently within the blockchain architecture, but rather functions of the underlying data platforms used by the enterprise.
Blockchain will increasingly be part of the cyber-security landscape over the next few years but it won't be alone and when considered in isolation is unlikely to radically change critical security processes without a supporting ecosystem of data accessibility technologies.
Contributed by Jim Scott, director, enterprise strategy & architecture, MapR.
*Note: The views expressed in this blog are those of the author and do not necessarily reflect the views of SC Media UK or Haymarket Media.