Stand Your Cloud: A Series on Securing AWS

This blog post is the first in an ongoing series about AWS security best practices.

Amazon Web Services (AWS) is arguably the most popular cloud computing platform. With the platform’s recent reduced pricing and added features, moving infrastructure to AWS is now more attractive for businesses and consumers looking to lower cost and maintenance while improving productivity.

Interested in migrating to AWS as well? That’s a great idea, but you need a strong security foundation first.

This series will discuss several recommendations for securing AWS. In this first blog post, we will cover how to minimize security risk and data loss.

Hardened IAM Policies

Identity and Access Management (IAM) enables system administrators to securely control services and resources for users. Properly configured IAM policies and permissions are important since these can affect the entire AWS infrastructure’s security posture.

Using IAM, system administrators can create granular permissions and assign them to specific roles and groups. System administrators can then follow the principle of least privilege when provisioning user access and reduce the attack surface in the event of an account compromise.

Implementing a strong password policy requires users to comply with industry security standards. It further reduces vulnerability and enhances the AWS infrastructure’s overall security. A strong password policy would entail using passwords with a minimum 10-character length and rotating keys on a 90-day cycle.

The IAM policy does not, though, apply to the AWS root account password. Therefore, ensure the root account is set up with the highest level of security and forgo using the root account for day-to-day interaction with AWS.

Another aspect to keep in mind is that passwords are a relatively outdated security authentication form and cannot sufficiently protect against more sophisticated cyberattacks. Thus, it is extremely important that all user accounts — especially AWS root accounts — enable multi-factor authentication as an extra level of protection. MFA can be implemented in various AWS services and can prevent unauthorized account access, AWS command line execution, and API (application program interface) calls. Many well-known security breaches could have been mitigated if the targeted organizations had used MFA.

Firewalls

Security groups are virtual firewalls that control the inbound and outbound network traffic of EC2 instances or virtual private clouds (VPCs). Consider the following guidelines when implementing security groups:

• Use caution with multiple security groups. You can apply multiple security groups to a single EC2 instance or apply a single security group to multiple EC2 instances. System administrators often make changes to the state of the ports; however, when multiple security groups are applied to one instance, there is a higher change of overlapping security rules. For example, security group A opened port 80 to the entire Internet. Meanwhile, security group B opened port 80 to one IP address. If you assign these two security groups to an EC2 instance and modify either, issues may occur. If you remove port 80 rules from security group A, security group B still has port 80 open. It’s easier to find these mistakes when there is a small number of EC2 instance or security groups. A larger number makes finding mistakes more difficult
• Complexity is the enemy of security. Keeping the number of security groups low can help to reduce the work required to maintain them. We have encountered situations in which an excess number of security groups have led to overlapping rules on instances, resulting in exposed services. As a result, effective management was difficult (to say the least).
• Ingress (inbound) security rules help prevent unauthorized incoming traffic from reaching your EC2 instance. But what about unauthorized outgoing traffic? We typically find ingress security rules implemented in the AWS environment – but we don’t typically see egress (outbound) rules being enforced. Egress security rules prevent compromised servers from leaking data out of the network or pivoting to servers within the network.

Backups

The Code Spaces compromise demonstrated the importance of a proper secure backup solution. AWS offers the Simple Storage Service (S3) that system administrators can use to securely store objects in the cloud. With S3, users can also set up MFA and server-side encryption to safeguard against unauthorized file access.

We recommend requiring MFA on critical S3 operations and storing the data with server-side encryption that includes a strong encryption key. The backup can be downloaded to a local file storage solution as another layer of protection. Additionally, S3’s lifecycle feature can retain backup data in Amazon Glacier — at a fairly low price. This will offer redundancy and it’s an essential for keeping your business running both effectively and securely.

Conclusion

Hardened IAM policies, security group management, and a secure backup solution are the three key aspects system administrators should focus on when managing their AWS infrastructure. By focusing on these, security risk and data loss can be kept to a minimum.

In the next post, we’ll discuss how to harden EC2 instances during deployment.

Questions or comments? Talk with us on Twitter.

You can read the second part of this series here.

Our recommendations should not be considered comprehensive; rather, they are meant to address common mistakes that system administrators need to avoid when deploying infrastructure to AWS. For a comprehensive list of security best practices, check out this Amazon whitepaper.