Rendering Ransomware Worthless with WORM

KISS: "Keep It Simple, Stupid" is a timeless phrase that underscores the importance of simplicity. During a workshop on Negotiation Strategy, Prof. Deepak Malhotra (Harvard) introduced me to the bias of "curse of knowledge". Ever since, in my job (which revolves in large part around communication), I have tried to step back and look at the situation from the other point of view - the "other" being the person who might not have all the information I might have. The resulting empathy makes it easier to communicate, understand the immovables and make progress towards a common ground. Simplicity in design/product/service is all about having empathy - empathy for the CIOs, for the IT leaders, for the IT practitioners, all of whom are figuring out how best to support their businesses in this new COVID world. In addition to managing internal initiatives and operations, unfortunately they have to continuously deal with externalities. Externalities such as ransomware attacks. Quoting from the article:

"In April, the international police organization INTERPOL warned it “has detected a significant increase in the number of attempted ransomware attacks against key organizations and infrastructure engaged in the virus response. Cybercriminals are using ransomware to hold hospitals and medical services digitally hostage, preventing them from accessing vital files and systems until a ransom is paid."

Time for a disclaimer: there is no silver bullet when it comes to protecting against ransomware. It is a vast and expansive topic that can encompass many aspects of your IT infrastructure including network, compute, memory, storage, disaster recovery among others. Let's focus on one of the critical aspects though - protecting your DATA, and rendering ransomware attacks on them ineffective.

How do ransomware attacks affect organizations' data? There are two typical strategies:

1. Steal Data - Attackers hope that by stealing and threatening to expose sensitive information, they can arm-twist organizations in paying them ransom. Keep in mind that if someone is trying to steal data, they not only have to breach into your network, they would also have to initiate data transfer from your infra and carry that data transfer undetected for some time.
2. Encrypt Data - Attackers aim to introduce a malware into the infrastructure that silently encrypts data. Once all data is encrypted, your systems/applications will simply become unable to access that data completely disrupting your ongoing operations. To repeat, it's not that your data is stolen (in which case you still have access to the original data). Rather, your entire dataset has been encrypted rendering it completely inaccessible to your applications. An encrypting ransomware can bring organizations to their knees with no end in sight. The silent nature of this attack means one can never be sure when an attack might be in progress.

To understand the protection strategies against (2) above, let's take a look into what an encryption process consists of. An in-place encryption process comprises of three steps:

• READ - the malware reads data from storage media (disks or SSDs).
• ENCRYPT - upon reading, the malware encrypts that data in memory.
• WRITE - finally that data is written back in-place (i.e. at the original location).

The challenge in all this of course is that this process is occurring completely out of band, unbeknownst to the applications that are happily going about their business. That is, up until the ransomware has done its job and encrypted the whole data set.

So how do you protect against something like this. Well, the usual solutions are to keep snapshots, or to take backups and keep such backups away from the primary infrastructure. They work in select cases - you can recover from a snapshot if snapshot data has not yet been encrypted; you can recover from backups if the attacker has not yet infiltrated your secondary backup environment. You might not want to tie your peace of mind to those "ifs".

Enter WORM - Write Once Read Many. A properly designed WORM system would ensure that no matter what, all data would be protected for a set period of time against all Write/Update and/or Delete requests regardless of who is requesting that operation. Let's break that down one more time.

• No Overwrites - Remember, ransomware would try to replace regular content with encrypted content in-place. A WORM system would say "No, thank you".
• No Deletes - Some ransomware attacks would try to make a copy of data elsewhere, and delete the original data. A WORM system would say "No, thank you" to the delete requests.
• No Shortening (of WORM Duration) - A malicious attacker with access to your control/mgmt APIs might want to reduce the WORM time period for which data has been locked. A WORM system would say "No, thank you". Note: WORM time period of course can be extended which is useful to meet ever changing regulatory requirements.
• No Matter Who - Should the super user/admin be allowed to overwrite these WORM policies? No. How about the support personnel from your vendor? No. How about the engineers/developers from your vendor? No. The point is once content is declared locked with WORM, absolutely no one should be able to revoke that setting for the duration of WORM. "WORM for life, in sickness and health".

WORM, as described above, has been natively built into Nutanix Objects since day 1. With a design where security is one of the three guiding principles, we decided to focus on WORM since early stages of Nutanix Objects development (see, "The 3 S of Nutanix S3").

How and where can you use Nutanix Objects WORM? Consider these three opportunities:

1. Secure your production infrastructure using one of the backup partners we support such as Commvault and HYCU among others. And simply declare the target buckets these applications use as WORM. Your backup data would be securely protected. By the way, in most cases, this can be accomplished completely transparently to your backup SW. E.g. if your retention requirements are for 180 days, you would set up WORM for 180 days on your bucket. On the backup SW side, you would put a retention policy that is slightly above your WORM time (e.g. 181 days). This will ensure that when your backup SW tries to clean up data after its retention period (181 days), Nutanix Objects would allow it (since WORM period of 180 days would have expired on such data).

Important to note: Even if your virtualized application does not talk S3 APIs, this is a way for you to protect its contents using Objects WORM. Just enable backup of your application using a bucket from Nutanix Objects. Then, protect that bucket using WORM.

1. Keep your Splunk archives protected with WORM - Nutanix Objects is Splunk certified to support Splunk SmartStore. Similar to the principle described above, you would enable WORM on a bucket for the retention period you need.
2. Financial/Legal/Email archives - Applications such as IBM FileNet that can write natively to S3 can all take advantage of Nutanix Objects WORM.

Nutanix Objects supports WORM on buckets regardless of their versioning state (enabled or disabled). In other words, regardless of your applications versioning requirements, you can protect its contents. This is useful since many applications do not work with version enabled buckets (yet).

Finally, as I noted before, protection against (or recovery from) ransomware is only possible when you deploy a slew of strategies. Safeguarding your data against ransomware is one of the most salient capabilities of Nutanix Objects WORM. There are additional considerations pertaining to networking best practices, micro-segmentation, access controls, backup and disaster recovery strategies that may be useful/applicable to you. My colleague, Neil Ashworth, shares his perspective here.

With our shared love for security, let's re-imagine and extend KISS to "Keep It Simple and Secure". Stay safe.