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.
AWS native tooling for securing your environment
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
How to audit an AWS 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.
1. Generate and maintain a complete list of assets
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.
How to create an asset inventory
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.
2. Secure IAM
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.
Identity and Access Management (IAM) basics
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.
3. Find public resources
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
- SNS topics
- 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!
4. Use AWS Organizations
Recommended AWS Organizations structure
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
- Production OU, Pre-Production OU, Build OU, Development OU
5. Ensure audit logs are enabled
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.
AWS Audit Logging basics
- 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.
How to turn on Global CloudTrail via CLI
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.
Lock down your cloud security skills
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.
6. Turn on security controls
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.
7. Build data flow diagrams and network maps if none exist
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.
8. Pick a standard
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.
9. Build a risk register to track findings
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:
|ID||Dedicated identifier of the finding|
|Priority||Indicator of criticality|
|Description||What is the risk?|
|Likelihood||Probability this scenario will occur|
|Impact||Consequences of the occurrence|
|Response Type||Accept, Transfer, Mitigate, Avoid|
|Response Description||What can be done to resolve or mitigate the risk?|
|Owner||Who is responsible?|
|Status||The current status of this risk|
Risk registers should drive remediation issues and stories.
How to secure an AWS account
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)
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
Recommended minimum 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
Example Service Control Policies
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/
Improving security of AWS environments
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?
Or, for the month of August, check out the following free courses, all free as part of ACG’s free courses line-up:
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.