Turbot GuardDuty Detector Configuration

Overview

Amazon GuardDuty provides intelligent threat detection by using a combination of multiple information sources. It makes continuous security monitoring and threat detection easier with multi-account feature. This guide provides information on setting up the configuration to achieve multi-account model of Amazon GuardDuty.

GuardDuty has a feature that allows users to designate a master account, which can then invite other AWS accounts as member accounts to forward their findings to the master account. This provides visibility of all findings across multiple AWS accounts to a central account and security team. More information about this feature can be found in Managing AWS Account in Amazon GuardDuty.

Note: A GuardDuty master account can have up to 1000 member accounts.

Getting Started

Turbot GuardDuty detector configuration policies and guardrails have been developed to allow easy management of GuardDuty master and member accounts across your Turbot environment.

To get started with configuring your GuardDuty detectors, the following policies need to be configured:

  • AWS > GuardDuty > Turbot Detector Configuration
  • AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID
  • AWS > GuardDuty > Turbot Detector Trusted Member Accounts

Turbot Detector Trusted Master AWS Account ID

The AWS account ID of the trusted GuardDuty master account. For the designated GuardDuty master account, this policy value should be set to its own AWS account ID.

This policy can be set to an AWS account ID that is not managed by Turbot, but Turbot cannot automatically extend invites and manage memberships from the master account then.

Turbot Detector Trusted Member Accounts

The list of trusted accounts that the GuardDuty master account will invite and monitor memberships for.

The policy setting must be a valid YAML object list with a valid account identifier.

For example:

- { id: aaa, email: aws+name+aaa@turbot.com} # Trust account aaa in all regions
- { id: aaa, email: aws+name+aaa@turbot.com, region: us-west-2 } # Trust aaa but only in us-west-2
- { clusterId: ab } # Trust all accounts in cluster ab in all regions
- { awsAccountId: 126697123538, region: us-west-2 } # Trust AWS account 776697123538 but only in us-west-2
- { id: 126697123538 }  # Trust AWS account 126697123538 in all regions

Any region limitation will take precedence, even if there is a wider trust specified in the list.

For the following trusted member list:

- { id: aaa, email: aws+name+aaa@turbot.com }
- { id: aaa, email: aws+name+aaa@turbot.com, region: us-east-1 }

Only us-east-1 will be trusted in account aaa, even though there is a broader setting also in the list.

Giving a cluster ID will include all accounts in that cluster, and should not include an account ID or AWS account ID:

- { clusterId: ah } # Valid entry
- { clusterId: ah, id: aaa } # Invalid entry
- { clusterId: ah, awsAccountId: 126697123538 } # I nvalid entry

If the email address is not provided (either when giving a cluster ID or Turbot account ID), Turbot will attempt to determine the email address from the cluster’s AWS organization. The AWS > Organizations policies must be configured for the cluster in order for this feature to work. For more information on configuring these policies, please see Using Organizations in your Cluster in Guardrails for AWS Organizations.

For Turbot accounts in your cluster that are not a part of your set AWS organization, or AWS accounts that are outside of your Turbot environment, an email address must be explicitly provided:

- { id: abc, email: aws+name+abc@turbot.com } # Account is in a different organization
- { awsAccountId: 126697123538, email: outside+aws+account@turbot.com, region: us-east-1 } # AWS account is not Turbot managed

Turbot Detector Configuration

This policy controls whether or not the master or member detector is configured in an account’s region and supports the following values:

  • Skip (default)
  • Check: Configured
  • Enforce: Configured

Once this policy is set to configure the detector, the guardrail will configure the detector based on the setting for AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID.

For instance, if the master AWS account ID policy for an account is set to its own AWS account ID, Turbot will recognize this account is a GuardDuty master account and configure the detector appropriately; however, if the master AWS account ID belongs to another account, then it will configure the detector as a member instead.

In order for Turbot to create memberships, the master and member accounts must trust one another. Any existing memberships with untrusted accounts are automatically removed by Turbot.

Note: Detectors managed by Turbot are automatically approved for the AWS > GuardDuty > Detector Approved guardrail.

Example Policy Settings

Below is an example set of policy settings and the resulting detector changes:

For 2 accounts:

  • aaa [AWS account ID 123456789012] (GuardDuty master account)
  • abc [AWS account ID 012345678901] (GuardDuty member account)

Policies in aaa for us-east-1:

  • AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID
    123456789012
    
  • AWS > GuardDuty > Turbot Detector Trusted Member Accounts
    { id: abc, email: aws+name+abc@turbot.com, region: us-east-1 }
    
  • AWS > GuardDuty > Turbot Detector Configuration
    Enforce: Configured
    

Policies in abc for us-east-1:

  • AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID
    123456789012
    
  • AWS > GuardDuty > Turbot Detector Configuration
    Enforce: Configured
    

After setting these policies, Turbot will perform the following steps:

  • Create a detector in us-east-1 in aaa if it does not exist yet
  • Send an invitation from aaa to abc in us-east-1
  • Accept the invitation from aaa in abc (AWS will automatically create a detector when accepting if it doesn’t exist yet)

FAQs

Q: What happens if the AWS account in AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID is not managed by Turbot?

Turbot will accept invitations for member accounts even if the GuardDuty master account is not managed by Turbot, but it will not be able to manage the GuardDuty master account.

Q: What happens for any accounts in AWS > GuardDuty > Turbot Detector Trusted Member Accounts that are not managed by Turbot?

For any member accounts not managed by Turbot, Turbot will extend invitations from the GuardDuty master account, but cannot automatically accept the invitation in the member account. This will need to be accepted manually by a user in that member account.

Q: What happens if AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID is not specified?

Turbot will treat this as an insufficient data condition and will not perform any configuration checks for the GuardDuty master or member accounts.

Q: What if the email address and AWS account ID information given for an item in AWS > GuardDuty > Turbot Detector Trusted Member Accounts do not match?

GuardDuty internally performs a verification process to validate the email address and AWS account ID once the invitation is sent. Turbot will report any of these errors when configuring the GuardDuty master account.

Q: What if an existing GuardDuty member account is set as a GuardDuty master account in AWS > GuardDuty > Turbot Detector Trusted Master AWS Account ID?

Turbot will promote the account as a GuardDuty master account and invite any GuardDuty member accounts.

Q: What if an account given in AWS > GuardDuty > Turbot Detector Trusted Member Accounts is already a GuardDuty master of other accounts?

Turbot will demote the account to a GuardDuty member, disassociating all of its previous member accounts and then accept the invitation from the new GuardDuty master account.

Q: What if a GuardDuty member account is already a member account for some other GuardDuty master account?

Turbot will resign the GuardDuty member account from the current GuardDuty master account, and then accept the invitation from the new GuardDuty master account.

Q: Can I disable the emails that go to account administrators when inviting accounts?

Yes! The policy AWS > GuardDuty > Turbot Detector Email Notifications can be set to Enforce: Disabled to prevent emails going to account administrators.

Was this article helpful?
0 out of 0 found this helpful