Continuously Enforce IAM Best Practices in Your Cloud with Stacklet

Overview

Hackers or malicious actors spend countless time and resources trying to gain access to your cloud infrastructure. A common way they achieve this is by compromising credentials and identities through techniques like phishing, social engineering, and other methods.

A cloud environment may have hundreds or even thousands of users, accounts, or roles that grant access to resources. Effective identity and access management (IAM) requires good hygiene and active governance to reduce the risk of breaches. This is especially true for highly-permissioned identities and credentials, which pose the greatest threat if compromised. Without automation, managing these according to industry standards becomes increasingly difficult due to the scale and the complex relationships between identities and cloud resources.

This blog will highlight how Stacklet can help reduce the risk of breaches caused by weak IAM controls and ensure that poor practices do not recur with new users, accounts, or misconfigurations.

Identity and Access Management 101

For this blog, an “Identity” could be a person or a role. In each case, the cloud environment verifies and grants access to the requestor based on the profile of that identity and its credentials.

The requestor’s authentication is the starting point for access to your cloud environment. For a person, it’s probably a username, password, and some form of secondary factor. For a service account, it’s most likely a username and password or potentially a certificate.

Strong authentication is the first and arguably the most critical step towards good cloud security and governance. Your organization must take appropriate measures, e.g., two-factor authentication, before granting access. Once authenticated, the user is “inside” the computing environment and has access to resources and data, depending on their assumed identity.

In a typical cloud account, there are thousands of identities, which are typically users or service accounts. User identities are used to map a person to a role, which is a set of privileges that the user can assume. For example, a person may log in as a person and be able to assume an administrator role or a database role. Each role has the ability to access different computing resources in your cloud environment.

There are some basic guidelines for good Identity management:

• Whenever possible, add a second factor, such as Yubikey, Google Authenticator, Certificate (for Service Accounts), etc.
• Make sure all identities comply with the latest authentication guidance, such as password rotation and complexity.
• Remove unused Identities.

Managing all the identities in your cloud environment and their relationships to your cloud resources requires automated policies to govern access.

Privilege Escalation

Privilege escalation, a serious threat to cloud security, occurs when an attacker gains low-level access and then exploits the initial identity’s relationships to other Identities with higher levels of access. The risk of privilege escalation grows as the number of identities in your cloud environment increases.

A simple example would be a very limited access role that permits a user to get a Unix Shell on an Amazon EC2 instance. Each EC2 instance will have its own role. If that EC2 Instance happens to have a highly privileged role, the user can then execute commands from that EC2 and take advantage of those higher privileges.

Another example is cross-account privilege escalation, which exploits trust relationships. A trust relationship defines which identities in one account can interact with resources in a different account. Trust relationships are necessary when resources across multiple accounts may need interaction to complete a transaction. With this attack, a hacker with a limited access role in one account will try to exploit these trust relationships to gain access to highly privileged Identities in other accounts.

There are some simple approaches to limiting privilege escalation attacks:

• Minimize the number of identities in your accounts.
• Limit each identity to the minimal privileges it needs to complete its tasks, a.k.a. the “Principle of Least Privileges (PoLP).”
• Minimize and audit the identities that can create, modify, and destroy Resources in your cloud environment, such as compute instances and security groups.
• Minimize and audit trust relationships.

In the above examples, PoLP may have prevented the user from exploiting the role of the EC2 instance since it would be the minimal set of privileges necessary for the EC2. Minimizing trust relationships may have helped mitigate the cross-account attacks.

Stacklet’s Flexibility Based on Open Source DNA

IAM policy enforcement is a multifaceted problem that requires the appropriate tools to identify and remediate unnecessary, over-permission, or easily compromised identities and credentials. Furthermore, as cloud providers add more capabilities, the burden of IAM policy enforcement also increases.

It is challenging for proprietary vendors to invest in identity management to fully support all cloud providers. Typically, vendors invest based on a cloud provider’s popularity, meaning their identity management support is uneven across all Cloud Providers. From a customer’s point of view, this means they will need consistent identity management in a multi-cloud environment.

Stacklet stands out in the marketplace with its unique approach. It is built off an open source project, Cloud Custodian, which empowers not only Stacklet but also the open source community. The flexibility empowers developers to rapidly evolve the platform and support all cloud providers. They can enhance Cloud Custodian to add more Identity Management capabilities for new Cloud Services, improve the current Identity Management functionality, and support specific use cases a customer may have. This level of empowerment is truly inspiring and motivates developers to contribute to the platform’s evolution.

In simpler terms, Stacklet’s open-source DNA means that customers are not limited by a proprietary vendor. They will always have the flexibility and adaptability to tailor the platform to suit their specific needs. This reassurance instills confidence in the platform’s ability to meet each customer’s unique requirements.

Stacklet Policies for IAM

Stacklet provides a robust set of pre-build Policies to audit and remediate Identity and Access Management. The policies below were selected to highlight how Stacklet can help manage identity and access risk in your cloud environment.

Removal of Unused Identities
The first step of identity management is to remove unused Identities. This proactive measure significantly reduces the risk of unauthorized access to your Cloud Environment, making auditing and reviewing Identities easier and more secure.
The following policy removes Identities that have not been used for 45 days. This type of monitoring requires automation since you need to prune unused Identities as soon as they hit the 45-day threshold.

Over-Permissioned Identities Due to Poorly Written Policies

Unfortunately, many IAM policies are not written with best practices in mind; they were written to work for all users in all environments. These policies apply blanket permissions across a range of resources. Hackers target and exploit overly permission policies as they can be used to affect a large part of your cloud environment.

Part of identity management is auditing all identity policies to ensure they do not override permissions by default, i.e., applying the least privilege principle (PoLP). This Stacklet policy audits your cloud environment for IAM policies that may be overly permissive.

Limit the Number of Highly Privileged Identities

All cloud environments need highly privileged identity policies to deploy applications and create new cloud resources, such as databases. However, these policies should be minimized.

One common practice that creates security vulnerabilities is using these highly privileged policies in roles that do not need them. Once these roles are compromised, directly or indirectly, by another role assuming access to them, the hacker can gain total access to your cloud environment.

This Stacklet policy reviews all your roles for access to these highly privileged policies and removes those roles. Since roles in your cloud environment will change over time, monitoring this security vulnerability is essential.

Identify Users Without Multi-Factor (MFA) Enabled
Good Authentication is the most effective way to prevent hackers from entering your Cloud Environment. Ensuring all your Users have and use MFA for access is a significant step towards preventing hacks.

Remember, the policy below is designed to identify users who do not have MFA enabled, a crucial step in ensuring the security of your Cloud Environment. With MFA in place, you can be reassured and confident in your security measures.

Remove Old User Access Keys
This is a straightforward yet essential policy. Regularly rotating access keys is a simple yet effective way to improve security when a User’s access keys have been lost or compromised.

Conclusion

Getting your IAM policies right is critical towards safeguarding your cloud environment. Applying standard security practices, like limiting the number of highly privileged identities, removing unused identities, etc., will limit exposure and reduce the blast radius if your cloud environment is compromised.

Enforcing IAM policies is a complicated task that requires 24/7/365 activity. Automated tooling must provide actionable information or take action to help secure your cloud environment.

Stacklet provides out-of-the-box capabilities to monitor and remediate potential risks due to bad IAM hygiene. Users can leverage Stacklet to enable quick, continuous enforcement of IAM policies, which reduces the attack surface and deters breaches.

If you are interested, please sign up for a demo here.