AWS Integration FAQ

The permissions are what we need from GuardDuty’s perspective for discovery inside your environment. NONE of these permissions edit, add, or delete your resources in any way. Below is a list of permissions we need for licensure.

• For more information, see How Cloud Control Plane Licensing and Usage are Determined and Amazon Web Services ingest details.

The permissions below are all used for License calculation purposes:

The permissions below are needed for the Cloudtrail integration:

We also ask for the following roles for the Red Canary Partner Access Role:

Important Cost Information

Before enabling GuardDuty, it’s essential to understand that it is 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 it analyzes, 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.

Red Canary 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 Red Canary, 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. Red Canary will be able to review what has been recorded while also understanding the bigger picture and respond more effectively to security incidents.

The 'rc-partner-access-control' role is not required for the CloudTrail integration, but it is critical to scan the environment to obtain resource counts for the license usage page.

Yes. You must deploy the 'rc-partner-access-control' role to all AWS accounts for full coverage. This action enables Red Canary to fetch GuardDuty alerts from each account. This role is deployed to all accounts you want Red Canary to monitor. We suggest using CloudFormation to automate this deployment. Enter any IAM role ARN from one of the accounts in the configuration box. However, the account number may vary, and the role name remains consistent across all AWS accounts in your organization.

Red Canary’s integration does not support fetching GuardDuty alerts from S3 buckets. We use polling via Security Token Service (STS), assuming the API role from the account was deployed using a CloudFormation StackSet or Terraform template. This method necessitates deploying the role in each account, as we use the same pattern to access accounts for Resource Scanning and GuardDuty.

You’ll need to access the ACL and turn off everything other than the Bucket Owner Checks. Otherwise the following error may be thrown when turning off the bucket ownership:

As demonstrated in the image below, this is what the ACL should look like before we go back to Object Ownership and try to disable the object ACL:

By default, the management account will not have the stack set applied. For more information, see Working with AWS CloudFormation StackSets.

Note: The rc-partner-access-role won’t appear on this account. However, you can force it by including the account name during the stack set account creation, which shows up only if you select the self-service permissions.

Yes! You can integrate AWS CloudTrail and GuardDuty at the same time. If you previously integrated Guard Duty with Red Canary, you can decommission this and use the new unified integration.