Last week, the news that Code Spaces suffered a breach that overnight put the company out of business and cost their clients untold millions reminded everyone in the IT community how devastating a major data security breach can be for our companies and clients.  At Logicworks, we manage highly available, compliant cloud infrastructure on Amazon Web Services, and in the wake of this catastrophe, we decided to publish a list of AWS security best practices.

Data Security is not binary.  Best practices are to use defense in depth and continuously evaluate what improvements can be made and how the threats are changing.  AWS, and public cloud computing in general, provide many new capabilities, but along with that come new threats and new tools to counter them.  Here are some of our recommendations to improve AWS security and build a good foundation for a secure scalable environment.

Improving Amazon Web Services Security:

1: Secure the root credentials with a strong password and multi-factor authentication. These are to be used exactly once, at the beginning of a deployment to create the IAM users that will do all further administration from that day forward.

2: Use Multi-Factor Authentication for all admin accounts.   Deny the day-to-day admin accounts the ability to modify S3 versioning policies via IAM. Naturally, it follows that you should use S3 versioning (and ideally, life-cycle management to glacier) for all critical production data.

3: AWS VPC security: Deploy everything in a VPC and place critical components that don’t need to be publicly available such as databases in private subnets with appropriate ACLs.

4: AWS EC2 security: Use roles with minimal permissions to make API calls from within EC2.  This limits the utility of a compromised instance to an attacker.

5: Use Cloudtrail to track changes made to the environment via API calls. Use a third party product with Cloudtrail integration to handle AWS monitoring and alert on certain API calls and changes to critical IAM policies.

6: Make use of intrusion detection and log analysis in your environment.  There are several third party tools for this.

7: For more complex environments, use SAML to establish a single sign-on (SSO) for your AWS management. Federated users allow for capabilities like password rotation, dual factor authentication and auditability.

8: AWS S3 security: If S3 data is only to be accessed from a known set of addresses or networks, limit access from outside these using S3 Access policies.

9: Use a separate AWS services account with separate credentials (AWS MFA in place as always) to pull backups from your primary account.  The primary account should not have write permissions on the backup account and the backup account should have read only permissions on the primary account.

10: Optionally, pull backups of your data outside the cloud environment entirely to a managed service provider (MSP), another cloud platform or your own datacenter/colocation. Your AWS account should not have write permissions on the remote backup platform. Rather, the platform should have read permission on the appropriate resources in your AWS environment.  As in 9 above, this prevents an attacker that has compromised your AWS services account from deleting your offsite backups.

This is by no means an exhaustive list of steps that can be taken to strengthen AWS security but it’s a good start.

Visit our Managed AWS Services page to learn more about Amazon AWS support, AWS security, AWS monitoring, and AWS compliance.

—–

By Jason McKay