BeyondTrust

blog-blockchain-privileged-access-management.jpg

A few days ago, I posted an article on how to secure ledger entries posted to a blockchain. The responses to that blog have been quite good, and a few readers asked how the mechanics of this would actually work. Using privileged access management (PAM) for password and key management, and its application programming interface (API), we can secure blockchain ledger entries after suitable business logic.

To begin, we 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 removed – just linked with a new entry. This makes blockchains suitable only for “new” simplistic information and not for any historical or complex data like a property, pictures, or blobs. Thus, all entries must be 100% valid by the business logic and be “short and sweet” – think very small data records.

The question becomes how to secure 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:

blog-blockchain-pam.jpg

1) 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.

2) 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 block chain ledger entry

b) Time to Live

c) Linkage to external logging or other applications

3) The privileged password management (PPM) solution, like PowerBroker 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 PPM solution itself. Once it is used, it is reset or invalidated.

4) The key or password, once set for the blockchain user, is then sent back to the business logic.

5) The business logic then uses Transport A with the one-time credentials to insert the ledger entry.

6) Once complete, the business logic informs the password safe the task is complete and that the one-time password should be terminated.

7) PPM then resets the user’s writeable 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 managed therefore 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. Ergo, how privileged access management can be used to secure blockchains and applications that use them.

As the business community begins embracing blockchains for business applications, then security must become of paramount concern due its replication and ability to access criteria attributes. If you’d like more information on how Powerbroker Password Safe can be used for this type of implementation, please contact us today.

You May Also Be Interested In: