Actions Library: S3 GuardDuty AV Scanner

This Action programmatically exports decrypted SendSafely package contents to a private AWS S3 bucket for malware scanning using AWS GuardDuty.

To request the template for this Action example, please reach out to your SendSafely account rep. 

Please note that this Action requires access to the contents of SendSafely packages, and thus must be configured with a Portal Master Key.

Setup Instructions

1. Deploy the Lambda

To deploy the Lambda, you'll need the following permissions in AWS:

• Create a new Lambda Function
• Create a new AWS Secret (AWS Secrets Manager)
• Define a custom IAM Role for the Lambda function

Follow these steps:

1. In AWS, navigate to CloudFormation and click Create stack, then select "With new resources (standard)" from the dropdown.
2. Under Template source, select "Upload a template file," then click Choose file and select the YAML file provided by your SendSafely account rep.
3. For the error reporting email, enter the email address that you wish to receive any errors–and any alerts, in the event that GuardDuty detects a file containing malware, or runs into an unsupported GuardDuty result (such as unsupported, access denied, or failed).
4. For the environment tag, choose dev, staging, or prod. You can deploy different instances of this Lambda to different environments for testing purposes.
5. For OtherStatusPolicy, choose what you want to do with the SendSafely package if the GuardDuty returns an unsupported, access denied, or failed result on a file. If true, this will unblock the file, if false, it will retain the block.
6. Click Next. Name the stack, e.g., "S3MalwareScanner," then click Next.
7. Click the three checkboxes at the bottom of the page, then click Next.
8. Click Submit.
9. Wait for the Stack's status to change from "CREATE_IN_PROGRESS" to "CREATE_COMPLETE." 

2. Update Secrets Manager

We'll update the malware-scan-config-{environment} Secret generated by this deployment. Click on this Secret in Secrets Manager, click Retrieve secret value, and click Edit. Provide the following secret values:

• ss-host
• ss-api-key
• ss-api-secret
• pk-<ss-public-key-id>. Note that you must update the Name of this secret to replace the text '<ss-public-key-id>' with the actual public key ID of your Master Key (the SendSafely Support team will provide you this ID when you submit them the public key). You must update the Value of this secret with the full text of the private key, including the opening and closing tags:

------BEGIN PGP PRIVATE KEY BLOCK-----
------END PGP PRIVATE KEY BLOCK-----

For now, leave the last two secret values be and Click Save. We'll populate one of them in Step 6.

3. Create a new Workflow

As an admin logged into your SendSafely portal, click the circle containing your initials in the top-right corner of the screen and select SendSafely Actions. Here, click New Workflow.

4. Choose the trigger event

At the time of this writing, the Actions framework supports two trigger events: "A file is uploaded to a Workspace" or "A package is finalized." If you wish to perform this Action on both events, you'll need to go through this process twice, setting up two Workflows: one for each event.

5. Decide whether this Workflow will apply to a specific user's packages (Optional)

This Workflow, by default, will apply to all packages portal-wide. To limit its scope to packages owned by a specific user:

1. Click the plus button and select Add an Event Filter.
2. From the Criteria dropdown, select Package Owner Email.
3. From the Operator dropdown, select equals.
4. In the Value input, type the email of the user in question and click Save.

6. Add the Actions 

Four Actions comprise this Workflow. We will add them one at a time.

Action 1.

First, we'll block the package or file, preventing your recipients from accessing it.

1. Click the plus button and select Add an Action.
2. From the Action dropdown, select Block Package (or, if the trigger event is "A file is uploaded to a Workspace, Block File).
3. From the Notification dropdown, select Notify on Error or Timeout.

Action 2.

Next, we'll invoke the webhook of the Lambda, which will use the Master Key to decrypt the package or file's contents, upload them to the S3, run a malware scan on them using GuardDuty, and return a verdict.

1. Click the plus button and select Add another Action.
2. From the Action dropdown, select Invoke an External Webhook.
3. From the Notification dropdown, select Notify on False, or Timeout.

4. Retrieve the WebhookUrl from the Outputs tab of the relevant Stack in CloudFormation, then paste it into the input in SendSafely and click Save. 

   

5. Click the text that says "Click here to view the action secret," then click Copy.
6. In AWS Secrets Manager, click into the "malware-scan-config-{environment}" Secret.
7. Click Retrieve secret value, then click Edit.
8. Paste the action secret into the value for action-secret-id-<actionId-finalize-package> (if the trigger event was "A package is finalized.") or for action-secret-id-<actionId-workspace-package> (if the trigger event was "A file is uploaded to a Workspace"). Replace the <actionId-finalize-package> or <actionId-workspace-package> placeholder in the key with the Action ID, then click Save.

Action 3.

Now, we'll unblock the package or file, rendering its contents available to its recipients.

1. Click the plus button and select Add another Action.
2. From the Action dropdown, select Unblock Package (or, if the trigger event is "A file is uploaded to a Workspace, Unblock File).
3. From the Notification dropdown, select Notify on Error or Timeout.

Add Action Filter.

We'll now add an Action Filter to this 3rd Action, so that it only runs if the 2nd Action succeeds. Packages deemed clean by GuardDuty will be unblocked, whereas packages deemed dirty will remain blocked.

1. Click Add Action Filter.
2. From the Criteria dropdown, select Action Step 2 Result.
3. From the Operator dropdown, select Equals.
4. From the Value dropdown, select True.

Action 4 (Optional).

If GuardDuty determines that the package contains malware, you may wish to delete it automatically.

1. Click the plus button and select Add another Action.
2. From the Action dropdown, select Delete Package (or, if the trigger event is "A file is uploaded to a Workspace, Delete File).
3. From the Notification dropdown, select Notify on Error or Timeout.

Add Action Filter.

We'll now add an Action Filter to this 4th Action, so that it only runs if the 2nd Action fails. Packages that GuardDuty deems malicious will be deleted.

1. Click Add Action Filter.
2. From the Criteria dropdown, select Action Step 2 Result.
3. From the Operator dropdown, select Equals.
4. From the Value dropdown, select False.

7. Enable GuardDuty Scanning on the S3 Bucket 

1. Open Amazon GuardDuty in the AWS Console.

2. Go to Malware Protection.

3. Choose Enable Malware Protection for S3.

4. Enter:

   • Bucket name: sendsafely-malware-scan-<your-selected-environment>
   • Leave prefix blank (optional).
   • Select "Tag scanned objects" to track scan results.

5. Under Service Access, select Create and use a new service role.

6. Press Enable.

8. Name and Activate the Workflow

Hover over the "New Workflow" text at the top of the page, then click the pencil icon and give the Action a descriptive name, such as GuardDuty Malware Scanner. Then click the toggle next to the text "Disabled" to enable the Action. The text will change from "Disabled" to "Live.

9. Test the Workflow

Now that we've activated the Workflow, let's trigger it. If the triggering event is "A package is finalized," we'll make a Dropzone submission or create a Transfer package. If the triggering event is "A file is uploaded to a Workspace," we'll upload a file to a Workspace.

If GuardDuty detects that the package or file that triggered the Action contains malware, it will remain blocked, or–if you prefer–be deleted. If the package or file is deemed clean, however, it will be unblocked.

Important Note: Lambda RAM Limits for Large Files

This Lambda function is configured with 3 GB of memory to support downloading and processing large files. In practice, files larger than 1 GB may hit the 15-minute execution limit if insufficient CPU/memory resources are available.

AWS Lambda supports up to 10,240 MB per function, but new accounts and certain regions may enforce a lower default cap (often 3 GB). If you encounter deployment errors or performance issues, request a quota increase for Lambda memory in the AWS Service Quotas console.

Increasing memory and redeploying

Once your quota increase is approved, update the CloudFormation template to allocate more memory. This can be done by editing the MemorySize property (line 133 of the template) before redeploying.

Increasing memory on an already deployed function

If the function is already deployed and you have obtained a quota increase, you can update the memory allocation without re-deploying the entire stack:

Option 1: AWS CLI

aws lambda update-function-configuration \
  --function-name <your-function-name> \
  --memory-size 3008

 

Replace 3008 with the desired memory in MB (up to 10240).

Option 2: AWS Console

1. Navigate to the Lambda service in the AWS Console.
2. Select your function.
3. Under the Configuration tab → General configuration, click Edit.
4. Adjust the Memory (MB) value and save.

These changes take effect immediately, without requiring a new deployment. Please note that provisioning large RAM for Lambda comes with increased costs.