Identity and Access Management (IAM) Misconfigurations Top the List of Exposures in AWS Cloud Environments

Misconfigurations have become expressways for exploits in otherwise secure cloud environments, despite the wealth of best practices offered by the security community and cloud platform providers.

Identity and Access Management (IAM) misconfiguration is a common security weakness

Using data from Alert Logic Cloud Insight Essentials exposure scans – run in early November 2017 across a representative sample of more than 31,000 Amazon EC2 (Elastic Compute Cloud) instances and workloads – we identified more than 150,000 instances of misconfiguration. Of these, 30,000 were linked to Identity and Access Management (IAM). In fact, four out of the top seven misconfigurations in our data set were IAM related, including:

• Dangerous user privilege access to S3
• User not configured to use multifactor authentication
• User access keys are not configured for rotation
• IAM policies are attached directly to a user

IAM misconfigurations are important to fix because bad actors can use them to access an organization’s documents, spreadsheets, data repositories, intellectual property and financial reporting, with the intent to steal information or damage the company’s business and reputation.

High Severity S3 access

In the “high severity” category of the Alert Logic scan results is “Dangerous user privilege access to S3.” This type of misconfiguration has been in the news a lot lately, and AWS has made improvements and released resources to help platform users steer clear of this problem. Users must continuously audit privileged accounts to confirm access controls and look for any anomalies. These anomalies may appear in the form of a username or directory that does not conform to the designated naming convention. Platform users should make sure to collect logs and process them through the AWS CloudTrail service. If you don’t have IAM logging to CloudTrail, review this AWS user guide to ensure you are properly configured to log IAM events.

Shrink your attack surface to reduce exposure to risk

While some of the misconfigurations in our scan only rated “medium” or even “info only,” simple misconfigurations can lead to a potential breach if left unfixed for any amount of time. We see in the real world that these same configuration issues, when left unattended, have served as the first step in a larger attack.

Take, for example, “User not configured to use MFA,” which has a “medium” severity rating. In today’s world of rampant breaches, multifactor authentication (MFA) should be implemented in every authentication situation, from social media access to ATM transactions. MFA can be as simple as using a cell phone or alternate email address in addition to the first method of authentication. Yet major breaches, such as the Deloitte breach that exposed confidential client information, have been attributed to a lack of MFA. AWS offers options ranging from free smartphone authentication to paid hardware tokens and key fobs. Guidance from AWS can be found here.

Keep Calm… and add authentication

Another “medium” severity misconfiguration, “User Access Keys are not configured for rotation,” defies a longstanding best practice. All cloud platform users should use rotating passwords and keys. PCI DSS recommends requiring password changes every few months, and businesses and industries of all types should consider whether they should change passwords and keys more frequently. AWS provides useful guidance on how to configure a strong Identity and Access Management strategy.

Turn on S3 logging

Another prevalent misconfiguration on our IAM list was “S3 not logging.” Although categorized as “informative only” with the appearance of an operational issue, this misconfiguration can have a big impact on cloud security, as seen in a September Verizon breach and the November leak of Australian employee data. Organizations that are not logging their S3 storage can’t know whether their data is properly encrypted, that the right resources are accessing the storage, or whether objects have been removed or modified. AWS provides good guidance to help you ensure your S3 storage is logging.

Once organizations have confirmed their S3 storage is logging, they should look at what the logs are producing and what valuable information they contain. New security content should be continually incorporated to detect new indicators in the logs, and log data should include 24×7 monitoring for malicious activity. Managed security providers can provide up-to-date security content, live monitoring of logs and incident escalation to the teams who can mitigate the risk quickly and efficiently.

Continuously monitor for misconfigs

In the shared responsibility model for cloud platforms, users must know and actively manage their exposures. The misconfigurations Alert Logic identified in our scan are all addressable, but organizations that don’t monitor are not aware of their risk. Threats move fast, so once misconfigurations are identified, cloud platform users must make fast judgements and quickly remediate, whether through their own internal security teams or through a SOC-as-a-service provider like Alert Logic.

The following list is the top ten identified misconfigurations in Amazon EC2 instances and workloads from our data set:

1. Unconfigured EC2 instance single-point-of-failure and/or auto scaling issue
2. S3 logging not enabled
3. S3 object versioning is not enabled
4. User not configured to use MFA
5. User access key not configured with rotation
6. IAM policies are attached directly to user
7. Dangerous user privileged access to S3
8. ELB security group allows insecure access to ports or protocols
9. IAM access keys unused for 90 days
10. Dangerous user privileged access to RDS