‘Immutable’ describes something that cannot be changed (the word derives from the Latin ‘mutare’, meaning ‘to change’). Applied to data, immutability provides the Integrity aspect of security’s CIA triad (the others being Confidentiality and Availability). C and A are not inherent to immutability, but may be enhanced.
Immutable, then, is only one aspect of security. On its own it prevents neither data theft nor data reading, nor does it prevent data destruction. To make a more appealing option for purchasers, providers can include or imply different levels of confidentiality and availability associated with different offerings of immutability. As a result, the term ‘immutability’ can be unclear and confusing.
We’re going to examine this by looking at the technologies and their use cases.
In modern security parlance, ‘immutable’ has three primary associations: immutable servers, immutable backup, and immutable data.
Immutable servers
An immutable server provides an environmental defense for the data it contains. It generally uses a stripped down operating system and configuration that does not allow, or severely limits, third-party access. Under such circumstances, any attempted access and any unusual activity is potentially malicious.
Once configured, the server’s state is fixed – the software, configuration files, and data on the server cannot be modified directly.
If this somehow does happen, the data contained can be burned, a new server with the same system configuration can be stood up (a common method would be to use infrastructure as code to define the configuration and allow easy repeatability), and fresh data from backup could be uploaded. It means, in theory, the immutable server could always be secure and contain the latest data.
Joe Tito, technical manager of secure development and cloud transformation at Optiv, explains the principles. “Immutable infrastructure requires that once a server is deployed, it cannot – and should not – be modified. If updates are required to a server, infrastructure engineers update the base image of that server and deploy a new instance of it, replacing the previous instance.”
That said, it is worth noting that ‘immutable’ refers more to the server than the data contained. Data security may be enhanced, but it is not immutable data. It is just heavily protected data.
There are also, naturally, some issues. Access to the uploaded data must be allowed if it is to be processed, access by technicians may be necessary, and without user access, the data cannot be used.
Very strict zero-trust access must therefore be employed to keep authorized access to the minimum necessary, and unauthorized access excluded completely.
Since access to the content and exfiltration of the content is regulated by a fixed infrastructure configuration, immutable servers provide a greater level of defense against data theft. Preventing theft of data is not generally included in a definition of immutability.
Immutable backup/storage
Immutable backup is a copy of data that cannot be altered, changed, or deleted (although technically the medium containing the data could still be destroyed or rendered inaccessible, and the data contained could be stolen). It is fundamentally some form of write once, read many times technology (like the old CD-ROM discs.)
Anthony Cusimano, director of technical marketing at Object First, provides more detail. “Immutable backup storage is a type of data repository where information cannot be modified, deleted, or overwritten for a set period. Most immutable storage targets are object storage and use an ‘object lock’ mechanism to prevent unintentional or deliberate alterations or deletions.”
He adds, “Immutable storage comes in multiple forms, two of them being governance and compliance mode. Governance mode allows specific administrators to disable immutability, whereas compliance mode ensures files remain readable and unalterable for a set period. This makes it ideal for storing critical business data such as legal documents, financial records, or personal information.”
Immutable backup is fundamentally data stored in some form of read only regime. The combination of immutable backup maintained on an immutable server would provide a high level of data security.
Immutable data (blockchains)
By ‘immutable data’ (as opposed to immutable servers or backup) we mean unalterable data-in-use. Encryption is a partial enabler for this. For example, homomorphic encryption allows encrypted data to be processed without being decrypted. However, the primary advantage of encryption to the security triad is confidentiality rather than integrity – encrypted data can still be deleted, and if the encryption key can be obtained it can still be read.
Encryption added to a distributed ledger (that is, blockchain technology) gets closer to the theory of immutable data.
Blockchains are often associated with Bitcoin – but blockchain research predates Bitcoin by many years. The concept of a cryptographically secured chain of blocks was introduced by Stuart Haber and W Scott Stornetta in 1991. In 1998, Nick Szabo proposed a mechanism for a decentralized digital currency he called ‘bit gold’. Eleven years later, Satoshi Nakamoto launched Bitcoin.
Bit Gold is often considered the precursor of Bitcoin, and although he denies it, Szabo is often thought to be Bitcoin’s Satoshi Nakamoto. This is irrelevant here: Bitcoin is the iconic first implementation of a blockchain, built on more than 15 years of earlier research.
The original blockchain was always intended to be ‘public’. Szabo was attempting to develop a system of currency that did not depend upon a central authority (such as the Federal Reserve, the Bank of England or some other central national bank). It would be like gold – and hence, perhaps, the term ‘bit gold’; that is, a cyberspace recreation of how the value of gold works. His proposed solution was that blocks in a chain of transactions would be tied together cryptographically beyond the control of banks; that is, owned and controlled by the users. Participants in the chain would solve a cryptographic problem for each block. That solution would become part of the next block, creating a cryptographically tied chain of blocks, effectively under the control of and verified by the participants.
Satoshi Nakamoto’s Bitcoin blockchain is built on this basic concept. Szabo’s nebulous concept of ‘gold’ or ‘property’ was replaced with the equally nebulous concept of bitcoins. Anybody with a computer and internet could join and be part of the blockchain as a node or miner. Nodes hold copies of the blockchain, verifying the cryptographic integrity of the chain. Miners solve complex mathematical problems to create new blocks. Success is rewarded with newly created bitcoins. All miners are nodes, but nodes are not required to be miners.
Anybody can join and be rewarded by the chain itself. This ensures there are multiple, decentralized and verified copies of the chain. The combination of multiple, public copies verified by the miners and chained by encryption is used to claim immutability. The cryptographic link between the blocks ensures that any tampering at one node will be detected and rejected by other nodes. Technically, content can still be deleted; but there is sufficient redundancy built into the multiple nodes to make this an almost nil possibility. This is a public blockchain and is very secure.
It still has issues. Firstly, the distributed nature introduces a time overhead that is incompatible with the need for speed in general business. The cost of the network without the built-in mechanism of self-generating bitcoin rewards would need to be borne by the blockchain operator, and that could be very high. Finally, a public blockchain remains susceptible to the theoretical attack known as a ‘51%’ attack.
An attacker with more computing power than the combined power of the distributed chain could create a competing chain comprising different transactions. With more computing power than the original, the competing network can grow faster and become longer than the original. Once it does, it is considered the legitimate chain. This is a theoretical attack that is extremely unlikely to occur – but since it is possible it means that a public blockchain cannot ultimately be called immutable: the entire content of the chain could be altered, and the original content ignored.
Attempts to make blockchain usable in general business have led to the evolution of the private (or permissioned) blockchain. Here the chain is centralized and operated by a single firm (or small and limited consortium), and access to the chain is controlled (permissioned rather than public). Private blockchains offer faster transaction speeds and greater scalability. But they provide a single point of failure and reintroduce the possibility that the public blockchain was designed to eliminate – potential manipulation by the operating or owning organization (which may be an advantage in general business if a transaction proves to be fraudulent and needs to be removed from the ‘ledger’). Ultimately, if a public blockchain cannot be called ‘immutable’, a private blockchain is even further from that epithet.
Nevertheless, blockchains do offer increased security, and there are many firms developing blockchain-based technology. It is already heavily used in finance applications.
Non-finance centric private blockchain apps are also being explored. Michael Shaulov, CEO at Fireblocks comments: “There are several projects that are creating what is called on-chain identity systems. This is a common use case. For example, there is a current use case right now where people are using a blockchain as a sign-in mechanism replacing passwords. Such applications are already live and gaining adoption. Here at Fireblocks we have projects that are that are using on-chain identity, and it’s an area where we are currently doing pioneering work.”
In some ways, blockchains can be described as an excellent security solution still searching for the right problems to solve. They are gaining traction and increasing in use but are still somewhat niche. However, they cannot be described as providing immutable data in the true sense of the word immutable.
It is difficult to say the three immutable technologies genuinely provide immutability. But they are technologies specifically designed to increase security. On that basis alone, their use may be valuable. The question then becomes ‘where’ should each be used?
Immutable servers
Tito has some excellent advice. “When considering moving toward immutable infrastructure, it’s important to first understand if your application and architecture can support this paradigm. Not every type of application is a good candidate for immutable infrastructure.”
He continues, “For example, monolithic applications with tightly coupled components or extensive build times are not great candidates. This is because it’s often difficult – or impossible – to swap out components without impacting other parts of the application. Applications that have loosely coupled/dynamic components or implement a microservice architecture are great candidates for immutable infrastructure.”
Immutable backup
The most compelling use case for secure backup today is for protection against ransomware. If you can recover data that is unaffected by an encryption attack, you don’t need to pay the ransom. The rider is that the recovered data must come from a very recent source otherwise there could be a costly gap in the recovered business process making full recovery more complex and lengthy – but not so recent that the backup contains aspects of the compromise.
One method of solving this is to use backup – whether it is described as immutable or not – that includes the technique known as snapshot backup.
A snapshot is a point-in-time copy of data. Snapshots are created rapidly but require little additional storage since only changes made since the last snapshot are stored. The result can be a very up-to-date backup since systems can be restored to the precise time of the most recent snapshot.
For recovery from ransomware, systems can be returned to the most recent state prior to encryption (provided care is taken to ensure that only good data is backed-up). This can eliminate restoration of good data into a compromised system, while simultaneously reducing data loss between compromise and recovery.
“Almost every storage vendor has both read-write snapshots as well as immutable [read only], so you need to be sure you are doing the right kind of snapshots based on your use case,” warns Eric Herzog, CMO at Infinidat. “Our snapshots have no performance impact, whether they are immutable or read/write. But that is not true of all vendors. It is necessary to understand what the vendor provides to know if the use of snapshots will impact application, workloads, or use cases.”
If the use case is ‘recovery from ransomware’, then so-called immutable storage would be best. Remember, however, that this definition does not prevent data exfiltration. Double extortion, the most common ransomware variant today, is not prevented. Nor does it prevent destruction of the medium containing the ‘immutable’ data.
Here, combining ‘immutable servers’ with ‘immutable backup’ can add an extra layer of security. The decision is ultimately one of risk analysis: is the risk of data exposure greater or lower than the cost of the security?
Immutable data
Perhaps unsurprisingly, given the history and purpose of the original Bitcoin blockchain, many current blockchain use cases are within decentralized finance (defi) payments applications. For example, on July 31, 2024, Canadian firm Layer2 Financial announced that it had raised $10.7 million (Series A led by Galaxy Ventures) to progress an application designed to rival the international Swift payments system (which had serious security issues back in 2016 and 2018).
Bhanu Kohli, CEO and founder of Layer2 Financial, told Fortune magazine, “Our long term goal is to replace Swift over the next 10 years, and we’re going to do that by building operations in a number of countries, with jurisdictions globally. And once we do that, money will never have to touch the Swift system. It will basically go over a blockchain, from one jurisdiction to another.”
Judy Kaldenberg, Nexsan senior VP of sales and marketing, expands the possibilities. “Private blockchain is ideal for organizations seeking the highest levels of security, transparency, and decentralized trust. It’s suitable for industries where auditability and traceability are key.” These include, she added, areas within government, finance, healthcare, ransomware protection, evidentiary records, and call recordings.
The elusive dream application that could be based on blockchain technology is a universal and privacy retaining identity system. A chain could contain irrefutable proof of identity that could be presented on demand without transferring personal information (such as address, social security numbers and so on). The theoretical possibility exists; but as with all blockchain applications, the practical difficulties are huge.
We’ve looked at three separate technologies that claim to provide immutability within cybersecurity: servers, backups, and blockchains. We’ve only looked at the basics – each one comes in various flavors, configurations, and use cases. The one common factor is that none of them can provide immutability in the genuine sense of the word. Each one, however, can be considered a valuable layer in a layered security stack.
‘Immutable’ is not an accurate definition within cybersecurity terminology. This should perhaps be obvious: anything that can be made can ultimately be unmade. ‘Immutable’ is used here primarily as a marketing term to suggest increased difficulty in malicious (or accidental) alteration. In most cases the term does not include prevention of theft or destruction of data (or at least the medium containing the data it is designed to protect).
This doesn’t mean that the immutable epithet has no value. It indicates increased security, and that is a good thing. But increased security inevitably comes with greater cost. The onus is on the prospective purchaser to do a thorough risk and cost analysis before committing to the right flavor of the right technology for the right use case.
“Choosing between these options depends on the organization’s specific needs, goals, and resources,” explains Kaldenberg. “Each technology brings unique strengths, making them valuable tools in the broader strategy for data integrity and immutability.”
Caveat emptor must apply.
Related: Details and Lessons Learned From the Ransomware Attack on the British Library
Related: Hundreds Download Malicious NPM Package Capable of Delivering Rootkit
Related: Fianu Labs Emerges From Stealth With $2 Million in Seed Funding
Related: Beating Ransomware With Advanced Backup and Data Defense Technologies
