Improve the security of your AWS account

As more organizations migrate their infrastructure to the cloud, security in the cloud has become a top priority. One of the most common security issues in AWS is misconfiguration, which can leave organizations vulnerable to attacks and data breaches.

In this article, we will discuss the most common security misconfigurations we find in AWS accounts. Understanding and addressing these misconfigurations can help ensure that your AWS environment is secure and protected from potential threats.

Avoid IAM Access Keys

For those of you who are not familiar with Identity and Access Management (IAM) access keys, let’s quickly define what they are. IAM access keys are static, long-term credentials that provide programmatic access to resources in your AWS account.

The issue with IAM access keys is that they are an example of a ‘long-term’ credential. Currently, there is no built-in mechanism to force rotation of IAM access keys which means that in some instances keys can sometimes become quite old (several years) before ever being rotated. As keys age, the likelihood of them accidentally being leaked increases.

Do yourself a favour and only assign IAM access keys when you have no other options for providing programmatic access. Providing permanent access adds operational overhead - you have to manage those accounts, which can increase the possibility of account compromise through poor password hygiene or old credentials. Also, make users justify why they need access keys before you create them. Finally, I would strongly recommend you have an automated process to either force the rotation of, or disable unused IAM access keys.

Here are just a few alternatives to using IAM access keys:

1. IAM roles: Unlike static access keys, roles provide access by assigning temporary access keys which are managed by the AWS Security Token Service (STS).
2. AWS Identity Center (aka AWS SSO): like roles, using Identity Center provides a method of temporary access for both the AWS management console and the AWS CLI.
3. If you’re using the AWS CLI, make sure you’re running V2 and integrate it with the AWS Identity Center.

Overly Permissive IAM Policies

Customer managed IAM policies are JSON documents that you create and maintain via the IAM service. Policy documents are used to control who has access to your AWS account, and what actions they can perform - think authentication and authorization.

IAM permissions that provide more access than required can lead to unintended consequences which could include interruption of service, deletion of data or unauthorized access. Quite often, when reviewing a customer’s IAM permissions we find many examples of assigned permissions that have either never been used, or haven’t been used for an extended period of time.

You should be regularly reviewing not only who (or what) has access to your AWS account, but also what permissions they have been granted. Here are just a few suggestions on how to better manage your IAM access:

1. Enable the IAM access analyzer across all AWS accounts in your AWS organization and take action on any findings which identify unintended access.
2. Create an automated review process that collects information about every IAM user, who is responsible for the account, and the currently assigned permissions.
3. Automate the process of automatically disabling (or deleting) any IAM accounts that have not been used in a specific time period.

Open VPC Security Groups

VPC security groups are stateful firewalls that operate at the Elastic Network Interface (ENI) level and provide network protection of resources deployed within a VPC. By default, security groups block all inbound traffic and allow all outbound traffic.

Next to poor access management, open VPC security groups is the most common issue we find within audited AWS accounts. By allowing traffic on ports which are not required for your solution, you’re leaving your infrastructure vulnerable to compromise which may lead to higher AWS costs, loss of trust with your customers, and loss of proprietary information.

Much like IAM permissions, you should regularly review the configuration of your security groups to ensure that the allowed network ports are still applicable to your solution. In addition to this on-going review process, you should consider the following:

1. Develop a set of security group guardrails. Define ports which should never be open and proactively stop deployments if rules in a security group violate these guardrails.
2. If you use CloudFormation you should consider using CloudFormation Guard to help with this. You could also use AWS Config to monitor for violations of existing security groups and automatically remove rules that violate your security group guardrails.

Lack of Encryption

In the event of a security-related incident, encryption often becomes your last line of defense. Before deploying any resources, you need to ensure you’ve defined an encryption strategy to protect your data while it’s at rest (and in transit). Protecting data at rest on the AWS platform is simple to do using the Key Management Service (KMS).

Many AWS services now enable KMS by default so your data is protected, which is great, however you can go a step further and configure KMS to use your own encryption keys - Customer Managed Keys (CMK).

In many of the AWS accounts we review, customers have not configured KMS, relying on the default AWS Managed Keys, and by doing so they’re giving up control and potentially the ability to adequately audit encryption key usage in their accounts.

Prior to starting any project on AWS you should review the services you intend to use, verify they are supported by KMS and then generate CMKs to use to protect your data.

Enable AWS security services to provide additional insight

Finally, AWS provides a set of fantastic (and cost-effective) security services that customers often overlook. Below is our list of ‘must-have’ AWS security services:

1. AWS CloudTrail: monitor and record all API activity in your AWS account.
2. AWS Config: Discover resources in your account and monitor them for compliance and changes.
3. Amazon GuardDuty: Continuously monitor your AWS accounts for indications of compromise.
4. AWS Security Hub: Monitor your AWS accounts against security best practices.