Warden Threat Detection ingests cloud events and generates alerts in response to real time events.
Currently, Warden Threat Detection only supports AWS.
The alerts generated from CloudTrail can trigger Warden scans dynamically based on specific event types. This is how it works:
For each event generated from your CloudTrail Trail, it is delivered to the S3 Logs Bucket. A notification for new log files is sent to the SNS Topic, which forwards it to the Horangi SQS Queue who in turn invokes a LogProcessor Lambda. The LogProcessor Lambda fetches the log file from the S3 Logs Bucket and forwards specific events in the file to a downstream ChangeAlertHandler Lambda. The ChangeAlertHandler Lambda will then either:
- trigger a Warden scan if the rate limit for scans is not reached.
- schedules a Warden scan in the immediate future if the rate limit for scans has been exceeded.
Warden limits the rate at which scans are run for each AWS Account. This is to keep the number of API calls to your cloud environment to a reasonable limit. Because of this throttling, scans may not run immediately after an event has occured in your Cloud environment.
Here is an example of how throttling works if the limit for scans is once per AWS Account per hour:
- 13:00 UTC: Warden scan for AWS Account 123456789012 started.
- 13:10 UTC: Warden scan for AWS Account 123456789012 completed.
- 13:30 UTC: Received an event from CloudTrail for the AWS Account 123456789012. Warden scan is throttled due to the timing of the previous scan and scheduled to 14:10 (last scan completed time + 1 hr).
- 14:10 UTC: Warden scan for AWS Account 123456789012 started.
- 14:20 UTC: Warden scan for AWS Account 123456789012 completed.
- 16:00 UTC: Received an event from CloudTrail for the AWS Account 123456789012. Warden scan is not throttled and starts almost immediately.
- 16:10 UTC: Warden scan for AWS Account 123456789012 completed.