Introduction

A big part of my work is cloud security automation and when I found out AWS integrated many of the AWS security services with AWS Organizations, I simply could not wait to get started. Yet, I found that there isn’t a dead-simple guide for cloud engineers in how to deploy these security services. There are a lot of references stating you can now automate with AWS Organizations, but no one telling how. Thus, in this multi-part blog post/guide I will focus on giving the reader dead-simple one-liner commands which are to be run from the AWS CloudShell, a new feature of the AWS web console for command line access.

The best part of this guide is that you will not be required to create any IAM users, API keys, nor EC2 roles/instance profiles to run the commands. All you will need to do is copy the commands, update the params and paste into your CloudShell to run (finally no mess deployments). Once configured, you are done and then let the automation take over!

Overview

This is the first part of a series of blog posts focusing on deploying security services through AWS Organizations. In this blog post we will go over AWS Organizations prerequisites and additional configurations of your AWS Organization to enable the security services. Then we will enable AWS CloudFormation StackSets for the AWS Organization. In my opinion if you plan to automate security within your organization, you should be in some way leveraging CloudFormation StackSets as it facilitates enabling/enforcing compliance for current and future accounts. In subsequent blog posts we will deliver AWS services that are integrated with AWS Organizations.

Note: If you are managing multiple AWS Accounts within your environment you should be managing them through AWS Organizations in some faculty. To get started, visit the AWS Documentation Creating an organization

If you are like me, you just want to see a GitHub repo to review the code for reference. You can find the code to deploy these services at https://github.com/grolston/AwsOrganizations. If wanting additional services to be automated, create an issue on the project and I will do my best to document, standardize and automate.

Prerequisites

There are some assumptions here that the reader has knowledge of most of the AWS security services and working knowledge of the AWS CLI (version 2). Additionally, the following technical prerequisites need to be met:

1. AWS Organization setup with All Features enabled or able to be enabled
2. A user account/role with Administrative access to your Management account (this is the account you have or will have your AWS Organization deployed in).
3. An AWS Account deployed in your AWS Organization you have set aside for a Security Operations Center (not a requirement in this blog post, but required in upcoming posts).

Getting Started with CloudShell

All our configurations will done with the AWS CloudShell. As stated in the prerequisites you should already have logged in with an Admin permissions. I am sure if least privileges are a top concern, you could create a permission set to do exactly everything I describe below; however, for brevity and since this is a setup, just ensure the AWS Managed Policy AdministratorAccess is attached to the role/user you are using. Once that is verified, you can access the CloudShell and start your configurations.

Accessing the CloudShell

Within the AWS web console at the top of the page located right of the search menu is the AWS CloudShell account. Click on it to open the CloudShell and give it time to start up. Also, if your first time take note of the great features you get with your CloudShell.

AWS CloudShell comes with many pre-installed tools for you to use immediately. You can leverage AWS CLI v2, python, node.js, and even PowerShell (pwsh) is installed though not mentioned in the Welcome dialog box as referenced below.

Note: With both Python and PowerShell you will need to install the specific AWS tools needed to access the AWS API. The CloudShell session is a regional service so ensure that you are logged into the right region prior to starting your CloudShell session.

This part is important: To avoid the frustration of having your commands not work, I recommend update your CloudShell environment to latest version of AWS CLI v2. By default, CloudShell comes with AWS CLI v2 but from my experience, it was not updated to latest and was missing some of the commands we will be doing our in our setup. To avoid this, I created as simple one-liner pulled in from a github repo I have:

curl -fsS https://raw.githubusercontent.com/grolston/AwsCloudShell/main/update.sh | bash

If you want to view the extremely simple update, you can check out the project or even contribute: https://github.com/grolston/awscloudshell

The missing CLI options were noticed when configuring AWS Security Hub. AWS may have fixed this issue by updating their image they are using for the CloudShell; however, running the update can’t hurt.

When running the update you may see the version change as such:

AWS Organizations CLI

With the CloudShell you don’t need to worry about configuring the AWS CLI v2 setting a profile. It is all set and ready to go for the commands. Try it out by running a read-only command to check your configurations for your AWS Organization:

aws organizations describe-organization

Running the command will output something similar to the following:

In describing your AWS Organization, you should look for FeatureSet: “ALL” being set. AWS Organizations can be configured for Consolidated Billing or All Features. You need to enable All Features on your AWS Organization to allow you to configure the AWS Organization integrated security services we plan to use in this guide.

Important: If you already have accounts in your AWS Organization and All Features is not enabled, you should review each account in your organization. When you enable All Features on an AWS Organization with pre-existing accounts, any account that joined the Organization will receive an email notification asking to approve the All Features. Until all joined accounts approve the All Features, you cannot leverage these services nor add any transferred accounts. Thus it is important when setting up any new AWS Organization, enable All Features immediately. I say this from experience of managing many AWS Organizations over time. If a group within your AWS Organization has concerns about enabling All Features, you may want to migrate them out to a new AWS Organizations so the rest can gain the additional security features we are discussing here.

If you notice that your AWS Organization does not have all features enabled and maybe you just missed it, you can correct this by simply running the enable command (please note my aforementioned warning about enabling all features with an Organization that has pre-existing accounts and reference All Features docs.

aws organizations enable-all-features

If you are reading this and have not even created your AWS Organization, you can save yourself some hassle and just run this command from the CloudShell:

aws organizations create-organization --feature-set ALL

Running the command will produce similar output:

After creation of your AWS Organization make sure to verify your root email address when the organization is created. This one command will create the organization and enable all features. The account which you create the organization in identifies the account as the “Management Account”.

Security and the AWS Management Account

The account which you create your AWS Organization in is known as the management account. This account is also known as the master payer AWS account, payer account, or the root AWS account. The scope of this account has evolved over time from a simple AWS used to organize and consolidate billing into the Management account we know it as today. The account you select as the AWS Management account is important as it can’t be switched unless you remove the AWS Organization and even doing that it is a horrible time. The AWS Management account is the only account that can delegate AWS Organization integrated services, deploy AWS Control Tower, created new AWS accounts (linked accounts), deploy Organizational CloudFormation StackSets, create and enforce policies, deploy AWS org trails, deploy/manage AWS SSO, etc.

The Management account is also unique in the fact that AWS Service Control policies cannot be enforced on it and Organization CloudFormation stack sets cannot be deployed to it even when targeting the root OU. The AWS account is basically set apart from the rest of the organization regarding management and guardrails.

Taking all that into consideration, the AWS account should not have any end-user workloads or even compute workloads deployed to it. You should isolate your AWS Management account as much as possible and delegate every AWS Organization service to a separate account when you can. DO NOT RUN ALL YOUR AWS SECURITY SERVICES FROM THE MANAGEMENT ACCOUNT. ONLY RUN FROM THE MANAGEMENT ACCOUNT WHAT YOU ABSOLUTELY HAVE TO AND FOLLOW STRICT LEAST PRIVILEGE ROLE CREATION.

Organization Service Configuration

With All Features enabled on your AWS Organization it is time to start configuring our security services. What we will be looking at is deploying some of the core security services most enterprises should leverage. I can’t cover all the services; however, I will add additional blog posts as new services come up or requests are made to me (open an issue at the GitHub repo). For the last portion of this blog post I will cover reviewing AWS Organization Services and enabling AWS Organization CloudFormation StackSets.

Reviewing Configured AWS Organization Services

To see what services that are already configured for your AWS Organization you can run the following command in the AWS CloudShell in your Management account.

aws organizations list-aws-service-access-for-organization

Running the command will produce similar output:

As you can see from the screenshot my AWS Organization does not have any AWS Organization services setup yet though we have completed the prerequisite of enabling All Features on the AWS Organization. Let’s change that by enabling AWS Organization CloudFormation StackSets.

AWS Organizations CloudFormation StackSets

Enabling AWS Organization CloudFormation StackSets is not necessarily a security tool; however, in my opinion, you cannot effectively manage your security of a large organization without it. AWS Organizations CloudFormation StackSets enables automated provisioning of CloudFormation templates to OU targeted accounts working across accounts and regions. Even a newly created account within a targeted OU will automatically have the template provisioned to it without any user intervention. Deleted or moved accounts immediately have the CloudFormation stacks removed from their AWS accounts (no user interaction!).

To enable CloudFormation StackSets for AWS Organizations you need to use the AWS CloudFormation StackSet web console and not the AWS CloudShell. You could do this via the AWS Organizations web console under the setting, but again it is recommended by AWS at the time to do it in the AWS CloudFormation StackSet web console ( ref. Integrate Trusted Access CloudFormation ).

Within your Management account after enabling AWS Organizations All Features you will need to go to the CloudFormation web console and then go into the StackSets page.

With the StackSets page open you will see an informational dialog box to click “Enable trusted access”. Note that you have to be in the AWS account which you created the AWS Organization in (aka the Management account). Simply click on the “Enable trusted access” button is the last step and you are greeted with success

If you would like you can even bounce back into the AWS CloudShell and run the aws organizations list-aws-service-access-for-organization command to view if the AWS Organizations Trusted service is deployed:

What’s Next?

In the Part Two we will enable AWS AWS Guard Duty and AWS Security Hub to be automatically deployed to all existing and new AWS Accounts within your Organization. Each account will report their findings into our SOC AWS Account enabling and ensuring all accounts have the security services up and running.

Read the next blog post: Configuring Security Services with AWS Organizations – Part 2 AWS GuardDuty