Article by: Morey Haber, Vice President of Technology, Office of the CTO, BeyondTrust
The level of hype around bitcoin, blockchain and cryptocurrency is absolutely amazing. When you hear an Uber driver talking about it, or your local news carries a piece on how a family paid for their daughter’s wedding with bitcoin, then you know that the hype is out of control. If you know anything about these technologies, excellent; you are ahead of the curve. Hopefully you have not realised too late that they actually have a limited place in business and need to be secured just like any other application; albeit with some curious twists.
What is blockchain? What is not.
A blockchain is an electronic ledger system that is distributed with copies residing on multiple nodes. Blockchains are not a database replacement, nor will future applications be that utilise them. They are a ledger system that secures entries based on work and verification. Natively, blockchain can only process a limited number of transactions per second and cannot store complex records or blobs – only ledger-style information that has a finite start date, like shipping information or inception and process dates.
Historical records, pictures, complex indexes and other large datasets are not good for blockchain technology. This is one of the problems everyone needs to understand. Think of a blockchain implementation like old school peer-to-peer network technology from Napster, LimeWire, or BearShare. Each node contains a database of all records and any new entries need to propagate to all other nodes for validity. While a peer-to-peer network queries its peers for entries, blockchain actually contains a duplicate of all entries compared to its peers. This means tampering with one node does not invalidate the entire blockchain; it means that an entry has to be properly validated (via work in the case of bitcoins) to be accepted as a ledger entry and propagated to other nodes. This is where security comes into play.
Entries into the blockchain ledger needed to be validated for fraudulent activity and more importantly, the hosts containing blockchain implementations secured against vulnerabilities and privileged attacks that could compromise or tamper with blockchain insertions. Blockchain implementations can have nodes that are explicitly trusted (commercial implementations) or out in the wild (like bitcoin) where the ledger could by anywhere at any time. To that end, there is no concept of blockchain ledger modifications (entry deletion or modification). This is key to protecting the integrity of the data. Once an entry is accepted, it is permanent. Therefore, if you can attack the server, application and ledger processes, you can tamper with the blockchain. This is how some of the recent cryptocurrency attacks have been occurring. The server and application have been the target, not the blockchain directly.
Blockchain implementations are only as secure as the applications that use them. Poor security controls for inserting data in the ledger will lead to tampering. In the case of bitcoins, beyond a 51% ownership of all bitcoin servers, the servers themselves validate mining via work. These are mathematical computations that prove; an insertion needs to be made and also proves who owns the bitcoin (mining).
The actual allocation of bitcoins is a more complex topic out of scope for this discussion. In either case, since they are distributed and verified by other servers, tampering is very difficult, if not near impossible, before an entry is made. Other cryptocurrency and blockchain implementations are currently nowhere near as secure for many reasons.
Securing blockchain
So how do we secure blockchain implementations? We begin with cybersecurity basic hygiene since the ledger operates on a computer just like any other application:
- Privileged access management to ensure all privileged access to the host is monitored and properly delegated
- Vulnerability management to secure the host and applications from tampering that could lead to inappropriate read or write blockchain ledger entries
- Patch management for prompt remediation, mitigation, or hardening to minimise risks
Once the basics are covered, we need to consider the unique characteristics of a blockchain and protect them:
- New entries into the blockchain should be secured with dynamic privileges and only valid for one time usage. This can be done with privileged password access solutions and keys or passwords using an API. An insecure insertion path into the blockchain can lead to devastating results.
- Reads from the blockchain should be secured in a similar fashion to ensure the retrieval is not tampered with (like a man in the middle attack) before processing by the application.
Since modifications and deletions of blockchain records are not permitted, all entries must be 100% valid or the entire model (ledger) could be compromised. Think of blockchains as just another application for data storage. It has limited data storage capabilities, is not very fast, but is designed to be highly distributed and 100% reliable. If your application or host can be tampered with, so can your blockchain. The goal, securing both during their design and implementation so this can never occur.
Sample blockchain implementation
To begin securing a blockchain, architects and security professionals must assume that the logic of the application approved an entry into the blockchain. This is dependent on the application using the blockchain and could be anything from bitcoins to a manufacturing or shipping application. Remember, once an entry is made, it cannot be deleted, modified, or suppressed; just linked with a new entry. This makes blockchains suitable only for ‘new’ information and not for any historical or complex data sets. Thus, all entries must be 100% valid by the business logic and be ‘short and sweet’ – think very small data records.
The question then turns to ways of securing that entry so that no malicious activity can occur outside of the business logic itself. Let’s start with this basic diagram and simplified workflow:
- The application’s business logic approves an entry into the blockchain. Without any additional PAM protection, the entry would occur through Transport A and potentially could be tampered with since no additional validation is present.
- The business logic of the application instead requests a one-time password or key from the PAM solution. This credential is valid for only one transaction (insertion or read) and can have additional access control parameters specified:
a. Source of blockchain ledger entry
b. Time to Live
c. Linkage to external logging or other applications - The privileged password management solution (Password Safe) then sets a one-time password or key in the blockchain application that has permissions to write into the ledger. This could be a privileged user with write permissions but its password or key is managed by the password safe itself. Once it is used, it is reset or invalidated.
- The key or password, once set for the blockchain user, is then sent back to the business logic.
- The business logic then uses Transport A with the one-time credentials to insert the ledger entry.
- Once complete, the business logic informs the password safe the task is complete and that the one-time password should be terminated.
- Password Safe then resets the user’s write-able account to a scrambled and unusable password or key by any other application to prevent rogue entries. Only the business logic can request a valid key or password, securely, for the next valid transaction.
While this workflow assumes a high-level of confidence in business logic and an application from tampering, it prevents a threat actor from maliciously reading and potentially writing to a blockchain. Since blockchains are inherently not a high-volume storage medium, you would only expect a few transactions per second and lag times are not critical to this process. This is nothing like the millions of transactions a second you would expect from an Oracle, IBM, or Microsoft database.
The security of the workflow is therefore managed in two parts – the business logic to approve an entry and the password safe technology to provide authentication for a new entry. Both must be satisfied for a write (or even a read if implemented) to secure the contents of the ledger. As the business community begins embracing blockchains for business applications, then security must become paramount concern due to its replication and ability to access ledger entries. Basic cybersecurity hygiene for privileged access management and password management can help make implementations secure above and beyond traditional database implementations, since once something is committed to the ledger, it will always be present. This twist on security is why securing your blockchain implementation is different than anything we have implemented in the past.
