GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to discover and prioritize potential risks.
Let’s see it in action. Imagine you’ve enabled GuardDuty and it just flagged a suspicious S3 bucket access.
{
"eventSource": "s3.amazonaws.com",
"eventTime": "2023-10-27T10:30:00Z",
"eventDetails": {
"bucketName": "my-sensitive-data-bucket-12345",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"sourceIpAddress": "192.0.2.10",
"requestParameters": {
"operation": "GetObject",
"key": "financial-reports/2023-Q3.pdf"
},
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAJ4577C262P3X",
"arn": "arn:aws:iam::111122223333:user/malicious-user",
"userName": "malicious-user"
}
},
"findingType": "UnauthorizedAccess:S3/BucketPublicRead",
"severity": 7.0,
"title": "S3 bucket is publically accessible or has been accessed by an unauthorized source."
}
This finding tells us malicious-user (an IAM user) accessed my-sensitive-data-bucket-12345 from 192.0.2.10, attempting to download financial-reports/2023-Q3.pdf. The findingType UnauthorizedAccess:S3/BucketPublicRead is the critical piece here. GuardDuty detected that this bucket, or at least this object, is accessible to the public or has been accessed in a way that suggests it should not be.
GuardDuty works by analyzing multiple data sources:
- VPC Flow Logs: Monitors network traffic within your Virtual Private Cloud (VPC) for unusual patterns, like connections to known malicious IP addresses or unusual port usage.
- CloudTrail Logs: Tracks API calls made in your AWS account. GuardDuty looks for suspicious API activity, such as unusual resource provisioning, IAM policy changes, or attempts to disable security services.
- DNS Logs: Analyzes Domain Name System (DNS) queries to identify requests to malicious domains or suspicious DNS activity.
- S3 Data Events: While not enabled by default for all buckets, if enabled, GuardDuty can analyze S3 access logs for unusual access patterns, like public access to sensitive buckets.
- Kubernetes Audit Logs: If you’re running Amazon EKS, GuardDuty can ingest and analyze Kubernetes audit logs for suspicious pod activity or API calls.
- RDS Login Activity: Detects brute-force login attempts and other suspicious database activity.
- EBS Volume Attachment: Identifies when EBS volumes are attached to an EC2 instance that is not authorized to access them.
The core problem GuardDuty solves is the sheer volume and complexity of security data generated by AWS services. Manually sifting through VPC flow logs, CloudTrail, and other logs to find a needle in a haystack is practically impossible and incredibly time-consuming. GuardDuty automates this detection and analysis, providing actionable findings with a severity score.
To get started, you simply enable GuardDuty in your AWS account. It automatically starts collecting and analyzing data from the sources mentioned above. You can configure it to monitor multiple AWS accounts within your organization using AWS Organizations.
The primary levers you control are:
- Data Source Enablement: You decide which data sources GuardDuty should ingest. For example, you might choose to enable S3 data event logging for specific, high-risk buckets.
- Findings Filtering and Suppression: You can create filters to automatically suppress findings that are known to be benign in your environment (e.g., a specific IP address that is part of your authorized testing framework).
- Integration with Other Services: GuardDuty findings can trigger automated responses. For instance, a finding might send a notification to an SNS topic, which in turn invokes a Lambda function to isolate a compromised EC2 instance or revoke credentials.
- Severity Level Configuration: While GuardDuty assigns severity, you can also set up EventBridge rules based on severity levels to prioritize your response.
When GuardDuty flags a finding, the resource field in the JSON output is often overlooked but is crucial for understanding the scope. It provides AWS resource identifiers like ARN, account ID, and region, allowing you to quickly locate the affected resource in the AWS console and take immediate action.
The next step after triaging these initial alerts is often setting up automated remediation workflows using Lambda and EventBridge.