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

This is Part 2 of a multi-part series of posts on how we securely ran ThreatSim in AWS for 5 years and never lost a customer (that we know of) due to any cloud security concerns.

In a traditional data center there are controls to prevent someone from turning off and walking out with your servers. Locks on doors, a cage, guards, lack of a dolly or crash cart, etc. In Amazon, these controls are assumed to exist but that is of little importance really. What matters is how you protect your organization's AWS account and the data within it. Different security controls are needed here.

Whenever an epic and cataclysmic cloud security incident happened, we always tried to understand what went wrong, look at our setup, and determined if we were exposed to the same vulnerability. If we were, we made adjustments. Here are some practical, detailed steps you should be doing to secure your AWS accounts:

AWS Account Security

Account Contact Phone Security
Description: Use a phone number that rings to a secure phone number.
Why it's important: Sensitive AWS account actions (e.g. Disabling MFA) require AWS support to contact the primary account owner via the phone number configured in the account. As such, the phone number used on the account should be secure. Insecure phone numbers include cloud-based VOIP and mobile numbers. VOIP numbers are vulnerable to compromise (attacker simply needs the account's SIP credentials to register) and mobile numbers have proven to be insecure and vulnerable to social engineering attacks against the mobile carrier.

Account Security Challenge Questions

Description: The account is configured with security challenge questions that are non-obvious. For example, the answer should be comprised of made of words that an attacker can not easily guess.

Why it's important: Application security questions are often comprised of information that is easy to guess, public, or easy to enumerate. As such, the AWS security questions should be stored with the same care and security as the root account credentials. For example if the security question is "What was the name of your first pet?" A proper answer would be "ice method chicken six".

Root Account Email

Description:
The email address that is used for root account recovery is secure and protected by MFA.

Why it's important: In the event that the MFA device is lost, damaged, or otherwise unusable, AWS support will send an email with a random code to the root account's email address. If that account is not secure, an attacker may gain access to the secret code sent to that email address. In this context, the account's email address is as important as the root account credentials themselves.

Root Account Email Address

Description: The root account email is configured to an email alias and not a specific person (e.g. a shared email alias)

Why it's important: Configuring the root account to an individual's personal email address may make root account access problematic. For example, if the root account owner is unavailable when access is needed to the root account. This situation creates a single point of failure in the event that urgent access to the account is needed. Additionally, this situation may cause problems if the individual account holder leaves the organization.

Root Account Name

Description:The root account name is configured to a meaningful value.

Why it's important: Given that may organizations are required to have multiple AWS accounts, it is helpful to configure the account with a meaningful name. During the account creation process, the account is typically named after the individual setting up the account. Change the account to a meaningful name makes it easier to identify what account the user is working in. For example, name the account after the region and environment (e.g. US-Prod, US-Staging, EU-Prod, EU-Staging, etc.)

Dedicated Accounts By Trust

Description: The organization has separate AWS accounts for each environment of differing trust (e.g. US vs EU, Prod vs. Non-Prod)

Why it's important: Creating separate AWS accounts for different purposes is an easy and "free" way to compartmentalize environments so that a security incident in one account does not impact the security of the other accounts. For example, if an attacker compromises a host in a non-production (and thus less protected account) the attacker can not move laterally into the production environment. Also, given that IAM users are specific to an AWS account, this is a key security control.

Shared MFA

Description: Configure the root account with an MFA device that is shared.

Why it's important: If emergency access is needed to the root account, it is necessary that the MFA device used to protect the account is securely stored in a location that allows multiple personnel access. For example, a hardware MFA token that is stored in a secured location (e.g. safe or other strong box) in the corporate office location.

Separate Security Account

Description: Establish a separate AWS account for security-specific functions or a separate security-specific environment.

Why it's important: In the event of the cataclysmic security event within a given AWS environment, an attacker will often delete and destroy all instances, EBS volumes, snapshots, etc. As such, the organization should establish a separate AWS account whose security can be assured in the event of an incident. Using VPC peering, this Security account should contain central logging servers (e.g. ELK, Splunk, etc.), vulnerability scanning solutions, endpoint IR servers, etc.

Next post: Part 3 - Identity and Access Management