Set up AWS Connectors

Set up AWS CloudTrail and GuardDuty connectors.

Overview

Radiant Security utilizes AWS CloudTrail and GuardDuty as sources of events and alerts, ensuring a proactive approach to triaging and investigating alerts within AWS cloud environments. CloudTrail records API actions while GuardDuty actively monitors for threats.

This guide addresses the broadest scenario, assuming neither GuardDuty nor CloudTrail are enabled. If these services are already configured in your organization, you can skip certain steps. However, be sure to review the callout boxes labeled “Attention.” These highlight important configuration details necessary for the setup to function properly. Adjust your environment accordingly.

You'll need to complete the following configuration requirements:

1. Create and configure AWS CloudTrail
2. Create and configure Amazon GuardDuty
3. Create the credentials and enable the data connector
4. Create and configure the IAM roles
5. Optional: Export GuardDuty logs to the main account bucket
6. Recommended: Test GuardDuty integration with Radiant Security

Prerequisites

This configuration requires the following:

1. AWS user permissions to create and update the following resources: IAM, CloudTrail, GuardDuty, SNS, and KMS.
2. Group all CloudTrail Logs into one account for event collection.
3. 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.

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.

Example of policy for KMS

{
   "Version":"2012-10-17",
   "Id":"Key policy created by CloudTrail",
   "Statement":[
      {
         "Sid":"Enable IAM User Permissions",
         "Effect":"Allow",
         "Principal":{
            "AWS":[
               "arn:aws:iam::${AWS_ACCOUNT_ID}:root"
            ]
         },
         "Action":"kms:*",
         "Resource":"*"
      },
      {
         "Sid":"Allow CloudTrail to encrypt logs",
         "Effect":"Allow",
         "Principal":{
            "Service":"cloudtrail.amazonaws.com"
         },
         "Action":"kms:GenerateDataKey*",
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "aws:SourceArn":"arn:aws:cloudtrail:${REGION}:${AWS_ACCOUNT_ID}:trail/${TRAIL_NAME}"
            },
            "StringLike":{
               "kms:EncryptionContext:aws:cloudtrail:arn":"arn:aws:cloudtrail:*:${AWS_ACCOUNT_ID}:trail/*"
            }
         }
      },
      {
         "Sid":"Allow CloudTrail to describe key",
         "Effect":"Allow",
         "Principal":{
            "Service":"cloudtrail.amazonaws.com"
         },
         "Action":"kms:DescribeKey",
         "Resource":"*"
      },
      {
         "Sid":"Allow principals in the account to decrypt log files",
         "Effect":"Allow",
         "Principal":{
            "AWS":"*"
         },
         "Action":[
            "kms:Decrypt",
            "kms:ReEncryptFrom"
         ],
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "kms:CallerAccount":"${AWS_ACCOUNT_ID}"
            },
            "StringLike":{
               "kms:EncryptionContext:aws:cloudtrail:arn":"arn:aws:cloudtrail:*:${AWS_ACCOUNT_ID}:trail/*"
            }
         }
      },
      {
         "Sid":"Allow alias creation during setup",
         "Effect":"Allow",
         "Principal":{
            "AWS":"*"
         },
         "Action":"kms:CreateAlias",
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "kms:ViaService":"ec2.us-west-2.amazonaws.com",
               "kms:CallerAccount":"${AWS_ACCOUNT_ID}"
            }
         }
      },
      {
         "Sid":"Enable cross account log decryption",
         "Effect":"Allow",
         "Principal":{
            "AWS":"*"
         },
         "Action":[
            "kms:Decrypt",
            "kms:ReEncryptFrom"
         ],
         "Resource":"*",
         "Condition":{
            "StringEquals":{
               "kms:CallerAccount":"${AWS_ACCOUNT_ID}"
            },
            "StringLike":{
               "kms:EncryptionContext:aws:cloudtrail:arn":"arn:aws:cloudtrail:*:${AWS_ACCOUNT_ID}:trail/*"
            }
         }
      }
   ]
}
 

Example of policy for SNS

{
   "Version":"2008-10-17",
   "Id":"__default_policy_ID",
   "Statement":[
      {
         "Sid":"__default_statement_ID",
         "Effect":"Allow",
         "Principal":{
            "AWS":"*"
         },
         "Action":[
            "SNS:GetTopicAttributes",
            "SNS:SetTopicAttributes",
            "SNS:AddPermission",
            "SNS:RemovePermission",
            "SNS:DeleteTopic",
            "SNS:Subscribe",
            "SNS:ListSubscriptionsByTopic",
            "SNS:Publish"
         ],
         "Resource":"arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}",
         "Condition":{
            "StringEquals":{
               "AWS:SourceOwner":"${AWS_ACCOUNT_ID}"
            }
         }
      },
      {
         "Sid":"AWSCloudTrailSNSPolicy20150319",
         "Effect":"Allow",
         "Principal":{
            "Service":"cloudtrail.amazonaws.com"
         },
         "Action":"SNS:Publish",
         "Resource":"arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME}",
         "Condition":{
            "StringEquals":{
               "aws:SourceArn":"arn:aws:cloudtrail:${REGION}:${AWS_ACCOUNT_ID}:trail/${TRAIL_NAME}"
            }
         }
      }
   ]
}

 

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.

1. Sign in to the AWS Management Console.
2. Navigate to S3 and create a bucket to store all logs (AWS Tutorial). 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). 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.
   1. For Edit frequency to publish updated findings, select 15 minutes. Click Save changes.
      

   2. 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. Navigate to SNS and create a new  with Standard type. (AWS Tutorial for creating an SNS). We suggest naming it: guardduty-s3-radiantsecurity

9. On the topic page, you must configure the Access Policy to allow the S3 to publish the events on the SNS.

   1. This is an example of the policy:

      {
          "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:::*"
                }
              }
            }
          ]
        }
      

10. Navigate to S3 and open the bucket configured on GuardDuty.

11. Navigate to the bucket properties.

12. Find the Event notifications section and click Create event notification.

    
13. On the Create event notification page, configure the notification with the following settings:
    1. For Event name, enter a name for the event notification. We suggest guardduty-new-finding
    2. For Event types, under Object creation, select All object create events.
14. For Destination, select the SNS topic and add the SNS topic that was created.
    
15. Review and save the settings you've chosen.
16. Still on GuardDuty settings, go to the Delegated Administrator section, fill your current account ID and click Delegate.
    
    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.
17. On the left side menu, click Accounts. You should see a list of all the available accounts in your organization.
18. 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.

19. Update the page and select all the previously selected accounts again. On the Edit Protection Plans Drop-down menu, for each option (Except Automate agent configuration), click Enable for N selected Accounts.

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.

 

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.

Create and configure an IAM Role (Main account)

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: 

   {
       "Version": "2012-10-17",
       "Statement": [
       {
           "Sid": "AllowListAndGetAllLogFiles",
           "Effect": "Allow",
           "Action": [
               "s3:Get*",
               "s3:List*"
           ],
           "Resource": [
               "arn:aws:s3:::*",
               "arn:aws:s3:::*/*"
           ]
       },
       {
           "Sid": "AllowManagingSNSTopicSubscriptions",
           "Effect": "Allow",
           "Action": [
               "sns:Subscribe",
               "sns:Unsubscribe",
               "sns:ConfirmSubscription"
           ],
           "Resource": [
               "arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME_CLOUD_TRAIL}",
               "arn:aws:sns:${REGION}:${AWS_ACCOUNT_ID}:${SNS_NAME_GUARD_DUTY}"
           ]
       },
       {
           "Sid": "EnableCrossAccountLogDecryption",
           "Effect": "Allow",
           "Action": [
               "kms:Decrypt"
           ],
           "Resource": [
               "arn:aws:kms:${REGION}:${AWS_ACCOUNT_ID}:key/${KMS_KEY_CLOUD_TRAIL}",
               "arn:aws:kms:${REGION}:${AWS_ACCOUNT_ID}:key/${KMS_KEY_GUARD_DUTY}"
           ]
       },
       {
           "Sid": "AllowAssumeARoleInAnotherOrganizationAccount",
           "Effect": "Allow",
           "Action": [
               "sts:AssumeRole"
           ],
           "Resource": [
               "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${ROLES_NAME}",
               ...,
               ...
           ]
       },
     {
               "Sid": "Statement5",
               "Effect": "Allow",
               "Action": [
                   "organizations:ListPolicies",
                   "organizations:DescribePolicy",
                   "organizations:ListPoliciesForTarget",
                   "organizations:DescribeResourcePolicy",
                   "organizations:DescribeOrganization"
               ],
               "Resource": [
                   "*"
               ]
           }
       ]
   }

   • Replace all the variables with the ARN values that you copied and saved throughout the onboarding.
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:
   1. For Trusted entity type, select Custom trust policy to allow Radiant Security to use this role to access the account.
      

   2. 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.

   

Permissions

 

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 guide to help you test GuardDuty integration.

We value your opinion. Did you find this article helpful? Share your thoughts by clicking here or reach to our Product and Customer Success teams at support@radiantsecurity.ai 

 

Last updated: 2025-02-04