AWS Security Guide: 7 Best Practices to Avoid Security Risks

There are many different benefits when engaging with Amazon Web Services as your cloud platform either as a standalone provider or as a multi-cloud, hybrid computing environment. AWS comes with a level of flexibility and agility in its service and infrastructure which makes it possible for an organization’s network to be innovative, responsive and open to quick change.

However, AWS comes with own set of challenges as well. While Amazon provides its subscribers with a wide variety of security features, organizations often do not use them to its fullest. While cloud security can be overwhelming at times, robust cybersecurity is still possible to achieve as long as potential pitfalls and best practices are kept in mind.

Insufficient Visibility

Cloud resources are mostly transient. This makes it a challenge to keep a log of assets. According to a recent research, the usual lifespan of a natural cloud resource is a little over a couple of hours.

Additionally, companies use environments that make use of different cloud accounts across geographical regions. This encourages scattered visibility and makes identifying risks increasingly tricky. What you cannot see, you cannot secure.

Best Practice

Ensure you are using a cloud security solution that gives visibility into the number of type of resources you use across geographies and accounts in a single dashboard. These can include load balancers, virtual machines, users, security groups, etc. A better understanding of your environment allows for the implementation of more minute policies and inhibits risk.

Exposed Root Accounts

Root accounts are capable of doing the most damage when unauthorized individuals get access to them. Often time administrators miss disabling API root access, providing a doorway for malicious users. Here’s a quote from the AWS docs.

We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. Instead, adhere to the best practice of using the root user only to create your first IAM user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks.

Best Practice

Most of the time, AWS root accounts should not be accessed by anyone, including top admins. These should not be shared with users or applications. It is imperative to protect root accounts via multi-factor authentication and should be accessed as less as possible.

Extra, Unnecessary Privileges

As mentioned earlier, misplaced and stolen credentials are among the leading causes of security breaches. AWS IAM can manage all user groups and accounts with detailed policies and permissions.

However, administrators regularly assign overly necessary access to different AWS resources. This not only allows users to modify and gain access to resources they shouldn’t get but also allows malicious users to cause additional harm if these accounts are breached.

Best Practice

Similar to any other permission-based systems, the configuration of IAM should also be compliant with the underlying rule of least privilege. This translates to any groups or users should only get permissions as required to perform their regular jobs or tasks.

Rotate IAM Access Keys and Credentials

Often, IAM access keys are not rotated. This leads to weaknesses in the IAM’s ability to keep user groups and account secure and allows attackers a larger window to gain access to them. Additionally, rotating IAM, access keys ensures that old keys are not used to get access to critical services.

Best Practice

Rotating or changing your access keys a minimum of once a quarter is a good idea. In case users have the right level of access, they should be able to rotate their access keys themselves. Here’s an example policy that shows how you might create a policy that allows IAM users to rotate their own access keys:

{ “Version”: “2012–10–17”, “Statement”: [ { “Effect”: “Allow”, “Action”: [ “iam:ListUsers”, “iam:GetAccountPasswordPolicy” ], “Resource”: “*” }, { “Effect”: “Allow”, “Action”: [ “iam:*AccessKey*”, “iam:ChangePassword”, “iam:GetUser”, “iam:*ServiceSpecificCredential*”, “iam:*SigningCertificate*” ], “Resource”: [“arn:aws:iam::*:user/${aws:username}”] } ]

}

Poor Authentication Practices

Leading cloud security incidents are down to stolen or misplaced credentials. Unfortunately, it is quite common to notice access credentials for public cloud environments on the web. A recent example would be the Uber breach. Organizations must prioritize a way to detect and close off these account compromises.

Best Practice

Robust password policies, coupled with multi-factor authentication (MFA) needs to be enforced within AWS environments. AWS suggests allowing MFA for all accounts that currently have console passwords. Users need to determine which accounts have pre-existing MFA. Then under IAM, ‘MFA Device’ needs to be checked for all users. Devices such as smartphones can also be used as an additional authentication device.

Get Rid of Unwanted Privileges

As mentioned earlier, misplaced and stolen credentials are among the leading causes of security breaches. AWS IAM can manage all user groups and accounts with detailed policies and permissions.

However, administrators regularly assign overly necessary access to different AWS resources. This not only allows users to modify and gain access to resources they shouldn’t get but also allows malicious users to cause additional harm if these accounts are breached.

Let’s take an example. User A who is new to IAM wants to create a new IAM user with privileges to manage EC2 instances for their AWS infrastructure. However, since User A is new, they are not sure what to put in the role’s access policy. To meet the immediate requirements, he/she attaches the PowerUserAccess policy that looks like this:

{ “Version”: “2012–10–17”, “Statement”: [ { “Effect”: “Allow”, “NotAction”: “iam:*”, “Resource”: “*” } ]

}

This is highly not recommended because any breach of this particular account will breach the entire AWS infrastructure for that particular company.

Best Practice

Similar to any other permission-based systems, the configuration of IAM should also be compliant with the underlying rule of least privilege. This translates to any groups or users should only get permissions as required to perform their regular jobs or tasks.

AWS offers more information about the policies that were last accessed under the Access Advisor tab. User A can scope down these application-specific permissions to get rid of permissions that are not used.

Unpatched Host Servers and Services

It is the responsibility of the organization or a dedicated team within the organization to ensure all of the latest security patches are applied to hosts within the cloud environment the organization is engaging with.

Traditional network vulnerability scanners are active on on-premise networks, but not so much when it comes to vulnerabilities in the cloud environment. This is one of the factors that needs to be taken into consideration while setting up your cloud migration strategy.

Best Practice

Ensure that the host(s) your organization uses is up to date when it comes to patches. All necessary fixes are released and applied by your OEM vendors. Third-party tools can assist with mapping the data originating from the host’s vulnerability updates. A prime example would be Amazon Inspector.

Alternatively, you can also manually perform updates as follows. The steps below are intended for use with Amazon Linux.

1. Start a screen session in your shell window. Screen sessions help you reconnect to a SSH session even after being disconnected.

You can see all active screens by running

[ec2-user ~]$ screen -lsThere is a screen on:17793.pts-0.ip-12–34–56–78(Detached)

1 Socket in /var/run/screen/S-ec2-user.

You can then grab the process ID from the previous command and use it to connect to a detached screen as follows:

2. Run the yum update command to run the updates. Furthermore, you can add the — security flag to install just the security updates.

If you need to update multiple EC2 instances, consider using EC2 run command update to manage your Linux instances.

Broad IP Ranges for Security Groups and Unrestricted Outbound Traffic

Security groups can be imagined akin to firewalls that control and monitor traffic to AWS environments. Admins again are at fault at often assigning this security to a range of IP addresses that tend to be broader than what is necessary.

Research by a reputed cloud analyst shows about 85% of resources that are associated with security groups have no restriction over outbound traffic whatsoever. An uncomfortably large number of companies were not adhering to network security related best practices and also had risky or misconfigurations.

Best practices in the industry rule that any outbound access needs to be restricted to inhibit data exfiltration during a security breach or any accidental data loss.

Best Practice

IP ranges should be limited when assigning them to security groups. This should be done in a way that though all systems network smoothly, systems are not left open unnecessarily. If you use 0.0.0.0/0, you enable all IPv4 addresses to access your instance using HTTP or HTTPS. To restrict access, enter a specific IP address or range of addresses.

Conclusion

It might sound like a challenge to keep your AWS cloud service secure from vulnerabilities. Many organizations commit mistakes which exposes their network and data at risk primarily due to poor configuration, lack of adequate planning and vulnerability detection and scanning methods.

Thanks to Amazon, there are some useful security measures that organizations can use to control the security of their environment. Unfortunately, most do not. Some of these include IAM, AWS CloudTrail and permissions on cloud resources which can be configured in a manner to suit the organization’s requirements.

Originally published at www.womenwhocode.com.