Conducting a Cloud Assessment in AWS


Heceta Head Lighthouse (2019)

I’ve been engaged in a lot of merger & acquisition (M&A) activity over the past year. One of the things that entails is understanding how organizations are using AWS, what controls they have in place and how they are using AWS’s security features.

This a general list of things you want to look at when evaluating an AWS environment for the first time.

Security & Governance Tooling

  • Is CloudTrail enabled?
    • is it configured for all AWS Regions?
    • Does it have File Validation enabled?
  • Where do CloudTrail events get written?
    • When events are written to an S3 Bucket outside the account, it is much harder to destroy evidence during an account compromise.
  • Are they using GuardDuty?
    • How do they monitor their events?
    • Master/Member configured?
    • Are there any serious findings you should bring to their attention?
      • such as EC2 Credential ex-filtration or systems regularly calling out to C2 DNS
IAM Access Analyzer

This service is new, so it may not be enabled. However it is very useful for finding public resources.

  • What is public?
  • What other AWS accounts have the ability to assumeRole into this account. Why?

Access Analyzer currently only supports:

  • IAM Roles
  • SQS Queues
  • S3 Buckets
  • KMS Keys
  • Lambda functions
  • Lambda layers


Account Contacts

Key here is making sure when AWS Abuse has an important notice around abuse or account compromise they can reach somebody.

  • Who gets root notices?
    • Is the root email address a person or a group of people?
  • Is the Security Alternate Contact set?
  • Are there any notices from AWS Abuse in the support console?
  • How do users login to their account?
    • Options here are IAM Users, Federated Users, IAM Identity account and cross-account roles.
  • Is IAM User MFA in use widely or not at all?
  • How old are the access keys? Are old access keys being used?
  • Does access advisor indicate the IAM Users have recent activity?
  • Are all the IAM Users admins, or do they attempt some level of least privilege?

The AWS Credential Report is a good place to download this data for sorting.


One of the best ways to determine what services an account (or an organization) uses is to review their AWS Bill.

  • What is the monthly spend.
    • Is it reasonably predictable?
    • Are there any unexplained spikes?
  • What services do they use
    • EC2, ECS, Lambda, WorkSpaces, etc?
  • Reviewing the AWS bill is also an opportunity to find waste.
    • Do they have multiple CloudTrails?
    • Lots of unattached EBS Volumes?
  • What is the oldest EC2 Instance (based on LaunchDate)? Ask if that machine is still needed?
  • Do they have a large number of un-attached Launch Wizard security groups?
    • Launch Wizard is an indication that lots of systems are deployed by hand via the console rather than via CloudFormation or Terraform?
    • Launch Wizard security groups also default to being open to the world (shakes fist at AWS!!!!), so they should be reconfigured if open to the world.
  • Look at CloudFormation, do they use it for deploying code?
  • Look at the Tag Editor, do they have a consistent tagging standard, or are they attempting to have one?
  • What AWS Regions do charges show up in?
    • Are there charges in regions that they normally don’t do business in?

Most organizations have multiple AWS accounts. The assessment should understand how these accounts are managed

  • What’s their multi-account strategy?
  • Do they leverage AWS Organizations?
    • Do they have SCPs?
    • How are new accounts created?
      • Are new accounts created by signing up with AWS then added to the organization, or is Organizations used to create an account (the difference between JOINED and CREATED)?

Big Gaping Security Holes

When doing an assessment, you want to identity any of these Big Gaping Security Holes that might exist in the environment.

  • Is root MFA enabled?
  • So root Access Keys exist?
  • Any Public S3 Buckets?
  • Look in Trusted Advisor for:
    • publicly AMIs
    • publicly shared EBS Snapshots
    • security groups exposing 22 or 3389 to the world
  • Make sure no ElasticSearch clusters are open to the world.

(This is not an exhaustive list, and I’ll be adding more to it as I end up doing more assessments, or learn about other things that need to be looked into)