(hopefully traveling to new places soon - Here is Bletchley Park in 2015)

AWS Organizations - Checklist for 2021

AWS , CloudSecurity , Technology

It’s 2021, time to revisit what you should do when setting up a new AWS Organization from scratch. I last visited this topic in January of 2017, but recently I needed to spawn a new org from a single account for the SECCCDC

Links will go to blog posts I’ve written or AWS announcements. If I say “(cft)", the link will take you to a CloudFormation template to automate the task. If I indicate “(sh)” there is a shell script to assist with the task.

Top things to do when setting up a new Org

  1. Create a Security Account, optionally create a logging account
    1. Create Generic Alert topics (cft) for the account and subscribe your email and mobile number
  2. Create CloudTrail bucket(s) (cft) in Security or Logging Account
  3. Enable OrgTrails (cft) to go to the bucket in the Security Account
    1. depending on volume, split your Read and Management Events
    2. depending on budget and volume, enable DataEvents into their own S3 bucket (but don’t do data events on your DataEvent bucket)
    3. Note: You cannot enable an Organization trail via CloudFormation, so you must check the box in the CloudTrail console once the OrgTrail templates are deployed.
  4. Get your events into something searchable. My choice is Splunk. See below for more on Splunk integrations in your environment.
  5. Enable Delegated Admin to your security account for:
    1. CloudFormation - see below
    2. GuardDuty (sh) - this must be done in each region
    3. IAM Access Analyzer
    4. Macie, no seriously
    5. AWS Config (sh) - more below
    6. Security Hub? (maybe - a post on this will be coming soon!)
  6. Require MFA cft in the Payer and Security Account.
  7. Deploy the AuditRole (cft) into the payer and all child accounts.
    1. Here is a CloudFormation Organization StackSet to do that!
  8. Configure GuardDuty for the Organization (sh) in the Security Account
  9. Configure GuardDuty to send Events to Slack (cft) and to send events to Splunk via HTTP Event Collector
  10. Deploy Config Recorders (cft) to all accounts and active regions in your Organization
  11. Deploy a Config Aggregator (cft) in the Security Account

There are a bunch of other things you should do if you’re a large enterprise:

  • Make sure the Security and Operational accounts are set, so AWS Abuse can reach you if necessary.
  • Enable SCPs and apply an OU structure. Enabling that is a layer of politics I cannot help you with, and AWS refuses to admit is an issue in most large organizations.
  • Set up SSO, preferably with your corporate identity provider.

AWS CloudFormation Delegated Administration

AWS released a new feature - CloudFormation StackSets delegated administration. This nifty capability allows the AWS Organization Management Account (formerly Master Account, or as I call it the Payer Account) to pick one or more AWS Accounts in the organization to have permission to push CloudFormation templates into all the accounts!. This is an epic win for centralized governance!1

For example, a year ago I ranted about much of a pain it was to deploy AWS Config, but with StackSet support in CloudFormation, and with Delegated Admin, I can now deploy a single CFT in my Security Account to ensure that AWS Config Recorders are deployed into all my child accounts.

Splunk

Like the aws-account-automation GitHub repo I have for my generic CFTs, I’m releasing a new repo for Splunk Automation CloudFormation Templates. This will have templates to:

  1. Send CloudTrail events via SQS
  2. Deploy Regional Stacks to send GuardDuty findings to Splunk via HEC
  3. Deploy a Splunk Enterprise Single Instance behind an ALB w/ ACM

AWS Config (again)

Seems like I keep coming back to this and I keep hating it. Well, not any more!

I can now push out Config Recorders via AWS StackSets and CloudFormation Trusted Access via a Delegated Admin account (like my Security Account).

I can also configure Config Aggregators to send data back to my Security Account from each account and each region.

Moreover, I can also push Config Rules via the same Org-wide stack-set capability I used for my Config Recorders.

Will I finally be able to build a cloud-native GuardRail system I can deploy with minimal fuss and with the capability to let account owners and development teams know about all their issues and auto-remediations? Perhaps.

AWS SSO

Federating identity for access to the AWS console & API is critical. In any non-personal organization IAM Users should be safe, legal, and rare.

For several years now, AWS has had a single sign on offering. Against all AWS recommendations for a payer account, it required you to create a VPC with an AWS Directory Service in the payer-account. That was a non-starter for many organizations. I tried it when I stood up AWS Control Tower about a year ago (which I never blogged about) and the experience was pretty good. The AWS CLI integration was slick and way easier than gimme-aws-creds or samlkeygen.

As we’ll probably need to stand up ClientVPN for 2022, perhaps AWS SSO is also the route we want to take for console and CLI access. Perhaps a blog post on that will be coming soon.

1 This is also an epic win for cloud-to-cloud lateral movement between accounts, so be very careful how this is implemented.