Summary

AWS Guard Duty offers an enhanced security scan of all AWS services and how to better protect them based on your usage patters and well known vulnerabilities.

General Observations

1. GD Analyzes VPC Flow Logs, AWS CloudTrail events and AWS DNS logs.
2. Console Notification for new findings – as they are analysed and discovered.
3. Notification frequency of new findings (to CloudWatch) every 5 minutes.
4. Notification configurable frequency of 15ins, 60mins or 6 hours (to CloudWatch) for updates to existing findings (counts for the same finding / vulnerability)
5. 1000 member accounts supported.
6. Definitions for trusted IPs and cloudwatch notification time / period are set and enforced at master only to flow down to sub accounts.
7. Max 2000 trusted IPs in single list.
8. Max 250,000 threat IPs in single list.
9. Master accounts cannot be member of any other account.
10. Sub accounts can view findings related to their own account, but are unable to archive them. Master account can view all findings for all accounts and archive them, which removes them from the sub accounts findings view also.
11. Guard Duty can be suspended on master and on slave accounts (from master) slaves can manage and re-enable suspension on themselves only.
12. GD detectors are region specific and need to be enabled on a per region basis including any regional master/sub collector services
    • Regional Master accounts are required for aggregation from sub accounts in the same region
      • e.g you cannot have one master Guard Duty collector in EU-WEST-1 and have AWS EU-WEST-2 regions send their Guard Duty findings to it.
      • You must have a Guard Duty master enabled in the EU-WEST-2 region and invite the sub account again for every region you want to enable Guard Duty
13. In master, sub account the trusted and threat lists are applied at the master as a single list only.
14. Log data from CloudTrail. VPC DNS are all encrypted when in transit to GuardDuty, after analysis the logs are discarded.
15. Immediate analysis of flow logs starts from the service being enabled, it consumes events directly as a duplicate stream of flow logs. This does not modify any existing flow log configurations.
16. DNS analysis will only work if using AWS DNS Resolvers. Other DNS services will not be ‘captured’ or analysed.

Rollout

AWS documentation points to a Cloud Formation template for enabling Guard Duty. Its only available as a template in us-east-1 region, so be sure to select this region.

CloudFormation

If you just want to setup Guard Duty services in your accounts via an AWS CloudForation StackSet – use this AWS Provided CT template ‘Enable Amazon GuardDuty’

https://console.aws.amazon.com/cloudformation/stacksets/home?region=us-east-1#/stacksets/new

Caveats

If you dont specify a master ID. The CF template simply enables GuardDuty in the stackset accounts and regions only.

You have to manually invite all your ‘sub accounts’ from all regions first before this stackset will work with the ‘masterId’ (as each sub account has to have an invitation waiting from the master)

CF Message:

The Amazon GuardDuty master account ID. If you specify the master account ID, this stack set creates a GuardDuty detector in each specified account and accepts the GuardDuty membership invitation sent to each of the specified accounts by this master account. If this value is specified, before you can create this stack set, all accounts in all regions to which this stack set template is to be applied must already have an invitation from this master GuardDuty account and must NOT have a detector already created.

Python

If you want a full cross account multi region master subscriber setup, from scratch – use the AWS provided python script.]=]#=[

It creates a master detector in your specified master account, and subscribes each sub account and even every sub account region to the master, accepts the invite and links the accounts.

The script can even be run from an unrelated ‘build or deploy’ account. Perfect!

https://github.com/aws-samples/amazon-guardduty-multiaccount-scripts

AWS Support recommended using the python script as the primary deployment mechanism.

There are no currently no ansible modules for AWS GuardDuty

Python Script Notes

The disable script breaks a little but a fix is provided in the issues list

The enable script messages the root account email for each account and for EVERY region that is listed to be ‘enabled’ so for a large scale deployment many multiple emails may be delivered!