The Myth of Magical Immutability

Immutability is taking on an almost magical quality in IT circles. Ransomware has led to the introduction of a dizzying number of “immutability” technologies, bolstered by claims that data can neither be hacked nor lost. These technologies never tell you how the immutability itself is protected though, handwaving away the fact that immutability is under attack from ransomware. So, what exactly is this mystic quality, immutability?

Immutability, in the context of data management and information technology, refers to the characteristic of data (or objects) being unchangeable or unalterable once they are created. This means that once data is stored (or an object is instantiated), it cannot be modified or deleted.

In data storage and databases, immutability ensures that records cannot be altered after they have been written. This is crucial for maintaining the integrity and historical accuracy of data, particularly in environments where security and traceability are paramount, such as financial services, healthcare, and legal fields.

In Backup and Disaster Recovery, immutability protects backup data from being altered or deleted, particularly in the face of ransomware attacks or accidental deletions, ensuring that recovery points remain intact and reliable.

I am a (ethical) hacker by trade, which tends to skew how I think about a systems functions and operations. Where many people see use cases, I see abuse cases. And so do the less than ethical hackers. Preventing an attacker from making unauthorized changes is not easy – in fact, it requires more than shallow forms of immutability.

Immutability is an important capability; however, it can lead to a false sense of security if not implemented properly, and unfortunately, we see a significant number of issues specific to these features. For example, when misconfigured, it is possible to delete supposedly immutable data (for example, by manipulating time/date settings on the storage device to bypass retention enforcement mechanisms). Even when configured correctly, an attacker with access to the data source can poison an immutable data store over time, corrupting it such that it becomes useless when needed for recovery. Immutability, while capable of preventing alteration or deletion of the original data, does not inherently provide mechanisms for preventing immutability bypass methods.

Safeguarding data from unauthorized change requires removing the many immutability bypass methods that exist. Immutability bypass methods fall into four categories:

Protecting immutability

Organizations that separate IT Infrastructure and Security into two different camps tend to be at greater risk of ransomware succeeding in deleting backups. In these companies, security teams develop security policies and procedures that infrastructure teams are tasked with implementing, sometimes often with minimal direction. Often, security teams are not aware of cyber resiliency capabilities that defend the immutability functions themselves, while infrastructure teams are more focused on day-to-day operations and less concerned with reducing the potential for cyberattacks.

Immutability controls are access controls. As such they are just as susceptible to privilege escalation attacks. In the real world we see this most commonly when ransomware gangs attack the backup management systems. These systems have elevated access to all storage tiers, making them extremely attractive targets, and in the case where things such as object lock is used, attacking backup management systems is the easiest way for an attacker to bypass immutability controls.

Access control to storage & backup, includes several different configuration levels:

• Access to storage elements - such as block devices, network shares, or even individual files and objects should be mapped only to designated components (e.g., individual hosts or applications). This is done both at the device level (e.g., share configuration, LUN mapping) and using network filtering techniques (e.g., IP filters, SAN zoning and Masking).
  
  
• Level of access to the data itself (e.g., read, write, modify permissions and ownership, file-level and device-level ACLs).
  
  
• Access to advanced storage capabilities (e.g., management, control, replication, snapshot management)

Current storage infrastructure designs suffer from immutability bypass vulnerabilities, including unrestricted access to shared storage, unrecommended zoning and masking configuration, ability to reach storage elements from external networks, and more. Incorrect access right management can at best lead to data exposure, and at worst to compromise of the data itself and its copies. In some cases, it can lead to compromise of the operating systems of the hosts that use the storage.

There are a surprising number of ways storage and backup systems can be manipulated and managed:

• Using device APIs
• Using management hosts and API gateways
• In-band – using storage protocols
• Using dedicated host agents
• Using storage agents on virtual infrastructure

Most of those control methods can be further managed to define what access level it can provide (e.g., which actions are allowed, including creation, destruction, mapping, copying, and more), which components could be controlled, filtering to which IPs, and more. Attackers abuse these controls to bypass immutability and governance locks. When you read in the news that <Insert Company Name Here> is still recovering from the effects of a ransomware attack, there is a 100% certainty that a privileged system with access to storage tiers was involved in the attack.

Undocumented and insecure API and CLI access paths can also provide cybercriminals with a backdoor to control storage devices, exfiltrate data, and tamper with storage content and its backups. For example, objects protected by GOVERNANCE mode in AWS S3 can be permanently deleted under the following conditions, even before the retention period is over:

• An attacker has obtained You s3:BypassGovernanceRetention permissions.
• An attacker explicitly includes x-amz-bypass-governance-retention:true as a request header in the DELETE request.

By default, the Amazon S3 console includes the x-amz-bypass-governance-retention:true header in a DELETE request. Therefore, if you have s3:BypassGovernanceRetention permissions, then you can use the S3 console to delete an object version that's protected by GOVERNANCE mode.

With s3:BypassGovernanceRetention permissions, you can also use the AWS CLI to delete an object version. Pass the -- bypass-governance-retention option in the delete-object command:

‘aws s3api delete-object --bucket sample-bucket --key test.txt --version-id "8_gad5vG56F.FNG’

But why should we expect a GOVERNANCE feature to be an effective security control??? The Myth became legend somewhere along the way though.

Enterprise storage & backup security is significantly lagging compared to other areas of cybersecurity, and a growing number of myths around controls such as immutability has taken the industry one step forwards and two steps back.

From Myth to Myota

Unbreakable Immutability Protection

Protecting and preserving immutability begins with Myota’s patented Shred & Spread™ process. A revolutionary innovation in chained encryption, polymorphic immutability and geographically dispersed unidirectional air-gaps.  

Unlike unprotected immutability, Myota also allows operations on its quantum resilient encrypted data without decrypting it – backup restoration for example can be performed without decryption – closing a popular window of attack.

Myota Shred & Spread™ goes beyond shallow immutability, single trust immutability, object lock and other governance controls meant to preserve the integrity of the data. Myota’s polymorphic immutability, plus its unique chained encryption process keeps information confidential and resistant to immutability bypass attacks.

An ”immutable” backup is no good if you lose access to it. That’s the Myota difference.

I’m not one for getting in the way of a good tall tale though, so I’ll leave you with some more Immutability Myths to ponder.

A Brief, Incomplete, and Mostly Wrong History of Immutability

2003: The Accidental Invention of Immutability

In 2003, a distracted programmer who constantly forgot his passwords and often mistakenly modified files, introduced the concept of immutability in data storage. This breakthrough came from his personal need to safeguard his work from his own errors, leading to a system where once data was written, it could never be altered or erased, effectively making his digital blunders somewhat less catastrophic.

2007: Immutability Meets Misinterpretation

In a whimsical twist of fate during 2007, the term "immutability" was first misinterpreted during a tech conference. A speaker discussing immutable systems accidentally knocked over a water bottle, declaring, "Like this spill, once data is stored, it cannot be 'unspilled'!" This analogy inexplicably caught on, propelling the concept of immutability into the limelight, albeit with a few raised eyebrows on the practicality of comparing data to a water spill.

2010: The Unintentional Creation of Hyper-Immutability

In a bizarre twist of fate at a cutting-edge cybersecurity conference, a keynote speaker, while demonstrating live hacking techniques, accidentally activated a prototype immutability algorithm on his presentation slides. The slides, which included embarrassing typos and outdated memes, became permanently immutable, preserved for all eternity on the conference’s main screen. This incident led to the tongue-in-cheek concept of "Hyper-Immutability," where even the slightest digital faux pas could no longer be edited or undone, much to the chagrin of presenters everywhere.

2013: The 'Immutable' Floppy Disk Revival

As ransomware attacks began to surge in 2013, a nostalgic IT veteran suggested reverting to floppy disks, touting them as "naturally immutable" due to their obsolescence. This brief and ill-advised resurgence was cut short when it was discovered that not only were floppy disks still writable, but most employees under forty had never seen one before.

2016: Quantum Immutability Debacle

Quantum computing's entry into the immutability saga in 2016 brought with it grand claims that quantum states, by their nature, were immutable. A high-profile experiment intended to showcase this ended in comedy when the demonstration quantum computer accidentally entangled the presentation slides, leading to a confusing mess of superimposed images and text, debunking the myth spectacularly.

2020: Home Office Immutability

The pandemic in 2020 led to the tongue-in-cheek "Home Office Backup" approach where workers were advised to maintain immutability by printing out critical emails and documents. This DIY immutability strategy ended when households realized that piling papers in a home office did not equate to data security, but did increase the risk of paper cuts.

2024: AI's Unintended Immutability

In 2025, a new AI tool designed to perfect online comments inadvertently made every edit permanent. Users found themselves stuck with their first drafts, leading to a comical uproar over the unexpected permanence. This gaffe, humorously named "Eternal Edits," became a viral reminder to think twice before hitting send.