Looking at Object Lock, versioning and immutability.

In my last post, I wrote about how to protect data from ransomware attacks using IBM Cloud Object Storage, its versioning system and separation of duty to store data in the cloud. In this post, I will expand on the fundamentals of using versioning as a basic concept for ransomware protection to include Object Lock.

I will outline the difference between Object Lock and versioning and discuss some additional threat vectors that will be addressed when using Object Lock as a defense against ransomware. As was true with versioning, the Object Lock technology does not introduce additional hardware or software components to the solution, nor is there an additional fee for the feature itself. Users just pay for the amount of data that is used.

Object Lock, versioning and immutability

The two features—Object Lock and versioning—are very similar in that Object Lock is a versioning system with immutable objects. Though versioning and immutability could seem diametrically opposed, the two concepts create a strong defense against ransomware attack when combined. I will make clear my claims of a “strong defense” later in this post where I compare Object Lock and versioning.

First, I’ll describe details about the Object Lock system that position it to address additional threat vectors. With Object Lock, end users can control retention policies for each object in an Object Lock-enabled bucket. Unlike classical immutable objects, data owners that have placed objects in buckets with Object Lock enabled can add new versions of objects to the bucket. Writes to the bucket with same named objects do not replace the existing object, but instead create new versions of the objects. The key difference between Object Lock and versioning is that the version history is immutable. This means that though new versions of the objects may be created, the version history cannot be modified outside the retention policy.

Object Lock and threat vectors

Using Object Lock as a data protection strategy will defend against ransomware attacks where the goal of the attack is to replace a victim’s data with encrypted data. In this scenario, only the adversary attacking the system is in control of the key material to decrypt the data. This ransomware defense will not address situations where the goal of the attacker is to use ransomware to exfiltrate data, then demand ransom to prevent leaking captured data.

There are several ways to prevent attackers from exfiltrating data. For instance, in addition to least privileged access controls, one can layer on context-based restrictions to prevent unauthorized access of the data. One could also apply strong encryption to data both in flight and at rest to defend against adversaries that manage to exfiltrate data. Encrypting the data on the client side before storing it in the cloud will help protect your data from attacks that might be mounted inside the cloud itself. The previous examples are just a few controls that could be applied to improve the security of your data.

As was alluded to earlier, the goal of using a system that includes versioning as a strategy to defend against ransomware is to prevent the overwrites that make the data unusable in the first place. The data is, of course, unusable because any software or human attempting to use the data cannot read the data after the adversary has encrypted it. The inability to access data will negatively impact the day-to-day business operations.

Adversaries attempt to use this data unavailability as the leverage against the victim. They demand payment to hand over encryption keys and instructions to decrypt the data and reenable business operations. Businesses that rely on their data for critical functions that generate revenue often see paying the adversary as the lesser of two evils. They must decide which is worse—the loss of revenue and/or customers that cannot use the services or paying the adversary to retrieve the keys and instructions to unlock their data. I will point out that paying the adversary is fraught with danger. What assurances does the victim have that the adversary will even turn over the keys and instructions to restore the data? The adversary may simply vanish after payment has been made.

This is where versioning is extremely helpful. By creating an environment where the only option to update the data is to create a new version, no adversary can permanently disable an enterprise. Attempts to encrypt the data and store it back to a bucket only generate a new version of the data, not replace it. This still means that the victim could see some disruption to daily operations, but they are able to help themselves. They are not reliant on the adversary’s good will.

A victim, armed with environment-specific information, can sort through the version history and find a useable version of the data. The cyber-recovery plan for the enterprise will need to consider automation that will allow version history inspection to find a useable version of the data. Manual attempts to restore large volumes of data will likely not reenable the enterprise’s business functions in a timely manner, resulting in unacceptable losses of revenue. This automation will need to consider situations where the ransomware may have written the data more than once, creating multiple versions of the encrypted data atop the useable data.

Both Object Lock and versioning with separation of duty accomplish the goal of preventing the adversary from overwriting useable data with encrypted data, making it inaccessible to the victim. However, Object Lock offers protection against additional threats, human error and the insider attack. When using versioning and separation of duty alone as the defense, there is nothing stopping the attack from coming from inside the organization by the victim’s own administrators. If an administrator were to install the ransomware with elevated privileges, any “version-aware” ransomware could theoretically encrypt all versions of the data. A different exploit could be to simply remove all versions of the data and leave only a single encrypted version in the data store.

Another cold hard truth is that administrators are as human as the rest of us and make mistakes. It could be that the administrative credentials were simply mishandled (such as being left in a history file and extracted through reconnaissance by the attacker). Credentials could also be obtained from an unwitting employee through a phishing attack. However they are obtained, accidental leakage of credentials would allow the attacker to adversely manipulate the version history.

Object Lock’s version history tree and any current version of the data are immutable. This means that not even administrators can modify a version of the data outside the retention policy. When using Object Lock, even if the administrative credentials were leaked, the ransomware could not destroy useable data. Clearly Object Lock can remove two critical attack vectors against the versioning approach to protecting data from ransomware: insider attack and human error.

Summary

In this post I introduced using Object Lock to address additional threat vectors when defending data against ransomware. Versioning with good separation of duty and Object Lock are both strategies that can successfully prevent ransomware from replacing valuable data with encrypted data.

However, Object Lock has additional benefits. When using Object Lock as a defense strategy, the version tree is protected against accidental or intentional modification. Because the version history is immutable, adversaries that manage to gain access to elevated privileges to the object storage account credentials cannot encrypt all previous version of the data or worse, remove all versions of the data. This is true of adversaries that are external to the victim’s organization or internal to the organization. Disgruntled administrators (or anyone for that matter) do not have permissions to remove or modify data outside the retention policy once it has been written. Object Lock has the benefit of protecting the version tree from insider threats, whereas versioning without Object Lock will only prevent adversaries without proper credentials from attacking the version tree.

Start your defense today

Take a tour of IBM Cloud Object Storage’s Object Lock feature to see how it can be employed in your own ransomware defense strategy.