Locking-in the Cloud: Seven Best Practices for AWS
Blog Article Published: 07/06/2017
By Sekhar Sarukkai, Co-founder and Chief Scientist, Skyhigh Networks
With the voter information of 198 million Americans exposed to the public, the Deep Root Analytics leak brought cloud security to the forefront. The voter data was stored in an AWS S3 bucket with minimal protection. In fact, the only level of security that separated the data from being outright published online was a simple six-character Amazon sub-domain. Simply put, Deep Root Analytics wasn’t following some of the most basic AWS security best practices.
More importantly, this leak demonstrated how essential cloud security has become to preventing data leaks. Even though AWS is the most popular IaaS system, its security, especially on the customer end, is frequently neglected. This leaves sensitive data vulnerable to both internal and external threats. External threats are regularly covered in the news, from malware to DDoS hacking. Yet the Deep Root Analytics leak proves that insider threats can be dangerous, even if they are based on negligence rather than malicious intent.
Amazon already addressed the issue of outside threats through its numerous security investments and innovations, such as the AWS shield for DDoS attacks. Despite extensive safety precautions, well-organized and persistent hackers could still break Amazon’s defenses. However, Amazon cannot be blamed for the AWS security breaches, as it is estimated that 95 percent of cloud security breaches by 2020 will be the customer’s fault.
This is because AWS is based on a system of cooperation between Amazon and its customers. This system, known as the shared responsibility model, operates on the assumption that Amazon is responsible for safeguarding and monitoring the AWS infrastructure and responding to fraud and abuse. On the other hand, customers are responsible for the security “in” the cloud. Specifically, they are in charge of configuring and managing the services themselves, as well as installing updates and security patches.
AWS Best Practices
The following best practices serve as a background to securing configuring AWS.
- Activate CloudTrail log file validation:
CloudTrail log validation ensures that any changes made to a log file can be identified after they have been delivered to the S3 bucket. This is an important step towards securing AWS because it provides an additional layer of security for S3, something that could have prevented the Deep Root Analytics leak.
- Turn on access logging for CloudTrail S3 buckets:
Log data captured by CloudTrail is stored in the CloudTrail S3 buckets, which can be useful for activity monitoring and forensic investigations. With access logging turned on, customers can identify unauthorized or unwarranted access attempts, as well as track these access requests, improving the security of AWS.
- Use multifactor authentication:
Multifactor authentication (MFA) should be activated when logging into both root and Identity and Access Management (IAM) user accounts. For the root user, the MFA should be tied to a dedicated device and not any one user’s personal device. This would ensure that the root account is accessible even if the user’s personal device is lost or if that user leaves the company. Lastly, MFA needs to be required for deleting CloudTrail logs, as hackers are able to avoid detection for longer by deleting S3 buckets containing CloudTrail logs.
- Rotate IAM access keys regularly:
When sending requests between the AWS Command Line Interface (CLI) and the AWS APIs, an access key is needed. Rotating this access key after a standardized and selected number of days decreases the risk of both external and internal threats. This additional level of security ensures that data cannot be accessed with a lost or stolen key if it has been sufficiently rotated.
- Minimize number of discrete security groups:
Account compromise can come from a variety of sources, one of which is misconfiguration of a security group. By minimizing the number of discrete security groups, enterprises can reduce the risk of misconfiguring an account.
- Terminate unused access keys:
AWS users must terminate unused access keys, as access keys can be an effective method for compromising an account. For example, if someone leaves the company and still has access to a key, that person would be able to use it until its termination. Similarly, if old access keys are deleted, external threats only have a brief window of opportunity. It is recommended that access keys left unused for 30 days be terminated.
- Restrict access to CloudTrail bucket:
No user or administrator account should have unrestricted access to CloudTrail logs, as they are susceptible to phishing attacks. Even if users have no malicious intent, they are still susceptible. As a result, access to the CloudTrail logs needs to be restricted to limit the risk of unauthorized access.
These best practices for the AWS infrastructure could go a long way in securing your sensitive information. By applying even a few of them to your AWS configuration, sensitive information could remain secure, and another Deep Root Analytics leak could be prevented in the future.
