Blockchain has the potential to be one of the most disruptive technologies since the invention of the Internet. There is an entire class of problems with distributed reconciliation of data entries that this can potentially solve. The creators of Blockchain saw past its initial usage for cryptocurrency implementation toward a future where many distributed applications can utilize this technology to craft auditable and verifiable solutions for a variety of problems. Healthcare and finance, in particular, will benefit greatly.
However, in the initial euphoria about Blockchain, there are notes of caution. While this is a new technology, this does not change the basic tenets of information security. We have to be very careful to reconcile implementations with the requirements of the HIPAA Security Rule, HITECH Act, and if used for financial or Revenue Cycle transactions, the guidance issued by the American Institute of Certified Public Accountants (AICPA). Auditors use the AICPA guidance to audit systems of record, and their focus is much like the HIPAA Security Rule, which is on providing provable, auditable, reasonable, and appropriate safeguards to protect transactional and data integrity. While the HIPAA Security Rule focuses on patient data and electronic medical records, the AICPA guidance focuses on general ledgers and accounting. With Blockchain, these two worlds converge.
With that, we will focus on four ways we can improve the security of Blockchain in healthcare and provably implement systems that meet HIPAA and AICPA requirements. By first, storing the minimum necessary data on the blockchain, enforcing collaboration to always ensure that there is never a computational majority, having distributed accountability for systems security, and finally, enforcing strong identity and key management processes, we can meet those security standards.
Blockchain is a loosely defined format. There is no limit on what information can be stored in it. The insults hurled at the FBI using Blockchain messages on Bitcoin after the Silk Road takedown are direct evidence of that. The HIPAA Privacy Rule and Security Rule both enforce the principle of minimum necessary information. In addition, there is no current way to effectively enforce auditing read access of Blockchain implementations. This means that there is no way to safely put Protected Health Information or any information that can be reverse-engineered to reveal it on the Blockchain without compromising it, even private Blockchain.
What is possible, however, is to store either direct links to systems storing PHI that require authentication that also audit access, or the cryptographic checksums of PHI that probably cannot be reverse-engineered. If you do store PHI on your Blockchain, you then have to assume that anyone who has access to it has access to all of the information in it, and if there is a breach of that information, all of that information will be considered breached as there is no way to prove otherwise. Combining the use of systems with authentication and auditing with cryptographic checksums to verify and validate data improves security and provides a distributed method of proving it. Storing data itself on a Blockchain weakens it by removing audit controls.
Another way to weaken Blockchain is the 51% problem. This is the case where if some entity has control of more than 50% of the computational power in it, that they will be able to literally rewrite history and alter transactions. The major purpose of it is to provide a distributed verification and validation process which is predicated on the principle that no one entity has a majority. Any implementation of Blockchain in healthcare needs to have strict contracts, covenants, and controls where all entities monitor the total processing power and usage, and make sure to either increase or dial back the processing power utilized to verify and validate transactions.
The recent implementations of Blockchain as a Service (BaaS) from IBM and Microsoft provide the technical mechanisms to do so for most organizations. All parties involved need to adhere to this principle. The reason why is because it is a basic tenet of both HIPAA and AICPA guidance to protect the confidentiality, integrity, and availability of data. Having one entity in a distributed system with the ability to change all three by having the power to alter data violates that.
With distributed systems comes distributed accountability. While the technology behind Blockchain is sound based on current cryptographic standards, there will always be vulnerabilities in the implementations of said systems. Whether it be the potential for introducing predictable patterns into one-time-pad implementations, as Neal Stephenson illustrated in the book Cryptonomicon, or a more real-world example such as the Heartbleed and KRACK vulnerabilities, there will always be weaknesses.
The issue with Blockchain is that they have the potential to not only affect the integrity of data for one entity, but also for all Blockchain participants. Organizations need to realize that this will affect them. Participants in both public and private Blockchains need to have a strong vulnerability management program and shared security standards in place. Just because the system uses strong cryptography does not mean it is immune.
Private blockchains need to strictly enforce this via contracts, covenants, controls, cross-monitoring of systems, and allowing other participants to view, manage, and potentially exclude transactions from all participating entities that do not meet standards. Under both the HIPAA Security Rule and AICPA guidance, organizations are required to have programs that continually assess and address risk. Making sure that Blockchain implementations meet these standards via multiple means is one larger step toward acceptance. Systems such as Mt. Gox were compromised through bad vulnerability management and associated processes.
This also extends to downstream systems that output data to Blockchains. Just because a system outputs data to one does not mean that the data itself is secure. There has been a push to use Blockchain to store data from Internet of Things (IoT) devices. While this is an excellent way to aggregate data from a number of devices in one verifiable place, it does not change that systems need to generate this data using a verifiable and valid process. Blockchain cannot be used as a step to validate system integrity for the IoT, or provide integrity to data generated from legacy systems that cannot be effectively mitigated for risk or documented. Implementation of a Blockchain system requires full end to end integrity and a verifiable process, or else you’re doing nothing more than validating bad data with cryptography.
Verifying process also means verifying who makes entries. The current Blockchain implementations do not provide for strong identity management, nor should they. Identity Management is a distributed process that shows, in a series of steps, how an entity is able to gain access to a set of systems, with periodic checks to ensure validity of said entity. Both the HIPAA Security Rule and AICPA guidance require that access to transactional systems, whether they have PHI, financial, or Revenue Cycle data, have strong identity management processes behind them.
What this means for Blockchain is that private implementations need to have shared processes that all parties agree on, enforced by contracts and covenants, that demonstrate that only entities who need direct access to either read or create/alter entries are authorized to do so. Shared provisioning, de-provisioning, and validation processes are a must. Just because the system is distributed does not mean that each entity can continue existing processes. To ensure total system integrity requires the adoption of shared identity management processes that meet industry standards, and are auditable by all parties. The continuation of existing processes means that there are potentially components that cannot be audited.
As another part of this, strong key and certificate management processes are a must. There needs to be a set standard for usage and continual management of encryption keys and certificates from a trusted certificate authority that all parties agree to, enforced using both technical and contract means, to ensure that only trusted certificates are used as part of the verification and validation process.
The compromise of multiple certificate authorities such as DigiNotar to issue certificates in the names of major companies such as Google and Microsoft only show how important this step is, as impersonation is a very real possibility. The usage of self-signed certificates as part of a Blockchain implementation does not provide a verifiable step that demonstrates that encryption follows a known good provable methodology. Reputable certificate authorities have multiple checks and balances to ensure the integrity in the certificate generation and issuance processes, and are regularly audited. Self-signed certificates do not have that integrity or process behind them.
Blockchain is full of promise for healthcare, finance, and Revenue Cycle. It has the potential to dramatically increase integrity and collaboration, and provide for distributed applications that once were not thought possible. However, there are still vulnerabilities to address. By reducing data to what is absolutely necessary, having shared vulnerability management across all participants with strong agreed-upon standards, even for downstream systems, enforcing collaboration and preventing a computational majority, along with strong identity management, HIPAA and AICPA standards can be enforced, even in a distributed environment, and security can be increased for all participants. This leads to Blockchain being disruptive in a positive way by increasing integrity and security, and enabling a new class of applications and services that benefit healthcare at all levels.