How to audit and secure an AWS account

Data leakage and exposed credentials: these are just a couple of the cloud security concerns that keep cybersecurity pros up at night, ​​according to Statista. Scary stuff indeed. That’s why investing the time in properly auditing and securing cloud environments should remain a top priority for any organization that values its continued existence. In this post, we'll talk about how to audit and secure an AWS account

But where do you start when it comes to securing your AWS account?

There are a few fundamental questions we can begin with, the answers to which we’ll cover in this blog post:

• How can we audit the AWS account?

• How can we secure the AWS account?

• What AWS-native tools are in our toolbox?

The following tips and insights are courtesy of security engineer extraordinaire Don Magee. Don is a cat lover, a veteran cloud architect with 20+ years IT experience, and the Cloud Security Lead at Stedi, a 100% remote, fully serverless B2B SaaS provider. 

This content is based on our Securing Your AWS Environment ACG webinar. Any mistakes are on the part of the editor.

Much of what you need to do to secure an AWS account can be done with the AWS-native tools at your disposal. 

What follows isn’t a comprehensive list, but these are some AWS-native tools Don finds most impactful in his work at Stedi. We’ll talk about some of these tools in greater detail below.

• Account and Organizations — This provides the strongest blast radius to limit the impact of a security event.

• Access and Identity Management (IAM) — Managed access to services and resources with roles, policies, and users

• Logging — Cloudtrail, S3 access logs, flow logs, CloudWatch logs

• Infrastructure and Data Protection — VPC, Shield, WAF, Network Firewall, Macie, KMS, Certificate Manager, Secrets Manager

• Security assessment, incident response, data protection, and threat detection — GuardDuty, Inspector, Confi, Detective, Artifact, Security Hub 

12 AWS Config rules every account should have
In this blog post, see the AWS Config rules that should be considered a bare minimum requirement for any account.

As we dig into how audit and secure an AWS account, let's start with auditing. Auditing an AWS account lets you review IAM users, roles, groups, and policies and see if there are any users or tools that have excessive permissions.

Auditing is crucial because you can’t secure what you’re not tracking. An audit is one of the most basic tools for securing an AWS account, but most of security is doing the basic things. (But, of course, the basic things can be hard.)

The things below are all accessible from day one in your environment.

What is an asset? In the AWS space, an asset is anything that has an identifier. This could be policies, roles, and servers. We need to have a list of these. Once we have a list, then we can start figuring out what these things do, how we can protect these resources, and if any of them are misconfigured.

There are different ways to build an asset inventory. You could use third-party tools or CLI scripts, but there’s a quick and easy way: AWS Config. AWS Config lets you record and assess the configurations of your AWS resources.

Check out this post for more details on creating an asset inventory with AWS Config and the 12 AWS Config rules every account should have.

As part of auditing, take a look at IAM. IAM is often over-privileged, so we want to make sure we have a solid strategy on how we’re going to tackle that.

Similar to resources, users and roles are quite often over-privileged. Here are some basic considerations you should consider taking as a bare minimum:

• Ensure you have password requirements configured.
• Enforce MFA for all users … especially the root account!
• Speaking off… STOP using the root account. It has no useful function that you can’t do with an actual IAM user or role — with the exception of setting the billing plan and changing its own address. 
• Use Access Analyzer to look for unintended access. You might see roles that have the ability to be assumed by outside entities, which you might not want...especially if it’s an account you don’t recognize.
• Limit the use of IAM users as much as possible. They bring with them extra risk.
• Use AWS SSO for human access. And build job-specific roles for humans to assume. It makes life way easier for developers. 
• Give your users access based on the job role, not the person.
• Disable any role that hasn’t been used in 90 days or more. If no one complains in another 90, delete it.
• Leverage open-source/third-party tools for IAM analysis.

Learn how to fix 5 common AWS IAM errors
AWS IAM errors are common. Don’t sweat it! In this blog post, we dig into the cause and resolution for 5 common AWS IAM errors.

Once you have a list of assets and have done a once-over on IAM, you need to start tackling public resources. 

These are anything we’ve identified as public and are therefore points of risk. These can include S3, EBS snapshots, SNS, Databases, and more.

We see things like S3 misconfigurations, but there are other things that may be public that are dangerous but overlooked. For example, sometimes people take snapshots of servers and accidentally configure those to be public. We need to check these things!

Publicly available resources can cause data exfiltration, data loss, and unintended access to accounts and services. (Those are bad.) That’s why we need to identify publicly available resources. 

Common resources that are unintentionally public include:

• S3 buckets or objects 
• Snapshots
• SNS topics
• Databases
• EC2 instances

“I’m going to make a very unpopular statement: there is no good reason that an S3 bucket should ever be public,” Don said. “No one has ever given me a good reason.”

To find public resources, you can use open-source tools, third-party tools, or AWS Config. But you have to go remediate them.

Here are some quick and easy wins you can do right out of the box. These are Don’s bare minimum to start with:

• Enable S3 Public Access block on the account level
• Turn on GuardDuty
• Use AWS Firewall Manager to apply common IP security rules to all VPCs
• Leverage managed config rules, but don’t be afraid to write your own!

AWS Organizations is an area that is one of the most underrated things you can do for security. This is one of the most powerful tools in your security toolbox. 

The account is the border. You have to allow things in and out of the account. You can’t say that with anything else that you have in AWS. Even with VPCs, you have to take extra steps to make it more secure than it is out of the box. With an account, by default, nothing comes in or out unless you allow it. 

We use these as service accounts for specific pieces of our tech stack. Each team or service has an account. 

• Root / Management Account — hosts the Organization
  • Production OU, Pre-Production OU, Build OU, Development OU
    • Each has one account per service or service
  • Operations OU
    • Corp systems accounts (billing, internal IT, etc.)
    • DNS account — delegates subdomains to other accounts
  • Security OU
    • Security account — owner of all security tools (GuardDuty, SIEM, Config, etc.)
    • Logging account — source of truth for all logs used by security
  • Suspended OU
    • This is where we keep closed or unused accounts
    • Has SCP to prevent any action from being taken

Securing Your AWS Environment
In this free, on-demand webinar, get a breakdown of taking complex AWS environments from zero to secure and see how to audit and secure an AWS account.

Next, we have to have audit logs. Audit logs are critical for detection of notable events and help you understand what has happened after an event.

CloudTrail is basically the auto-log of every action that takes place in AWS for the most part. But there are other services too that — depending on your workloads — you might want to consider, including VPC Flow Logs if you’re using servers or S3 access logs if you’re using buckets publicly.

• Ensure CloudTrail is enabled and storing logs in S3.
  • The S3 bucket should have highly restricted access
  • Best practice is to store all logs in a dedicated account
  • If using AWS Organizations, turn on Global CloudTrail
• Other logs of note are S3 Access logs, CloudWatch logs, WAF logs, and VPC Flow Logs
• Logs are nearly useless without SIEM tooling.
• Only store longs as long as they are useful.

CloudTrail can get expensive fairly quickly, especially if you’re storing in S3. You need to keep just exactly what you need. But you need it. If you don’t have CloudTrail turned on, you don’t have means to detect incidents.

Create an S3 bucket to store the logs, and ensure the bucket is locked down as much as possible. Then, enable Global CloudTrail via CLI:

• aws organizations enable-all-features
• aws organizations enable-aws-service-access --service-principal cloudtrail.amazonaws.com
• aws cloudtrail create-trail --name my-trail --s3-bucket-name my-bucket --is-organization-trail —is-multi-region-trail

If using a SIEM, configure the S3 bucket and the SIEM to consume the logs.

Learn faster. Move faster. Get started with ACG and transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

Turn on those native tools that align, if applicable, such as Guard Duty and Inspector.

Guard Duty is always good to have on, but if you’re running EC2 instances and you don’t have a strong vulnerability management program, you might want to turn on Inspector to look for patches that are missing and things of that nature.

We want to have data flow diagrams of everything. If you don’t know how a developer is using the system, you don’t know what you can do. This can help make decisions such as blocking S3 public access.

Security shouldn’t be made up as you go along. You shouldn't come into an issue and just decide to implement a rule. As part of your efforts to audit and secure your AWS account, you need guideposts. And that’s what standards are for.

Don recommends NIST CSF/800-53, CIS, or CCM. But keep in mind: these shouldn’t be rules. You should use them to inform your decision making.

Risks themselves have to be tracked, just like assets. We don’t want to be playing whack-a-mole. Building a risk register ensures that we’re not fire-fighting but fire-preventing.

A risk register can be as simple as a spreadsheet and at a minimum should track the following:

Risk registers should drive remediation issues and stories.

Next, let’s pivot to applying some of these concepts in ways similar to Don’s approach at Stedi.

• Use Infrastructure as Code for all deployments
• Turn on Default EBS Encryption
• Turn on S3 public access block on the account level
• Require IMDSv2 for EC2 instances
• Use AWS Organizations
• Leverage Service Control Policies
  • Enforce the “do nots” and the “must nots”
  • Protect critical assets 
  • Keep these light
• Use AWS SSO over IAM users
• Use job-based roles
• Alert on critical account access

This is an example of some of the things touched on above and how to do them in CloudFormation:

S3AccountPublicAccessBlock:
    Type: "Community::S3::PublicAccessBlock"
       Properties:
      BlockPublicAcls: true
      BlockPublicPolicy: true
      IgnorePublicAcls: true
      RestrictPublicBuckets: true
  EbsEncryptionDefaults:
    Type: "Community::Organizations::EbsEncryptionDefaults"
    Properties:
      EnableEbsEncryptionByDefault: true
IMDSv2LaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
      Properties:
      LaunchTemplateName: IMDSV2
      LaunchTemplateData:
        MetadataOptions:
          HttpEndpoint: enabled
          HttpPutResponseHopLimit: 1
          HttpTokens: required

Service Control Policies (SCP) allow you to apply restrictive policies to accounts. These can be applied on the root level or at the OU level. The root account is immune to SCPs

• Deny root users access
• Require the use of IMDSv2
• Deny ability to create IAM access keys
• Deny ability to leave Organization
• Deny ability to disrupt GuardDuty or prevent GuardDuty from being disable
• Deny the ability to disable S3 public access block
• Deny the ability to disable EBS default encryption
• Deny the ability to disable AWS Config

• Disable unused regions
• Require tags on resources
• Prevent the deletion of databases, S3 buckets, or other sensitive items in production

The example SCP below prevents the root account from taking almost all actions. Don recommends applying this all child accounts and creating an alarm that triggers when removed. 

DenyRootUserSCP:
    Type: OC::ORG::ServiceControlPolicy
    Properties:
      PolicyName: DenyRootUser
      Description: Deny using the root account
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Sid: DenyRootUser
            Effect: Deny
            Action: "*"
            Resource: "*"
            Condition:
              StringLike:
                "aws:PrincipalArn": "arn:aws:iam::*:root"

A great list of SCPs can be found at https://asecure.cloud/p/scp_package/

Beyond the steps above around how to audit and secure an AWS account, one of the biggest things an organization can do going forward is to shift security left by empowering developers. You can read more about that here.

Want to learn more about securing your cloud environment? 

ACG has you covered with the essentials you need to secure AWS, Azure, and GCP environments. Check out our Mastering the AWS Well-Architected Framework course.

Or, for the month of August, check out the following free courses, all free as part of ACG’s free courses line-up:

• AWS Security Essentials
• Google Cloud Security Essentials
• Microsoft Azure Security Essentials

Looking for more in-depth security training? Check out ACG’s AWS Security learning path and level up your skills, whether you’re a total novice or a security guru.

Watch: What Leaders Need To Know About Cloud Security
Is your business safe in the cloud? The answer is largely up to you. Watch this free on-demand webinar with Mark Nunnikhoven as he tackles the keys to cloud security that sticks.