AWS Integration FAQ

CloudTrail
Zscaler MDR needs permission within your AWS environment which stores the CloudTrail telemetry. The S3 bucket must publish S3 object write events to a SNS topic, and Zscaler MDR must have permission to subscribe to that topic.

GuardDuty
Zscaler MDR needs permission within your AWS environment to read data from the S3 bucket which stores the GuardDuty findings. The S3 bucket must publish S3 object write events to a SNS topic, and Zscaler MDR must have permission to subscribe to that topic.

Environment Scanning
Zscaler MDR infrastructure needs to assume a role within your AWS environment in order to regularly scan for newly-created accounts and resources, ensuring that data is properly attributed and monitored as the environment grows and evolves.

The permissions are the minimum we need for discovery inside your environment. None of these permissions edit, add, or delete your resources in any way.

The following permissions are required for the CloudTrail and GuardDuty integrations:

The following permissions are used for license calculation purposes. For more information, see How Cloud Control Plane Licensing and Usage are Determined.

The following permissions are used for troubleshooting the integration:

We also need the following roles for the Zscaler MDR partner access role (redcanary-partner-access):

Important Cost Information

Before enabling GuardDuty, understand that it’s a paid service that monitors for malicious activity and unauthorized behavior to protect your AWS resources. The service charges are based on the volume of AWS data analyzed, such as logs and events. Ensure you review the pricing details on the GuardDuty page to understand the cost implications and budget accordingly before activation.

Zscaler MDR strongly recommends turning on AWS GuardDuty. GuardDuty is a powerful ally that bolsters your security posture. It helps correlate and enrich the telemetry data we’re already analyzing with CloudTrail. By enabling GuardDuty, you're not just collecting data but empowering our systems to deliver deeper insights and more comprehensive security analysis.

GuardDuty and CloudTrail create a dynamic duo for Zscaler MDR, enhancing our ability to detect and respond to potential threats more swiftly and effectively.

Finally, GuardDuty acts as an extra layer of intelligence, providing context to the footage by correlating different data points and highlighting activities that require closer inspection. Zscaler MDR will be able to review what has been recorded while also understanding the bigger picture and respond more effectively to security incidents.

While we recommend that you allow Zscaler MDR to ingest GuardDuty findings, you can remove GuardDuty from the integration by deleting the ARNs from the GuardDuty section on the configuration page. You can also add GuardDuty if you chose to skip it during initial provisioning. Note that if you decide to add GuardDuty alerts later, you’ll also need to re-provision the IAM role to update the permissions.

A failing GuardDuty alerts are being processed status check in Zscaler MDR can mean one of two things:

• The Zscaler MDR integration isn’t properly configured to read GuardDuty data from the S3 bucket

• GuardDuty isn’t set up to export data to an S3 bucket in the AWS account

Please review Step 4  - Identify the GuardDuty S3 Bucket on the Integrate Amazon Web Services (AWS) with Zscaler MDR page to ensure the integration is configured to read from the S3 bucket. For more information on setting up an S3 bucket for GuardDuty, see the AWS documentation.

Yes. You must deploy the redcanary-partner-access role to all AWS accounts. It’s used to access the S3 buckets where the CloudTrail and GuardDuty data is stored, and also for license scanning. We suggest using CloudFormation to automate this deployment, using the template generated by the integration configuration page.

Please do not rename the role or change its permissions.

Yes, you can use an encrypted SNS topic to receive the event notifications sent when data is added to the S3 buckets that store the CloudTrail telemetry and GuardDuty findings. However, you’ll need to give the S3 service principal permission to access the KMS key used to encrypt the topic. Note that this means you can’t use an AWS managed key for encryption.

To set the service principal permissions, add the following policy to your KMS key:

{
                                "Version": "2012-10-17",
                                "Id": "example-ID",
                                "Statement": [
                                {
                                "Sid": "example-statement-ID",
                                "Effect": "Allow",
                                "Principal": {
                                "Service": "s3.amazonaws.com"
                                },
                                "Action": [
                                "kms:GenerateDataKey",
                                "kms:Decrypt"
                                ],
                                "Resource": "*"
                                }
                                ]
                                }

For more information, please see the AWS documentation.