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:
- Port scan an instance
- From an instance, nslookup GuardDutyC2ActivityB.com
- From an instance, curl http://xdn-xmr.pool.minergate.com/dhdhjkhdjkhdjkhajkhdjskahhjkhjkahdsjkakjasdhkjahdjk
- Black list an IP that responds to ping (like 8.8.8.8) then initiate a ping from the instance and the reply will get flagged.
- There are other methods here
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.
