Amazon GuardDuty Malware Protection for Amazon S3 is now generally available at re:Inforce 2024

Amazon GuardDuty Malware Protection for Amazon S3 was released at AWS re:Inforce 2024, so I immediately checked it out.

- The GuardDuty Malware Protection extension detects the upload of malicious files to the selected S3 bucket
- If GuardDuty is not enabled, you can enable only the GuardDuty Malware Protection for Amazon S3 feature
- The scanned object is tagged with GuardDutyMalwareScanStatus, and the tag value indicates whether it was determined to be a threat

The tag values ​​are as follows

- NO_THREATS_FOUND: No potential threats were detected
- THREATS_FOUND: Potential threats were detected
- UNSUPPORTED: Scanning of the object is not supported
- ACCESS_DENIED: The object cannot be accessed
- FAILED: Malware scanning cannot be performed

More details about tags are also available in the following documentation

- Pricing is based on the size and number of objects.
Prices are as follows:
- $0.79/GB per month for file size
- $0.282/1k per month for number of files

Click "Enable Malware Protection for S3" from "Malware Protection for S3" in GuardDuty.

Select "All objects in S3 bucket" as the S3 bucket to scan, and "Tag objects" as the tagging.
Create an IAM role for the Malware Protection for Amazon S3 feature.
Click "View Permissions".

The policies required for the IAM role will be displayed, so copy them.

For reference, the policies and trust relationships are as follows:

Policy

Trust relationship

Next, create an IAM role.
The entity type should be a custom trust policy and paste the copied trust relationship.

Policies are added as inline policies after creating a role.
Enter a role name and create the role.

In the inline policy permissions, paste the policy that you copied.

Enter a policy name and create the policy.

Return to the Enable S3 Malware Protection setting, select the IAM role you created, and click "Enable."

S3 Malware Protection has been enabled.

You can monitor the scan status.

The IAM policy had permissions to S3 and EventBridge.
So I checked EventBridge and found that a rule called "DO-NOT-DELETE-AmazonGuardDutyMalwareProtectionS3-<string>" had been created.
Looking at the event pattern and target, it appeared that when an object is created in the S3 bucket, guardduty-malware-protection-plan is launched and a scan is performed.

Upload the eicar file to S3 bucket.
By the way, when S3 Malware Protection is enabled, a test file called "malware-protection-resource-validation-object" is automatically created.

When watching the monitoring, you can see that it is being scanned and determined to be infected.

The eicar file is tagged with "GuardDutyMalwareScanStatus: THREATS_FOUND", indicating that a potential threat has been detected.

By the way, if you look at the tag of the test file "malware-protection-resource-validation-object" created during activation, you will see that it is tagged with "GuardDutyMalwareScanStatus: NO_THREATS_FOUND", which indicates that it was not determined to be a potential threat.

Now let's look at the detection results.
Looking at the "Detection Results" in GuardDuty, you can see that the detection result type is "Object:S3/MaliciousFile" with a severity of "High".

If you look at the details, you can see the reason for the detection and information about the object.

After scanning, objects are tagged, so you can implement tag-based access control (TBAC) in your bucket policies to isolate malware from the resources it accesses.

There is an example policy, so set it in the S3 bucket policy.

It denies access to any objects other than those with the tag "GuardDutyMalwareScanStatus": "NO_THREATS_FOUND".

Tag-Based Access Control (TBAC) Bucket Policy Examples

As a test, upload a harmless file to your S3 bucket.

The result was "GuardDutyMalwareScanStatus: NO_THREATS_FOUND".

When I tried copying it locally using AWS CloudShell, only the eicar file was blocked.

I tried Amazon GuardDuty Malware Protection for Amazon S3.
I'm glad that we can easily implement the isolation mechanism, not just detection.

As a use case, I think it will be effective in applications where an unspecified number of users can upload files to an S3 bucket.
On the other hand, there seems to be no need to force it on S3 buckets that are used internally for log storage and do not have room for uploads from an unspecified number of users.
Use it according to your needs.

You can freely customize tagging and EventBridge, so you can send notification emails to operators or isolate them in other buckets.
It's a good idea to design it flexibly according to your requirements.

The scope of use of GuardDuty is expanding, so let's try it out.