In the majority of cases, breaches and data exposure happens due to user misconfiguration of available security settings. Most hosting services such as AWS operate under a policy of shared security responsibility – 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 organization. The following recommendations serve as an initial checklist to kick-start the creation of internal guidelines.
CREDENTIALS AND USER ACCESS MANAGEMENT
One of the main reasons for data breaches lies on the inside. Increasingly sophisticated spear fishing campaigns and negligence often lead to compromised account credentials
- Treat root access credentials with extreme care.
- No one should have access to these without absolute necessity, not even within the corporation.
- Every user with access to your AWS cloud should use a unique and secure password, preferable generated by a password manager.
- Use multi-factor authentication
- Make full use of Amazon’s Identity and Access Management (IAM) service.
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. It’s important to remember that even the resulting log data needs to be protected.
- Enable CloudTrail log file validation as well as access logging and encryption.
- Configure CloudWatch to alert you when certain thresholds are met that represent abnormal network activity.
- Configure CloudWatch to send you reports about outages, threat indicators and more. Learn more about setting it up here.
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.
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.
S3 Best Practices
Amazon S3 buckets are a safe and reliable way to store data – if configured correctly. 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.
- Ensure that no buckets are public. Use one of the following links and replace “bucketname” with the actual name of your bucket:
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
Crawl Amazon S3 buckets for interesting files.
Checks buckets for public access.
Dump or list the contents of ‘open’ buckets.
Encrypt Sensitive Data
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.