This article highlights the blockchain security reference architecture that can be applied across blockchain projects and solutions for various industry use cases and deployments that span on-prem and Software as a Service (SaaS) environments. It examines the security risks and threats that are unique to blockchain, and then introduces key blockchain security controls, alongside business controls and conventional security controls. Finally, the article illustrates a blockchain security reference architecture and security model that can be used to secure any blockchain solutions.

We strongly recommend that you review the solutions that you design and architect against this blockchain security model to ensure that all measures are in place to adequately secure your blockchain solutions.

Blockchains — not immune to cyber-attacks

Blockchain is a shared, replicated, and permissioned ledger with consensus, provenance, immutability, and finality. The shared ledger ensures that participants can decide which assets to share, and enables them to know the identity of the other participants that they are dealing with. Blockchain also provides participants with provable endorsement, which comes with confidentiality — information shared only on a need-to-know basis.

It’s no secret that blockchain and blockchain applications are not immune to cyberattacks and fraud. Here are a few examples:

  • The Decentralized Autonomous Organization (DAO), a venture capital fund operating through a decentralized blockchain inspired by bitcoin, was robbed of more than $60 million worth of Ether digital currency (about one-third of its value) through code exploitation.

  • A theft of nearly $73 million worth of customers’ bitcoins from one of the world’s largest cryptocurrency exchanges, Hong-Kong-based Bitfinex, demonstrated that the currency is still a big risk. The likely cause was stolen keys.

  • When Bithumb, one of the largest Ethereum and bitcoin cryptocurrency exchanges in the world, was recently hacked, the data of 30,000 users were compromised, and $870,000 worth of bitcoin was stolen. Even though it was an employee’s computer that was hacked — not the core servers — this event raised questions about the overall security.

Addressing and examining the key security issues/risks for blockchain helps ensure the security of blockchain solutions.

Security risks associated with blockchain-based solutions

Security is about risk management, so it’s important to start with an understanding of the risks associated with blockchain solutions. The specific risks of a blockchain solution depend on the type of blockchain being used. Let’s take a look at the various types of blockchains with decreasing levels of risk and increasing levels of security:

  • Public blockchains are public and anyone can join them and validate transactions. They are generally more risky (for example, cryptocurrencies). This includes risks where anyone can be part of the blockchain without any level of control or restrictions.

  • Private blockchains are restricted and usually limited to business networks; membership is controlled by a single entity (regulator) or consortium.

  • Permissionless blockchains have no restrictions on processors.

  • Permissioned blockchains allow the ledger to be encrypted so that only relevant participants can see it, and only those who meet a need-to-know criterion can decrypt it.

There are a number of other risks with blockchain solutions, and they can be broadly categorized into three areas:

  • Business and governance: Business risks include financial implications, reputational factors, and compliance risks. Governance risks emanate primarily from the decentralized nature of blockchain solutions, and require strong controls on decision criteria, governing policies, identity, and access management.

  • Process: These risks are associated with the various processes that a blockchain solution requires in its architecture and operations.

  • Technology: The underlying technology used to implement various processes and business needs may not always be the best choice, and this can ultimately lead to security risks.

Some of the examples of these risks are captured in Table 1.

Table 1. Risk category and associated risks with description

Category Risk Risk description and examples
Business and governance Decision making A blockchain solution has a decentralized governance process that creates risks around lack of control over policy compliance and decision making.
Access controls Lack of centralized governance can also cause reduced control over who can access the platform and the level of access provided to every user. This can be a larger issue if members have different ways of categorizing users in their respective organizations.
Financial Financial risks in a blockchain solution come primarily from risk of fraud transactions and critical data loss due to potential security breaches.
Audit, legal, and compliance risks Certain operations on the platform may rely on data that is stored on-chain or validated by data on-chain. This can cause challenges with compliance regulations and compliance with system and application audits. It can also introduce legal risks that define the liability of the data in question.
Process Identity and access management (IAM) Unauthorized access to the platform can result in dire consequences for members with critical data loss, suspension of operations, and denied access. Lack of IAM can also cause incorrect invocation of certain smart contract functions.
Secure communications Insecure communications between different nodes within the solution or between the solution and external components may result in misdirection, which in turn can lead to transport-level security issues. This can also raise challenges related to access permissions and threats from insider attacks.
Vulnerable solution (untested codes) Untested codes or solutions that come through non-DLT-certified processes or methodologies can be vulnerable to hacking and may impact the overall business and operability of the solution.
Blockchain identity keys on hardware security module (HSM) When using a shared HSM for storing blockchain identity keys, a set of keys for one organization can potentially be mixed up with those of another organization.
Infrastructure security The underlying infrastructure that is deployed for architecting a blockchain solution can have numerous issues, including unnecessary access and unwanted packets trying to get into the network.
Technology Storage, expiration, and malfunctioning of keys Blockchain identity keys and transaction tokens are an important component of the solution. Challenges with certificate and key expiration, renewal, archive, and revocation can bring huge risks to the functioning of the platform.
Application security The blockchain itself is immutable and tamper-proof, but the applications that leverage the network pose challenges at every level.
Validation and authentication of shared ledger It is important to understand the validity and the authenticity of the shared ledger. This is also an emerging technology and associated risks are sometimes unknown.
Risks in smart contracts Smart contracts are an important component of a blockchain solution, and any logical flaws in the implementation of these contracts or their transactions can result in validation of incorrect contracts or transactions.
Risks with deletion, auditability, and consensus It is important to consider the risks of deleting parties when one party leaves the consortium and apply the appropriate procedures. The distributed network setup in blockchain is prone to auditability and consensus risks.

It is important to analyze the risks highlighted above in order to then derive a risk model for the blockchain-based solution. Some key considerations for designing a blockchain solution include:

  • What are the specific features that are unique to blockchain?
  • What is the governance model for participating organizations/members?
  • What data will be captured in each block?
  • What are the relevant regulatory requirements and how can they be met with blockchain?
  • How are the details of identity managed? Are block payloads encrypted? How are keys managed and revoked?
  • What is the disaster recovery plan for the blockchain participants?
  • What is the minimal security posture for blockchain clients for participation?
  • What is the logic for resolving blockchain block collisions?

Blockchain security threat models

The security of a solution should also be evaluated in the context of its threat model. Blockchain, by nature, has robust record integrity guarantees, however a number of things can go wrong in other parts of a blockchain-based application that can lead to compromise and loss. Some examples include weak access controls, loose key and certificate management protections, and insufficient communication security. The key to properly securing such an application is to develop a comprehensive threat model for it and mitigate identified weaknesses.

One well-known model is the Spoofing, Tampering, Repudiation, Information disclosure, Denial of service attacks, and Elevation of privilege (STRIDE) model that is used to study relationships between the actors and assets, review threats and weaknesses related to these relationships, and propose appropriate mitigations.

Blockchain applications often incorporate external components — Identity and access management (IAM) systems, multi-factor authentication (MFA), public key infrastructure (PKI), and regulatory and audit systems — that are owned and managed by actors. These systems need to be carefully scrutinized before they can become part of the overall solution as they are developed or controlled by third parties. These should be taken into consideration for the threat model in a blockchain solution.

Figure 1 takes into consideration the various factors and derives a threat model that can be applied in a blockchain-based implementation.

Figure 1. Threat model in a blockchain solution

Threat model in a blockchain solution

The threats illustrated in Figure 1 can be classified into three main categories:

  1. New threat landscape — these are threats that are specific to blockchain.
  2. Conventional threats that take on new meaning — with the addition of blockchain, conventional threats bring in new meaning adding new threats.
  3. Conventional threat management — these are the business-as-usual threats that needs to be addressed for any solution.
1

New threat landscape

  • In this unique IT infrastructure, blockchain introduces new paradigms that may not be fully understood. Most of the vulnerabilities lie in the various individual components and the way they are stitched together.
  • The system includes a multitude of actors, each of whom may come with their own identity management mechanisms — so it can be a challenge to establish the mutual trust mechanisms necessary for proper management of consensus.
  • It’s important to strike a balance between the detail of information that’s collected in order to properly identify system actors, and the need to securely manage and dispose of that information to satisfy privacy legislation (GDPR and others).
  • Attacks need to be identified across a distributed landscape of assets.
  • Coordination of detection, response, and recovery across all network participants is a must.
  • “Structured” attacks may only be identified through analytics across multiple network participants. Attacks against a blockchain are most likely to succeed when directed towards the supporting application and infrastructure. Relationships between participants and different parts of the system have to be carefully orchestrated. Attackers may try to exploit the complexities in the system and conduct attacks that exploit these relationships in subtle ways.
2

Conventional threats that take on new meaning

  • New vulnerabilities in the blockchain infrastructure and tampering with smart contracts can lead to new threats.
  • In a decentralized blockchain solution, user impersonation and improper elevation of privilege can lead to new threats.
  • External data in a blockchain solution can be tampered with or stolen, which can, in turn, lead to a threat in an overall blockchain solution.
  • Compromised or tampered keys and certificates can lead to a threat in a blockchain solution
  • Disruption of services can also be a threat.
  • Malicious transactions/repudiation can give rise to additional threats.
3

Conventional threat management

  • Penetration testing is key in any solution and applies to a blockchain solution as well.
  • Vulnerability scanning of the entire solution mitigates considerable known threats.
  • Threat insights, detection, and remediation procedures need to be put into place.
  • Incident response and recovery plans should be put into place.
  • Best practice identity management mechanisms need to be put into place.
  • Business continuity planning/disaster recovery is key in any blockchain solution.

Individual blockchain-based applications are sufficiently different that it’s not feasible to build a universal threat model. Yet these apps are frequently associated with a number of similar actors, assets, and use cases. In this article, we propose a threat model for these common elements that can be used as a template that would serve as a starting point for more detailed security analysis in specific projects.

What’s needed for a secure blockchain solution?

For a secure blockchain solution, start by developing a risk model that can address all of the business, governance, technology, and process risks.

Next, evaluate the threats to the blockchain solution and develop a threat model as shown in Figure 1.

Define the security controls that mitigate the risks and threats based on the following three categories:

  • Enforce security controls that are unique to blockchain.
  • Apply conventional security controls.
  • Enforce business controls for blockchain.

Security controls unique to blockchain

  1. Treat the underlying infrastructure of the blockchain solution as critical infrastructure.

    • This ensures that all required security practices are in place. Adopt and enforce an industry standards certification.
  2. Partition and adopt best practices for namespacing to regulate access.

    • The solution needs to be partitioned by means of channels and namespacing so it can host digital assets for all members of the platform. Namespacing allows it to regulate access to the digital assets hosted on the platform. Completing this up front also helps with cost savings, since making changes later on may require rework. Leverage best practices for partitioning within the network, outside the network, and within the organization.
  3. Define and enforce the appropriate endorsement policies based on business contracts.

    • The blockchain solution utilizes endorsement policies to define the criteria that must be met in order to confirm that a submitted transaction is valid. Examples include the number of signatures required and from which organizations. These policies should be bound to a smart contract to factor in the security of the business network and any digited assets and data that are associated with that contract. As a best practice, these policies need to be scoped and specified on a namespace level (for the whole smart contract) as well as on a ledger key level (for single entries in the world state database).
  4. Enforce identity and access controls to access the blockchain solution and data.

    • Define policies that ensure the right level of access to the right individual for the right use. New members should be on-boarded into the blockchain platform through appropriate identity and access mechanisms. The off-boarding process should also be defined to stop any information exfiltration (malicious activity performed through various different techniques). Audit logs and access processes need to be put in place to alert the operations team of any malicious activity so it can be mitigated.
    • If the organization is using the in-house IAM system and playing the role of identity provider (IDP), appropriate tokens like OAUTH, OIDC, and SAML2 should be used to perform the authentication, verification, and authorization. This applies to other consortium members as well. Key decisions around whether the consortium members are IDPs or service providers (SPs) should be made up front.
  5. Enforce the hardware security module (HSM).

    • It’s critical to use a HSM to secure the blockchain identity keys. It is equally important to ensure that each organization has its own partition in the HSM where the keys are stored. Using the HSM to store the blockchain identity keys ensures the security of the keys. The HSM partition process ensures that each organization has a separate partition with separate admin rights and roles (crypto officer, crypto user, super admin, etc.) to perform partition operations on each different partition.
  6. Use a privileged access management (PAM) solution for escalated actions.

    • Use a PAM solution to ensure that the appropriate users with the appropriate privileges access the components for administrative or change management purposes. This is especially important since the platform may have confidential information, including payment transactional data for users and members.
    • A PAM solution should be put in place with password rotation and efficient separation of duties. It’s also important to configure end-to-end logging to capture flows from entry to exit. Access to secrets should be linked to a ticketing system, and every secret release should have a reviewer. Every instance of administrative access should be traced to an approved ticket or change.
  7. Use API security best practices to safeguard API-based transactions.

    • APIs are the primary form of communication between the different parts of a blockchain solution. APIs need to be protected from any improper use and limited to the scope of the transaction. While API security encompasses a number of things, three key controls should be enforced for all APIs: identification, authentication, and authorization. It’s important to leverage an industry standard like OAUTH, not only to standardize the interactions but also to secure the APIs.
  8. Leverage a secrets-store for both application and privileged access.

    • The blockchain solution has a number of components that interact with each other with both user- and API-based transactions. Some of these transactions are based on static keys like passwords, tokens, or certificates. These keys must be stored in a secrets-store (where keys are encrypted), and access at runtime needs to be limited based on usage. The secrets-store needs to support granular audit for compliance and threat management.
  9. Adopt a data classification approach to safeguard data/information.

    • Identify and classify data related to business, legal, and technical issues so that the appropriate information security controls can be applied to safeguard data and privacy. Data classification must be enforced on an ongoing basis for all members of the blockchain solution.
  10. Use privacy-preserving technologies for sensitive information.

    • Leverage permissioned ledger technology where privacy is a design principle, and provide controls to safeguard members’ privacy information. In addition, enforce privacy-preserving security controls to hide transaction information, such as the identity of the transaction creator and the transaction details.
  11. Protect applications from vulnerabilities and safeguard data.

    • Leverage DevOps to automate application vulnerability scanning during the development lifecycle. It is also critical to implement data security at various levels (such as application and database) in line with the data classification analysis.
  12. Enforce access control in smart contracts.

    • Smart contracts are a key part of a blockchain solution, and they enforce policies that are aligned to business objectives — therefore, all aspects of smart contracts need to be secured. Specific focus should be applied to access control to smart contract lifecycle management, fine-grained access within the smart contract, and processes or applications with which the smart contract will collaborate.
  13. Leverage Trusted Platform Modules (TPMs) for sensitive code execution.

    • Certain solution components are more critical than others, and these critical components should use trusted platform modules. This helps with storing cryptographic material — enabled by HSMs. They also enable privacy-preserving chaincode execution such that the node’s administrator cannot tamper with the execution without being detected.
  14. Secure communications both internally and externally.

    • Ensure that all communications on the platform between components that interact internally and externally go through a highly secure channel. This can be done using mutual or standard Transport Layer Security (TLS) solutions. Additional levels of security can be used, including IP whitelisting and frequent key rotation.

Conventional security controls

  1. Use corporate security standards and systems to ensure a secure software development lifecycle, application scanning, and appropriate security policies.

    • All corporate policies, standards, and common security platforms should be used. This provides consistency, reliability, familiarity, and operational efficiency.
  2. Enforce identity and access management capabilities for user on-boarding.

    • Use enterprise-standard identity and access management (IAM) tools for authentication, access control, and identity data storage.
  3. Mandate multi-factor authentication.

    • Mandate multi-factor authentication (MFA) for access to the blockchain, along with the standard IAM tools. Users and administrators must use MFA with no exceptions.
  4. Use strong cryptographic key/certificate management.

    • Use a strong and reliable key management solution to manage the number of keys used in the blockchain solution, including blockchain identity keys, internal TLS certificates, external TLS certificates, and domain certificates.
    • Use an efficient internal PKI solution to manage internal TLS certificates.
    • Make the proper certification authority decisions for external TLS certificates.
  5. Leverage security incident and event management.

    • Organizations need to establish security event feeds from the platform to the members, and for selected event information between members. Security incident and event management (SIEM) across all components in the architecture is critical.
  6. Leverage hardware security.

    • Leverage a hardware security module (HSM) to store critical key data. Since the proposed platform has multiple members, the proposed architecture needs to evaluate HSM and its impact. A common open protocol for using HSM is required to proceed on the platform.
    • Store the keys in appropriate partitions with controlled access for members.
  7. Enforce application security.

    • Applying security measures for individual components ensures that the overall solution has no security breaches.
  8. Enforce infrastructure security.

    • Infrastructure security of the network and the data that is stored on the platform is key. The underlying infrastructure (including all software and hardware components) on which the blockchain solution is deployed needs to be secured.
  9. Perform full-scope penetration testing and vulnerability assessment.

    • Be sure to perform full-scope penetration testing at every phase of solution deployment. It’s important to perform vulnerability assessments at the individual organization component level and for the overall system in order to ensure all issues are addressed.

Business controls

  1. Define and implement security governance.

    • Make sure to put security governance in place through various policies, access control mechanisms, and reporting.
    • Define an exclusive governing law for the platform, regardless of node location, to ensure that the customer has security and certainty of the laws governing disputes and legal claims.
  2. Ensure that compliance and legal controls are in place.

    • Liability is an important element, and each organization is likely to have their own unique requirements that are driven by their legal departments. For this reason, it is critical to explicitly define the liability of each member and the vendor in the event of a security violation or breach. Confirm compliance with system and application audits to ensure that this risk is mitigated.
  3. Define, scope, and implement operational controls.

    • A blockchain solution requires a complete list of security processes, which should be compiled and followed once the design and build phases are complete and the solution is deployed. Every actor, every operational process, and all work instructions need to be put into place to ensure that the project functions without any security loopholes.

Blockchain security reference architecture

In the absence of generally accepted security standards and regulations, the state of blockchain application development is clearly nascent. From a security assurance standpoint, blockchain business network ecosystems that are nearing implementation require a comprehensive risk management approach that leverages cybersecurity risk frameworks, best practices, and cybersecurity assurance services to effectively mitigate risks.

Understanding that most enterprise-based blockchain systems require assessment and authorization (A&A) and authority to operate (ATO) processes to determine whether they comply with regulatory and privacy requirements, our approach emphasizes that the blockchain ecosystem, participant nodes, and actors have a shared security responsibility.

In the previous sections, you saw that in order to build a secure blockchain solution it is important to assess the risks and threats, and derive the security controls. Using the security controls in a blockchain architecture leads to the blockchain security reference model, which can be applied across all blockchain solutions.

Figure 2. Blockchain security reference architecture

Blockchain security reference architecture

The key takeaways for this article are summarized in the blockchain security model shown in Figure 3, which highlights the most important parts of securing a blockchain solution. These include:

  1. Scrutinizing the risks (business and governance, process and technology) that lead to a risk model
  2. Analyzing the threats that derive a threat model
  3. Deriving the security controls that mitigate the risks and threats, thus securing the blockchain solution

Figure 3. Security model for a blockchain-based solution

Security model to secure a blockchain-based solution

Conclusion

This article has explained the essential components needed to secure a blockchain solution. Going forward, we strongly recommend that you review the solutions that you are designing and architecting against this blockchain security reference architecture and blockchain security model to ensure the security of your blockchain solutions.

For more blockchain security resources, see the Related Content links below and the Resources links in the right-hand column.

Acknowledgements: The authors would like to thank the following colleagues for their contributions to this article: Adewale Omoniyi, Dmitriy Beryoza, Kapil Singh, Jeff Tennenbaum, and Alessandro Sorniotti.