Podcast: Immutable storage essential against ransomware, but...

Antony Adshead: Where do we find immutable storage and why is it important?

Paul Speciale: Those of us who have been around a while know that immutable storage has been around for years, even decades. I’m sure we all remember WORM – write-once, read-many media.

We started with optical disks. Later we progressed to things like content-addressed storage, which for me was interesting because it’s a forerunner of what we work in today, such as object storage solutions.

But now, customers have several options for immutable storage: tape, hardened operating system repositories, backup appliances, file system snapshots, and object storage.

It’s important to have all these options because of what’s happening to our industry and to our world – ransomware attacks on data. Immutable storage is a great cornerstone of a multi-layered to protect data from attacks that try to modify a file or delete data.

It’s very interesting, and I wouldn’t have thought this a few years ago, but it is now the case that sophisticated ransomware actors have learned that they need to attack backups as well as primary production data.

It’s easy to see, because if the business has access to the backups and they can restore, they don’t need to pay the ransom. It turns out this happens a lot, if you look at some of the recent ransomware trends reports. The one from Veeam says 93% of ransomware attacks actually target the backups. That’s how nefarious it is.

So, immutability is important. We did a survey late last year to ask enterprises how important it was to them. We did this survey in the UK, US, France and Germany and we asked them how immutable storage is an essential element of their corporate cyber security strategy. It turns out that 94% of them already rely on it and 69% consider immutable storage essential to their corporate cyber security.

So, that’s really good. It says it’s important and everybody is using it, but then you have to look at how strong your immutable storage is.

Adshead: What gaps exist in which kinds of immutable storage?

Speciale: You have to look at these macro differences. What are the gaps that create exposure to ransomware attacks? I’m going to zero-in on this scenario where we’re protecting backup data, because in backup data you can be a little stronger in immutability.

Of course, in primary data, you have to have writable storage systems. But for backups, the first question is, does the underlying storage have true immutable properties, or can the data essentially be modified in place? The latter, the storage would be mutable. That’s the first one.

The second question is, is the data immutable the second you store it, or is there some kind of delay? If there’s a delay that’s more than hours, then there’s a window of exposure.

The third one we try to think about is how tightly integrated is the immutable storage with the application? Does the application have the ability to configure and enable the immutability? Or is it a default in the storage system or is the admin responsible for it? We’d like there to be an API [application programming interface].

And the final one is, is the immutable data online? Let’s say it’s very immutable but it’s offline and you don’t have it when you need to restore it. That’s not so great.

So, I’ll compare file systems and object storage in that scenario. You know, true object storage, really, the semantics never overwrite existing data. The overwrite should always be implemented as new writes, so you have inherent immutability.

And if we think about Posix file systems, that’s not their design. Their design by nature is to be editable, down to the byte level, so that’s not inherently immutable. That’s inherently mutable storage.

And then there are things like S3 object locking. That’s a way to make the data immutable the moment you store it. That’s very different from a file system where it’s mutable until you create a snapshot. And you might create the snapshot minutes later or hours later or every day; there’s still a window of exposure.

You can go on and on. The S3 object-locking API allows you to set retention policies and compliance enforcement. The API is something that the application, like Veeam, Commvault or Rubrik, can use to set the storage system the way it needs to be.

I would say that sort of intrinsic immutability does create a much stronger degree of immutability than other forms, but the gaps are the ones we talked about.

Look for truly immutable – data that is immutable the moment you write it – and tight application control. Those are the gaps that I look for.