A Deep Dive into the Security of IAM in AWS 

Public clouds are valuable targets for cybercriminals looking to exploit vulnerabilities in organizations’ infrastructure. While the time frame for a potential breach can vary, it’s common for hackers to scan newly deployed cloud resources within a matter of minutes in search of weaknesses to exploit.

Unfortunately, many security breaches go undetected for an extended period of time, sometimes even months, making it essential for organizations to implement strong security measures and regularly monitor their cloud environment for potential threats.

One of the key components of a comprehensive security plan in the cloud is a secure and robust implementation of identity and access management (IAM). IAM plays a critical role in controlling and managing access to cloud resources, ensuring that only authorized users have the necessary permissions to perform actions on the resources.

In Amazon Web Services (AWS), Identity and Access Management allows users to define fine-grained access control policies for AWS resources based on user identities, roles and other attributes.

With AWS’s IAM features, administrators can grant permissions to users and services to access resources, and they can also create roles that can be assumed by AWS services to access resources.

IAM also provides a centralized location for managing user accounts, including password policies, multifactor authentication, and other security-related settings. Additionally, IAM can be integrated with other AWS services, such as Amazon Simple Storage Service (S3), to provide more granular access control policies.

A well-designed IAM implementation can help to mitigate the risk of security breaches by reducing the attack surface, restricting access to only authorized users, and providing a centralized place to manage access to cloud resources.

Cloud Misconfigurations: The No. 1 Cloud Risk

The main attack surface in the cloud is not the operating system of servers hosted in the cloud, nor is it the configuration of applications or the security of applications. While these are still relevant to the data center, the majority of hacks now involve the misconfiguration of cloud resources.

“Nearly all successful attacks on cloud services are the result of customer misconfigurations, mismanagement and mistakes,” wrote Neil MacDonald, a Gartner vice president, in a 2019 report on cloud security.

In the news media, these scenarios are often portrayed in overly simplified terms, such as an AWS S3 bucket being left open to the world. However, when digging deeper, it is often the case that a combination of IAM misconfigurations was used to gain access to the S3 data.

Even if you think you are secure because you have examined your IAM configuration against best practices and have used the AWS IAM analyzer, you still likely have highly vulnerable settings. It is often difficult to identify them and they are usually missed by security tools.

For example, there’s an Elastic Compute Cloud (EC2) action that allows an EC2 instance to change the IAM policy that applies to it — and many people have this turned on accidentally. This presents a huge breach potential.

Similarly, S3 lists in IAM permissions can be dangerous in production environments, but your security tooling may not identify them as vulnerabilities.  Even when you have compliance standards in place, your security tools may not catch some of the techniques hackers are using.

Many advanced cloud misconfigurations are only apparent when considering the full context of an environment. You can’t just scan an infrastructure code file and assume you are secure; you have to look at when that Terraform or CloudFormation script runs and deploys, whether automatically or manually.

You also have to consider how the configuration impacts the overall account, Amazon Virtual Private Clouds (VPCs), and other components. This is what hackers target, as the primary network is not the TCP/IP network — it’s the IAM network.

And research shows that too many organizations are careless with their IAM; a report released in May by Unit 42, the security research branch of Palo Alto Networks, found that 99% of organizations studied have overly permissive IAM policies, meaning they issue credentials that went unused in the previous 60 days.

The Perils of Poorly Configured IAM Policies

IAM policies play a critical role in controlling access to AWS resources. The policies are written in JSON and define who can access which resources, and under what conditions. These policies can be associated with AWS identities such as users, groups, and roles, or with AWS resources directly.

The policies are evaluated by AWS when a user makes a request to access an AWS resource, and access is granted or denied based on the policies in place.

In AWS, the security of a system depends on the configurations and policies set by the administrators.

It’s important to note that IAM policies apply not only to users but also to the infrastructure that is running in AWS, such as EC2 instances. A common security issue: when IAM policies are overly permissive, allowing too much access to AWS resources.

For example, if a policy is set with a wildcard `*` for read-write access on an EC2 instance, this could result in a security breach if an attacker gains access to the instance. This is because the attacker would have read and write access to all resources associated with the EC2 instance, potentially leading to data exfiltration, lateral movement, and other security incidents.

The use of a wildcard (i.e., `*`) in the policy grants permissions to all available actions within a particular AWS service. So, when new actions are introduced in a service/resource, they will automatically inherit all the `read` policies, as long as they are covered by the `read-*` statement.

This can result in unintended consequences, as users may be able to perform actions that were not intended. Therefore, it’s recommended to use more specific policies that only include the necessary permissions, rather than using a wildcard policy such as `read-*`.

The `iam:PassRole` permission allows an IAM user or role to pass an IAM role to an EC2 instance, allowing the EC2 instance to assume the IAM role and perform actions authorized by the policies associated with that role.

This is useful in scenarios where you want to change the IAM instance profile associated with an EC2 instance — for example, to grant or revoke certain permissions.

However, it’s important to carefully manage this permission and ensure that it’s granted only to trusted entities to prevent any unauthorized access to your AWS resources.

Not granting the `iam:PassRole` permission only to trusted entities can lead to several security implications. For example, it could result in unauthorized access to AWS resources: If an attacker gains access to an IAM user or role with the `iam:PassRole` permission, they could launch new EC2 instances and pass a malicious IAM role to those instances. This could allow the attacker to gain access to sensitive AWS resources and cause damage to your environment.

The Security of Identity Access Management

Attribute-based access control (ABAC) in AWS allows administrators to define fine-grained access control policies for AWS resources based on attributes such as the identity of the user, the time of the request, the type of resource, and others. ABAC policies are defined using AWS Identity and Access Management policies.

IAM in AWS is a service that enables you to manage users, groups, and permissions for various AWS resources. It is a critical component of AWS security and allows you to control access to your AWS resources.

The policies can be scoped to specific AWS resources, such as an S3 bucket or an EC2 instance, allowing administrators to apply different levels of access control to different resources. This level of control helps to secure sensitive data and enforce compliance with security best practices.

One of the key concepts in IAM is the idea of a principal. A principal is an entity that can interact with AWS resources and can be a user, a group, or a role. Each principal is associated with an AWS access key and secret key, which are used to authenticate the principal when making requests to AWS.

AWS IAM has a number of built-in policies that allow you to provide granular access control to various AWS services and resources. These policies are written in JSON and can be used to allow or deny access to AWS resources based on various conditions, such as the resource’s Amazon Resource Name (ARN), the time of day, or the IP address of the request.

You can also create custom policies to control access to specific resources or perform specific actions. Policies can be attached to users, groups, or roles, which are similar to users and groups but are intended to be used with AWS services and resources rather than human users.

A lot of the complexities in designing secure IAM are not constrained to just the policy understanding but are caused by the interactions of principals, actions, and resources. There are a lot of scenarios that you can get into where you can overly complicate things — or worse, you can make them overly permissive and therefore dangerous.

Streamlining Access to AWS Resources with ABAC

Managing access to AWS resources can be a challenge, especially in large, complex environments where multiple teams are responsible for different applications and resources. That’s where ABAC comes in. It allows you to grant access to resources based on the attributes or tags of those resources.

We’ll describe a scenario where multiple teams — Team A, Team B, Team C — are responsible for different applications and AWS resources. To control access to these resources, we’ll use ABAC, where access is granted based on the values of resource tags. For example, if a resource is tagged with `team: A`, it means that Team A has access to that resource.

Here’s How ABAC Works in AWS

• Resource tagging: The first step is to tag the AWS resources with appropriate attributes, such as `team: A`. This allows you to categorize the resources and associate them with the appropriate teams.
• Policy definition: Next, we define policies that control access to the resources based on the values of the tags. These policies are written in JSON format and use AWS IAM policy language to specify the conditions under which access is allowed or denied.
• Policy attachment: The policies are then attached to the appropriate IAM users, roles, or groups. For example, if Team A has responsibility for a resource with the tag `team: A`, we would attach the policy that allows access to that resource to the IAM users or roles associated with Team A.
• Access control: When an IAM user or role attempts to access a resource, AWS evaluates the attached policies to determine whether the request should be allowed or denied. If the request meets the conditions specified in the policy, access is granted.

ABAC requires careful management of tag values and permissions for modifying tags. For example, we would want to restrict write permissions to the `team` tag to only trusted entities, such as the team administrators or resource owners, to prevent unauthorized changes to the tag values.

By using ABAC, we can dynamically control access to AWS resources based on the values of resource tags, making it easier to manage access in large, complex environments. Whether you have multiple teams working on different applications, or you’re managing access to a large number of resources, ABAC is a powerful tool that can streamline access control and reduce the risk of unauthorized access.

Using Policy as Code with IAM

Remember, the cloud cannot be treated like an on-premise data center to make it robust and secure; it’s not a castle that can be protected with a moat. Hackers will always find ways around traditional security controls. No wonder more organizations that deploy on the cloud are moving to a zero trust strategy, which depends on a robust IAM architecture.

The point of the cloud is to go fast and its software-defined infrastructure is highly dynamic, configured, deployed, and maintained via APIs. These APIs give customers the ability to go fast, experiment, and iterate, which is one of the key benefits of the cloud.

However, these APIs also introduce challenges when it comes to security and compliance. Since APIs are highly automated and remove much of the manual checking and friction associated with traditional IT infrastructure, it’s easy to inadvertently misconfigure resources or overlook security vulnerabilities.

Developers are now building and modifying their own infrastructure environments via APIs. This is why it’s important to use Policy as Code for any kind of security at scale on the cloud.

Policy as code allows security policies to be defined as code, which can be version controlled and audited like any other software code. This enables organizations to automate the enforcement of security policies, which can help battle hackers who also use automation to find vulnerabilities they can exploit. It helps prevent security incidents and reduces the time it takes to detect and respond to them.

The Policy as Code approach allows security teams to define and enforce policies across the entire software development life cycle. This means that security policies are integrated into the development process and enforced automatically, reducing the risk of security issues being introduced into the environment.

Policy as Code also enables continuous monitoring and compliance testing, which helps organizations to identify security issues early on and quickly respond to them. This enables a feedback loop where security policies are continuously refined based on the latest threat intelligence and security trends, making them more effective over time.

What’s Open Policy Agent and How Does It Help?

The open source tool Open Policy Agent (OPA), created by Styra to implement cloud configuration management policies, is frequently used as the cornerstone of any Policy as Code strategy.

OPA is a policy engine that helps address issues with IAM and AWS cloud misconfigurations by providing a unified and flexible approach to defining and enforcing security policies across cloud environments. Here are some specific ways in which OPA can help:

• Defining and enforcing policies: OPA allows you to define policies for IAM and AWS cloud misconfigurations as code, which can be version controlled, reviewed, and tested. With OPA, you can define policies that ensure security best practices are followed, such as ensuring that only authorized users and applications have access to AWS resources, that data is encrypted in transit and at rest, and that security configurations are applied consistently.
• Enforcing fine-grained access control: OPA provides dynamic authorization by allowing you to define policies that evaluate context-specific information, such as user identity, resource type and request parameters. This can enable you to enforce fine-grained access control, which can reduce the risk of privilege escalation attacks and improve overall security.
• Integrating with existing tools: OPA can be integrated with existing tools, such as AWS Config and AWS Security Hub, to provide a consistent and automated approach to security policy enforcement. For example, you can use OPA with AWS Config to monitor and enforce compliance with security policies across your AWS environment.
• Providing visibility into policy decisions: OPA provides visibility into policy decisions by allowing you to audit and analyze policy evaluations. This can help you identify areas of non-compliance and make informed decisions about how to improve security policies.
• Enabling collaboration and standardization: OPA allows teams to collaborate on policy definitions, review changes and ensure that policies are consistent across different environments. This can help ensure that security policies are effectively enforced and reduce the risk of security breaches.

Tools that Use Open Policy Agent

Fugue, a cloud infrastructure security company acquired by Snyk in February 2022, recently announced the merger of its two flagship products, Fugue Platform and Fugue Risk Manager, into a unified Software as a Service (SaaS) solution called Fugue.

The new product combines the strengths of both platforms to provide cloud stakeholders with a comprehensive solution for securing cloud infrastructure, delivering compliance assurance and reporting, and enabling application teams to “shift left” and incorporate security and compliance early in the software development life cycle.

One of the key features of the new Fugue platform is its API, which enables developers to integrate cloud infrastructure policy checks into CI/CD pipelines. This enables teams to incorporate security and compliance checks early in the development process, helping to prevent issues from occurring downstream.

For example, Fugue uses OPA to implement cloud configuration management policies. OPA can define cloud security policies as code, which can be tested in a CI/CD pipeline.

Fugue also provides a policy library that includes pre-defined policies for common cloud security and compliance frameworks, such as CIS AWS Foundations Benchmark, GDPR, HIPAA, ISO 27001, NIST 800-53 rev.4, PCI, and SOC 2. Users can customize these policies to meet their specific security and compliance requirements.

When a policy violation is detected, Fugue automatically creates a remediation plan to correct the issue. This can include updating cloud configurations, taking action on cloud resources, and sending alerts to security teams. Fugue provides visibility into all policy violations and remediation actions, enabling security teams to track and audit changes made to cloud configurations.

Additionally, Fugue’s cloud resource visualization tools provide auto-generated visualizations of cloud resources, configurations, and relationships, which help teams understand and track changes over time.

Here’s a closer look at two open source OPA-focused solutions developed by Fugue, and also deep dive into Fugue Risk Manager, an essential component of Fugue as a SaaS solution.

Regula

Regula was developed by Fugue to help organizations assess their cloud infrastructure for compliance with security and regulatory standards. It also leverages the OPA framework to provide a Policy as Code approach to security and compliance.

The tool works by analyzing cloud infrastructure configurations and comparing them against defined policies. It supports scanning infrastructure configurations stored in various formats, including AWS CloudFormation, AWS Kubernetes manifests, and Terraform. When a violation is detected, Regula provides detailed information about the issue and guidance on how to remediate it.

One of the key benefits of Regula is that it can be integrated into a CI/CD pipeline so that organizations can assess their cloud infrastructure for compliance as part of their software delivery process. This helps ensure that compliance and security issues are caught early and can be addressed quickly.

Fregot

Fregot is a valuable tool for anyone working with the Rego policy language, which is used in the OPA policy engine. With Fregot, developers can evaluate expressions, debug code, test policies, and more, all in a lightweight, user-friendly environment.

Unlike the OPA agent, which provides general-purpose components and functionality that are specifically designed for Kubernetes, Fregot was developed to provide a streamlined, Rego-specific toolkit that can be used to enhance the development experience.

This includes useful tools for debugging Rego queries and modules, as well as enhanced error messages that make it easier to identify and fix issues. Fregot also offers ease of extending and experimenting with different language features, making it an excellent choice for developers who want to experiment with the Rego language and explore its full potential.

Fugue Risk Manager

Fugue Risk Manager is an essential tool to consider as part of AWS IAM security tooling when hardening IAM architecture and improving an organization’s overall security posture.

It helps address the risks associated with cloud infrastructure by providing security and compliance and provides infrastructure teams with a single source of truth.

Fugue Risk Manager scans cloud environments to discover running cloud infrastructure resources and identify infrastructure compliance violations. It provides continuous security and compliance for AWS environments by detecting and mitigating security risks in real time.

Once known-good infrastructure baselines have been established, Fugue Risk Manager can identify unauthorized changes and configuration drift. It automatically remediates drift events back to the provisioned baseline, ensuring that infrastructure remains secure and compliant.

The tool also generates reports on remediation events for compliance, allowing organizations to maintain an audit trail of their cloud infrastructure changes.

In addition to identifying misconfigurations, vulnerabilities, and policy violations in AWS accounts, Fugue Risk Manager also provides continuous monitoring and reporting to help organizations understand the state of their infrastructure security and take action to address any identified risks.

Additionally, Fugue Risk Manager integrates with other AWS security tools such as AWS Security Hub, AWS Config, and AWS Inspector, to provide a comprehensive view of security across an organization’s AWS environment.

Best Practices for IAM Security in AWS

To maintain IAM security on Amazon’s cloud, follow these best practices:

Grant least possible privilege to all users. The principle of least privilege, a cornerstone of a zero trust security strategy,  advises that users should only be granted the minimum set of permissions required to perform their job. This helps to minimize the potential impact of an accidental or malicious action and makes it easier to understand and audit the permissions in use.

Keep in mind that IAM permissions can be granted through the AWS Management Console, APIs and CLIs and all should be audited and locked down as much as possible.

Using a tool like the Fugue Best Practices Framework can help identify any potential vulnerabilities that may be missed by compliance checks.

It’s also important to make IAM changes a part of your change-management process to ensure that any changes are properly reviewed and approved. This helps reduce the risk of accidental or unauthorized changes to the IAM configuration.

The “deny by default” mentality is also a crucial aspect of IAM security. By denying all access unless explicitly allowed, you can help prevent unauthorized access to your resources. Additionally, using privileged identity and session management tools can help monitor and control access to sensitive resources, providing an extra layer of security.

Use individual IAM users instead of the root account. The root account has full administrative access to all AWS resources and services. By using IAM users instead of the root account, you can delegate administrative control, provide granular permissions, and enhance the security of your AWS environment.

Use groups to assign permissions to multiple users. IAM groups are a way to grant a set of permissions to multiple users. Instead of having to grant permissions to each user individually, you can assign permissions to a group, and then add users to the group. This makes it easier to manage user permissions and reduces the effort required to make changes.

Use roles to grant permissions to AWS services and applications. AWS roles allow you to grant permissions to AWS services and applications, rather than to IAM users or groups. For example, you could grant a role that allows Amazon S3 to read and write objects to a bucket. This eliminates the need to share AWS credentials with other services or applications.

Use multifactor authentication (MFA) for privileged users. MFA provides an additional layer of security by requiring users to provide two forms of authentication before they can access AWS resources. It is recommended to enable MFA for privileged users, such as IAM administrators, to help prevent unauthorized access. even if a password is compromised.

Rotate access keys periodically. Access keys are used to authenticate an AWS API request. Access keys should be rotated regularly to reduce the risk of unauthorized access. When an access key is rotated, a new key is created and the old key is deactivated.

Remove unnecessary permissions and access. Regularly review and remove any permissions or access privileges that are no longer needed. This helps reduce the attack surface and minimize the risk of unauthorized access.

Monitor and review access keys, user policies, and authentication logs. Monitoring and reviewing access keys, user policies, and authentication logs can help you detect and prevent any unauthorized access. Regular monitoring can also help you identify trends and patterns that may indicate potential security issues.

Define and measure mean time to recovery (MTTR). This is critical for effectively managing security in cloud environments. MTTR refers to the amount of time it takes to detect and resolve a security incident. By setting goal targets for your MTTR, you can ensure that your team is able to respond quickly to potential threats and minimize the impact of security incidents.

Measuring your MTTR can also help you identify areas where your security processes may need improvement. For example, if your MTTR is significantly longer than your target, it may indicate that your team needs additional training or resources to respond more quickly to security incidents.

In addition to measuring MTTR, it’s also important to establish a process for continuous monitoring and assessment of your cloud security posture. This can help you identify and remediate misconfigurations before they become a security risk. Automated remediation can be especially helpful in reducing MTTR, as it can quickly resolve issues without the need for manual intervention.

Conclusion

In the AWS cloud, managing security and compliance for large datasets can be a daunting task. One way to simplify this process is through the use of Policy as Code. By defining policies as code, organizations can ensure that their security and compliance requirements are met consistently across all their AWS resources.

This approach allows for more efficient monitoring and auditing, as well as easier automation of security and compliance processes. Additionally, Policy as Code can help to detect and prevent misconfigurations and security breaches, which can be particularly important for large datasets where the potential for risk is higher.