Lot of storage, cloud and backup solutions are promising some kind of data immutability.

Of course, immutability is an important key capability, but it does not imply automatically that your solution is secure (or more secure).

It can give a false sense of security if not implemented properly. 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.

Immutability is just a concept: immutable (or unchangeable) backups are copies of files and data that cannot be altered or tampered with for a preset period of time. Immutable storage enables the unalterable preservation of archived objects.

But the reality can be diffent and at least we should divide in two main categories:

• Hard immutable: where write protection is in hardware but selectable (like tapes with write protection), or is in hardware by design (like WORM tapes or CDR/DVD-R) or the data are totally air-gapped and off-line.
• Soft immutable: the hardware storage remain a R/W storage (like disks) but some software protections are added, like write-lock features limited by the retention period of the associated SLA domain or by using specific filesystem capabilities.

Hard immutable can provide a better security by design, but less flexibility because require special devices or manual operations…

Immutable does not protect by destroy or thief

And, by the way, immutable does not mean that you cannot destroy (or loose) your data. Also hardware immutable can be attached (if you have watched “Mr. Robot – Season 1” you know a possible example).

But for soft immutable the attach patterns can be much more effective.

And about steal data, offline data or remote data can be much more attackable.

Immutable requires hardening

Expecially for soft immutable, hardening is totally necessary to improve security, reduce direct attach at low level (for example destroy the partitions or the volumes), enforce the lock / security features and reduce the attack surface.

For example, for a Veeam repository on a Linux server, an hardened repotory is mandatory to enable immutability… but still lot of people are doing stupid things, like make running the repository on a VM (instead on a dedicated and protected hardware) or by keeping lot of management features activated (increasing the attack perimeter).

Hardening should use mandatory models

One big issues on normal Operating Systems (like Windows or Linux) is the default authentication model: is Discretionary Access Control (DAC) that is not enough for a system that must provide immutability.

Other models are needed and should be implemented to make possible, at least, a separation of concern where user that manage date cannot modify remove immutable locks or labels and where system administrators cannot access to the protected data (or at least cannot change immutability settings). Only security users with not direct access to the systems should be able to modify (if needed) immutable settings.

For more information on access control model see: https://www.twingate.com/blog/other/access-control-models

Of course, for appliances (like storage system or dedup appliance) this is much more simple to implement and for public cloud the separation of concern is build in the model!

And note that the four-eyes principle (where a certain activity, i.e. a decision, transaction, etc., must be approved by at least two people) could be totally useless in a DAC enviroment… an admnistrator can add another administrator user and use it for the operation approval!

If is online is attackable

Network attack pattern are common… so everything that is online is attackable because has in IP and maybe some open ports.

Closing SSH/RDP ports may be not enough… the destination is still connected. Use dedicated VLAN or direct-connected cable, may be not enough… because you can first compromise the systems connected to the immutable destination.

The only way to make more secure an immutable system, from network point of view, is changing the flow of the data, from a push to the immutable destination to a get from the immutable system. And putting offline the immutable system during the rest of time… In this way your “vault” is connect to the network only during sync operation and without active socket in listering mode.

Of course you can still try to attack existing network sessions, that must be at least encrypted.

But still remember that on each system you need to perform update and patching… not necessary online, but you must keep your system updated!

Immutable does not imply consistent or correct

Another common threat of immutable system is data poisoning or DoS attack. If backup systems have been attacked, then is possible can tamper immutable destination with compromized backup jobs, poison data before it is immutably backed-up, and render it useless when it comes to recovery. If the attack running unnoticed for sufficiently long time (say, several months), then can be possible initiate a ransomware attack and organizations victims are left with no current backups to restore from.

But is possible fill the immutable destination with lot of data or lot of connections trying to make it unusable (or for public cloud storage, making the cost increasing exponentially). Be sure to put some limits in connections and amout of data transfered to minimize this issue.