At Threat Stack, we process tens of billions of events for customers each day. Insight into that amount of data gives us a unique perspective to identify meaningful trends in AWS service usage. Two such trends we’ve recently observed have been increased usage of Amazon Elastic Container Registry (ECR) and AWS Systems Manager. To ensure that our customers use these services securely, we have added default alerting rules for ECR and Systems Manager to Threat Stack. Let’s look at some of the new rules and their filters.
You all know what a container registry is, but what’s great about Amazon ECR is how integrated it is with Amazon Elastic Container Service (ECS). Of course Threat Stack already instruments ECS environments with granular detail from Amazon Linux 2 and Docker at runtime. Now, we can deliver more security observability into how static Docker images are sourced within ECR.
Here’s what Threat Stack’s new CloudTrail ECR rules include out of the box:
In particular, let’s look at the rule CloudTrail: ECR Image Scan Findings – Severity HIGH.
Figure 1: Screenshot of Threat Stack Rules UI for CloudTrail: ECR
The filter syntax here is the most interesting bit, so here’s a closer look:
event_type = "cloudtrail" and eventSource = "ecr.amazonaws.com" and eventName = "DescribeImageScanFindings" and responseElements.imageScanFindings.findingSeverityCounts.HIGH > 0
Since the CloudTrail event JSON for the ECR image scan findings can potentially contain a long list of CVEs, we use the aggregated
findingSeverityCounts object to take a quick look. From there, follow the AWS documentation to access the full findings from your scan, either through the Amazon ECR console or via the AWS CLI.
Threat Stack’s goal is to alert you as quickly as possible. But feel free to modify the severity settings, and to customize the rule filter. (For more on the Threat Stack query language used above, see our docs.)
AWS Systems Manager is a powerful automation tool with a wide range of features. Two of those features — AWS Systems Manager Session Manager and AWS Systems Manager Run Command — are particularly interesting for auditing purposes.
Figure 2: Screenshot of Threat Stack Rules UI for CloudTrail: SSM
Here’s what Threat Stack’s new CloudTrail Systems Manager rules include out of the box:
With Sev 3 defaults across the board, we anticipate that these alerts will be used mostly for auditing purposes — but they can always be tuned to best suit your needs. Let’s look at the filter syntax for CloudTrail: SSM Information Discovery:
event_type = "cloudtrail" and eventSource = "ssm.amazonaws.com" and (eventName starts_with "Describe" or eventName starts_with "List")
While it’s relatively straightforward, it’s a nice example of the
starts_with operator that’s supported in Threat Stack’s query language.
Custom CloudTrail alerting is but one dimension of the rules you can create in Threat Stack. And once these rules fire, you’ll probably want to dig into the underlying events if you need to conduct an investigation. Check out this investigation of Docker cryptojacking, where we go step-by-step through an alert and its associated events. And look for more investigations as conducted by Threat Stack Cloud SecOps Program℠ analysts coming to this space soon!