Enabling Amazon GuardDuty in AWS Control Tower using Delegated Administrator

My customers have asked how to monitor their AWS environments for potential malicious activity. Many have standardized on using AWS Control Tower to implement a multi-account framework that is governed and based on known AWS best practices. They are also interested in enabling Amazon GuardDuty to supplement this with effective monitoring capabilities. This post shows you how to monitor your AWS Control Tower managed environments using GuardDuty.

AWS Control Tower is an AWS managed service that automates the creation of a well-architected AWS multi-account framework (environments). It creates a multi-account framework using AWS Organization and further automates new account provisioning in the organization with prescriptive and detective guardrails. AWS Control Tower also centralizes logging from AWS CloudTrail and AWS Config, and provides protective and detective guardrails. The guardrails are AWS best practice settings and AWS Control Tower is designed to monitor and report the compliance status to a central console dashboard.

We deploy GuardDuty using the GuardDuty delegated administrator feature. This feature allows you to manage multiple GuardDuty accounts in an AWS Organization, and is broadly applicable to any AWS Organization. Where AWS Control Tower is an ideal use case, it is not a prerequisite for using GuardDuty or the GuardDuty delegated administrator feature.

GuardDuty can be used to continuously monitor any AWS account or workload for malicious activity and unauthorized behavior. It uses machine learning and integrated threat intelligence to identify abnormal behavior and suspected attackers. This is done from billions of events recorded via AWS CloudTrail, Amazon Virtual Private Cloud (VPC) Flow logs, and Domain Name System (DNS) logs. In this example, we implement GuardDuty to protect accounts that have been created and are governed by AWS Control Tower.

Managing multiple GuardDuty accounts is simplified using the AWS Organizations delegated administrator feature. With this feature, the AWS Organizations management account can designate a member account to be the GuardDuty administrator for the entire organization. The delegated GuardDuty administrator is then granted permission to enable and manage GuardDuty for all existing and future accounts in the organization.

By default, AWS Control Tower creates an audit account for cross-account audit and centralized security operations within the AWS Control Tower multi-account framework. AWS best practices suggest this audit account can also serve as the GuardDuty administrator account. To follow AWS security best practices, you must perform the following tasks:

• Delegate the audit account as the GuardDuty administrator account in all Regions of the AWS Control Tower managed organization.
• Add all existing AWS Control Tower accounts as GuardDuty members of the GuardDuty administrator in the same Region.
• Export GuardDuty findings from the GuardDuty management account in all Regions to a single S3 bucket in the AWS Control Tower log archive account. It is important to note that because GuardDuty findings are aggregated from member accounts into the management account, the S3 bucket contains findings from all member accounts in all Regions.

Solution overview

In this post, we show you how to automate the use of GuardDuty for your Control Tower managed environments. This diagram describes the components of the solution, which are deployed using an AWS CloudFormation template.

Figure 1: Solution Architecture

Here is how the solution works:

1. The AWS CloudFormation template deploys the EnableGDDelegatedAdminLambda Lambda function with appropriate access permissions.
2. Upon successful deployment of the EnableGDDelegatedAdminLambda Lambda function, the AWS CloudFormation template deploys the FirstRun AWS CloudFormation custom resource. The FirstRun custom resource invokes the EnableGDDelegatedAdminLambda deployment function to perform steps 3 through 5 below.
3. The EnableGDDelegatedAdminLambda function registers the GuardDuty delegated administrator account in all Regions that support GuardDuty. Even though any account in the organization could be delegated as the GuardDuty administrator account, we recommend that the delegated GuardDuty administrator account be the AWS Control Tower audit account.
4. The EnableGDDelegatedAdminLambda function iterates through all Regions to enables GuardDuty in all member accounts via the following steps:
   1. Adding all AWS accounts in the AWS Control Tower environment as members of the GuardDuty administrator account. GuardDuty is enabled automatically in each member account.
   2. Automating the addition of any new AWS Control Tower accounts as members in all Regions that support GuardDuty. This is achieved by turning on the auto-enable setting in the GuardDuty administrator account.
5. The EnableGDDelegatedAdminLambda function creates a S3 bucket in the AWS Control Tower log archive account. It also creates a customer-managed KMS key in the GuardDuty management account in the same Region where the bucket is created.  All GuardDuty findings from all member accounts are encrypted using this KMS key and are exported to the S3 bucket.

Prerequisites

This solution assumes that you have deployed AWS Control Tower and have access to the AWS Control Tower management account. The solution is deployed to the AWS Control Tower management account and uses the AWSControlTowerExecution role from AWS Control Tower.

Although you deploy this solution from your AWS Control Tower management account, you must choose an AWS account as your GuardDuty administrator. By default, AWS Control Tower creates an audit account for cross-account auditing and centralized security operations within AWS Control Tower. We recommend using the audit account for our GuardDuty administrator account, but it may use any AWS account within AWS Control Tower.

AWS Control Tower creates a log archive account that stores logs from all AWS Control Tower accounts. We create a centralized S3 bucket in the AWS Control Tower log archive account as the publishing destination for all GuardDuty findings. GuardDuty findings from all members accounts in all AWS Regions are aggregated into this S3 bucket.

The following deployment steps assume that you have deployed AWS Control Tower in the us-east-1 Region. If you deployed AWS Control Tower in another Region, make sure to host the deploy_guardduty.yml  and function.zip file in a S3 bucket for that same Region.  These files are also available via the AWS Service Catalog reference architecture github repo. You can deploy your solution by launching the stack from your S3 bucket in step 2. Make sure the S3SourceBucket and S3Key reflect your S3 bucket and S3 path location.

Deploy the solution

Once you’ve taken care of the prerequisites, follow theses steps:

1. 1. Log in to your Control Tower management account console as a user or role with administrative permission.
   2. Click the Launch Stack button to launch the EnableGuardDuty stack.
      • Note: This should be done from the same Region where your deploy_guardduty.yml and function.zip file (used in this launch stack) are located.
   3. Select Next on the Create Stack page.
   4. On the Specify Details page, confirm that your stack name is EnableGuardDuty.
   5. Under Parameters, review the default parameters and input your own parameters:
      • GDDelegatedAdminAccountId: The Account ID of the account you would like to be your GuardDuty administrator. This is typically the AWS Control Tower audit account. The Account ID is in a 12-digit numeric format.
      • OrganizationId: The ID of the organization (in a format such as o-xxxxxxxxxx), which can be found on the Settings tab of the AWS Organizations console.
      • RoleToAssume: IAM role to be assumed in child accounts to enable GuardDuty.  The default is AWSControlTowerExecution that is created by AWS Control Tower and has necessary permission. Ensure that this role exists if you are deploying to a non-AWS Control Tower managed account.
      • S3Key: The path to the function.zip file that contains the EnableGDDelegatedAdminLambda function.  The default security/guardduty/function.zip value is the Amazon S3 path location in the aws-service-catalog-reference-architectures S3 bucket.
      • S3SourceBucket: The S3 bucket that hosts the function.zip file that contains the EnableGDDelegatedAdminLambda function.  The function.zip file is hosted in the aws-service-catalog-reference-architectures S3 bucket.
   6. Select Next, and continue to select Next on the Review EnableGuardDuty page.
   7. Review and confirm the settings. Be sure to select the box acknowledging that the template Might create AWS Identity and Access Management (IAM) resources.
      Select Create Stack to deploy the stack.
   8. Monitor the status of the stack deployment from the Events tab of the CloudFormation stack.

Figure 2: Deployment Status

The EnableGDDelegatedAdminLambda function is invoked immediately upon successful deployment.

Validate Deployment

Validate GuardDuty administrator account

After successful deployment of the solution, you can validate that we have delegated the GuardDuty administrator account for the AWS Control Tower organization. To do this, sign in to the AWS Management Console of the AWS Control Tower management account, navigate to the GuardDuty service console, and select Settings.

We see that the AWS Control Tower audit account is the GuardDuty administrator account for the AWS Control Tower Organization as shown.

Figure 3. GuardDuty Delegated Administrator account validation

Validate GuardDuty Member Accounts

Next, we validate that the active GuardDuty administrator account also manages members of the multi-account framework provisioned by AWS Control Tower. To do this, sign in to the AWS Management Console of the AWS Control Tower audit account, navigate to the GuardDuty service console and choose Accounts.

Here you will see that GuardDuty in the AWS Control Tower accounts is enabled and managed by the GuardDuty administrator account. Furthermore, the auto-enable feature is also turned on. This is a key feature, as auto-enabling provides the GuardDuty administrator account access to manage all newly created accounts without any additional configuration.

Figure 4: GuardDuty member accounts validation

Summary

We’ve described an automated solution that creates a GuardDuty administrator account in AWS Control Tower using the delegated administrator feature. This GuardDuty administrator account enables and manages GuardDuty in all existing and future AWS Control Tower member accounts. GuardDuty findings from all member accounts are also aggregated to the management account. Furthermore, all GuardDuty findings are exported to the designated S3 bucket in the AWS Control Tower log archive account.

You can leverage GuardDuty findings in additional ways to enhance your security posture, including:

• Automate security remediation to findings identified by GuardDuty. The security response automation blog contains sample code and instructions on how to respond to the Stealth:IAMUser/CloudTrailLoggingDisabled GuarDuty finding.
• Consume GuardDuty findings by AWS Security Hub or another Security Information and Event Management (SIEM) system. GuardDuty is integrated with Security Hub by default. All GuardDuty findings are available in Security Hub. The Splunk serverless application post shows how to send GuardDuty findings to Splunk.
• Investigate GuardDuty findings using Amazon Detective. Detective uses analytics and visualization from behavior graph to investigate GuardDuty findings. You can pivot from a GuardDuty finding to investigate activity that is connected to the finding and associated AWS resources.

If you have questions about this blog post, start a new thread on the Amazon ControlTower forum.

About the Authors

As a Senior Security Transformation Consultant at AWS Professional Services, Joe Zhou works with enterprise customers to protect IT infrastructure and prevent data leakage in cloud and on-premise. He architects and deploys automated solutions to accelerate and secure cloud adoption.