Controlling GuardDuty and Inspector from a Dedicated Security AccountAggregating all regions with Organizations and Security Hub, with Slack and email alerts

1. Why a dedicated security account?

If all you want is to see every finding in one place, you could use the organization's management account. We still chose to create a dedicated account, for three reasons.

2. The big picture: three services and a delegated administrator

We use three services, each with a different role.

The key to running these across the organization is the delegated administrator. Once the management account says "moobon-security manages this service for the whole organization," moobon-security can enable the service in every member account and view their findings.

[ Management account ]  … only designates the delegated admin (rarely touched after)
        │
        ▼ delegates
[ moobon-security ]  … delegated admin for GuardDuty / Inspector / Security Hub
        │  ▲
        │  │ findings flow in automatically (org accounts × all regions)
        │  │
        │  ├── [ Management account ]
        │  └── [ Accounts for our own services ]
        │
        ▼ Security Hub (all regions aggregated into Tokyo)
        ▼ GuardDuty findings of MEDIUM and above only
  EventBridge → SNS → email / Slack (Amazon Q Developer)

3. Creating the moobon-security account

Sections 3 and 4 are run in the management account. First, create a new account in the organization.

# run in the management account
aws organizations create-account \
  --email aws-security@example.com \
  --account-name moobon-security

# check progress (done when State is SUCCEEDED)
aws organizations list-create-account-status --states SUCCEEDED IN_PROGRESS

• Use a shared email address, not a personal one. This address becomes the account's root user. Use a group address that still works when people change roles.
• Move it into a Security OU. Keeping it in a separate OU from workload accounts makes it easier to apply different SCPs later.

# create a Security OU and move moobon-security into it
aws organizations create-organizational-unit \
  --parent-id <ROOT_ID> --name Security

aws organizations move-account \
  --account-id <SECURITY_ACCOUNT_ID> \
  --source-parent-id <ROOT_ID> \
  --destination-parent-id <SECURITY_OU_ID>

Sign-in is through IAM Identity Center (SSO), by assigning a permission set for moobon-security. The root user gets MFA and is not used day to day. We cover the SSO setup in detail in our related article Ditching IAM Users in AI-Driven Development: AWS SSO + AssumeRole.

# add a profile for moobon-security to ~/.aws/config
[profile moobon-security]
sso_session = moobon-sso
sso_account_id = <SECURITY_ACCOUNT_ID>
sso_role_name = AdministratorAccess
region = ap-northeast-1

4. Designating the delegated administrator

This is essentially all the work done in the management account. For each of the three services, designate moobon-security as the delegated administrator.

# run in the management account
SEC=<SECURITY_ACCOUNT_ID>

# Security Hub (once, in the aggregation region = ap-northeast-1)
aws securityhub enable-organization-admin-account \
  --admin-account-id $SEC --region ap-northeast-1

# GuardDuty and Inspector must be designated per region
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws guardduty enable-organization-admin-account \
    --admin-account-id $SEC --region $r
  aws inspector2 enable-delegated-admin-account \
    --delegated-admin-account-id $SEC --region $r
done

5. Enabling GuardDuty across the organization

From here on, commands run in moobon-security. Once it is designated as the delegated administrator, GuardDuty is enabled in moobon-security itself. All that's left is to add the organization's accounts as members.

# run in moobon-security (per region)
DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text \
        --profile moobon-security)

# add organization accounts as members (no invitation email needed inside the org)
aws guardduty create-members \
  --detector-id $DET \
  --account-details AccountId=<ACCOUNT_ID_1> AccountId=<ACCOUNT_ID_2> \
  --profile moobon-security

# check the members (OK when RelationshipStatus is Enabled)
aws guardduty list-members --detector-id $DET --profile moobon-security \
  --query 'Members[].[AccountId,RelationshipStatus]' --output table

MOOBON has only a handful of accounts including the management account, so we add members individually. If your organization adds accounts often, set --auto-enable-organization-members ALL with update-organization-configuration, and both existing accounts and any account that joins later are covered automatically.

6. Enabling Inspector across the organization

In Inspector, the setting that automatically enables accounts that join the organization later is separate from the operation that enables existing accounts. The auto-enable setting alone does not scan existing accounts.

# run in moobon-security
# 1) automatically enable accounts that join later
aws inspector2 update-organization-configuration \
  --auto-enable ec2=true,ecr=true,lambda=true \
  --profile moobon-security

# 2) make existing accounts members and enable scanning
for acct in <ACCOUNT_ID_1> <ACCOUNT_ID_2>; do
  aws inspector2 associate-member --account-id $acct --profile moobon-security
done
aws inspector2 enable \
  --account-ids <ACCOUNT_ID_1> <ACCOUNT_ID_2> \
  --resource-types EC2 ECR LAMBDA \
  --profile moobon-security

In the console, "Activate all accounts" on Inspector's account management page does the same thing.

7. Aggregating in Security Hub

In accounts where Security Hub is enabled, GuardDuty and Inspector findings are sent to Security Hub automatically. Two things remain: (1) gather the results from all regions into one region, and (2) make the organization's accounts members.

(1) Gather all regions into Tokyo

# run in moobon-security, ap-northeast-1
aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS \
  --region ap-northeast-1 --profile moobon-security

Tokyo is now the aggregation region, and findings from other regions are collected there. This aggregation turns out to be the key to fixing the alerts in section 8.

(2) Make the organization's accounts members

aws securityhub create-members \
  --account-details '[{"AccountId":"<ACCOUNT_ID_1>"},{"AccountId":"<ACCOUNT_ID_2>"}]' \
  --profile moobon-security

aws securityhub list-members --only-associated --profile moobon-security \
  --query 'Members[].[AccountId,MemberStatus]' --output table

For configuration checks, we enabled AWS Foundational Security Best Practices (FSBP) and the CIS AWS Foundations Benchmark. In an organization with many accounts, central configuration lets you define which standards to use as a policy and associate it with the organization root or an OU, so new accounts get the same settings automatically.

8. Alerts: we were only catching Tokyo

Even with everything on one screen, you won't notice anything unless you open it. The last step is alerts that send findings needing action to email and Slack. We narrowed the condition to "GuardDuty findings of MEDIUM (4) severity or higher." Inspector and configuration checks come in large numbers, so we handle them in the console instead of alerting.

Our first alert: catching GuardDuty events directly

At first, we followed the commonly described approach and created a rule in the Tokyo region that catches GuardDuty events directly with EventBridge.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [{ "numeric": [">=", 4] }] }
}

It sends to two SNS topics. One is for email, with the message body assembled in Japanese by EventBridge's input transformer. The other is for Slack, connected to Amazon Q Developer in chat applications (formerly AWS Chatbot), which posts to our #aws-security channel.

When we generated a sample finding in Tokyo, both the email and the Slack message arrived, and we thought we were done.

The pitfall: findings outside Tokyo went nowhere

We realized it while reviewing the setup for this article. GuardDuty events are delivered only to EventBridge in the region where the finding occurred. With a single rule in Tokyo, a finding in, say, Oregon (us-west-2) is never alerted on anywhere.

The fix: switch the alert source to Security Hub

You could create a rule in every region and forward events to Tokyo, but in section 7 we had already aggregated findings from all regions into Security Hub in Tokyo. So catching the events for findings that Security Hub imports, in Tokyo, lets a single rule catch every region. Save the following as pattern.json.

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "ProductName": ["GuardDuty"],
      "Severity": { "Label": ["MEDIUM", "HIGH", "CRITICAL"] },
      "Workflow": { "Status": ["NEW"] },
      "RecordState": ["ACTIVE"]
    }
  }
}

# run in moobon-security, ap-northeast-1 (the aggregation region)
aws events put-rule \
  --name securityhub-guardduty-medium-plus \
  --event-pattern file://pattern.json \
  --profile moobon-security

aws events put-targets \
  --rule securityhub-guardduty-medium-plus \
  --targets file://targets.json \
  --profile moobon-security

Security Hub findings use a common format called ASFF, so the paths referenced by the input transformer that builds the email body change too. The finding sits under detail.findings[0].

// targets.json (the input transformer part of the email target)
"InputPathsMap": {
  "acct":   "$.detail.findings[0].AwsAccountId",
  "region": "$.detail.findings[0].Region",
  "sev":    "$.detail.findings[0].Severity.Product",
  "label":  "$.detail.findings[0].Severity.Label",
  "type":   "$.detail.findings[0].Types[0]",
  "title":  "$.detail.findings[0].Title",
  "desc":   "$.detail.findings[0].Description",
  "first":  "$.detail.findings[0].FirstObservedAt",
  "last":   "$.detail.findings[0].LastObservedAt"
},
"InputTemplate": "\"[GuardDuty] Severity <sev> (<label>)\"\n\"Account: <acct>  Region: <region>\"\n..."

The email also includes a link that signs in to moobon-security through SSO and opens GuardDuty in the relevant region directly. Appending #/console?account_id=…&role_name=…&destination=… to the IAM Identity Center access portal URL takes you straight to that console page after sign-in. The less effort it takes to get from an alert to the console, the less likely the check gets put off.

For Slack, we simply pass the raw event to SNS. Amazon Q Developer formats Security Hub events into a readable post, so no extra setup is needed.

Verifying: generating a sample in Oregon

# generate a single MEDIUM sample finding in a region other than Tokyo
DET=$(aws guardduty list-detectors --region us-west-2 \
        --query 'DetectorIds[0]' --output text --profile moobon-security)
aws guardduty create-sample-findings --region us-west-2 \
  --detector-id $DET --finding-types "Recon:EC2/Portscan" \
  --profile moobon-security

The result: within about a minute, the rule in Tokyo fired and the alert reached both email and Slack. At the same time, the old rule (wired directly to GuardDuty) did not fire even once, confirming in practice that it had been missing findings outside Tokyo. Once verified, disable the old rule (otherwise Tokyo findings arrive twice) and archive the sample finding.

9. Costs and pitfalls