Blockchains are the latest darling of the technology world. Enterprise blockchains promise to unify and secure transactions and data records between disparate organizations through the use of cryptography. Because this technology is new, researchers are coming up with innovative ideas and new applications every day. In fact, IBM has built more than 700 enterprise blockchains in the past year.

Fundamentally, a blockchain is a data structure. We could certainly use this structure for security purposes. (Indeed, the market for security tools based on blockchains has only started to emerge.) We could hypothesize hundreds of ideas for this technology.

But first things first: How can organizations secure enterprise blockchain platforms and applications?

The Enterprise Blockchain Platform

An enterprise blockchain platform typically includes:

• A network of organizations which have agreed to share the platform;
• Organizations that are members of the network, with varying levels of authority over data and transactions;
• The fabric of the platform, which includes all the shared systems, infrastructure, applications that manage the blockchain, functionality and use cases;
• Applications that interact with and affect the data of the blockchain;
• The blockchain data, including the information stored within the blockchain and the data elements for which the members are authorities; and
• A vendor who creates and likely hosts the blockchain platform.

Enterprise blockchain platform providers are typically cloud-based to provide dynamic scalability, neutrality and consistent access. Therefore, the components and security are often a black box — but that doesn’t mean security is guaranteed. Before selecting a platform vendor and joining a blockchain network, an organization must undergo extensive legal review and conduct cross-network trust, governance and technology reviews. Security needs to be part of all of these evaluations.

Some vendors’ enterprise blockchains include applications used by end users, while others are simply systems exposed via application programming interfaces (APIs). Regardless of their type, the applications require the same security controls as other enterprise applications. Each component must adhere to and leverage corporate policies, standards, processes and technology for continuity and operational efficiency.

In the interest of building cross-network trust, it is also important to share and enforce consistent application security control information among the member organizations.

Platform and Application Components

The components underlying the enterprise blockchain platform will likely be unknown to the member organizations. Unless a company develops the blockchain platform itself, it won’t be possible to understand the technology in-depth. Let’s assume that the platform contains the components shown below. As you can see, these are typical components among enterprise applications.

Enterprise blockchains include a “secret sauce” in the form of the fabric code. This code defines the data structures, functionality and capabilities each member has to use the blockchain. To a certain extent, this fabric can be standardized — but, as of now, every fabric is bespoke for the network.

Similarly, the applications that interact with the platform use familiar architecture components. The business logic and functionality are in the application code and configuration information. Since each member organization’s blockchain application is likely created and managed separately, each member organization should have full control over its application and components.

As security professionals, we care about the security of each component of both the platform and the application, and especially the coding practices of the fabric and application code. Therefore, we need to apply as many corporate security policies and tools as possible for consistency and operational efficiency.

Vendor Selection and Validation

On the surface, the blockchain network includes the other member companies. In reality, the most important unofficial member is the blockchain vendor. We all have policies and procedures for assessing vendors — these are often merely rubber-stamp assessments.

Given the sensitivity and impact of enterprise blockchains — the impact on multiple companies and the potentially critical nature of the data — this assessment needs to be more comprehensive. A simple request for proposal (RFP) won’t suffice — and a third-party security audit report is just a start.

An assessment should also consider:

• The size and reputation of the company;
• Security for each component in the platform;
• The security stature of each member of the network;
• Minimal storage of sensitive data in the blockchain;
• Proper data life cycle controls, such as creation, management, validation, encryption and destruction;
• Quantum-proof encryption and technologies to ensure that the blockchain cannot be decrypted or corrupted in the future as quantum computing becomes mainstream;
• Capacity for growth and assurance of performance as the size of the blockchain grows;
• Availability, uptime and disaster recovery capabilities of the platform;
• Component patching and maintenance processes;
• Privileged access control and a responsible, accountable, consulted and informed (RACI) matrix within the vendor and among the members of the network;
• RACI for operations and support activities within the vendor and among members of the network;
• Reliability of the cryptography management; and
• Testing to prove transaction integrity.

Over time, market leaders will rise, and their security will be proven — as was the case with cloud providers in decades past. Until then, organizations must conduct their own comprehensive evaluations before investing in a blockchain vendor.

Blockchain Platform Security Considerations

After assessing the vendor’s secure posture, the next major task is to evaluate the platform itself. This step is really an extension of the vendor assessment, but it requires participation and agreement by the other member organizations.

Legal and Contractual

All aspects of the enterprise blockchain platform, network and fabric must be defined contractually. Of course, security must be a substantial part of this. This part is likely the most difficult consideration because all members must agree. More members means longer legal reviews and more red lines.

Liability is an important element of this assessment, and each company likely has different requirements driven by their legal departments. For this reason, it’s critical to explicitly define the liability of each member and the vendor in the event of a security violation or breach.

Functional Use Cases

Start with the use cases. Define them contractually and via detailed designs with the vendor. These will typically include things like “create transaction,” “approve transaction,” “look up data” and other business functions. Security activities and component interactions — such as multifactor authentication (MFA), validation of entitlement to approve transactions, encryption and decryption and API security — should be included in each of these use case definitions.

Network Governance

Members often govern themselves, with some minimal participation from the vendor. It’s important to understand the roles of each member, the individuals who have authority within the member organizations, the cadence of activities, dispute resolution, reporting among constituents and many other areas. In other words, organizations should apply a consistent security program to both members and the blockchain vendor.

Cloud-Based Security Controls

The security frameworks from the Cloud Security Alliance (CSA) and similar groups are good foundations on which to assess the blockchain platform. While it would be nice to have full visibility into the platform components, most vendors won’t reveal their intellectual property.

So, the member organizations must ask questions and quantify and qualify as much as they can. The CSA provides a good framework to solicit detailed answers.

Shared Operations

The blockchain vendor will likely do the technology-level hosting and maintenance, but the members need to perform specific operational tasks too.

All tasks — ranging from server operating system (OS) hardening to blockchain data validation — must be defined. Security operations and controls, such as rolling encryption keys, periodic penetration testing, incident response and forensics and patch and configuration management, require the participation of many or all members.

Data Ownership

The best practice is to avoid storing sensitive data on the blockchain — only shared and reference information should be included. This tactic keeps the size manageable and the performance of the blockchain as high as possible. It also means data is distributed among the authoritative parties.

Therefore, it is essential to define and codify which member owns each data element, how it can be accessed or validated, who can access it and how the owners will protect it. This is especially complex when multiple members may be authoritative for the same data element under different conditions. It’s also significantly impacted by General Data Protection Regulation (GDPR) requirements if personally identifiable information (PII) is being stored.

Security Testing Other Members

The security of other members is an important part of building trust within the network. So, annual third-party security testing, including penetration testing, vulnerability scanning and policy reviews, should be mandatory for the applications used by all members, and the results should be published to all other members.

How to Secure the Blockchain Application

The security around each enterprise blockchain application — assuming they are managed separately by each member — is much easier to control. In general, these should be secured like any other enterprise application, with the following special areas of concern.

Implement Corporate Security Standards and Systems

All corporate policies, standards and common security platforms should be used. This provides consistency, reliability, familiarity and operational efficiency.

For example, the enterprise-standard identity and access management (IAM) tools should be used for authentication, MFA, access control and identity data storage. Similarly, the secure software development life cycle (SDLC) and application-scanning tools should be used to ensure secure code development and deployment.

If integration patterns or specific security policies don’t exist for the technologies used, take this opportunity to develop them.

Assume Highest Data Classifications

Assume the blockchain will manage data of the highest risk classification. Even though your member organization may not manage or access confidential information, other members might. Assuming the highest data classification also demonstrates a commitment to other members about security — thus building trust among the network.

Mandate MFA

Humans are often the weakest link in security, and MFA helps counter this risk. MFA has become the de facto standard for cloud-based applications, and it should be used for blockchain too. This is driven by the distributed nature of blockchains, the potential sensitivity of the data and the need to instill trust among other members.

Mandate Identity-Aware API Security

Most blockchains rely on APIs, and this will continue for the foreseeable future. API security best practices include user identity and session information associated within each API call. This should also be the standard practice for blockchain applications because it provides an audit trail and allows function-level entitlements to be applied.

Mandate Strong Cryptographic Key Management

Ensure that your organization has a strong and reliable key management system. Blockchain is based on the use of encrypted data, and a blockchain network might contain hundreds of encryption keys. It requires a lot of effort to manage these keys manually, but it’s essential to protect the data and the member organizations.

Correlate Security Events

Members should share security event information as transparently as possible. Nondisclosure agreements (NDAs) should allow members to pass security incident forensic information. While it may be difficult to share one security information and event management (SIEM) system, security event feeds should be established from the platform to the members and for selected event information between members.

A Bright Future for Enterprise Blockchains

There’s no telling what the future holds for this versatile and complex distributed ledger technology. If implemented correctly, enterprise blockchains offer tremendous advantages and unprecedented capabilities to unify and secure transactions between disparate organizations.

But until the market catches up and security standards are established and widely followed, it’s crucial for businesses to thoroughly assess the security posture of blockchain vendors and evaluate the ability of their own technology infrastructure to integrate with the blockchain platform.