With the majority of our applications now being cloud-native and containerized, ensuring security has become paramount. While static security measures, such as image scanning with Amazon Inspector, play a crucial role, monitoring container security during runtime is equally important. This is where ECS Runtime Monitoring with Amazon GuardDuty comes into play. GuardDuty Runtime Monitoring, now over a year in general availability, has proven its effectiveness in detecting runtime security threats across EC2 instances, ECS Clusters, and EKS Clusters. In this blog, we'll walk through enabling runtime monitoring for your ECS Cluster, generating GuardDuty findings, and setting up alerts for both runtime monitoring health and GuardDuty Findings to enhance your security posture.
Amazon GuardDuty: Advanced Threat Detection for AWS Security
Amazon GuardDuty is a fully managed threat detection service that continuously monitors your AWS environment for suspicious activity. By analyzing vast amounts of data from sources like AWS Cloudtrail, VPC Flow Logs, and DNS logs, GuardDuty detects threats such as unauthorized access, data exfiltration, or compromised instances engaging in malicious activity.
Leveraging AI, machine learning, and threat intelligence , GuardDuty identifies anomalies such as unusual login attempts, unexpected changes to resources, or attempts to disable security controls helping you respond before threats escalate. It provides automated analysis and actionable insights without the need for complex security infrastructure, making it an efficient and scalable solution for cloud security.
GuardDuty offers specialized protection across AWS Services including:
- S3 Protection - Detects unauthorized access and data theft from S3 Buckets.
- EKS Protection - Monitor Kubernetes workloads for suspicious activity.
- Runtime Monitoring - Identifies real time threats in compute environments.
- Malware Protection - Scans Amazon EC2 and S3 for malware threats.
- RDS Protection - Guards against database related security risks.
- Lambda Protection - Monitors serverless workloads for anomalies.
By automating threat detection and reducing manual security efforts, GuardDuty helps businesses safeguard their AWS infrastructure with minimal operational overhead.
Enabling the fully managed GuardDuty Agent
When we deploy the GuardDuty security agent, GuardDuty will create a VPC Endpoint for the security agent to deliver runtime security events to GuardDuty. Alongside it will also create a new security group that will control the traffic that's allowed to reach the resources using inbound rules of the security group and will adapt to vpc cidr range changes.
ECS Cluster
I started with an existing ECS Cluster with a single task running on AWS Fargate.
Within the task configuration, you'll notice two containers running:
- Main Application Container
- Sidecar Container launched by AWS to run the Amazon GuardDuty agent
GuardDuty actively monitoring the ECS Cluster
GuardDuty Runtime Monitoring Alerts
It is essential to configure alerts for when GuardDuty Runtime Monitoring enters an unhealthy state or when a Runtime Monitoring Finding is detected.
To achieve this, I have configured EventBridge rules with Amazon SNS as the target to trigger email notifications for both.
GuardDuty Runtime Monitoring Unhealthy State Alert
I manually scaled down the ECS service from 1 to 0, so that the GuardDuty agent is no longer able to communicate with Amazon GuardDuty and the Runtime Monitoring status is pushed to an unhealthy state, upon which the Eventbridge Rule is triggered and a SNS notification is generated.
Event Pattern for Eventbridge Rule:
{
"source": ["aws.guardduty"],
"detail-type": ["GuardDuty Runtime Protection Unhealthy"]
}
GuardDuty Runtime Monitoring Findings Alert
I generated sample findings in GuardDuty to test and validate the alerting mechanism.
Event Pattern for Eventbridge Rule:
{
"source": ["aws.guardduty"],
"detail": {
"type": ["Backdoor:Runtime/C&CActivity.B", "PrivilegeEscalation:Runtime/DockerSocketAccessed"]
}
}
You can find the full list of GuardDuty Runtime Monitoring Finding Types here.
Sample Findings Generated
Using an Encrypted SNS Topic
If you would like to encrypt your SNS Messages before saving them in it's data centers in order to comply with a certain compliance, there are a few things you need to ensure so that your GuardDuty alerts don't fail to deliver.
Firstly, you need to use a CMK(Customer Managed Key) instead of a default SNS Encryption key to encrypt your SNS Topic.
Secondly the Eventbridge rule should have the necessary permission to invoke your KMS key to decrypt the data.
While you are creating the Eventbridge rule note down the IAM role that is being created by default and you can later add the necessary permissions to it.
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": [
"arn:aws:kms:ap-south-1:123456734:key/53c1b423-3a5e-1234-1111-eda13df344de" ]
}
Replace your kms key arn!
- Third, you need to add the necessary permission in your KMS policy to authorize Eventbridge.
If you see the messages not getting delivered, it means you failed to satisfy any of the above three pointers and for further troubleshooting you can also refer [this].(https://repost.aws/knowledge-center/sns-not-getting-eventbridge-notification).
Conclusion
I hope this blog serves as a great starting point for exploring this exciting feature. Below, I've compiled a few additional resources that will help you dive deeper and make the most of it.
Top comments (0)