Monitoring a Blockchain with a SIEM
In this article, I will explore the possibility of monitoring a blockchain network with a traditional SIEM tool. But first, some background..
What is a Blockchain?
At the risk of alienating the non-technical reader, a blockchain is a distributed data structure which stores records with a cryptographic integrity guarantee. This means that it is impossible for an adversary to alter a previous record without detection. This data structure is then shared amongst many entities in a manner where no single entity maintains control or authority. Therefore it is decentralised.
Much of the hype around blockchain technology is due to the growth of various cryptocurrencies. These are facilitated by public blockchain networks such as Bitcoin and Ethereum. A private blockchain network is one which has been implemented by an organisation, or group of participating organisations (known as a ‘consortia’), to facilitate more efficient business operations. These are otherwise known as permissioned blockchains. These networks will already operate with an inherent basis of trust between operating members. Yet there is still an element of risk associated with operating a private blockchain.
Despite the risks, many organisations are still looking to leverage the benefits of a private blockchain or Distributed Ledger Technology (DLT) to improve both operational and business performance.
But how are they being monitored?
What is a SIEM?
A SIEM (Security Information and Event Management) is a tool which performs threat detection through log collection and analysis. SIEM tools have existed for a some decades. They generally perform tasks such as: centralised log collection and analysis, dashboard visualisations, log correlation, and security alerting. SIEM tools also usually come bundled with other good stuff such as analytics and built in threat detection features. I will explore these features and evaluate their application to a blockchain network.
Why Monitor a Blockchain?
Due to their decentralised nature, blockchain networks present a large attack surface. In the case of private blockchain networks, there is a risk of significant financial damage if an adversary were to exploit a vulnerability in the network.
Software, network and protocol vulnerabilities aside, there remains the issue of blockchain governance. Monitoring activity on a private blockchain network will help to mitigate risk. This will allow blockchain members to focus on efficient business operations.
Many studies have been conducted into theoretical attacks on public blockchain networks. Many of these attacks are based on what is known as a 51% attack. This is where an attacker owns a majority of the hashing power of a network, and thus may be able to manipulate or influence the creation of blocks.
It is worth noting that 51% attacks only pertain to blockchain networks which utilise a Proof of Work (PoW) consensus mechanism. In a private blockchain network, the consensus mechanism is unlikely to be a PoW scheme. This means there is no concept of ‘mining’ as there is in the Bitcoin and Ethereum networks.
However, there is still the risk that an adversary may attempt to manipulate the behaviour of the blockchain nodes with malicious intent. To mitigate this risk, we need to monitor for anomalous network activity, and this is where our existing SIEM tools can come into play.
How do we Monitor a Blockchain?
Many tools already exist to provide monitoring of a blockchain network. Yet, these tools are generally focused on providing specific metrics related to the operational health of the network.
The inbuilt threat detection capabilities of a SIEM can lend themselves very well to providing threat detection on a blockchain.
To further explore this idea, I setup a small but functional private blockchain network. The private network is a five node Ethereum network. Each node is a Ubuntu virtual machine. Each node is running an instance of Ethereum Foundation’s go-ethereum implementation known as geth. Two of the nodes have been designated to mine blocks, while the other three nodes maintain the distributed blockchain.
As it turned out, the geth console logging can be rather verbose when it comes to node activity. For this experiment, I used the default logging verbosity of geth. For the experiment I only needed to ingest the geth logs into the SIEM. To achieve this, I configured the geth hosts to send their logging output to the SIEM via syslog:
On the SIEM, I configured custom regular expressions to parse the log output and reflect the criticality of the geth event types. I then setup a custom dashboard to display the results.
After all that, I ended up with this:
Let me break this down a little more. All Ethereum node log activity in my test network is visualised in a bar chart:
We can apply analysis to this data by firstly breaking it down into individual node activity:
And also displaying notable data points such as an overall count of transactions submitted to the Ethereum consensus chain:
SIEM Analytics
While this appears interesting, it is still only showing us specific network metrics and operational health. Yet, this information is still important to a SIEM as it provides enough data to develop a baseline. Baselining allows us to represent the normal logging behaviour of a node and so provide an sign of any deviation from the baseline.
Using the SIEM, we can apply analytics such as Deviation Analysis. This is when average values are compared to previous average values over a rolling time window. Deviation analysis will alert us to an instance where node behaviour deviates from that previously observed. This is one method to detect adversarial manipulation of a node.
To apply further analytics to my data, we can leverage the SIEM’s Risk Scoring feature to assign risk scoring to each of the nodes. Risk scoring will allow us to assign a risk value to each of our nodes, based on the weighted average of the risk scores assigned to values contained in the geth logs. These values are summed over time and allow for risk score decay in the absence of perceived risky behavior.
On the left, we can see the risk score assigned to each of our nodes. We can also define a risk threshold, beyond which a node has reached critical risk. On the left, we can see a distribution of the risk scoring which shows us how the risk has increased and decreased over time. An increase in risk levels beyond the critical threshold will warrant further investigation.
Lastly, a counter such as the one shown below can be effective dashboarding technique to provide a regular observer with their own perception of normal behaviour:
In a private blockchain network, the network operation outside of the actual transactions should operate consistently. Especially when compared to the wild-west of a public blockchain network such as Bitcoin. Analytic features included with a SIEM are quite powerful in identifying anomalous activity on a blockchain network.
Threats to a Blockchain Network
Now let us examine some specific threats to a blockchain network and discuss how these are addressed by a SIEM.
Existing Transaction Manipulation
By its nature, a blockchain possesses an append-only property for the ledger thanks to the magic of cryptography. If an adversary were to attempt to remove or alter an existing transaction, it would affect all following blocks and be obvious and easy to catch. In this case, a node could generate an event if the blockchain validation fails, for which we could configure an alert on our SIEM.
Double Spend Attack
In the context of crypto-currencies, a double-spend attack is where an attacker attempts to spend the same ‘coin’ twice in a row.
This could be applied to another blockchain network, where an attacker could attempt to execute the same transaction twice. Again, the nature of a blockchain implementation inherently solves this issue, and in fact this problem was the basis for Satoshi Nakamoto’s Bitcoin paper. It is also the rationale behind Bitcoin miner incentivisation.
In the Bitcoin network, to prevent a double-spend, a recipient must wait to ensure the transaction appears on the consensus blockchain to be sure that the transaction has been accepted.
As nodes will broadcast new transactions to the network, if we can correlate a transaction announcement with the same transaction written to the blockchain (by reading the actual blockchain itself), a SIEM could then detect a double transaction attempt.
Obviously, this is not applicable to a public blockchain network, but in a private blockchain network, we could theoretically accelerate overall operations by not waiting for confirmation of transactions to be written to the consensus chain, with the knowledge that a double spend attempt would be detected by the SIEM, and that there would be another non-technical form of recourse against the offending party.
Forking Attack
A forking attack is where a node will propose a block that contains alternate transactions. The idea behind this is that the attacker is attempting to invalidate existing transactions by ‘forking’ the chain.
Yet, for this attack to succeed the forked chain must overtake the current longest chain. In the context of Bitcoin, this is related to the theoretical 51% attack mentioned earlier. An attacker would need to own a majority of the hash power to mount this attack on the Bitcoin network.
While this specific type of attack is not applicable to a private blockchain network, the principle remains the same. That is, an adversary can attempt to manipulate the blockchain by forking the chain.
To detect this with a SIEM, we can track the creation of new blocks on the chain and detect when nodes propose earlier blocks. This will then alert us to potential forking attacks:
It is worth noting that in this scenario, each node requires the correct logging configuration for output to the SIEM. The SIEM monitoring would also operate in a centralised fashion. This somewhat goes against the idea of a blockchain network operating in a decentralized fashion. Yet, I will also point out that in a private blockchain network the nodes would not be anonymous. In a private blockchain network, the nodes already operate under a basis of trust. This means central configuration, monitoring and management is not out of the question.
Conclusion
With a small amount of customization, a traditional SIEM tool can provide a large amount of value when it comes to monitoring a blockchain network.
We can further extend this idea by exploring the possibility of applying machine-learning-based analytics to the data produced by a blockchain network.
But that will be the basis for a future experiment!
