Overview

I've been writing an AWS Security Overview blog series over the past few weeks, and while writing my next post I happened to see a tweet by @jeffbarr mentioning that AWS released GuardDuty yesterday.

I went ahead and read the documentation so you don't have to and here is a one/two pager on the product, along with some screen shots on how to get it setup.

Amazon GuardDuty

According to Amazon, "GuardDuty is a continuous security monitoring service that analyzes and processes VPC Flow Logs, AWS CloudTrail event logs, and DNS logs. It uses threat intelligence feeds, such as lists of malicious IPs and domains, and machine learning to identify unexpected and potentially unauthorized and malicious activity within your AWS environment. This can include issues like escalations of privileges, uses of exposed credentials, or communication with malicious IPs, URLs, or domains. For example, GuardDuty can detect compromised EC2 instances serving malware or mining bitcoin. It also monitors AWS account access behavior for signs of compromise, such as unauthorized infrastructure deployments, like instances deployed in a region that has never been used, or unusual API calls, like a password policy change to reduce password strength."

GuardDuty partners (at the time of this writing) include: Accenture, Alert Logic, Crowdstrike, Deloitte, evident.io, IBM, logicworks, Palo Alto, Proofpoint, Rapid 7, RedLock, Splunk, Sumologic, Trend Microm, and Trustwave.

There is a cost associated with this product. More details on pricing can be found here.

You can have a max number of GuardDuty member accounts of 100, GuardDuty generated findings have a retention period of 90 days. You also have a limit of, 1 detector.

I couldn't find the exact definition of a detector in the documentation, but from looking around it appears to be a unique identifier that's used (for example) in your resource ARN. It's also passed in various API calls as a unique identifier.

"Resource": "arn:aws:guardduty:us-east-1:012345678910:detector/1234567"

Supported Regions

It's supported in:

• Asia Pacific: Mumbai, Seoul, Singapore, Sydney and Tokyo
• Canada: Central
• EU: Frankfurt, Ireland, and London
• US East: N. Virginia and Ohio
• US West: Oregon and N. California
• South America: Sao Paulo

Enabling GuardDuty

First you can navigate to the GuardDuty service within your AWS Console. Once there, you will need to select, "Get Started".

You will then be prompted with a, Welcome to GuardDuty page. You can view the service role permissions you're allowing this service to have, which is depicted here in the below image.

Next you will simply need to select, Enable GuardDuty.

Once enabled, you're presented with the GuardDuty dashboard.

You can invite other AWS accounts to enable GuardDuty and become associated with your AWS account in GuardDuty. This would effectively create a, master GuardDuty account, which you could then view and manage findings on their behalf.

Managing Lists

You can also configure a list of white listed IP addresses as well as the option to create a, Threat list. This can be accomplished by going to the left hand side and selecting, Lists.

Both sets of lists can be pulled in from S3 and be formatted in the following formats:

• Plain text
• Structured Threat Information eXpression (STIX)
• Open Threat Exchange (OTE) CSV
• FireEye iSIGHT Threat Intelligence CSV
• ProofPoint ET CSV
• AlienVault Reputation Feed format

You have a hard limit of 1, for Trusted IP sets, and 6 for Threat Intel sets per AWS account. You can have single IPs or CIDR ranges.

GuardDuty doesn't generate findings for any non-routeable or internal IP addresses in your threat lists. It also doesn't generate findings based on activity that involves domain names that are included in your threat lists.

According to the latest documentation, it ONLY generates findings based on activity that involves IP addresses and CIDR ranges in your threat lists. IMHO, this limits its usefulness, given the shelf life of IPs used by attackers.

Findings

Generated Findings

My environment is quite small, so I generated some sample findings so you could see what the dashboard looks like. It appears I have one alert that's not a sample.

Severity Levels

The severity levels are broken out into; High Medium and Low. It uses a number system to grade the finding

• High finding: Falls within a 7.0 - 8.9
• Medium finding: Falls within a 4.0 - 6.9
• Low finding: Falls within 0.1 - 3.9

The documentation says, if it's a high findings it, "indicates that the resource in question (an EC2 instance or a set of IAM user credentials) is compromised and is actively being used for unauthorized purposes."

A medium finding, "indicates suspicious activity, for example, a large amount of traffic being returned to a
remote host that is hiding behind the Tor network, or activity that deviates from normally observed behavior"

A Low finding, "indicates suspicious or malicious activity that was blocked before it compromised your resource."

Finding Example - Unprotected Port on EC2

GuardDuty uses the following format for the finding types it generates.

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.ThreatFamilyVariant!Artifact

In the finding below, the finding type is Recon:EC2/PortProbeUnprotectedPort. All the different types can be found in the documentation under, "Complete List of GuardDuty Finding Types".

In this alert it's letting me know that it's a Low severity and that someone ( 121.18.238.119) was conducting a port probe against my. The IP originates in Hebei, China, and the Threat list used to detect this alert appears to have come from, ProofPoint (maybe this is how they leverage the partnerships as indicated above).

The other sample alerts contain similar information. You can get a full list of the alert schema in the GuardDuty documentation.

CloudWatch

At the time of this writing, there is now UI support for CloudWatch. I'm sure it's only a matter of time before the team builds this functionality, but figured I would mention it here.

You can create rules and targets via the aws cli. There are some samples in the documentation if you care to look.

Access

AWS has gone ahead and created a couple IAM policies that you can attach to a user, group or role.

• AmazonGuardDutyFullAccess
• AmazonGuardDutyReadOnlyAccess

You could also deny access to GuardDuty findings, and limit access to GuardDuty resources. I suggest taking a look at the GuardDuty API Documentation so you can get a complete list and build your policies as you see fit.

Summary

That's really all I have to say about it. After reading the documentation, the blog posts, and playing around for an hour or so.

I need to study the API a bit more as, this would be something you would want to automate into other security processes you have within your organization.

If you find this post useful and educational you can donate via PayPal.Me here: $1, $2, $3, $4, $5 or Custom.

I should also mention that it was really hard, not to type, GuardDog. I had to do a triple take to make sure I didn't mistype.

Happy Threat Hunting!

References

Amazon GuardDuty Amazon Guard Duty User Guide
Amazon GuardDuty API Reference
Amazon GuardDuty - Continuous Security Monitoring & Threat Detection