The SOC wants AWS CloudTrail events from several accounts searchable in Splunk beside its other security data, using a supported Splunk-built integration rather than custom code. What is the appropriate approach?
Select an answer to reveal the explanation.
Short Explanation
Use the adapter made for the plug. The Splunk Add-on for AWS knows how to pull CloudTrail logs, typically from the S3 bucket where they land, with SQS telling it what's new. Don't fall for HEC here — CloudTrail doesn't push to Splunk on its own just because you made a token.
Full Explanation
CloudTrail records API activity in an AWS account and delivers log files to an S3 bucket, optionally with notifications through SNS and SQS. The Splunk Add-on for AWS, built and supported by Splunk, provides inputs that collect this data, including an SQS-based S3 input that reads notifications to find new CloudTrail objects and ingests them with the correct sourcetype and field extractions. Configuring the add-on with appropriate IAM permissions for each account brings CloudTrail into Splunk without custom code, and the add-on also maps the data for use in security searches and the Common Information Model. A universal forwarder on one EC2 instance sees only that instance's local logs; CloudTrail API records are not written to an instance's syslog, and one instance cannot represent several accounts. Creating an HEC token does not make CloudTrail send anything; AWS would need an intermediary such as a delivery stream or function configured to push events, which is not what the stem asks for. A lookup table only enriches data that is already indexed; it does not ingest any events. Exam caveat: the blueprint frames this as configuring Splunk to ingest cloud logging, so expect the add-on and input concepts rather than detailed IAM policy syntax. Operational check: confirm the input shows healthy collection and that CloudTrail events from each account appear with the expected sourcetype.