The Top 5 AWS Security Mistakes To Avoid
by Hannah Grace Holladay / August 25th, 2021
AWS’s compute and data storage services are the beating heart of tens of thousands of businesses. That makes AWS security and compliance a matter of critical concern. It’s all too easy to make a configuration mistake that opens the door to bad actors intent on stealing data and infiltrating malware. For example, estimates put the proportion of misconfigured buckets on Amazon’s Simple Storage Service (S3) at 46%.
In this article, we’re going to look at five of the most common AWS security mistakes and show you how to check if your AWS environment is vulnerable.
How Secure Is AWS?
AWS is a secure cloud platform. However, no platform can be totally secure. AWS is incredibly flexible, but that flexibility gives you the power to shoot yourself in the foot. Cloud users can’t rely on Amazon to take care of all security risks. Responsibility for cloud security is shared between the platform and the user, and who is responsible for what depends on the service.
AWS’s EC2 infrastructure-as-a-service platform puts more responsibility on users than a platform-as-a-service such as Elastic Beanstalk. But user misconfigurations can create security vulnerabilities on any cloud service, which is why user error causes all of the common security problems we’ll discuss here today.
To learn more about the cloud shared security model, read Who’s Responsible for Cloud Security?
Storing Data in S3 Buckets or EBS Volumes without Encryption
Encryption at rest and in transit makes data worthless to bad actors—even if it is leaked or intercepted. All Amazon data storage services offer strong encryption, but many users fail to activate it.
S3 provides various server-side encryption options alongside key management solutions that simplify the use of encryption keys, but users can choose to store data unencrypted. Elastic Block Storage offers encryption for data at rest, in transit, and for snapshots, but users can select unencrypted volumes, creating a risk of accidental misconfiguration that could expose sensitive data.
Configuring S3 Buckets with Public Availability
As we mentioned in the introduction, misconfigured S3 buckets cause numerous data leaks. S3 is an object storage service. Data is stored in buckets, and each bucket has configurable access permissions. By default, buckets are private so that only accounts given explicit permission can access them.
However, buckets can, and often are, configured so that anyone on the internet can access them and the data they contain. Sometimes this is a genuine mistake, but buckets are usually made publicly accessible because the user finds it convenient to circumvent access controls. S3 configuration errors have, on many occasions, exposed highly sensitive data on the open internet.
Connecting EC2 Instances Directly to the Internet
There are legitimate reasons to assign EC2 instances a public IP address, but, in most cases, they should be deployed on an internal network with access limited to other resources under your control. For example, if you host a web application’s database server on an EC2 instance, it should not be directly connected to the internet. Access should be mediated by firewalls and limited to web or application servers that need to request data.
Leaving Insecure Ports Open
Software services running on a server connect to the network via a numbered port. Many services use a standard port: SSH on Port 22 or HTTP on Port 80. Several services are widely recognized as insecure, either because they send data unencrypted or they contain software vulnerabilities. FTP (21), Telnet (23), and SNMP (161) are in this category. Ideally, these services should not run on EC2 instances, and the associated ports should be blocked by AWS security groups and network access control lists.
Not Using Multi-Factor Authentication MFA
Although AWS’s Identity and Access Management (IAM) service allows authentication with only a username and password, it is recommended that all users take advantage of multi-factor authentication (MFA). MFA requires users to provide additional authentication factors, which might be a one-time code sent to a mobile device or a hardware security key. MFA eliminates the risk that leaked passwords or brute-force attacks could give bad actor access to your AWS account.
How To Identify Security Risks in Your AWS Environment
We’ve covered the five most common AWS security mistakes, but our list is far from exhaustive. There are many more mistakes and misconfigurations that create risk for your business’s data and infrastructure.
There are two ways you might go about finding and fixing AWS security mistakes.
- Manually assess all of your infrastructure and configurations for security vulnerabilities.
- Use the KirkpatrickPrice AWS Scanner, which performs over 50 checks automatically, including checks for the cloud security mistakes we’ve discussed in this article.
The AWS Scanner, part of our comprehensive AWS security and compliance services, quickly and reliably highlights sources of risk, giving you the information you need to secure your AWS infrastructure. Sign up today or contact an AWS security and compliance expert to learn more.
