How Pure Storage helps customers guard against ransomware • The Register

Paid Feature Ransomware is one of the great scourges of our time. And it's getting worse. Chris Mellor, editor of our companion title Blocks & Files, talked to Shawn Rosemarin, global vice president for emerging technology solution sales at Pure Storage, about how the company can help customers protect themselves

Blocks and Files: What happens if a Pure customer finds to their chagrin that they've been hit by a ransomware attack? What's the best outcome they can hope for?

Shawn Rosemarin: In the ideal scenario, the customer has prepared and secured their infrastructure to sniff out and discover ransomware attacks as early as possible. It's the dwell time that affects the difficulty of restore. The sooner you can know that someone's doing something that they shouldn't be doing, the quicker and easier it is to restore. It's the amount of time and the amount of data that needs to be restored that is a direct driver of how long and complex it will be for you to get to that point of restoration.

The other assumption is that there's no panic because the organisation has reliably prepped for the event. Everybody knows what their roles and tasks are. They also know which applications are essential to business operation, and how long they can be out of service without affecting operation. That would be the recovery time objectives, how long can they be down? How much data can they afford to lose? Can they afford to lose an hour, a minute, a second, and depending on their industry, that would come down to that RPO.

Can Pure Storage software or services detect ransomware and alert customers to it?

Across Pure storage arrays, we do look at what is happening. We work closely with partners in the industry in the log analytics space, like Splunk or Elastic, to power the security incident and event management architectures.

So we look at what's happening, for things that are deemed to be different or odd. Like someone suddenly spending a lot of time in shares that they have access to, but they wouldn't typically go there.

The thing to think about with dwell time is that the longer I stay in the system, the more I can get access to other credentials. If I happen to snag a set of admin credentials, I could go and create problems, but I'm not going to do that yet, I'm going to use the credentials to get into other systems, look at where the backups are. What would be my attack vector that would give me the maximum leverage or cause the maximum pain so that that organisation would just pay the ransom?

How can Pure help customers recover if their data starts getting compromised?

So the first thing that happens is we know there's a breach, and we have a plan or we put together a plan very quickly. Then the organisation is typically going to go to their insurance company and declare a ransomware attack, the insurance company would then involve a third party security forensics team like Mandiant to come in and discover what actually happened. What did they gain access to? What sort of data has been compromised? Are there some backdoors that have been set up?

This is a big part of it, because I have to decide what point can I restore to that is clean, assuming I have infrastructure to restore to. If the dwell time was 30 days, if I go back 31 days ago, I may be clean, but can I actually patch myself against them coming right back in?

But the most important piece is, do I have a non-encrypted backup to actually recover from? Or do I have non-encrypted snapshots to recover from? Snapshots are easy to restore but, in many cases, organisations cannot afford to keep 30, 45, 60 days of snapshots, so now you're looking at coming back from backup.

And that's where you're getting into large volumes of data that need to be restored quickly. And our experience is that with traditional tape or disk-based backup, we're looking at roughly one terabytes, two terabytes an hour.

With our Pure Storage FlashArray//C, we see recovery speeds of eight terabytes an hour, and in FlashBlade recovery speeds of 40 to 270 terabytes an hour. So there are orders of magnitude of restoration time here significantly different than what has traditionally been viewed as kind of a backup.

Because the paradigm changed, right? We think about backup speeds, and how quickly it could be backed up, so how quickly could we get the SQL database done so that the impact on performance wasn't there? However, these days, it's restore time, how quickly can we restore the data of those critical applications?

Would people typically restore from snaps, say on FlashArray, and backups on FlashBlade?

Here's the way I would say we look at it: a basic protection would be to use snaps to restore. I'm going to turn on SafeMode on my primary array so that the snapshots are being written to a volume that cannot be encrypted, it's immutable.

If we get to a little bit better, we're not only running snapshots, we're actually taking backup volumes. We're putting backup volumes now into those safe mode repositories. And now in the event that we can't restore with snaps, we can actually go get an immutable backup.

In the best scenario, we would have a FlashArray//X connected to a FlashBlade so that we have all of our most recent backup volumes ready to be restored incredibly quickly. So in an event, we can mount from the FlashBlade and then put the FlashBlade volumes back onto our primary array.

Is there any difference between the way SafeMode operates on FlashArray//X, FlashArray//C and FlashBlade?

SafeMode operates the same in both scenarios. It's an immutable volume. And it's interesting because we've seen a lot of vendors say unless you're the system administrator you cannot change or modify the array. SafeMode is different, we actually assume that anybody could be causing the damage, and your credentials could be compromised or stolen.

Because once a ransomware attack has happened, you can't trust anybody's credentials in the attacked organisation?

That's right. It's called zero trust, so I should give every employee only access to what they absolutely require. But we always have to assume any set of credentials can be compromised.

What happens from a SafeMode perspective, I have something called 'Eradication Timer'. So let's assume I have administrator credentials and go and delete a backup. With SafeMode there's an eradication timer, and no matter who deletes it, it actually doesn't delete for 30 days, 45 days or 60 days. So if it is deleted, no problem, it's actually not deleted, it's sitting on a timer that's been preset.

Now, if you want to go and change that or reconfigure it, you have to call support and you have to be one of a few named individuals. So you have to identify yourself by name, and you have to state your PIN that only you know. And only then would support on our side go in and actually reset or change the eradication timer and the settings on SafeMode.

Security protection companies imply that recovery from ransomware is getting easier and easier. What is your response to that?

If you were to ask me whether you could restore from snapshots easily, I would tell you, yes, snapshots are incredibly easy. And I think that in the event that you were restoring data, or even a user file that they had accidentally deleted, that would be easy.

The hard part is, as I said earlier, figuring out how did we get here. We have seen first-hand what is required to restore working with various organisations. This is not an easy task. I would love to put a marketing veneer and say, you know it's one click. That's not the way this works.

Sponsored by Pure Storage.

Results for “"scourges"”

How Pure Storage helps customers guard against ransomware