CloudTrail Integration Troubleshooting

The CloudTrail integration involves several critical components, including SNS topics, Event Notifications (related to S3), KMS permissions (if using an encrypted bucket), and S3 Bucket Policies. Below are the steps to effectively diagnose and resolve common problems. Follow these guidelines to ensure your integration runs smoothly and securely.

Is the ARN correct for the SNS Topic and does it match what is in the integration configuration?

Navigate to AWS and then search for Simple Notification Service.
Click Simple Notification Service.
From the SNS dashboard, click Menu.
From the sidebar menu, click Topics.
Locate the specific topic created for this integration.
Click on the topic name to view its details.
Review the ARN (Amazon Resource Name) displayed on the topic detail page.
Confirm that the ARN matches the one provided in the Integration article.

Replace <INSERT BUCKET ARN> and <INSERT SNS TOPIC ARN HERE> with the relevant information.

{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "RCPartnerAccessControl",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::823104324086:root"
      },
      "Action": "SNS:Subscribe",
      "Resource": "<INSERT SNS TOPIC ARN HERE>"
    },
    {
      "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": "<INSERT SNS TOPIC ARN HERE>",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "<INSERT BUCKET ARN>"
        }
      }
    }
  ]
}

Is the Bucket Policy and configuration correct?

AWS S3 Bucket Policy and Control Tower Configuration

Identify and select the bucket you need to configure.
From the Permissions tab, click Bucket Policy.
Check that the following JSON policy item is appended in the Bucket Policy:

{
    "Sid": "AllowAdditionalReadAccess",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::823104324086:role/rc-partner-access-control"
    },
    "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:GetObjectAttributes"
    "Resource": [
        "<CUSTOMER S3 ARN HERE>",
        "<CUSTOMER S3 ARN HERE>/*"
    ]
},

Note: This code needs to be appended to the existing Bucket Policy. The code above is not a working policy. Instead the code is a single item that should be appended to the JSON array that makes up the Policy Definition.

Replace <CUSTOMER S3 ARN HERE> with your S3 bucket ARN.
Ensure there are no deny statements that could prevent access.

Review the AWS Control Tower Settings

To review existing policies, access the Control Tower from the AWS Management Console.
If you use an AWS Control Tower, check your GuardRails settings for any explicit denies affecting the S3 bucket, including CloudTrail use.

Configure S3 Bucket Access Settings

From the Permissions tab, ensure that ACLs are disabled and that Bucket owner enforced is enabled.
From the Permissions tab, ensure that all settings to block public access are enabled.

Set Up S3 Bucket Event Notifications

Select an existing S3 bucket.
Click the Properties tab.
Scroll down to Event Notifications to see if any are active. If not, proceed to create one.

Create an Event Notification

Click Create event notification.
Enter a name for the event notification.
From the Event types section, select All object create events.
From the Destination section, select SNS topic.
From the Specify SNS topic section, select Choose from your SNS topics.
From the SNS topic dropdown, select the relevant SNS topic.
Click Save Changes.

Am I currently using KMS? If I am, did I grant Red Canary access to the KMS Key used on the S3 bucket?

Navigate to the S3 service in the AWS Management Console.
Select the bucket you want to review.
Click the Properties tab.
From the Default encryption section, review the encryption settings to determine if a KMS Key is active.

Grant Red Canary Access to the KMS Key used on the S3 bucket

Review both the AWS managed key and customer managed key settings.
Verify that the Red Canary account (arn:aws:iam::823104324086:role/rc-partner-access-control) has the necessary permissions to access the KMS Key.
From the Key policy section, click Edit, and then review the Key policy.
If permissions adjustments are needed, append the following policy item to the KMS Key policy for the key used to encrypt the S3 bucket:
```
{
  "Sid": "RCPartnerAccessControl",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::823104324086:role/rc-partner-access-control"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
},
```
Note: The code needs to be appended to the existing KMS Policy. It is not a working policy, it is a single item that should be appended to the JSON array that makes up the Policy Definition.
Click Save.

GuardDuty Integration Troubleshooting

Is GuardDuty currently active, and is the Security Token Service (STS) enabled?

Checking GuardDuty Activation

Note: Before enabling GuardDuty, it’s essential to understand that GuardDuty 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. Review the pricing details on the GuardDuty page to understand the cost implications and budget accordingly before activation.

Navigate to AWS and then search for Simple Notification Service.
Click GuardDuty.
If GuardDuty is not enabled in the region you are reviewing, you will see a screen prompting you to enable it.

Checking STS Activation Across Regions

Navigate to AWS and then search for IAM.
Click IAM.
Click Account Settings.
From the Endpoints section, review the STS status and ensure that it is active for each region.

Why enable STS in all regions?

Operational Efficiency and Security: Enabling AWS Security Token Service (STS) in all regions is a crucial best practice for security and operational efficiency. By default, STS requests are routed to a single endpoint (sts.amazonaws.com), which can cause latency if requests originate from regions geographically distant from this endpoint.

Local Request Handling: Enabling STS regionally ensures that requests are handled locally, reducing latency and enhancing response times.

Security Operations: For a security-focused company like Red Canary, having STS enabled in each region is beneficial. It enables us to quickly and effectively authenticate and authorize actions without delays, ensuring efficient resource management and monitoring.

Avoiding Failed Status Checks: If STS is not enabled in every region, it can lead to benign but failed status checks when attempting to verify resources. These are not critical but can impede our ability to detect and respond to potential security issues promptly.

Best Practices and Security Protocols: Therefore, enabling STS across all regions not only aligns with AWS best practices but also supports our security protocols by facilitating faster and more reliable access to regional resources.

Did I deploy the Stack, StackSet, or Terraform Template?

Navigate to AWS and then search for IAM.
Click IAM.
Click Roles. You should see the role listed.

Note: The Role tab will list all the roles associated with your AWS account, including the one created by your Stack, StackSet, or Terraform Template.

Ensure that the role appears precisely as specified in your deployment instructions. If the role is present and correctly configured, this confirms that your deployment has successfully created the required resources.

AWS Troubleshooting