Security recommendations for hosting on AWS
All state of the art hosting services make the security of their infrastructure a number one priority. Regardless, many of their users still suffer from sensitive data exposure and data breaches. Does that imply that the efforts of the hosting service are insufficient? Surprisingly, it does not!
In the majority of cases, data exposure and breaches happen due to a user’s misconfiguration of available security settings. This is possible, because most hosting services such as AWS operate under a policy of shared security responsibility. This means the customer is responsible for ensuring secure configuration of their AWS environment, for example by managing data access rights meticulously. Additionally, it’s the customer’s responsibility to establish usage and compliance policies such as mandatory multi-factor authorization (MFA) and to identify if an internal user misuses AWS.
Therefore, it is important to be aware of AWS settings bearing high security implications and to establish guidelines and best practices inside the organisation. The following recommendations are based on condensed expert opinions and serve as an initial checklist to kickstart the creation of internal guidelines.
Be conscious about credentials and user access management
While this might sound obvious at first, one of the main reasons for data breaches lies on the inside. Even without malicious intent, increasingly sophisticated spear fishing campaigns and negligence often lead to compromised account credentials. Here are the steps to avoid these issues:
Treat root access credentials with extreme care. No one should have access to these without absolute necessity, not even within the corporation.
It should go without saying that every user with access to your AWS cloud should use a unique and secure password, preferable generated by a password manager. On top of that, using MFA should be a baseline requirement and part of your security guidelines.
It is important to make full use of the tools given to you by Amazon’s Identity and Access Management (IAM) service. This service enables you to ensure that your users in fact use safe passwords and MFA. Additionally, it allows you to set access rights individually for each user, which makes it easy to restrict a user’s access solely to what she really needs on a daily basis.
Make use of Monitoring and Logging
Recording logs and monitoring web traffic such as API calls lay the foundation for security analysis, post incident forensic investigation and even compliance audits. Curiously however, studies show that CloudTrail, Amazon’s internal logging service, is turned off on many instances or not configured correctly. Additionally, it’s important to remember that even the resulting log data needs to be protected. Therefore, it is recommended to enable CloudTrail log file validation as well as access logging and encryption.
In addition to logging data with CloudTrail, the AWS component CloudWatch can be configured to alert you when certain thresholds are met that represent abnormal network activity. Additionally, it can be used to send you reports about outages, threat indicators and more. If CloudWatch is not running on your EC2 instance yet, you can learn more about setting it up here.
Shield Data through Virtual Private Clouds
Amazon’s Virtual Private Cloud (VPC) lets you launch AWS resources in a virtual network that is logically isolated from the AWS Cloud. This allows you to isolate your data from other resources since it is not directly connected to the internet and enables you to apply access control lists and advanced security groups to reduce the vulnerability to different attack types. This effect can be further strengthened by using not only one, but multiple VPCs and accounts to isolate different workloads or teams, such as development, staging and production.
Monitoring and logging are important for VPCs as well: VPC Flow Logs allow you to keep track of all network traffic flowing to and from your VPCs. The recorded information, such as source and destination address, source and destination port, number of packets, bytes, duration, and whether or not the traffic was accepted or rejected, can then be monitored to detect suspicious traffic early on and support incident response.
Apply S3 Best Practices
Amazon S3 buckets are a safe and reliable way to store data - if configured correctly. Similar to the IAM policies, bucket policies specify which users or applications are allowed to access which resources. Additionally, it is also possible to grant or deny access to specific resources by using Access Control Lists (ACLs), which allow for a more fine-tuned approach as compared to bucket policies.
When the number of buckets used increases, it also becomes more difficult to ensure that all of them are sufficiently secured. Many companies still fail at doing so, as shown by the impressive number of open buckets collected by GrayhatWarfare and lists of recent S3 leaks.
One important part of securing your buckets is ensuring that no buckets are public. For individual buckets this is easy to check. Use one of the following links and replace “bucketname” with the actual name of your bucket:
http://s3.amazonaws.com/bucketname/ http://bucketname.s3.amazonaws.com/ If your bucket is indeed private, you should receive the response “Access Denied”. If you are looking to verify the security of one or many buckets at once, multiple free tools are available on GitHub:
Bucket Finder
Let’s you trawl Amazon S3 buckets for interesting files
S3Inspector
Checks all your buckets for public access and gives you a report on each bucket
S3Scanner
Takes in a list of bucket names to check for and will output findings to a file. The tool will also dump or list the contents of ‘open’ buckets locally.
Encrypt Sensitive Data
Sensitive data exposure is a common issue and it can often be linked to a lack of encryption of the respective data in flight or in rest. Therefore, make sure that you encrypt all potentially sensitive data such as personally identifiable information, credit card numbers or protected health information using customer controlled keys. To secure data in rest, you can opt to use S3 server-side encryption, if you use S3 file servers, or alternatively encrypt selected fields within each database record. When your data is being transmitted however, ensure that you are using HTTPS and SFTP respectively.
Avoid mistakes by implementing guidelines
The guidelines above make it clear how breaches are often not caused by system vulnerabilities of a certain vendor, but instead by mistakes made by individual users within corporations. These should serve as a starting point for you to learn from other’s mistakes.
If you are still unsure about how to implement any of the recommendations, additional information as well as customer support can be accessed directly via the AWS knowledge center.