Enabling Amazon GuardDuty in AWS Control Tower using Delegated Administrator

Amazon Web Services Feed
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 AWS Control Tower to implement a governed AWS environment based on known AWS best practices, and are interested in enabling Amazon GuardDuty to accomplish this task. This post shows you how to monitor your AWS Control Tower managed environment using GuardDuty.

We deploy GuardDuty using the GuardDuty delegated administrator feature. This feature makes managing multiple GuardDuty accounts in an AWS Organization a simple process and is broadly applicable to any AWS Organization. AWS Control Tower is an ideal use case but not a prerequisite for using GuardDuty or the GuardDuty delegated administrator feature.

AWS Control Tower is an AWS managed service that automates the creation of a well-architected AWS environment. It creates a multi-account environment under an AWS Organization and automates new account provisioning in the organization. AWS Control Tower 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.

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

With the added AWS Organizations support in GuardDuty, managing multiple GuardDuty accounts is simplified. Using the AWS Organizations delegated administrator feature, the AWS Organizations master account can designate a member account to be the GuardDuty administrator for the organization. The delegated GuardDuty administrator is granted permission to enable and manage GuardDuty for all existing and future accounts in the organization.

By default, AWS Control Tower creates a SecurityAudit account for cross-account audit and centralized security operations within the AWS Control Tower managed environment. We recommend that the audit account serves 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 AWS Control Tower accounts as GuardDuty members of the GuardDuty administrator in the same Region.
• Export GuardDuty findings from the GuardDuty master account in all Regions to a single S3 bucket in the AWS Control Tower log Archive account. Because GuardDuty findings are aggregated from member accounts into the master account, the S3 bucket contains findings from all member accounts in all Regions.

Solution overview

In this post, we show you how to automate these steps in the Control Tower environment. The diagram  below describes the components of the solution, which is deployed using an AWS  CloudFormation template.

Here is how the solution works:

1. The CloudFormation template deploys the EnableGDDelegatedAdminLambda Lambda function with appropriate access permissions.
2. Upon successful deployment of the EnableGDDelegatedAdminLambda Lambda function, the 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. We recommend that the delegated GuardDuty administrator account be the AWS Control Tower Audit account. However, any account in the organization can be delegated as the GuardDuty administrator account.
4. The EnableGDDelegatedAdminLambda function iterates through all Regions to enables GuardDuty in all member accounts via the following steps:
   1. Adds 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. Automates 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.
   3. Creates a customer-managed KMS key in each Region of the GuardDuty master account. The KMS key is required for encrypting GuardDuty findings in order to export them to the S3 bucket.
5. The EnableGDDelegatedAdminLambda function creates a S3 bucket in the AWS Control Tower log Archive account. All GuardDuty findings from all member accounts are encrypted using the KMS key created in step 4 and exported to the S3 bucket.

Prerequisites

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

Although you deploy this solution from your AWS Control Tower master account, you must choose an AWS account as your GuardDuty administrator. By default, AWS Control Tower creates a SecurityAudit account for cross-account auditing and centralized security operations within AWS Control Tower. We recommend the Audit account for our GuardDuty administrator account, but it can designate 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.

Deploy the solution

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

1. 1. Log in to your Control Tower master account console as a user or role with administrative privilege.  Your console session should be in the same Region as your S3 bucket.
   2. Click the Launch Stack button to launch the EnableGuardDuty stack.
   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, but can be any account in the AWS Control Tower organization. If you already have an account that is used as a GuardDuty master account, it can also be delegated as the new AWS Organization supported administrator. 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 which is created by AWS Control Tower and has necessary permission. Ensure this role exists if you are deploying to a non-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 s3 path location in the 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, we validate that we have delegated the GuardDuty administrator account for the AWS Control Tower organization. Sign in to the AWS Management Console of the AWS Control Tower master 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

Now we validate that the active GuardDuty administrator account manages members of AWS Control Tower. Sign in to the AWS Management Console of the AWS Control Tower audit account. Navigate to the GuardDuty service console and choose Accounts.

We see that GuardDuty in the AWS Control Tower accounts is enabled and managed by the GuardDuty administrator account. Furthermore, the auto-enable feature is turned on. Auto-enabling provides the GuardDuty administrator account access to manage all newly created accounts without any additional configuration, as shown below.

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. The GuardDuty administrator account enables and manages GuardDuty in all existing and future AWS Control Tower member accounts. GuardDuty findings from all member accounts are aggregated to the master account. All findings are exported to the 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-prem. He architects and deploys automated solutions to accelerate and secure cloud adoption.