Let’s face it, there’s been a lot of hype about blockchain over the past few years. Nowadays though, there are signs that we may be on the cusp of moving from the “blockchain will solve all your problems” segment of the hype cycle into the “blockchain may be useful for a few targeted applications” segment.
Yes, utility-based Darwinism is at work, where we’re starting to see the more bizarre and unlikely of proposed enterprise blockchain applications fall away, and only those places where it truly adds value continue to prosper. The shift will take time, of course, but ultimately blockchain use in the enterprise will continue to mature.
As a practical matter, though, there is a subset of security pros who have a very specific problem in the meantime: Namely, how do they validate the security model of an enterprise blockchain application for their environment? This can be quite a challenge.
After all, a detailed understanding of the mechanics of blockchain operation requires understanding concepts that practitioners may not be familiar with out of the gate, while an analysis of potential threats requires understanding new attacks and threats outside what practitioners normally encounter.
Likewise, the broader business impacts require an in-depth understanding of the business itself to see how blockchain will change operations.
No Validation Standard
To see what I mean, consider something like a 51 percent attack. For a blockchain application like a cryptocurrency, this refers to a situation in which adversaries are able to temporarily or permanently control a majority of the computing power, and therefore manipulate data stored on the blockchain as they see fit. (Holders of Ethereum Classic are right now becoming intimately familiar with this situation.)
Unless your organization’s security team has staff who are familiar with cryptocurrencies, through personal interest or because of off-hours speculation, this type of attack is probably unfamiliar to the security team. That said, depending on the specifics of usage, this very well can be something your implementation team needs to think about.
The answer for this, of course, is standardization. However, even though there’s no shortage of proprietary methodologies to help organizations gain assurance about blockchain deployments, enterprise use is still early enough that there’s no de facto assessment or validation standard.
In the meantime, therefore, it’s incumbent on practitioners to develop strategies for evaluating blockchain deployments — either to supplement the methods employed by specialists they might engage or to stand alone if they do not have sufficient resources to engage such specialists.
With those needs in mind, following are a few techniques that can be adapted to assessing and validating the security models in use for enterprise blockchain deployments. It goes without saying that the details of how to apply these techniques to your specific situation will vary according to the type of usage being planned, the security requirements, where and how you will employ blockchain, etc.
That said, the following techniques will almost always add value generically, regardless of specific circumstances, and they are flexible enough to allow adaptation to your specific implementation.
Technique 1: Application Threat Modeling
The first such technique we’ll discuss is application threat modeling. For those who are not familiar with it, application threat modeling is the process of systematically deconstructing an application into its component parts in order to view those components from an attacker’s point of view.
It’s a technique that is heavily used in application and software security circles. It lends tremendous value to validating application design, and selecting appropriate countermeasures to bolster points at which the application may be less resilient to attack. It can provide value to blockchain applications the same way that it can provide value to applications more generically.
A full description of how to perform a threat model for a given application would be too long to include here, but there are plenty of freely available resources (such as the OWASP Threat Modeling page and Microsoft’s free Threat Modeling Tool) that can outline the basics. The important part to remember as you’re doing it, though, is to account for attack techniques and methods of operation that are specific to blockchain implementations: for example, proof-of-work requirements, 51 percent attack scenarios, duplication of entries on the ledger (analogous to a “double spend” situation in a cryptocurrency context), denial-of-service conditions that could impact operations (analogous to liquidity considerations for a currency), etc.
Technique 2: Software Security Testing
In a similar vein, bear in mind that the software supporting a blockchain deployment is just that: software. Many of the problems that have disrupted cryptocurrency implementations adversely are fundamentally issues with software.
For example, the attack that brought down the Ethereum DAO (Decentralized Autonomous Operation — an organization operating entirely using smart contracts) was fundamentally a software error (i.e., buggy code) rather than attack on the underlying blockchain itself.
The impacts of software errors, then, are as critical for blockchain applications as they are for any other application. Therefore, just as you might consider employing static or dynamic application security testing for any other production application, so too should you consider doing so for blockchain applications — particularly for software written internally or customized heavily (e.g. from open source implementations).
Technique 3: Environmental Testing
In addition to evaluating the application and implementation of the blockchain, it’s important to validate the environment supporting the blockchain. This means testing the systems and supporting technology on which blockchain elements will run.
This can include vulnerability scanning and review of the systems themselves in the case of on-site components, as well as vetting of the provider if a Blockchain as a Service platform is used, or if other cloud components are used as part of the implementation substrate.
Technique 4: Outcome Monitoring
Lastly, as with anything, monitoring of the outcomes obviously is important to successful validation. Unlike the prior techniques, there’s obviously only so much monitoring that can be done before the implementation is live.
However, judicious use of monitoring can help ferret out business, technology, or other impacts that might be emergent in nature — i.e., only coming to light at scale once transactions start being recorded on the ledger.
These aren’t the only techniques that can be used to help validate a blockchain deployment, of course. That said, each of these elements can provide value regardless of the specific implementation or business use case for the blockchain deployment in question.
Each of these approaches provides value regardless of your specific business goals, your particular security requirements, or the implementation details of the blockchain deployment itself.
Loading ...
