What we learned about cloud security running a SaaS in AWS for 5 years - Part 6 - Access Security

This is Part 6 of a multi-part series of posts on how we securely ran ThreatSim in AWS for 5 years and did right by our customers. Some of the controls described are common sense and others are a bit more unique.

In this post, we focused on how we secured access into our AWS services. The lowest-level of access into AWS, we think, is via IAM keys. We looked at a few well known breaches where AWS-specific factors played a part in the event. In many cases the attacker was able to gain access to IAM keys that were then leveraged to gain additional access to other AWS resources or were used to nuke the victim's entire infrastructure. This is the AWS version of someone compromising the admin console to your hosting account or hypervisor.

With that in mind, we looked at controls we could implement that didn't drive our Ops folks crazy but kept our account secure.

MFA Authentication Into Environment

Description: Ensure that all remote access requires MFA.

Why it's important: Ensure that all remote access that leads to the AWS environment requires multi-factor authentication. For example, if access is restricted to the corporate IP space, ensure that the corporate VPN requires MFA.

IP Restrictions

Description: Restrict jumpbox and API key access to specific IP addresses.

Why it's important: Allow SSH or RDP access to a jumpbox from approved IP ranges. Do not allow administrative access from personal or home IP addresses. For example, force all access to use a VPN so that access to your infrastructure is only permitted from an approved IP address.

Authentication Controls

Description: Any network access method (e.g. VPN) should be protected against authentication attacks.

Why It's Important: Ensure that the VPN or other remote access method uses authentication controls such as account lockout, password length and complexity requirements, etc. For example, the VPN could authenticate via LDAP or active directory so that AD controls would protect the accounts.

Separate Network Access Channel

Description: Do not grant trust to IP ranges with disparate user populations.

Why It's Important: Often, organizations will whitelist a single IP address into their AWS environment (e.g. SSH to a jumpbox or via IAM Policies in the case of API keys). The risk with this approach is that if all users originate from the same IP address, inherently the same level of trust is then extended to all users originating from the NAT IP address. An attacker that compromises any device or network within the corporate network and AWS API keys may be able to successfully attack the AWS environment. As such, the organization should establish a separate network access path (and thus, separate egress IP address for AWS access). This approach can be accomplished by requiring all AWS access originate from a VPN device that is dedicated to operations and security personnel.

S3 Bucket Policies

Description: Apply S3 bucket policies that restrict access by IP address to sensitive S3 buckets.

Why It's Important: S3 buckets that serve static assets (e.g. JS, CSS, images, etc.) are a highly critical part of many web applications. An attacker that is able to compromise an organization's S3 bucket may be able to launch several attacks against users of the application. For example, if an attacker modifies JS files within an S3 bucket, it may be possible to launch an XSS attack. As such, S3 buckets should have policies applied that limit changes to approved IP address ranges.

Given the large number of data breaches that are the result of S3 bucket permissions, we highly suggest that organizations regularly identify all exposed buckets and monitor those buckets for permission changes. This can be accomplished with commercial tools as well as home-grown scripts.

Previous Post: Part 5 - EC2 Instance Security