Protect Against Potential Ransomware Attacks on Object Storage
Wed, 06 Oct 2021 13:23:05 -0000
|Read Time: 0 minutes
Ransomware is defined as a form of malware that encrypts a victim’s files. The attacker will then demand a ransom from the victim and will only restore access after a payment has been made. These attackers are unscrupulous, always looking for opportunities to exploit weaknesses in potential victim’s defences.
In the VMware 2020 Cybersecurity Outlook Report, defence evasion is a key tool for these attackers. So having the right protection in place is paramount. Here are some highlights:
A wiper attack involves wiping/overwriting/removing data from the victim. Unlike typical cyber-attacks that tend to be for monetary gain, wiper attacks are destructive in nature and often do not involve a ransom. Wiper malware can however be used to cover the tracks of a separate data theft.
Object storage can be regarded as a potential weak point in an organization’s armour. There are some key considerations about object storage that you need to be aware of when putting a security plan in place:
- Object storage platforms typically have no security monitoring tools to make you aware that your data is under threat.
- Ransomware attackers usually target weak links within IT security and if they somehow obtain the secret key, they can gain access to petabytes of data with no security tools actively monitoring for these potential intrusions.
- Object is often used as a backup and that can make it a soft target because it’s not actively monitored.
- Also, Object can also be used for compliance data for legal hold, making it a target.
- With no notion of native, namespace level snapshots on object platforms recovery is made difficult.
- A few lines of python code are sufficient to attack object storage over S3.
- If your data is important you need to get monitoring in place before your data is attacked unknowingly.
So how can I ensure my Object storage is safe and actively monitored?
Protecting against any security threats including ransomware is a layered approach. Currently in Dell EMC Elastic Cloud Storage (ECS) you can use versioning to retain multiple copies of an object to protect against potential attacks. For many years ECS has provided SEC17a-4(f) level compliance as a WORM-enabled capability when leveraging Amazon S3 API retention extensions. This WORM capability has been expanded in ECS version 3.6.2 with the addition of S3 Object Lock. Having these in place will give you a good foundation of protection for your object storage.
Building on this to offer superior protection to our customers, we have partnered with Superna. With ECS and the Ransomware Defender from Superna, we can monitor user behaviour and detect potential threats to systems quickly. If potential threats do materialize, you can be alerted quickly to disable the user keys to mitigate the threat. Alternatively, you can configure Ransomware Defender to automatically lock the corresponding application user when it detects malicious activity. This can help expedite the recovery process by providing the user with a list of infected objects. The following figure shows a thorough workflow of how Superna can help secure your storage.
For a demo of the functionality of this partnership, see Eyeglass Ransomware Defender for ECS Overview.
With this partnership we believe we can offer better protection for our customers and allow them to defend themselves against potential external security threats.
Author: Finbarr O'Riordan @finbarrorcork on Twitter
Related Blog Posts
Manage Object Retention with ECS Object Lock
Wed, 08 Sep 2021 20:24:39 -0000
|Read Time: 0 minutes
Dell EMC ECS 3.6.2, available for download since August 5, 2021, includes Object Lock support for our customers. This has been a popular ask and we are delighted to be able to deliver this to our Object Storage install base as it enables them to satisfy many use cases and help them in their daily roles.
ECS allows you to store objects using a write-once-read-many (WORM) model through Object Lock. This feature prevents objects from being deleted or overwritten for a specified time or indefinitely. Also, Object Lock helps to meet WORM storage related regulatory requirements and adds a protection layer against object modifications and deletion.
ECS Object Lock allows you to manage object retention through retention periods and legal holds. With a retention period, you can specify a period during which an object remains locked. During the specified period, the object is WORM-protected, that is, the object cannot be overwritten or deleted. Legal hold provides the same protection as retention period but is independent from retention period, and does not have an expiration date. Legal hold is retained in objects until you explicitly remove it. Any user who has the appropriate Object Lock permissions can specify retention period and legal hold in objects.
So, let’s look at a practical example for how we would use these. We may have a situation in a medical environment whereby patient files are not set up correctly for retention purposes, and we have a regulatory requirement to retain these files. To comply with government regulations, we can use the following command to put a legal hold on a bucket that contains the medical records.
S3curl.pl --id=ecsflex -- http://${s3ip} /my-bucket/obj?legalhold -X PUT –d “<LegalHold><Status>on/Status></LegalHold>”
After he places a legal hold on the necessary buckets, our trusty storage administrator should be prepared if an audit is held.
Next let’s review how we use retention; Object lock has two retention modes:
- Compliance -- This is regarded as the stricter of the two modes and is primarily targeted for regulatory compliance for certain customer use cases. Users cannot overwrite or delete an object version. Additionally, users can neither remove nor shorten an object retention. However, with s3: PutObjectRetention permission, you can increase an object’s retention period.
- Governance -- The governance protection mode is focused on protecting against potential security vulnerabilities such as rogue actors, accidental deletion, or comprised credentials. Ordinary users cannot overwrite or delete an object version, but users with the special privilege of s3:BypassGovernanceRetention can remove or shorten an object retention and delete locked objects. This is, in essence, a superuser privilege, so it is not granted lightly. Additionally, a user with the s3:PutObjectRetention permission can increase the object retention period.
So, let’s look at a practical example for how we would use these modes. Let’s say from a governance perspective that we have an application owner who is working on an IT skunkworks type project that bore fruit, and they want to make sure that their work is protected and guards against any potential ransomware attack or through accidental deletion. To extend a retention time out to the year 2030 on an existing bucket, they can use this curl command.
S3curl.pl --id=ecsflex -- http://${s3ip} /my-bucket/obj?retention -X PUT –d “<Retention><Mode>GOVERNANCE</Mode><RetainUntilDate>2030-01-01T00:00:00.000Z</RetainUntilDate></Retention>”
This will ensure that the bucket is more secure and protects the user’s work from being overwritten.
ECS Object Lock fulfils some key requirements:
- Enables the management and enforcement of retention policies and legal holds for objects and buckets
- Supports a Governance and a Compliance version of enforcement
- Maintains data integrity and version consistency in multiple sites
We have delivered an API that enables customers to easily manage their Buckets and Objects while protecting themselves and complying to best practice standards. For more detail and other examples, please see our 3.6.2 Dell EMC ECS Data Access Guide.
Notes:
- The ECS Object Lock feature supports only the versioning enabled buckets.
- There is no ECS user interface for Object Lock. It can be accessed through ECS Object Lock APIs. (In the 3.6.2 Dell EMC ECS Data Access Guide, for the Object Lock API examples, see the section “Object Lock API Examples”; for the list of supported S3 APIs, see the section “S3 API supported and unsupported features”.)
- The locked objects are protected from life cycle deletions.
Author: Finbarr O’Riordan @finbarrorcork on Twitter
Better Protection with Dell EMC ECS Object Lock
Tue, 31 Aug 2021 20:46:06 -0000
|Read Time: 0 minutes
Dell EMC ECS supported WORM (write once, read many) based retention, starting with ECS 2.X. To provide more compatibility with more applications, ECS now supports the object lock feature (starting with ECS 3.6.2), which is compatible with the capabilities of Amazon S3 object lock.
Object lock is designed to meet compliance requirements such as SEC 17a4(f), FINRA Rule 4511(c), and CFTC Rule 17.
Object lock overview
Object lock prevents object version deletion during a user-defined retention period. Immutable S3 objects are protected using object- or bucket-level configuration of WORM and retention attributes. The retention policy is defined using the S3 API or bucket-level defaults. Objects are locked for the duration of the retention period, and legal hold scenarios are also supported.
There are two lock types for object lock:
- Retention period -- Specifies a fixed period of time during which an object version remains locked. During this period, your object version is WORM-protected and can't be overwritten or deleted.
- Legal hold -- Provides the same protection as a retention period, but it has no expiration date. Instead, a legal hold remains in place until you explicitly remove it. Legal holds are independent from retention periods.
There are two modes for the retention period:
- Governance mode -- users can't overwrite or delete an object version or alter its lock settings unless they have special permissions. With governance mode, you protect objects against being deleted by most users, but you can still grant some users permission to alter the retention settings or delete the object if necessary. You can also use governance mode to test retention-period settings before creating a compliance-mode retention period.
- Compliance mode -- a protected object version can't be overwritten or deleted by any user, including the root user in your account. When an object is locked in compliance mode, its retention mode can't be changed, and its retention period can't be shortened. Compliance mode helps ensure that an object version can't be overwritten or deleted for the duration of the retention period.
Object lock and lifecycle
Objects under lock are protected from lifecycle deletions.
Lifecycle logic is made difficult because of the variety of behavior of different locks. From a lifecycle point of view there are locks without a date, locks with date that can be extended, and locks with date that can be decreased.
- For compliance mode, the retain until date can't be decreased, but can be increased.
- For governance mode, the lock date can increase, decrease, or be removed.
- For legal hold, the lock is indefinite.
Some key points for the S3 object lock with ECS
- Object lock requires FS (File System) disabled on bucket in ECS version 3.6.2.
- Object lock requires ADO (Access During Outage) disabled on bucket in ECS version 3.6.2.
- Object lock is only supported by S3 API, not UI workflows in ECS version 3.6.2.
- Object lock only works with IAM, not legacy accounts.
- Object lock works only in versioned buckets.
- Enabling locking on the bucket automatically makes it versioned.
- Once bucket locking is enabled, it is not possible to disable object lock or suspend versioning for the bucket.
- A bucket has a default configuration including a retention mode (governance or compliance) and a retention period (which is days or years).
- Object locks apply to individual object versions only.
- Different versions of a single object can have different retention modes and periods.
- A lock prevents an object from being deleted or overwritten. Overwritten does not mean that new versions can't be created (new versions can be created with their own lock settings).
- An object can still be deleted. It creates a delete marker and the version still exists and is locked.
- Compliance mode is stricter, locks can't be removed, decreased, or downgraded to governance mode.
- Governance mode is less strict, it can be removed, bypassed, or elevated to compliance mode.
- An object can still be deleted, but the version still exists and is locked.
- Updating an object version's metadata, which occurs when you place or alter an object lock, doesn't overwrite the object version or reset its Last-Modified timestamp.
- Retention period can be placed on an object explicitly, or implicitly through a bucket default setting.
- Placing a default retention setting on a bucket doesn't place any retention settings on objects that already exist in the bucket.
- Changing a bucket's default retention period doesn't change the existing retention period for any objects in that bucket.
- Object lock and traditional bucket/object ECS retention can co-exist.
ECS object lock condition keys
Access control using IAM policies is an important part of the object lock functionality. The s3:BypassGovernanceRetention permission is important because it is required to delete a WORM-protected object in Governance mode. IAM policy conditions have been defined below to allow you to limit what retention period and legal hold can be specified in objects.
Condition Key | Description |
s3:object-lock-legal-hold | Enables enforcement of the specified object legal hold status |
s3:object-lock-mode | Enables enforcement of the specified object retention mode |
s3:object-lock-retain-until-date | Enables enforcement of a specific retain-until-date |
s3:object-lock-remaining-retention-days | Enables enforcement of an object relative to the remaining retention days |
ECS object lock API examples
This section lists s3curl examples of object Lock APIs. Put and Get object lock APIs can be used with and without the versionId parameter. If no versionId parameter is used, then the action applies to the latest version.
Operation | API request examples |
Create lock-enabled bucket | s3curl.pl --id=ecsflex --createBucket -- http://${s3ip}/mybucket -H "x-amz-bucket-object-lock-enabled: true" |
Enable object lock on existing bucket | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket?enable-objectlock -X PUT |
Get bucket default lock configuration | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket?object-lock |
Put bucket default lock configuration | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket?object-lock -X PUT \ -d "<ObjectLockConfiguration><ObjectLockEnabled>Enabled</ ObjectLockEnabled> <Rule><DefaultRetention><Mode>GOVERNANCE</Mode><Days>1</Days></ DefaultRetention></Rule></ObjectLockConfiguration>" |
Get legal hold | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket/obj?legal-hold |
Put legal hold on create | s3curl.pl --id=ecsflex --put=/root/100b.file -- http://${s3ip}/ my-bucket/obj -H "x-amz-object-lock-legal-hold: ON" |
Put legal hold on existing object | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket/obj?legalhold -X PUT -d "<LegalHold><Status>OFF</Status></LegalHold>" |
Get retention | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket/obj?retention |
Put retention on create | s3curl.pl --id=ecsflex --put=/root/100b.file -- http://${s3ip}/ my-bucket/obj -H "x-amz-object-lock-mode: GOVERNANCE" -H "x-amz-object-lock-retain-until-date: 2030-01-01T00:00:00.000Z" |
Put retention on existing object | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket/obj? retention -X PUT -d "<Retention><Mode>GOVERNANCE</ Mode><RetainUntilDate>2030-01-01T00:00:00.000Z</ RetainUntilDate></Retention>" |
Put retention on existing object (with bypass) | s3curl.pl --id=ecsflex -- http://${s3ip}/my-bucket/obj? retention -X PUT -d "<Retention><Mode>GOVERNANCE</ Mode><RetainUntilDate>2030-01-01T00:00:00.000Z</ RetainUntilDate></Retention>" -H "x-amz-bypass-governance-retention: true" |
Conclusion
Dell EMC ECS object lock helps to protect object versions from accidental or malicious deletion, such as a ransomware attack. It does this by allowing object versions to enter a WORM state where access is restricted based on attributes set on the object version.