Why using a blockchain could be a bad idea for a SaaS compliance product

Don’t fall for the blockchain hype

A chain of blocks, or blockchain (Shutterstock image)

Table of content

• Short Intro — my blockchain credentials.
• What are the issues and risks to consider when using blockchain?
  – Marketing hype and inconsistent definitions.
  – Scalability.
  – Response Time.
  – Blockchain does not provide any security by default.
  – It is hard to assess risk and exposure when evaluating blockchain offerings.
• Why we may think about using a blockchain?
  – Mitigating Trust and Transparency Issues.
  – Decentralization of decisions and storage.
  – Managing and Ensuring the Integrity of Digital Assets.
  – Increasing Fault Tolerance and Resilience.
• When should we really use a blockchain?
• How does blockchain requirements measure against the use case of a Compliance application?
• Questions you should ask a supplier offering a Compliance solution based on blockchain.
• Questions you should ask yourself before adopting a Compliance solution based on blockchain.
• Conclusions.

Short Intro — my blockchain credentials.

First — I believe I cannot be accused of not being a supporter of the blockchain. Maybe, even more, than I would really like to admit.

I was very much into blockchain up to a couple of years ago (I gave variations of this presentation — you can also watch it from Slideshare — at several conferences including the ISACA Cybersecurity Nexus (CSX) Europe 2018; I got twice certified on IBM Hyperledger; I graduated from a pretty technical Berkeley course on Bitcoin, cryptocurrency, and in general, about all the basics of blockchain and underlining protocols; even recently, I coded consensus protocols with Python as part of my master-level studies at the Ira A. Fulton Schools of Engineering at Arizona State University; and so on).

Of course, I noticed the massive hype mounting around blockchain, which has led to millions in investments. Fierce critics and detractors were not lacking:

“Blockchain Is The Most Over-Hyped Technology Ever, No Better than a Spreadsheet/Database” ¹

“‘Shitcoin’ is a pejorative term used to describe an altcoin that has become worthless.” ²

“Ten years in, nobody has come up with a use for blockchain.” ³

“Blockchain is not only crappy technology but a bad vision for the future.” ⁴

“There is no single person in existence who had a problem they wanted to solve, discovered that an available blockchain solution was the best way to solve it, and therefore became a blockchain enthusiast.” ⁵

The issue is, that many do not understand that blockchain is more of a design pattern than a technology. This design pattern in itself relies on pieces of technologies, such as:

• P2P networks
• a consensus protocol
• basic cryptography such as hashing
• basic storage capabilities

Obviously, one or more of those can be singularly adopted in non-blockchain applications; the only case where blockchain applications are required is when all of them must be used together in a certain way.

What are the issues and risks to consider when using blockchain?

When implementing a blockchain architecture, we need to consider the following risks:

Marketing hype and inconsistent definitions.

The definition of blockchain and the applications thereof are highly fluid. Specific implementations vary in functionality, and many proposed solutions are yet to emerge from the conceptual stage. It is often difficult to pierce through the evangelistic marketing hype, which distracts attention from the development of a targeted set of potential use cases. As a matter of fact, up to 2022, there are really very few production-worth applications shipped that utilize blockchain outside cryptocurrency, FinTech, and Cybersecurity.

Scalability.

As transactions, (big) data, devices, and identities explode, so does the requirement to manage and store all artifacts relating to them. Depending on the blockchain system itself, downstream applications, and the distribution of nodes, the scale can be a possible benefit; however, scale in the blockchain community is an active area of research and development, and is mostly considered a risk more than an advantage.

Response Time.

To increase scale and responsiveness, blockchain developers can leverage data and asset object hashes, and store those in the blockchain, rather than the entire object itself. However, transactions per second (TPS), a critical metric when determining performance, remains poor with most blockchain systems today, despite the efforts of certain technology providers focused on building a scalable and responsive blockchain-based database, with TPS as a critical metric.

Blockchain does not provide any security by default.

Contrary to a popular belief, blockchain is not immune to cyberattacks or fraud — quite the contrary.

Initial blockchain deployments (such as bitcoin) have proven to be quite resilient. However, it is naïve to rely solely on the apparent robustness of cryptographic algorithms for security.

Blockchain security can best be defined as the least common denominator of cryptography, associated key management, software implementation, and the operating system(s) upon which the blockchain platform operates.

As more and more applications of the blockchain have been shipped, the surface of attack has extended, and the burden of security has moved from the network to the endpoints that are writing to the blockchain. Like in any other cryptographic system, vulnerabilities often occur in ancillary system components (such as operating systems), networking protocols, and some security-related areas (such as key management, protection, and distribution). For instance, a very high-profile attack against Ethereum in 2017 (which allowed attackers to steal $32 million from a variety of crypto-wallets) demonstrates how attackers search for weaknesses across blockchain system dependencies (in this case it was a heavily-relied-upon library that related to the crypto-wallet).

Many blockchain applications run “smart contracts”, that is, code that is executed whenever certain conditions on the ledger, such as a transaction, are triggered. While this feature is extremely useful and one of the main drivers for blockchain adoption (for instance, it is the mechanism that allows crypto-exchanges to reward themselves for the transactions provided to users), we need to remind that this is still computer code, and as any other code, it will contain vulnerabilities which can be exploited.

Bitcoin has kept the possible logic of this code voluntary simple in order to limit exploiting possibilities; however, this has also restricted practical usages of its ledger outside of bitcoin itself, and therefore more advanced possibilities have been introduced with newer blockchains based on the Ethereum ledger. Attacks on the Distributed Autonomous Organization (DAO), involve the exploitation of weaknesses in the logic of smart contracts based on the Ethereum blockchain, even when they are (ironically) executed in a cryptographically sound way. The programming capabilities of Ethereum allow introducing flaws in the software architecture, which compounds the lack of experience, specialized audit and debugging tools, and the complexity in the logic while programming smart contracts. A “stupid” code error has been the cause of a major hack that in 2021 ruined the startup MonoX Finance as they lost $31 million from “smart attackers”.

Finally, when implementing the business logic on the blockchain, excessive complexity can also introduce weak links in the business logic that attackers can point into, such as the one that in 2022 wiped the savings of hundreds of Terra-UST-LUNA investors, bringing the value of the cryptocurrency down by 98.3% in just a couple of days.

It is hard to assess risk and exposure when evaluating blockchain offerings.

First, with blockchain, it is difficult to construct a detailed threat model on which to perform a risk assessment. Simply adopting a vendor of a blockchain application, without understanding the implication of the technology, is obviously not a good idea: you only shift responsibility — you never outsource accountability. Compliance Program Leaders must ensure that they treat governance and accountability separate from blockchain technology.

Second, blockchain is a complex technological system and can lack the clarity of oversight and auditability that more traditional systems offer. It is relatively simple to explain traditional database-based applications to IT or Information Security leadership; however, with blockchain, intricate and subtle flaws in software architectures require considerable skills and expertise to understand. As a result, compliance and enforcement costs may increase, not decrease, as some regulatory environments require oversight and accountability that are difficult to achieve with blockchain.

Blockchain is relatively new, and expertise is lacking even in traditional risk management fields — let alone in the blockchain. The complexity of blockchain makes it difficult to accurately assess risk, and exposure remains a challenge. In addition, this is exacerbated because there are currently no common standards or regulations.

Why we may think about using a blockchain?

Given all of those drawbacks, you may be wondering why we should bother about using blockchain at all.

There are certainly benefits and legitimate use cases that can be brought by using blockchain. Some known core advantages of a blockchain architecture include the following:

Mitigating Trust and Transparency Issues.

Blockchain is based on a distributed and decentralized architecture. Depending on the particular blockchain platform, all transactions are made available to interested parties via the blockchain. The notion of “interested parties” can vary depending on requirements (for example, enterprise-oriented blockchains may only be limited to the enterprise itself). The blockchain, in theory, is not controlled by a central authority, thus providing transparency, community control, and data integrity.

Decentralization of decisions and storage.

Use cases allowing decentralization wherever there is still a centralized trust arbiter. For example, a blockchain-enabled Land Registry replacement would allow any interested individual to discover ownership of land, while also ensuring that transfer of ownership does not occur without the authorized consent of interested parties (for example, a financial institution holding the property as security for a loan). Other potential uses include notification of fraud between consortium members; verification and repudiation of identity proofing; and the distribution, verification, and revocation of public keys in an extension to public-key infrastructure (PKI).

Managing and Ensuring the Integrity of Digital Assets.

Since blockchain can mitigate trust and transparency concerns, ensuring integrity is an inherited outcome. One of the key aspects that ensures the integrity of data is that all transactions are digitally signed, and a consensus system is leveraged to mitigate against fraud and ensure the overall functioning of the blockchain system. The consensus approach will differ depending on the nature and application of the blockchain system. Once the data or transaction meets the consensus requirements, it is placed in the immutable public ledger. Tampering, or attempts at the fraud of this ledger, are made evident through the cryptographic nature of the entities/blocks within the blockchain itself. Most importantly, the cryptographic binding of all the elements, or blocks, in a blockchain and the associated data are stored in the ledger for as long as the blockchain system still exists.

Increasing Fault Tolerance and Resilience.

The decentralized and distributed nature of blockchain provides a level of fault tolerance and resilience. In an ideal blockchain system, if nodes are diverse and distributed — both from a system and location perspective — mitigation against brute-force attacks (such as “denial of service” or “distributed denial of service” attacks) can be achieved. As the number of nodes in the system increases, so does the ability to mitigate against faults and resilience. However, there are several considerations to make: is the required volume, diversity, and distribution of these nodes accounted for when considering this benefit? Can the same result be obtained with more traditional technologies, like data center redundancy and network attacks mitigation, and in a more economical fashion? Is the solution explored really such a mission-critical service that it cannot afford even a minimal downtime?

Generally, the benefits of decreased downtime tend to flat-out after an SLA of 90–95% availability. After this level of availability, the costs for resilience increase exponentially and should be really deserved for enterprise mission-critical or life-preserving services.

When should we really use a blockchain?

After all of this digression about the pros and cons of the blockchain, we can summarize that blockchain should only be considered for specific use cases, such as the ones where:

1. Hundreds of different participants have to write at the same time.
2. There is a need to decentralize the governance of the changes to the ledger, where the consensus on the changes is complicated.
3. The software adopts an open-source model.
4. Data integrity resistance is more valuable than efficiency and cost containment.
5. The use case leverages decentralized storage via P2P networks.
6. Business logic is kept simple.
7. Privacy of transactions is not necessary (everyone can know that a transaction has happened), or at least, it is not the fundamental requirement of the application.
8. Transactions must be immutable, which means, immutability takes precedence over other considerations, such as the need to remove sensitive information, or legal requirements to remove certain content.

How does blockchain requirements measure against the use case of a Compliance application?

My takes on those are:

1. Hundreds of different participants have to write at the same time. This is very unlikely to be a hard requirement in Compliance software — most certainly, this is not happening in a whistleblower solution, especially because every customer will need to have its ledger. The key question is, how is the ledger managed? If every participant must share the same ledger, a major issue arises — there is a requirement for a permission ledger blockchain, which is more complicated and generally regarded as less secure. Conversely, if every customer is installing its ledger, we need to measure if there is any benefit justifying the additional cost against a simple, cheap database.
2. There is a need to decentralize the governance of the changes to the ledger, where the consensus on the changes is complicated. Absolutely not the case in Compliance: for instance, on a whistleblowing system, the states of the cases are straightforward — a case is either saved, assigned, opened, examined, or closed — and it does not require voting between unknown participants to decide on such state changes. Quite the contrary, there are specific roles assigned to perform state changes, and we do not want interferences to happen.
3. The software adopts an open-source model. Proprietary blockchain solutions are costly and unneeded, while in reality, everyone is using some variation of open-source ledgers such as the Linux Foundation's Hyperledger. If the Compliance solution will not be fully open-source, it makes no sense to use a blockchain. For instance, in the case of whistleblowing software, I believe that being open-source is not a key driver. Conversely, companies may prefer to use an external SaaS service rather than internal implementation because reporters are generally skeptic of using a solution that resides in the same IT infrastructure of the company they report about. To me, I see a clear case for a whistleblowing solution for not using open-source software.
4. Data integrity resistance is more valuable than efficiency and cost containment. This basically sums up to the fact that the user has very deep pockets for an implementation that will require lots of IT resources, and doesn’t mind using a blockchain for something that can be perfectly done by a database for a fraction of the infrastructure cost.
5. The use case leverages decentralized storage via P2P networks. Maybe, P2P networks can be applied to certain Compliance applications, such as an ESG or Third-Party verification system, where third-party participants and suppliers may need to provide records of compliance to a requestor seeking evidence. Besides that, I am not convinced: why would you want to use a P2P network? If a SaaS Compliance solution is offered, the application will want to logically keep everything on the same database or ledger to leverage the economy of scale; if every company implements the solution in its IT infrastructure, why would they want to generate transactions among each other’s? Besides the mentioned record validation (which can also be done in several other ways, leveraging strong and proven encryption rather than using a full-blown, complex, insecure, and expensive blockchain), I do not see how a distributed ledger would be beneficial.
6. Business logic is kept simple. This can probably be applicable to certain Compliance applications, such as a simple, non-integrated whistleblowing application — but it gets progressively more complex as solutions integrate into other applications, such as the EQS Compliance Cockpit. While certain parts of blockchain technology can be exploited to achieve business benefits, blockchain as an overall architecture — offering just an append-only, immutable ledger as a database — is not a valid paradigm when going beyond a simple use case, and no further integration with other applications is required. When a blockchain application needs to be integrated into ordinary enterprise systems, complexity raises exponentially.
7. Privacy of transactions is not a fundamental requirement of the application. This is clearly a no-go for any kind of Compliance application. For instance, on a whistleblowing system, only authorized users should see that a case has been processed. Trying to hide a blockchain transaction is negating the very reason why you use a blockchain in the first place and adds permissions’ complexity — more complexity means more things that can go wrong.
8. Immutability of transactions has the overall precedence. Immutability of transactions means that information cannot be amended, including when they are sensitive, or illegal, or we must comply with data privacy subjects requests such as the rights to erasure as per GDPR. What about the risk of anonymous reporters storing illegal material on your ledger? The only solution is to heavily verify, censor, and limit what can be stored on the ledger; if personal data cannot be stored, the functionality of a whistleblowing solution will be severely crippled. Conversely, we cannot be sure of what a reporter will write in a case, and we need to keep it integral to allow for forensic verification. Therefore, using a ledger suddenly does not look like a good idea.

Questions you should ask a supplier offering a Compliance solution based on blockchain.

• Are you actually expecting your Compliance software to generate thousands of concurrent transactions per second? Why do you believe a traditional database will not be efficient enough?

At EQS Group, through thousands of happy customers, we have never seen such cases, not even for the bigger implementations. Should that eventually happen, we can guarantee we can easily scale up our databases in the Cloud using simple, 40-years-proven technologies like transactional databases — without requiring Ph.D.-level IT architects and engineers studying how to improve performance on a blockchain ledger (because yes, this is the level of complexity in a blockchain solution!).

• Why would I need to implement in-house a complex blockchain solution, when I can order an off-the-shelf, relatively inexpensive SaaS that does the job perfectly?

We wish we were a fly on the wall when you ask that, so we could hear their reply to that!

• Do you think that “blockchain” means “more secure”?

Let’s please discuss the list of the dozens of cryptocurrencies or crypto exchanges that have been hacked already and think again. Blockchain applications can have both technical and logical implementation shortcomings, and when they are exploited, the whole ledger and all the actors on it are compromised for good.

• How do you test your blockchain application against vulnerabilities?
• How can I test vulnerabilities myself (run a “penetration test”) through an independent third party?

Blockchains are hard to test and audit for security vulnerabilities, because of the very vertical knowledge required which is not available to most security testing firms; most likely, a permissioned blockchain is in use, which means it is as well less secure. Conversely, traditional solutions like the EQS Compliance Cockpit and EQS Integrity Line rely on known, proven technology, and are continuously tested multiple times per year — internally, by our customers, and by independent auditors, and fulfill the most demanding security compliance and standards such as ISO/IEC 27001 and ISAE 3000 Type II.

Questions you should ask yourself before adopting a Compliance solution based on blockchain.

• Am I sure I understand how a blockchain solution works, how the reports are stored, who has access to them, and how permissions are controlled?
• Do I feel confident in adopting a technology that has been highly hyped but has seen very few real-world applications outside of finance?
• Can I trust it to be performant? What would I do, should it not work properly? Am I confident my supplier will be able to scale it and improve its performance as I require?
• Am I confident my supplier will be able to adapt the solution and customize it to my requirements?
• At contract renewal, should I decide to switch suppliers, will I be able to easily export the information from the blockchain ledger and import it into the new solution? In other words —am I not being locked in by this vendor, as it uses a very peculiar technology I cannot easily change?
• In the case that I have a GDPR SAR (Subject Access Request), am I confident that an immutable ledger will be able to comply and delete the stored personal information as required by law?
• What about an anonymous reporter storing adult material, or even child pornography? What if I cannot remove it?
• …and if I can remove content from the ledger, what about the blockchain’s assurance of immutability? It’s either always working, or it is not.

Conclusions.

When looking at the business case of using distributed ledger technology, one needs to consider the merits of the technology as well as the new problematics that it creates in the specific use case.

Whereas the use of the blockchain paradigm can potentially reduce cost in use cases that require interactions with different interested parties, the peculiarities of blockchain can create entirely new sets of problems in either risk management and assessments, IT resources, and cybersecurity — so much as that even the alleged initial cost reduction could be easily vanished; this is especially true in our specific use case of Compliance applications, which does not seem to especially require an immutable ledger or P2P networks.

As for myself, I have never managed to work for a company that used a blockchain. This is because no company I worked for… built a cryptocurrency! In fact, this is overall the only field where a blockchain architecture has indeed proven itself: unregulated crypto — besides that, not much else.

Questions? Doubts? Shouts? Hate mail? (no, seriously…). Just comment here on Medium and let me know what you think.

Footnotes

¹ https://www.banking.senate.gov/imo/media/doc/Roubini%20Testimony%2010-11-18.pdf

² https://www.investopedia.com/terms/s/shitcoin.asp

³ https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100

⁴ https://www.cnbc.com/2018/04/09/blockchain-is-not-only-crappy-technology-but-a-bad-vision-for-the-future.html

⁵ https://medium.com/@kaistinchcombe/decentralized-and-trustless-crypto-paradise-is-actually-a-medieval-hellhole-c1ca122efdec

Does your heart beat for developing exciting SaaS products? We are constantly looking for motivated new team members. Take a look at our vacancies: https://eqs-group.personio.de/recruiting/positions