Overview

In the previous blog I showed how to setup AWS Organizations in All Features mode and and prepare the AWS environment to run my Security Operations Center (SOC) AWS Account by delegating administrative functions through AWS Organizations. Additionally, we configured AWS Organizations CloudFormation StackSets and demonstrated how the AWS CloudShell can be used and configured to deploy our services. If you have not read the blog post please visit here.

If you are wondering what is CloudShell, read the first blog post.

In this blog post I will go over deploying AWS GuardDuty as an integrated AWS Organization service which will automatically enroll all new accounts reporting GuardDuty findings into the GuardDuty Delegated Administrative account.

What Is AWS GuardDuty

AWS defines GuardDuty as:

Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts, workloads, and data stored in Amazon S3.

In other words AWS GuardDuty is a service that monitors network traffic (VPC and S3) and analyzes it for malicious or suspicious behavior. Finding are reported to the AWS GuardDuty web console within the account or reports back to a central account, also know as the Delegated Administrative account. It is best to deploy GuardDuty to every account as you are only billed for utilization (so if not network traffic or S3 activity, no utilization, no noticeable cost).

Why do I need to deploy GuardDuty via Organizations?

This is a great question and many with experience of large implementations can answer it easily: technical debt. Prior to integration with AWS Organizations, AWS GuardDuty worked via Invitations from the central GuardDuty Adminsitrative account to the member account. This was not too bad, but you were stuck running CloudFormation and Lambda functions that would enable the AWS GuardDuty service in a specific region, send out a request invite from the central GuardDuty account then accept GuardDuty invitation from the member account. At the end of the day you were stuck managing that automation. There have been some great solutions, but none as simple as the AWS Organizations integration I am going to show you here. Best way to put this: you will set it once and not worry about it at all going forward.

Prerequisites

If you followed along with Part 1 meeting all the prerequisites and deploying the necessary configurations, then you are doing great. If not please go back and review Configuring Security Services with AWS Organizations: Part 1. For this blog post, the only additional prerequisite here is to have deployed a SOC account.

Note: If you are using AWS Control Tower, you should use the Audit account for you Security Operations functionality. AWS highly recommends this and using the account for this functionality will better enable you to take advantage of new features in the future.

What is a SOC account? A SOC account is merely an AWS account you have set aside to conduct all security operation services (and only security operations).

WARNING: As I mentioned in Part 1 of the series, DO NOT DEPLOY your security services to the Management account if you can avoid it.

Enabling AWS GuardDuty via Organizations

Regardless of you using AWS GuardDuty prior to configuring AWS Organizations integrated GuardDuty, the process is still the same. So starting out in the Management account, we can open the CloudShell and run a few commands to enable.

Info: If you don't know what the CloudShell is and have not read Part 1, please go back and read Part 1 of the blog series.

In the CloudShell we will make a couple of simple one-liner commands to configure AWS GuardDuty for Organizations. To start off let's enable the service for the Organization by running:

aws organizations enable-aws-service-access --service-principal guardduty.amazonaws.com

If you are looking for some status of AWS GuardDuty being configured in the AWS Organizations Settings web console, you will not find this. The AWS Organizations Settings currently only lists services that are enabled and managed out of the management account. It does not show delegated AWS Organization services at this time. To view the status of enabled AWS Organization services you can run aws organizations list-aws-service-access-for-organization. The output should list GuardDuty as enabled:

That command will enable AWS GuardDuty for the Organization. Step one is done and now we can move on to step two, which is delegating the GuardDuty administrative account. This is not really a complex process here and it consists of one or more commands depending on how many regions you need to support.

AWS GuardDuty is a regional service meaning that whatever region you are running your CloudShell in, is the region you will delegate the admin account unless specified otherwise. My recommendation is that you stick with the Audit/SOC account you identified and just enable it for the necessary regions you have workloads in. If concerned about monitoring, simply place an Service Control Policy (SCP) on all accounts restricting the regions they can run in. To enable AWS GuardDuty in the current region you are in run the following command:

aws guardduty enable-organization-admin-account —admin-account-id 123456789 

If you need any region outside of the current region you are in, run the following command replacing the --region param. Example here would enable GuardDuty Admin account on Account Id 123456789 in us-west-2

aws guardduty enable-organization-admin-account —admin-account-id 123456789 --region us-west-2

Note: You don't need to deploy GuardDuty to every region possible in AWS in an attempt to monitor. Use AWS Service Control Policies to deny/allow regions you choose to operate in, then deploy GuardDuty to those regions.

The command will give AWS GuardDuty Administrative account permission to enroll and automate the configuration of AWS GuardDuty for the region for any account except the management account.

Note: Your Management account can be a member of the AWS GuarDuty Organization, but will require you to enable AWS GuardDuty in the desired region. If not enabled, you will get an error in your GuardDuty Delegated Administrative account when you try to automate the enrollment.

Once you have completed those two simple tasks of enabling and delegating AWS GuardDuty, you are done in the Management account.

The next step is to go to the AWS GuardDuty Delegated Administrative account and begin configuring the GuardDuty service.

Configuring the AWS GuardDuty Administrative Account

After properly delegating the GuardDuty service in the AWS Organization you can login to the account you assigned as the GuardDuty Delegated Administrative account and begin configuring. If this is your first time setting up GuarDuty in the AWS account you can quickly change to the region you wish and run the following command in the CloudShell to enable and create an GuardDuty detector.

aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES

The create-detector command has some key points which I pulled from the AWS documentation: To start using GuardDuty, you must create a detector in each Region where you enable the service. You can have only one detector per account per Region. All data sources are enabled in a new detector by default. Therefore, what we just did was setup AWS GuardDuty in the current region of the account and enabled all data sources.

Next, we need to take note of the output returned from the previous command and copy the detector-id value for our next command. In the following command we update our configuration for GuardDuty to auto-enable. Auto-enable means that any new AWS account created within the Organization will automatically have GuardDuty created in the region and reporting back to the GuardDuty Delegated Administrative account.

aws guardduty update-organization-configuration --detector-id [whatever detector you just created ID] --auto-enable 

If you just deployed your AWS Organization and immediately set this all up, your work is limited now. The only cleanup you will have is to go back to the management account and possibly enable GuardDuty as it is not impacted by Organization integrated services.

Post Deployment Actions

If you already have AWS accounts deployed prior to configuring AWS Organization GuardDuty or that you were leveraging AWS GuardDuty by Invitation, you can convert these accounts to be managed by Organization as a Member account.

Note: GuardDuty allows accounts to be managed outside of your AWS Organization though Invitation. Only AWS accounts that are part of the Organization can be converted from Invitation to Member accounts.

To view all the accounts for AWS GuardDuty you can see their status by going to the AWS GuardDuty web console and selecting the Accounts tab in the Settings page. You can see the status as shown below circled in red.

In the screenshot you see there are 7 accounts and 0 of them are enrolled via Organizations or Invitation. This means I have 7 accounts in my Organization which could be enrolled in GuardDuty and none of them are by Invitation. To add these pre-existing accounts or accounts that are of Type via Invitation you can select their checkboxes and click Add Member from the Actions menu located in the top right of the Accounts page.

Once added as member, AWS GuardDuty will be deployed and configured to the region of the pre-existing account if not already done. The only error you may receive is from the management account which requires you to go into the management account and enable GuardDuty prior.

Note: Converting AWS GuardDuty member accounts from Invitation to Organization will have no noticeable impact to the member account. It is a simple conversion.

What's Next

In Part 3 post we will continue configuring AWS Organization integrated security services by deploying AWS Security Hub.