How to Feed AWS CloudTrail Logs into ThreatHawk SIEM

Understanding AWS CloudTrail and Its Role in SIEM

AWS CloudTrail is a governance, compliance, and operational auditing service that logs every API call made within your AWS environment. This includes actions taken through the AWS Management Console, AWS SDKs, command line tools, and higher-level AWS services. Each CloudTrail event record contains detailed information such as the identity of the caller, the time of the request, the source IP address, the request parameters, and the response elements returned by the service.

CloudTrail logs are essential for SIEM platforms because they provide the raw material for detecting unauthorized access attempts, privilege escalation, misconfigured resources, and other security-relevant activities. When integrated properly, a SIEM can transform these flat log files into actionable security intelligence by applying correlation rules, user and entity behavior analytics (UEBA), and threat intelligence feeds.

Prerequisites for Integrating CloudTrail with ThreatHawk

Before starting the integration, ensure you have the following in place across your AWS environment and CyberSilo tenant:

• An active AWS account with CloudTrail enabled for all regions (organization trail recommended for multi-account setups).
• An S3 bucket designated for CloudTrail log delivery. This bucket must have logging enabled and appropriate lifecycle policies to manage storage costs.
• An IAM role that ThreatHawk will assume to read logs from the S3 bucket. This role must have a trust policy allowing the ThreatHawk AWS account ID to assume it, and an inline policy granting s3:GetObject and s3:ListBucket permissions on the specific bucket and its prefix path.
• ThreatHawk SIEM access with administrative privileges to configure data sources. If you are evaluating the platform, you can contact our security team to set up a sandbox environment.
• Basic familiarity with AWS IAM for creating roles and policies, or coordination with your AWS administrator.

Step-by-Step Integration Guide

The integration between AWS CloudTrail and ThreatHawk SIEM follows a secure, infrastructure-as-code-friendly pattern. Below is the complete workflow for SOC teams and security architects.

Mapping CloudTrail Events to ThreatHawk Correlation Rules

Ingestion is only half the battle. To derive value from your CloudTrail logs, you need correlation rules that fire alerts on suspicious patterns. ThreatHawk includes a library of pre-built correlation rules for AWS-specific threats, but you can also create custom rules tailored to your environment.

ThreatHawk's correlation engine runs these rules against the normalized CloudTrail events in real time. When a match occurs, the platform generates an alert with full context — the raw CloudTrail event, the user identity, the source IP, and any related events within the same time window. This eliminates the need for analysts to manually cross-reference multiple log sources.

Common Challenges and Troubleshooting

Even with a well-architected integration, enterprise environments can introduce complexity. Below are the most common challenges teams encounter when feeding CloudTrail logs into a SIEM, and how ThreatHawk addresses each one.

IAM Permission Issues

The most frequent failure point is an incorrect IAM role trust policy. The IAM role's trust relationship must explicitly allow the ThreatHawk AWS account ID to assume the role. Additionally, if you are using a bucket policy instead of an IAM role, the bucket policy must grant the ThreatHawk account access. ThreatHawk's validation step provides a detailed error message when permissions are insufficient, but the root cause often stems from a missing sts:AssumeRole condition key or a mismatch in the account ID. Double-check the role ARN you entered in ThreatHawk matches exactly what is in AWS, including the trailing path if one exists.

Encryption and Key Management

If your CloudTrail S3 bucket uses SSE-KMS, ThreatHawk cannot read the log objects unless the IAM role has explicit kms:Decrypt permissions on the KMS key. This is a common oversight when teams reuse existing IAM roles. The KMS key policy must also grant kms:Decrypt to the IAM role principal. If you are using a multi-region KMS key, ensure the key region matches the S3 bucket region — ThreatHawk reads logs from the bucket's regional endpoint.

Log Format and Parsing Edge Cases

CloudTrail logs are delivered in gzipped JSON format, but some SIEM platforms struggle with nested JSON structures or large log files (CloudTrail files can exceed 50 MB). ThreatHawk's ingestion engine is purpose-built for these formats, handling deeply nested requestParameters and responseElements without loss of fidelity. However, if you have customized CloudTrail log delivery (e.g., using a third-party lambda to transform logs before S3 delivery), ThreatHawk may not parse the modified format correctly. Always deliver raw, unmodified CloudTrail logs to the S3 bucket for ingestion.

Multi-Account and Organization Troubleshooting

For AWS Organizations, CloudTrail supports organization trails that aggregate logs from all member accounts into a single S3 bucket. ThreatHawk handles this out of the box — use the AWSLogs/ prefix and ThreatHawk will recursively discover logs from all accounts within the organization trail. Ensure the IAM role used by ThreatHawk has s3:ListBucket permission on the entire bucket and s3:GetObject on the full prefix path. If some member accounts do not appear in ThreatHawk, verify that CloudTrail is enabled for those accounts and that they are part of the organization trail.

Comparison: ThreatHawk vs. Other Approaches for CloudTrail Ingestion

Many teams evaluate whether to build a custom ingestion pipeline, use a generic log shipper, or adopt a purpose-built SIEM integration. The following comparison outlines the practical differences for SOC operations.

For enterprise SOCs managing multiple AWS accounts and high event volumes, ThreatHawk's native integration offers the best balance of reliability, security, and operational efficiency. The platform's next-generation SIEM architecture automatically handles log deduplication, schema normalization, and enrichment with built-in threat intelligence — capabilities that are extremely time-consuming to build and maintain in custom pipelines.

Securing the Integration Pipeline

Security teams must ensure that the integration itself does not introduce new attack surface. Below are the key security controls to implement when connecting CloudTrail to ThreatHawk.

• Least-privilege IAM: The ThreatHawk IAM role should only have s3:GetObject and s3:ListBucket on the specific CloudTrail bucket and prefix. Never attach a broader S3 read policy that grants access to other buckets in the account.
• Bucket policy enforcement: Add a bucket policy condition that requires aws:SourceArn to match the ThreatHawk role ARN, preventing confused deputy attacks if your bucket is accessed by other services.
• Encryption in transit and at rest: Use S3 bucket policies that enforce aws:SecureTransport for all API requests, and encrypt log files with SSE-S3 or SSE-KMS. ThreatHawk supports all S3 encryption methods, including SSE-KMS with customer-managed keys.
• Log integrity validation: Enable CloudTrail log file validation, which adds a SHA-256 hash to each log file. ThreatHawk can optionally validate these hashes on ingestion to guarantee log file integrity — particularly important for compliance evidence chains.
• Network segmentation: If your SOC operates in a VPC with egress restrictions, ensure the ThreatHawk integration endpoints (S3 API and SQS API) are reachable. For highly sensitive environments, use an S3 VPC endpoint and a VPC interface endpoint for SQS to avoid traversing the public internet.

Advanced ThreatHawk Capabilities for CloudTrail Data

Once CloudTrail logs are flowing into ThreatHawk, you can unlock several advanced capabilities that go beyond basic SIEM correlation.

User and Entity Behavior Analytics (UEBA)

ThreatHawk's UEBA engine builds baselines of normal user behavior across your AWS environment using CloudTrail identity data. When a user who typically performs read-only S3 operations suddenly executes iam:CreateUser or ec2:RunInstances with unusual instance types, the UEBA engine flags this as an anomalous behavior and escalates the alert. This catches insider threats and compromised credentials that might not match any known signature-based rule.

Threat Intelligence Enrichment

ThreatHawk correlates the sourceIPAddress field from every CloudTrail event against its embedded threat intelligence feeds — including known C2 infrastructure, anonymous VPN exit nodes, and recent malware C2 domains. If an administrative API call originates from an IP address that is flagged as malicious in any integrated feed, ThreatHawk automatically adds threat intelligence tags to the alert and surfaces it in the SOC triage queue with elevated priority. For organizations with ThreatSearch TIP, the enrichment includes both open-source and commercial threat intelligence feeds.

Automated Response with ThreatHawk SOAR

CloudTrail alerts can trigger automated response playbooks within the ThreatHawk SIEM + SOAR platform. For example, a critical alert on a root user login can automatically trigger a CloudWatch Events rule that rotates the root access keys and sends a notification to the CISO. A compromised IAM credential pattern can trigger a playbook that deactivates the user keys, isolates the EC2 instance, and creates a Jira ticket for post-incident review — all without manual intervention.

Retention and Cost Optimization

CloudTrail logs can generate massive volumes of data — a busy enterprise account might generate 10–50 GB of CloudTrail logs per day. ThreatHawk's tiered storage architecture helps manage the associated SIEM licensing and storage costs.

• Hot storage (30–90 days): CloudTrail logs remain in high-performance indexed storage for rapid search and alert correlation. Data retention policies can be set per data source, meaning you might keep CloudTrail logs in hot storage for 90 days while keeping other data sources for only 30 days.
• Warm storage (6–12 months): After the hot period, data moves to lower-cost warm storage. ThreatHawk can still search this data, but query speed is slightly reduced — acceptable for compliance audits and historical investigation.
• Cold archive (1–7 years): For regulatory compliance (PCI DSS requires 12 months of log availability with 7 years of retention), ThreatHawk supports cold archive storage at a fraction of the cost, with the ability to request data restoration for active investigation.

You can further reduce costs by filtering which CloudTrail events enter the SIEM. For example, you may choose to exclude health checks from Route53 or read-only S3 GetObject requests that generate thousands of events per minute with low security value. ThreatHawk allows pre-ingestion filtering at the data source level, so only security-relevant events consume your active storage tier.