Thoughts on AWS GuardDuty

I recently deployed AWS GuardDuty for a client and wanted to share some thoughts on the services at a high level.

If unfamiliar, GuardDuty is a managed threat detection service that continuously monitors for malicious or unauthorized behavior by evaluating VPC Flow Logs, CloudTrail and DNS Logs (if using AWS DNS).

The Good

A single click enables the service- this can’t get any simpler.  This enables the service for the entire account, regionally.

You don’t need to enable VPC Flow Logs and CloudTrail individually- GuardDuty will act in parallel to anything already in place.

As classified threats are logged, you’ll see the console start to populate with various findings.  The findings are based on about 40 static categories, which you can find here.

Notifications for findings can be sent to SNS via Cloudwatch Rules via JSON pattern matching.  The input transformer is useful for making the SNS messages more human-readable.

In terms of cost, it is very affordable. $1/GB of flow logs/Mo & $4 per 1M CloudTrail events. I find it very difficult to calculate how many GBs of flow logs are generated by a VPC if not currently enabled. Fortunately, there is a 30-day trial for GuardDuty, providing a projected daily cost. For my project, the total was less than $1/day.  Obviously, costs will vary account-to-account.

The Bad

There really isn’t anything clearly bad with the service, IMO.  However, keep in mind that the Findings definitions are a static list. If you need to detect on other specific threat patterns then perhaps you should send logs directly to a SIEM tool (which I haven’t tried, but I’ve read can GuardDuty can do) along with other logs.

I will note that testing GuardDuty could be easier. If a finding has already been detected, it could take 6 hours to report that it occurred again (when alerting via Cloudwatch). This is just a gripe and not really a big deal once you get the service setup.

Just to mention, here are some methods I’ve used for testing include:

Currently you can’t delete individual findings (that you may generate during testing). You could delete all your data by disabling the service.  Not really a problem, but it’s a desired feature.

Final Thoughts

If you don’t have a solution for thread detection on your AWS workloads, you need to seriously take a look at GuardDuty- you’ll have much higher level visibility into what’s going on in your AWS account without spending all of your time digging through logs.  If you have an existing solution, GuardDuty could be a nice supplement, but not necessarily a replacement based on everyone’s needs.

As of this writing, GuardDuty is a fairly new service and you may be reluctant to jump in. I’ve personally found AWS’ services to be rock-solid when getting to GA, although they generally are not full-featured.  At the rate Amazon rolls out new features, it should only be a matter of time.  I hope to see this feature extend it’s capabilities.

As I mentioned, GuardDuty does have a 30-day trial and can be disabled with a click, so the barrier to entry is extremely low.

Go forth and try GuardDuty.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s