Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. SPDX-License-Identifier: CC-BY-SA-4.0
The GuardDuty Organization solution will enable Amazon GuardDuty by delegating administration to a member account within the Organization management account and configuring GuardDuty within the delegated administrator account for all the existing and future AWS Organization accounts. GuardDuty is also configured to send the findings to a central S3 bucket encrypted with a KMS key.
- All resources are deployed via AWS CloudFormation as a
StackSet
andStack Instance
within the management account or a CloudFormationStack
within a specific account. - The Customizations for AWS Control Tower solution deploys all templates as a CloudFormation
StackSet
. - For parameter details, review the AWS CloudFormation templates.
- The Lambda function includes logic to enable and configure GuardDuty
- IAM role used by the Lambda function to enable the GuardDuty Delegated Administrator Account within each region provided
- All the
AWS Lambda Function
logs are sent to a CloudWatch Log Group</aws/lambda/<LambdaFunctionName>
to help with debugging and traceability of the actions performed. - By default the
AWS Lambda Function
will create the CloudWatch Log Group and logs are encrypted with a CloudWatch Logs service managed encryption key.
- SNS Topic used to fanout the Lambda function for deleting GuardDuty within each account and region.
- SQS dead letter queue used for retaining any failed Lambda events.
- SNS Topic used to notify subscribers when messages hit the DLQ.
- GuardDuty is enabled for each existing active account and region during the initial setup
- GuardDuty will automatically enable new member accounts/regions when added to the AWS Organization
- The python boto3 SDK lambda layer to enable capability for Lambda to enable protection features of the GuardDuty service.
- This is downloaded during the deployment process and packaged into a layer that is used by the Lambda function in this solution.
- The GuardDuty API available in the current Lambda environment (as of 05/24/2023) is boto3-1.20.32, however, enhanced functionality of the GuardDuty API used in this solution requires at least 1.26.117 (see references below).
- Note: Future revisions to this solution will remove this layer when boto3 is updated within the Lambda environment.
- S3 bucket where GuardDuty findings are exported for each account/region within the AWS Organization
- See 1.8 GuardDuty
The example solutions use Audit Account
instead of Security Tooling Account
to align with the default account name used within the AWS Control Tower setup process for the Security Account. The Account ID for the Audit Account
SSM parameter is
populated from the SecurityAccountId
parameter within the AWSControlTowerBP-BASELINE-CONFIG
StackSet.
- GuardDuty is configured to encrypt the exported findings with a customer managed KMS key
- IAM role assumed by the Lambda function within the management account to configure GuardDuty within each region provided
- See 1.8 GuardDuty
- See 1.8 GuardDuty
- An IAM role is created within all the accounts to clean up the GuardDuty detectors when the Disable GuardDuty parameter is set to 'true' and the CloudFormation stack is updated.
- Download and Stage the SRA Solutions. Note: This only needs to be done once for all the solutions.
- Verify that the SRA Prerequisites Solution has been deployed.
Choose a Deployment Method:
In the management account (home region)
, launch an AWS CloudFormation Stack using one of the options below:
-
Option 1: (Recommended) Use the sra-guardduty-org-main-ssm.yaml template. This is a more automated approach where some of the CloudFormation parameters are populated from SSM parameters created by the SRA Prerequisites Solution.
aws cloudformation deploy --template-file $HOME/aws-sra-examples/aws_sra_examples/solutions/guardduty/guardduty_org/templates/sra-guardduty-org-main-ssm.yaml --stack-name sra-guardduty-org-main-ssm --capabilities CAPABILITY_NAMED_IAM
-
Option 2: Use the sra-guardduty-org-main.yaml template. Input is required for the CloudFormation parameters where the default is not set.
aws cloudformation deploy --template-file $HOME/aws-sra-examples/aws_sra_examples/solutions/guardduty/guardduty_org/templates/sra-guardduty-org-main.yaml --stack-name sra-guardduty-org-main --capabilities CAPABILITY_NAMED_IAM --parameter-overrides pAuditAccountId=<AUDIT_ACCOUNT_ID> pLogArchiveAccountId=<LOG_ARCHIVE_ACCOUNT_ID> pOrganizationId=<ORGANIZATION_ID> pRootOrganizationalUnitId=<ROOT_ORGANIZATIONAL_UNIT_ID> pSRAStagingS3BucketName=<SRA_STAGING_S3_BUCKET_NAME>
- Log into the Management account and navigate to the GuardDuty page
- Validate that the delegated admin account is set for each region
- Log into the Audit account and navigate to the GuardDuty page
- Verify the correct GuardDuty configurations have been applied to each region
- Verify all existing accounts have been enabled
- Verify the findings export is configured for the S3 bucket
- Generate sample findings to verify S3 delivery
- Log into the Log archive account and navigate to the S3 page
- Verify the sample findings have been delivered
- In the
management account (home region)
, change theDisable GuardDuty
parameter totrue
and update the AWS CloudFormation Stack (sra-guardduty-org-main-ssm
orsra-guardduty-org-main
). This will disable the solutions within each of the member accounts/regions. - In the
management account (home region)
, delete the AWS CloudFormation Stack (sra-guardduty-org-main-ssm
orsra-guardduty-org-main
). - In the
management account (home region)
, delete the AWS CloudWatch Log Group (e.g. /aws/lambda/<solution_name>) for the Lambda function deployed. - In the
log archive acccount (home region)
, delete the S3 bucket (e.g. sra-guardduty-delivery-<account_id>-<aws_region>) created by the solution.