For Software as a Service (SaaS) companies operating in Amazon Web Services’ (AWS) cloud environment, there are a number of AWS best practices that should be considered in order to improve security and meet certain SOC 2 trust services criteria (TSC). When Schneider Downs performs a SOC 2 examination, we typically look for the following controls and configurations to be in place:
- Use Multifactor Authentication (MFA) for the Root User Account – The root account is the most privileged user in an AWS environment. With MFA enabled, a user signing in to an AWS website via the root account will be prompted for the account password as well as for the authentication code they’ll receive on their AWS MFA device. For stronger security, it’s recommended that a hard token device be used rather than a soft one (e.g., authenticator on a mobile device). AWS supports both methods.
- Store the Root User Account Password in a Secured Password Vault – Due to the critical nature of this password, there should be at least two highly privileged users who have knowledge of it. Since the password is shared, it should be stored in a secured vault so that its usage can be tracked. If someone with knowledge of the password leaves the organization, the password should be changed.
- Use MFA for all Identity Access Management (IAM) Users who have Console Access – Enabling MFA provides increased security for console access, since it requires the user to have both knowledge of a credential and possess a device that emits a time-sensitive key. Depending on the number of users, it could become problematic if hard tokens are used for MFA, since those devices may frequently be misplaced. If you’ve configured AWS to use single sign-on through another service, such as G Suite, ensure that MFA is turned on for the authentication service you’re using.
- Only Use the Root User Account when the Root User is the Only User Who Can Perform the Action – The root account should only be used for specific actions, a list of which can be found here at https://docs.aws.amazon.com/general/latest/gr/aws_tasks-that-require-root.html.
- Configure Strong IAM Password Policies – Complexity (use of upper and lowercase letters, numbers and symbols), minimum length, password expiration and prevention of password reuse should all be enforced. Some requirements – including minimum length – can be relaxed depending on the use of MFA. If MFA is in use and minimum length is set to a minimum of 14 characters, for instance, complexity, password expiration and password reuse restrictions do not have to be enforced. As with above, if you’ve configured AWS to use single sign-on through another service, ensure that appropriate password controls are set for the authentication service you’re using.
- Use Groups to Assign Permissions to IAM Users – Groups like Admin, Developers, Read-Only and Test should be created, with specific unique permissions. Once these groups are established, IAM users should be assigned appropriately, based on the principle of least privilege.
- Use Security Groups to Restrict Traffic Flow to your Virtual Private Cloud (VPC) – A security group acts as a virtual firewall. For each group, one set of rules controls inbound traffic to instances, while a separate set controls outbound traffic. After creating a security group, ensure you change the default rules.
- Monitor CloudTrail Log Files with CloudWatch Logs – Several CloudTrail events should be monitored. CloudWatch alarms can be configured to alert appropriate personnel when specific activity occurs. Examples of events that should be monitored include S3 API calls made to bucket policies; deletion of an S3 bucket; security group configuration changes; network gateway changes; VPC changes; creating, terminating, starting, stopping or rebooting an Elastic Computing (EC2) instance; creating, updating or deleting a CloudTrail trail; stopping CloudTrail; AWS Console sign-in failures; unauthorized API calls; IAM policy changes; root account logins; and any AWS Console sign-in without MFA.
- Protect CloudTrail Logs – CloudTrail logs should be stored in a dedicated and centralized S3 bucket, where strict security controls access and segregation of duties can be enforced. Only authorized users should have access. The bucket should be configured to require MFA to delete.
- Use Correct Policies and Ensure S3 Buckets are not Publicly Accessible – Unless explicitly required for anyone on the internet to be able to read or write to them, S3 buckets should not be public.
- Run AWS Trusted Advisor on a Regular Basis – Trusted Advisor performs best practice checks and recommendations across five categories: cost optimization, security, fault tolerance, performance and service limits. Running this tool on a regular basis, documenting the review of the results, and making changes as necessary will show your auditor that you have a process in place to monitor for vulnerabilities.
- Use Amazon Machine Images (AMI) – An AMI provides the information required to launch an instance. This is essentially equivalent to creating a server-hardening standard. When a new EC2 instance is launched, an AMI can be specified to ensure the instance has the appropriate configurations in place.
- Deploy Critical Application Components across Multiple Availability Zones and Replicate Data and AMIs – Amazon EC2 is hosted in multiple locations worldwide and is composed of Regions and Availability Zones. Resources are not replicated across Regions unless configured otherwise. Although rare, failures can occur that affect the availability of instances that are in the same location. If all instances are hosted in a single location that’s affected by a failure, none of the instances would be available.
- Keep AWS Account Owner Contact Details Up to Date and Map Contact Information to Multiple Individuals – This ensures that important communications from AWS, such as breaches of the Acceptable Use Policy and security breaches, are communicated to multiple members of your organization and not overlooked.
