# AWS CloudTrail and GuardDuty
In this guide, you will configure AWS CloudTrail and GuardDuty to forward events and alerts to Radiant Security. CloudTrail logs API activity across your AWS environment, while GuardDuty detects suspicious behavior and potential threats.
This guide assumes a clean slate: neither service is currently enabled. If your environment already uses CloudTrail or GuardDuty, you can skip some steps. However, make sure to review all **Important note** callouts to ensure your configuration meets Radiant’s integration requirements.
{% hint style="warning" %}
**Important note:** These highlight important configuration details necessary for the setup to function properly. Adjust your environment accordingly.
{% endhint %}
### Prerequisites
This configuration requires the following:
* [ ] AWS user permissions to create and update the following resources: IAM, CloudTrail, GuardDuty, SNS, and KMS.
* [ ] Group all CloudTrail Logs into one account for event collection.
* [ ] Place all GuardDuty alerts across all of the monitored accounts into a single S3 bucket. For more information on how to manage multiple accounts in Amazon GuardDuty, please visit [this page](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).
### Configuration in AWS
Before configuring the connector on the Radiant Security app, you must set up CloudTrail and GuardDuty and create an IAM Role on AWS.
### **Create and configure AWS CloudTrail**
Amazon CloudTrail is a service provided by AWS that allows you to enable logging of AWS API calls. This is useful for auditing, compliance, and security purposes. Below are the general steps for creating and configuring AWS CloudTrail.
{% hint style="info" %}
**Note**: The ARN of S3, SNS, and KMS (if enabled) will be used when configuring the IAM role and the Radiant Security connector. Be sure to copy and store those values.
{% endhint %}
{% hint style="info" %}
**Note**: You need to perform this step using the **Management Account** for the AWS Organizations or use an account that is **Delegated Administrator for AWS Organizations.** Otherwise the checkbox **Enable for all accounts in my organization** won't be available.
{% endhint %}
1. Sign in to the **AWS Management Console**.
2. Navigate to **CloudTrail**.
3. On the CloudTrail service home page, select **Create trail.**
4. In the **Choose trail attributes** page, configure the trail with the following required settings:
* Enter a name for your trail. We suggest `management-events`.
* Select the **Enable for all accounts in my organization** checkbox. This will gather logs from all accounts. This option is available only to administrator accounts.
* For **Storage location**, choose where to store the logs. You can create a new S3 bucket or use an existing bucket.
* Optionally, if you'd like to enable log encryption select the checkbox for **Log file SSE-KMS encryption**. Choose to set a **New** KMS alias. We suggest naming it: `cloudtrail-log-encryption`.
* Under **Additional** **settings**, enable the **SNS** notification delivery by selecting the checkbox. Choose to use a **New** **SNS**.
{% hint style="warning" %}
**Important note**: Ensure that the checkbox titled **Enable for all accounts in my organization** is selected and enabled. If you choose to use an existing S3 bucket, KMS or SNS topic, make sure that they have the correct policies set to allow CloudTrail to perform necessary actions such as encrypting S3 files and publishing to the SNS topic.
By creating those resources during this configuration, AWS will take care of those permissions.
{% endhint %}
5. Now, you'll need to configure the log events:
* On the **Choose log events** page, under **Events** select the **Management events** and **Data events** checkboxes. While selecting **Data events** is optional, we recommend enabling it to improve RCA/Investigation.
* For **Management events,** under **API activity** select the **Read** and **Write** checkboxes.
* For **Data events,** Under **Data event type** select **S3** from the drop-down. In the **Log selector template** select **Log all events** from the drop-down. Alternatively, you can select the specific events from S3 you want to monitor.
6. Review the settings you've chosen for your trail. When you're ready to create your trail, click **Create trail.**
{% hint style="success" %}
**Tip:** For more details on how to create a trail, you can review the AWS documentation on [creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html).
{% endhint %}
### **Create and configure Amazon GuardDuty**
Amazon GuardDuty is a managed threat detection service that continuously monitors malicious or unauthorized activities in your AWS environment. The following steps outline how to create and configure Amazon GuardDuty.
{% hint style="info" %}
**Note:** Remember to copy and store all the **ARNs** created during the following steps as you will need them.
{% endhint %}
1. Sign in to the **AWS Management Console**.
2. Navigate to S3 and create a bucket to store all logs ([AWS Tutorial](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html)). Store the S3 ARN as you will use in GuardsDuty settings. We suggest creating a **General purpose** bucket leaving the default settings unchanged. We also suggest naming the bucket: `{your_company_name}-guardduty-radiantsecurity`.
3. Navigate to KMS and create a key to cipher all logs ([AWS Tutorial](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)). Store the KMS key ARN as you will use in GuardsDuty settings. We suggest the default configurations with `guardduty-s3-radiantsecurity` as the **Alias** name. We will come back to this resource later to attach a policy allowing GuardDuty to use this key.
4. Navigate to **GuardDuty**.
5. Click **Enable GuardDuty**.
6. In the navigation pane, click **S3 Protection** and choose **Enable** to enable S3 monitoring.
7. Navigate to **Settings** to configure the **Findings export options**.
* For **Edit frequency to publish updated findings**, select **15 minutes**. Click **Save changes**.
* For the **Edit** **S3 bucket**, add the S3 bucket ARN and the KMS key ARN created in the previous steps. GuardDuty enforces log encryption using KMS.
Follow the AWS instructions to attach the policy to the S3 bucket and KMS key described in the second box on this page.
8. Still on GuardDuty settings, go to the **Delegated Administrator** section, fill your current account ID and click **Delegate**.
{% hint style="info" %}
**Note:** This section might be grayed out if the account you’re logged into does not have organization admin rights. If that is the case and you only want to monitor your current account, you can skip steps 15-18.
{% endhint %}
9. On the left side menu, click **Accounts**. You should see a list of all the available accounts in your organization.
10. We recommend checking all accounts. You might want to uncheck those used for tests or without external exposure. On the **Actions** drop-down menu, click **Add** **member**.
11. Update the page and select all the previously selected accounts again. **On the Edit Protection Plans** Drop-down menu, for each option (Except 'Runtime Monitoring - Automated agent configuration'), click **Enable for `N` selected Accounts**.
Now that we have configured GuardDuty, we must configure event an event notification for when the findings are created.
12. Navigate to SNS and create a new **Topic** with **Standard** type. ([AWS Tutorial for creating an SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html)). We suggest naming it: `guardduty-s3-radiantsecurity`
13. On the topic page, you must configure the **Access Policy** to allow the S3 to publish the events on the SNS.
* This is an example of the policy:
{% hint style="warning" %}
**Important Note:** Replace `arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}` with the SNS arn and `${AWS_ACCOUNT_ID}` with your Account ID.
{% endhint %}
```
{
"Version": "2008-10-17",
"Id": "__default_policy_ID",
"Statement": [
{
"Sid": "__default_statement_ID",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"SNS:Publish",
"SNS:RemovePermission",
"SNS:SetTopicAttributes",
"SNS:DeleteTopic",
"SNS:ListSubscriptionsByTopic",
"SNS:GetTopicAttributes",
"SNS:AddPermission",
"SNS:Subscribe"
],
"Resource": "arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}",
"Condition": {
"StringEquals": {
"AWS:SourceOwner": "${AWS_ACCOUNT_ID}"
}
}
},
{
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": "sns:Publish",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "${AWS_ACCOUNT_ID}"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:s3:::*"
}
}
}
]
}
```
14. Navigate to **S3** and open the bucket configured on **GuardDuty**.
15. Navigate to the bucket **properties**.
16. Find the **Event notifications** section and click **Create event notification**.
17. On the **Create event notification** page, configure the notification with the following settings:
* For **Event name**, enter a name for the event notification. We suggest `guardduty-new-finding`
* For **Event** **types**, under **Object** **creation**, select **All object create events**.
18. For **Destination,** select the **SNS topic** and add the SNS topic that was created.
19. Review and save the settings you've chosen.
### **Create the credentials and enable the data connector**
Next, you'll add the necessary credentials and enable the AWS data connector so that Radiant Security can automatically subscribe to both SNS topics and collect the CloudTrail and GuardDuty logs. The following steps outline how to add the credentials and enable the data connector.
1. Log in to [Radiant Security](https://app.radiantsecurity.ai/).
2. Navigate to **Settings** on the sidebar.
3. From the navigation menu, click **Settings** > **Services** > **Credentials**.
4. Click **+** **Add Credential**.
5. From the list of credentials, select **Amazon Web Services** and click **Credentials**.
6. Enter a **Credential Name** and fill in all of the fields with the respective values. Add the following values you saved from the previous steps:
* **SNS Topic Name for GuardDuty**
* **SNS Topic Name for CloudTrail**
7. Return to the **Settings** page and click **Data Connectors**.
8. Click **+ Add Connector**.
9. Search for and select the **Amazon Web Services** option and then click **Data** **Feeds**.
10. Select **Amazon Web Services CloudTrail** and **Amazon Web Services GuardDuty.**
11. Select the credentials of this vendor from the drop-down.
12. Click **Add** **Connector** to save the connector.
13. Return to the **Settings** page. In **Data Connectors**, search for **Amazon Web Services**.
14. Click **View Details** and copy the **AWS External Role ID**. You'll use this value for the creation of the IAM role in the upcoming steps.
{% hint style="info" %}
**Note:** Save the **AWS External Role ID** to use in the upcoming steps for IAM roles. You'll replace the variable **${RS\_CREDENTIAL\_ID}** on the Custom trust policy with this ID.
{% endhint %}
### Create an configure the IAM roles
Finally, you’ll create and configure an Identity and Access Management (IAM) role in AWS roles to grant permissions to Radiant Security to access AWS resources. The following steps outline how to create and configure an IAM role.
{% hint style="info" %}
**Note:** The main account role must be configured on the account that will centralize the logs.
{% endhint %}
{% hint style="info" %}
**Note:** Only add the KMS keys used for encryption in the last part. We must remove the last object if we do not use any KMS in the resources.
{% endhint %}
1. Sign in to the **AWS Management Console** on the main account.
2. Navigate to **IAM**.
3. Select **Policies** and click **Create Policy**.
4. For **Specify Permission**, select the JSON format and use the JSON below:
{% code overflow="wrap" %}
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3Api",
"Effect": "Allow",
"Action": [
"s3:GetBucketAcl",
"s3:GetEncryptionConfiguration",
"s3:GetBucketLogging",
"s3:GetBucketPolicy",
"s3:GetBucketPolicyStatus",
"s3:GetBucketTagging",
"s3:GetBucketWebsite",
"s3:GetObjectAcl",
"s3:GetObjectAttributes",
"s3:GetAccountPublicAccessBlock",
"s3:GetBucketPublicAccessBlock",
"s3:GetObject",
"s3:ListAllMyBuckets",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::*",
"arn:aws:s3:::*/*"
]
},
{
"Sid": "EC2Api",
"Effect": "Allow",
"Action": [
"ec2:DescribeAddresses",
"ec2:DescribeImageAttribute",
"ec2:DescribeImages",
"ec2:DescribeInstanceStatus",
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroupRules",
"ec2:DescribeSecurityGroups",
"ec2:DescribeVolumeAttribute",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVolumes",
"ec2:DescribeVolumesModifications"
],
"Resource": [
"*"
]
},
{
"Sid": "GuarddutyApi",
"Effect": "Allow",
"Action": [
"guardduty:ListFindings",
"guardduty:GetFindings"
],
"Resource": [
"arn:*:guardduty:*:*:*"
]
},
{
"Sid": "IAMApi",
"Effect": "Allow",
"Action": [
"iam:GetAccessKeyLastUsed",
"iam:GetAccountAuthorizationDetails",
"iam:GetAccountSummary",
"iam:GetGroup",
"iam:GetGroupPolicy",
"iam:GetInstanceProfile",
"iam:GetLoginProfile",
"iam:GetMFADevice",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:GetSAMLProvider",
"iam:GetServiceLastAccessedDetails",
"iam:GetServiceLastAccessedDetailsWithEntities",
"iam:GetUser",
"iam:GetUserPolicy",
"iam:ListAccessKeys",
"iam:ListAccountAliases",
"iam:ListAttachedGroupPolicies",
"iam:ListAttachedRolePolicies",
"iam:ListAttachedUserPolicies",
"iam:ListEntitiesForPolicy",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListInstanceProfileTags",
"iam:ListInstanceProfiles",
"iam:ListInstanceProfilesForRole",
"iam:ListPolicies",
"iam:ListPoliciesGrantingServiceAccess",
"iam:ListPolicyVersions",
"iam:ListRolePolicies",
"iam:ListRoles",
"iam:ListUserPolicies",
"iam:ListUserTags",
"iam:ListUsers",
"iam:ListVirtualMFADevices"
],
"Resource": [
"arn:aws:iam::*:role/*",
"arn:aws:iam::*:saml-provider/*",
"arn:aws:iam::*:instance-profile/*",
"arn:aws:iam::*:user/*",
"arn:aws:iam::*:group/*",
"arn:aws:iam::*:policy/*"
]
},
{
"Sid": "Account",
"Effect": "Allow",
"Action": [
"account:GetAccountInformation"
],
"Resource": "*"
}
]
}
```
{% endcode %}
5. Enter a **Policy name,** review the settings, and create the policy.
6. On the **Roles** page, and click **Create role**.
7. On the **Select trusted entity** page, select the following:
* For **Trusted entity type**, select **Custom trust policy** to allow Radiant Security to use this role to access the account.
* For **Custom trust policy**, in the text box, add the following JSON, making sure to replace `${RS_CREDENTIAL_ID}` with the value provided in Radiant Security connector’s page:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AssumeRadiantSecurity",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "${RS_CREDENTIAL_ID}"
}
}
}
]
}
```
This line: `"AWS": "arn:aws:sts::649384204969:assumed-role/tenant-aws-access-role/radiant-security"` might be highlighted as an error in the AWS console. However, you can still save and use this policy.
8. On the **Add permissions** page, find and select the policy for the role.
9. Set the name to be `radiant-aws-access-role`, review and save the role.
{% hint style="info" %}
**Note:** Our platform enforces that role name. This is for enhanced security.
{% endhint %}
### Permissions
| S3 | s3:Get\* | All | CloudTrail, GuardDuty | Allows access to files and information from buckets. |
| --- | ----------------------- | ---- | --------------------- | ------------------------------------------------------------ |
| S3 | s3:List\* | All | CloudTrail, GuardDuty | Allow a list of all buckets and files. |
| SNS | sns:Subscribe | Main | CloudTrail, GuardDuty | Allow our queue to subscribe on SNS. |
| SNS | sns:Unsubscribe | Main | CloudTrail, GuardDuty | Allow our queue to unsubscribe on SNS. |
| SNS | sns:ConfirmSubscription | Main | CloudTrail, GuardDuty | Allow your system to confirm the subscription. |
| KMS | kms:Decrypt | Main | CloudTrail, GuardDuty | Allow to get the key and decrypt log files. |
| STS | sts:AssumeRole | Main | CloudTrail, GuardDuty | Allow assuming a role in other accounts in the organization. |
### Optional: Export GuardDuty logs to the main account bucket
In this section, you’ll export GuardDuty logs to the main account bucket. This section is marked as optional because you may have already done this.
1. For each sub account with its own GuardDuty, extract the detector identifier for each account. This is found on the **GuardDuty** > **Settings** page.
2. In the main account S3 bucket, edit the **Bucket** **policy** and add the following permissions, filling in the **SourceARN** for each GuardDuty detector:
```
{
"Sid": "Allow PutObject All GuardDuty",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:SourceArn": [
"arn:aws:guardduty:::detector/",
"arn:aws:guardduty:::detector/",
...
]
}
}
},
{
"Sid": "Allow GetBucketLocation All GuardDuty",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:GetBucketLocation",
"Resource": "arn:aws:s3:::/*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:SourceArn": [
"arn:aws:guardduty:::detector/",
"arn:aws:guardduty:::detector/",
...
]
}
}
}
```
3. In the main KMS account, edit the permissions for the KMS configured to encrypt the S3 bucket files. Add the following, filling in the ARN for each GuardDuty detector:
```
{
"Sid": "Allow GuardDuty to encrypt findings All Accounts",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "kms:GenerateDataKey",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"aws:SourceArn": [
"arn:aws:guardduty:::detector/",
"arn:aws:guardduty:::detector/",
...
]
}
}
}
```
4. After the permissions are set, execute the following command within each AWS account context (go to the AWS Console and execute it in the CloudShell):
```
aws guardduty create-publishing-destination --detector-id 0 --destination-type S3 --destination-properties DestinationArn=0,KmsKeyArn=0 --region 0
```
5. This command should finalize with the **DestinationID**:
```
{
"DestinationID": "xxx"
}
```
6. If the command fails and finalizes with the following message, then the permissions that were added in the previous steps were not correctly set up:
```
The command does not have proper permissions for the given KMS or destination
```
### Recommended: Test GuardDuty integration with Radiant Security
Since this is a lengthy integration that involves multiple AWS accounts, we highly recommend testing the integration from end-to-end. Refer to the [Test GuardDuty’s Integration with Radiant Security](https://help.radiantsecurity.ai/radiant-connectors/data-connectors/aws/aws-cloudtrail-and-guardduty/test-guarddutys-integration-with-radiant) guide to help you test GuardDuty integration.
