There’s no denying it: ransomware is now big business. Entire supply chains exist where organized criminals specialize in one or more parts of the crime. The growing popularity of Ransomware-as-a-Service significantly lowers the technical bar of entry for cybercriminals. Some specializations include gaining access to credentials, penetrating hosts, identifying data, delivering encryption payloads, and accepting and distributing the ransom money. Because of this, each step can be more focused and specialized. Ransomware gangs understand the mitigation strategies, seek them out in the network, and destroy them when found. According to the UK National Cyber Security Centre, there have been cases where attackers have destroyed copied files or disrupted recovery processes before conducting ransomware attacks. Were an attacker successful in this, you would have little option but to make the ransom payment.
While many technologies are involved in ransomware mitigation, such as firewalls, restricting access to devices, antivirus, and Endpoint Detection & Response (EDR) software, backup infrastructure is the last line of defense against paying the ransom or losing data. As such, the backup infrastructure must be immune from encryption or deletion. One of the best protections from backup encryption is for the backups themselves to be immutable. Let’s take a look at what this means in practice.
What is Immutability?
Let’s look at the definition of the word itself from Merriam-Webster.
Immutable
im· mu· ta· ble | (ˌ)i(m)-ˈmyü-tə-bəl
Definition of immutable
: not capable of or susceptible to change
The key difference between a mutable and an immutable file system is that a mutable file system will modify data directly in the exact storage location leading to a loss of the original form. The data never changes (or “mutates”) in an immutable file system. Once you write the data to a location, it cannot be modified by design. When a data update occurs in an immutable file system, it stores the updated data in a new location and references it back to the original file. Typically, the entire file is not moved. Only the block with the modified data is written to a new location, and the metadata of the files’ locations is updated. This means that if you still have the old metadata for that file, you can read it from its “old” locations. Additionally, files can be read in their “old” form while being updated, and a file has an implicit history. The data stays the same in an immutable file system, and the metadata changes over time.
Why is immutability important?
Immutability is critical when data must remain in its original form, such as backups. Still, it is also essential for other use-cases, such as chain-of-custody and applications that deduplicate files for storage efficiency. Because the underlying data in each location is guaranteed to be in their original form, the system can use the underlying block location in the metadata for multiple files that are identical or composed of blocks that are identical to the source. Confused? Maybe a diagram will help.
How Rubrik helps
As you might expect, this concept of immutability is one of the core principles on which Rubrik CDM is built. Files and directories written to the Rubrik CDM file system are defined by a distributed metadata layer and accessed through an internal file server. Under the hood, data is written in stripes, which are subsequently broken into chunks. Chunks are written to disk in a distributed fashion to protect against data loss. Checksums are calculated when creating both chunks and stripes, and these are checked periodically after this. These checksum operations protect against both logical and physical corruption or loss.
Once a file write completes, the file is explicitly marked as immutable, which we call “finalizing” the file. After this, nothing can change it. When you amend data, the changes are written to a new file and new metadata. Recovery is as simple as walking back to the correct version of the metadata file. Remember: this metadata is distributed throughout the cluster, so the loss of a disk or node poses no issues to recoverability. As you might imagine, this immutability is vital for recovering from a ransomware attack!
Extending on Immutability
According to the US National Institute of Standards & Technology (NIST), one of the critical concepts of Zero Trust is that the network is considered to be compromised, and therefore hostile.
Strong Authentication, including multi-factor authentication (MFA), must be used to protect against brute-force and password stuffing attacks. Robust Authorization, including the principles of the least privilege and separation of duties, is critical when protecting data from unauthorized access, encryption, and deletion. Third, Accounting is essential to monitor what actions those who are authenticated and authorized take once connected to the network. We refer to these as AAA. Rubrik performs authentication and authorization checks to all communication, both externally and internally to the nodes, and logs events in line with the core tenets of AAA.
In the case of the last line of defense against ransomware, you must also protect data protection SLAs. A backup cannot be deleted until it has reached the end of its life cycle, either through a manual deletion attempt or another method that might seek to use the data lifecycle against the backup data. Rubrik prevents this with a feature known as SLA Retention Lock. Once enabled, SLA Retention Lock can only be disabled by Rubrik Support and requires approval from two previously authorized officers from the customer side. Think of it as the launching of nuclear weapons requiring 2 authorized officers before you can press the big red button–this is your failsafe against a potentially malicious insider threat.
Extending Immutability to archives in the Azure cloud
Immutable storage for Azure Blob Storage enables users to store business-critical data in a WORM (Write Once, Read Many) state. While in a WORM state, data cannot be modified or deleted for a user-specified interval.
Microsoft retained a leading independent assessment firm that specializes in records management and information governance, Cohasset Associates, to evaluate immutable storage for blobs and its compliance with requirements specific to the financial services industry. Cohasset validated that immutable storage, when used to retain blobs in a WORM state, meets the relevant storage requirements of CFTC Rule 1.31(c)-(d), FINRA Rule 4511, and SEC Rule 17a-4(f). Microsoft targeted this set of rules because they represent the most prescriptive guidance globally for records retention for financial institutions.
Rubrik provides native immutability through the underlying filesystem in CDM. While this is a great place to start when securing your backup data, many customers need to retain older backup data on more cost-effective archival storage. This archival storage might be a cheap & deep NFS export or some form of cloud-native storage like Azure Blob storage. The same logic that applies to the data once held by CDM applies equally to these archive locations, as Rubrik no longer has sole ownership of data once it leaves the CDM platform. As such, you rely on the protections that the archive platform offers. While cloud providers offer the option to store things in an immutable fashion, this typically requires a second management pane, and as such more management overhead, and more potential for misconfiguration.
With Rubrik CDM, configuring Azure Immutable Archive as an archive location is a simple process. You simply flick a switch when creating the archive, and specify your immutability period. Rubrik CDM then performs all of the under-the-hood tasks to create a new container in your storage account to meet your needs. Once this is configured, nobody can delete the data held there. Not a Rubrik admin, not an attacker, not even Microsoft. In doing this, your data remains immutable everywhere, whether it’s on the CDM appliance or archived out to the cloud.
To learn more about how Rubrik solutions , contact us at inquiries@serviceitplus.com
