AWS CloudTrail Threat Detection with Sigma Rules
Why Sigma for Cloud Detection?
AWS CloudTrail provides comprehensive audit logging, but raw CloudTrail events are not detections. Translating audit events into meaningful threat detections requires query logic that is often vendor-specific. Sigma rules solve this by providing a vendor-agnostic detection format.
With Sigma, you write a detection rule once and can convert it to queries for Splunk, Elastic, Microsoft Sentinel, or any other SIEM. For cloud security, this portability is invaluable — especially in multi-cloud environments.
CloudTrail Schema Understanding
Effective CloudTrail detection starts with understanding the event structure. Key fields include:
- eventSource — The AWS service (e.g.,
ec2.amazonaws.com). - eventName — The API call made (e.g.,
RunInstances). - userIdentity — Who performed the action.
- sourceIPAddress — Where the call originated.
- requestParameters — What was requested.
Example: Detecting Unauthorized API Calls
A simple but effective detection: identify API calls from IP addresses outside the organization's known ranges. In Sigma format, this translates to a rule that can be deployed across any SIEM.
Multi-Cloud Considerations
The real power of Sigma for cloud detection emerges when you need to cover multiple clouds. A rule detecting suspicious API calls can be written once and adapted for CloudTrail, Azure Activity Logs, and GCP Audit Logs.
"Cloud detection should be portable. Your detection logic should not be held hostage by any single SIEM vendor."
顺势而为,趋吉避凶