SOC 2 Controls for AWS: A Practical Security Checklist for SaaS Teams

You’re good at your job – you’ve built and designed your application on AWS with fundamental cloud security practices in mind – but when SOC 2 enters the picture, your controls don’t take credit for your hard work.

Many SaaS compliance programs are built from standard SOC 2 control templates provided by an audit firm or GRC tools that fit like a bad pair of shoes. Properly scoping AWS controls in your SOC 2 report can be intimidating at first. Companies usually overestimate the number of controls managed by AWS, and fail to implement controls to secure their infrastructure.

The recommended controls below are based on my experience helping clients improve their AWS security posture, while undergoing audits with automated evidence collection.

Who am I?

My name is AJ Dehn, and besides assessing and implementing technical AWS Security controls for hundreds of companies, I’m the author of the AWS Audit Playbook & founder of AuditOps.io – two programs dedicated to helping companies solve these problems at the intersection of compliance and security.

In addition to identifying critical risks and important controls, I’m going to tell you how you can practically address them in your AWS environment. 

Let’s look at several key areas below:

AWS IAM Key Rotation

Control Description: Acme Co rotates infrastructure service account credentials at least once per year.

Why it matters:

• Permanent Credentials: Access keys are totally separate from AWS console logins, and I’ve seen dozens of keys that are over 10 years old. These keys have identical permissions to the IAM user they are attached to, but aren’t subject to the same MFA requirements making it extremely important that you rotate them at least once per year.
• Former Team Member Access: Keys can mistakenly be stored in plaintext within your application’s environment variables. This means they could easily be written down by a former DevOps team member who may not have left on the best terms.

Implementation Guidance:

1. Download the AWS credentials report to see how many access keys are over one year old.
2. Build a rotation plan, and rotate the keys. Consider using AWS Secrets Manager to add an additional layer of security. Important: Don’t disable the old key until you are confident it’s no longer being used. Failing to do so could cause downtime, and give your team a reason to not practice this basic cyber hygiene.
3. Once you’ve confirmed the key is no longer needed, disable or delete it. Document the rotation procedure in case you need to change it quickly because of a security incident.

Automation Potential: Yes, testing for this control can be fully automated. The easiest way is to provide your share a copy of your AWS Credentials Report with your auditor.

AWS Environment Separation Best Practices

Control Description: 

• Production and non-production infrastructure are segmented from each other.

Why it matters:

• Limited Blast Radius: If your non-production AWS infrastructure is compromised, production data won’t be impacted.
• Principle of Least Privilege: Unique environments allow you to have strict access controls and permissions in production and more relaxed settings in lower environments.

Implementation Guidance:

1. The best case scenario is to maintain completely independent AWS accounts to separate your infrastructure. If that’s not possible, consider creating separate resources ( S3 buckets, EC2 instances, etc) used for production and non-prod workloads.

Automation Potential: It depends. The best way to implement this control is to have completely separate AWS accounts. It’s difficult to fully automate because I don’t recommend giving your audit team access to lower environments. Fortunately, this control should only require 1 screenshot of each environment or a few minutes of discussion on an audit walkthrough call.

AWS Asset Tagging & Inventory

Control Description: 

• An inventory of assets including databases, software applications, operating systems, and hardware is maintained in a central repository.

Why it matters:

• Lottery Test: If your lead DevOps engineer wins the lottery and never shows up for work again, could someone easily maintain your AWS environment? If not, you should consider a tagging strategy to make your environment more resilient.
• Asset Management Policy: Many clients have a policy that requires an asset inventory, but I rarely see anything beyond a list of assets. Impress your auditors and comply with your policy by actually identifying what each resource is used for.

Implementation Guidance:

1. Define your tagging standard. I recommend keeping this simple to make it easy for your team to actually implement. Here’s are the tags I recommend starting with:
   1. Owner: Identify the team responsible for the asset’s configuration. Use team names (ex. Engineering, DevOps, IT) to make it easier to maintain long term.
   2. Description: Describe what the resource is used for.
   3. Classification: Document what type of data is stored or processed by this resource (ex. Confidential, Internal, or Public).
2. Ask your team to tag your AWS resources (EC2, S3, RDS, etc). This can be done through the console or by using infrastructure as code. If you get pushback, remind them of the lottery test.

Automation Potential: Absolutely. This is one of the easiest controls to automate, and you can thank me later the next time you’re wondering what type of data is stored in your S3 buckets.

AWS WAF for SOC 2

Control Description: 

• The organization maintains a Web Application Firewall (WAF) to protect public facing web applications.

Why it matters:

• Additional Protection: WAF’s block known or suspected malicious traffic into your application. AWS has preset rules that will block common attacks (ex. SQL injection) to protect your customer’s data from compromise.
• Customer Requirements: Enterprise customers are getting more aggressive when it comes to protecting their data. Having a WAF configured demonstrates your commitment to security and makes it easier next time you’re trying to sign a large customer.

Implementation Guidance:

1. Create a new Web ACL with a basic rule set to start. At a minimum, check out the KnownBadInputsRuleSet to protect your environment based on Amazon’s research.
2. Attach the Web ACL to your staging environment (ex. Application Load Balancer, CloudFront, etc). Troubleshoot until the staging environment is working as expected.
3. Once you’ve tested in a lower environment, apply the Web ACL to your production environment and make sure to notify your team so everyone can test the change to help avoid disruption.
4. Set a recurring cadence (at least annually) to review your WAF ruleset and make updates as needed. AWS does a good job of improving their rule options, and you definitely want to take advantage of their hard work.

Automation Potential: Definitely! With the right access, auditors can get the evidence independently without having to ask you for screenshots.

Amazon GuardDuty Threat Monitoring

Control Description: 

• The production environment is monitored for suspicious or anomalous activity. Alerts are sent to the Security team for investigation, when necessary.

Why it matters:

• Ongoing Monitoring: When using GuardDuty, AWS will analyze activity in your account, and raise alerts when they find something out of the ordinary. This is the easiest way to enable deep investigations of activity in your cloud environment without needing to purchase another tool.
• Catch Problems Early: When you have GuardDuty alerts set up, you can catch suspicious activity before it becomes a costly, widespread problem.

Implementation Guidance:

1. Enable GuardDuty in all regions that you have resources. Note: Consider turning on GuardDuty in all regions even if you don’t have resources. Malicious actors may spin up resources in unused regions hoping that it goes unnoticed.
2. Setup email or Slack alerts to your security and/or DevOps team and build a process to actually review the findings. Document your investigations in JIRA tickets to make it easy to provide audit evidence down the road.

Automation Potential: 100%. GuardDuty configuration evidence can be automatically gathered while you focus on actually building your application. You still need to be prepared to share evidence of how you investigated high severity alerts.

Taking the time to customize your control description pays off when you have your first enterprise contract that actually reads your SOC 2 report. A properly scoped SOC 2 can help you win more deals, shorten sales cycles, and strengthen client relationships.

More Resources

Looking for a practical AWS SOC 2 compliance checklist with an automated implementation script to gather evidence automatically? Check out the AWS Audit Playbook, free and open source on GitHub. It is designed to help you automate AWS evidence collection for external audits and third party due diligence processes.

About the Author:

AJ Dehn is the author of the AWS Audit Playbook & founder of AuditOps.io. He is passionate about automating evidence collection to perform high quality audits. At AuditOps, he helps clients implement and maintain their environment with common sense controls. If you have any questions, or if you’re interested in a free consultation, please reach out on LinkedIn.

AuditOps and Render Compliance partner together to provide a unique and cohesive experience for AWS-native SaaS companies undergoing SOC 2, combining in-depth review, implementation, and monitoring of AWS security controls with an audit firm who understands how to use the automatically gathered evidence and incorporating applicable AWS-specific controls in the SOC 2 report.