Discover what CIEM Security is and how easy it is to implement with Sysdig Secure for cloud.
Over-permissioned accounts and roles is the most common cloud service misconfiguration security problem. Implementing least privilege is a crucial best practice to avoid or mitigate risks of data breaches and contain privilege escalation and lateral movement.
In this article, we will:
- Explain why this is a problem.
- Provide some examples of dangerous situations CIEM security tries to avoid.
- Cover tools on the Cloud Infrastructure Entitlement Management (CIEM) category.
And finally, show how to use the new Sysdig Secure CIEM security feature to visualize usage of permissions across users, roles, and policies to strengthen your cloud security posture.
Why is IAM misconfiguration a big deal?
AWS Identity and Access Management (IAM) enables you to manage access to AWS services and resources securely. Using IAM, you can create and granularly manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
From what IAM is about, we can easily agree this is a piece of our infrastructure we need to focus on. If this service is misconfigured, users or groups might cause huge damage to your infrastructure.
Due to the fine granularity of permissions available in the Cloud environments, CIEM security is key in applying the least privileges concept. Carefully giving exactly what a user needs to perform its actions is absolutely fundamental. Just a misconfigured privilege could lead to an attacker escalating the privileges inside the environment.
But as cloud providers keep adding services and features, it becomes harder to know exactly what those least privileged settings are.
Often, developers rely on examples and documentation, very broad permissions are given, and later on that setup, the code goes to production.
Examples of issues covered by CIEM security
Think about a small scenario with the following components:
- An EC2 instance.
- An Apache server.
- Perform several read operations on an S3 bucket.
By giving an unneeded wildcard permission to the EC2 instance, the Apache server can write to the bucket, which is unnecessary. A vulnerability like the recent CVE-2021-41773 (Oct. 2021) could not only expose all the files in the EC2 machine and the bucket, but could also be used by someone to completely delete all the bucket’s content. Even worse, they could encrypt all the bucket’s information and demand a ransom payment.
So, when granting permissions, you need to consider not using wildcards for services.
As cloud providers add more and more services, you are giving away permissions on things you don’t know anything about, and it may be wrong for those users or roles to have them.
For example, granting a readonly permission on all "*" to a user might seem harmless. The user can’t change things, right?.
Well… it turns out that AWS Systems Manager (SSM) includes an ssm:DescribeParameters method accessible with read-only access, which can be used to read secrets stored as parameters 🤯. This is AWS’s recommended way to read secrets, and it makes complete sense.
Another common situation is not revoking long unused credentials.
Maybe a permission was granted for a time scoped task, then the admin forgot to revoke them after the task was completed. Perhaps some developers left the company without being removed from the system. And possibly the computers of one of these users got compromised and their access was used for malicious purposes.
You can prevent all of this by not allowing unused credentials to live for long.
Remember IAM vulnerabilities and weaknesses are not tracked by NIST and can’t have a CVE assigned, so they are not analyzed by vulnerability scans. It’s up to you to make sure all IAM policies, users, and roles follow best practices to avoid over-permissioned insecure situations.
CIEM security tools
To help manage these situations, there is a subcategory of tools called Cloud Infrastructure Entitlements Management (CIEM). These tools belong to the more general category of Cloud Infrastructure Security Posture (CSPM), and specialize in looking for over-permissioned accounts and roles, unused permissions, and unused accounts.
Although it’s possible to manually check some of these IAM weaknesses by hand, automating analysis across cloud accounts for access governance controls ensure a constant good health on the full identity lifecycle. And, as in any activity related to security:
“Automation is the key to maintaining speed and agility for DevOps.”
Implementing CIEM security mitigates the risk of data breaches in public clouds due to excessive entitlements.
How Sysdig Secure brings you CIEM security
Sysdig Secure for cloud analyzes the audit log of all executed cloud commands in your accounts and correlates them with policies, roles, and users.
When using threat detection, Sysdig Secure is already looking into the full stream of cloud commands. By constantly checking if any specific one triggers one of the out-of-the-box set of Falco rules, Sysdig detects misconfiguration or changes to assets that make them more vulnerable.
Adding CIEM security to the mix, all those commands are now processed to create a profile of permission usage on users, roles, and policies.
This way, Sysdig brings visibility to real permission usage and over-permissioned situations that translates to risk of an exposure in case of credential misuse.
When you visit the CIEM feature in the Posture section, a general dashboard informs you of:
- The total permissions given and used.
- How many users are inactive and which you should consider deleting.
- Averages of permissions per policy and policies per user.
- The policies, users, and roles with the worst case of unused permissions.
All those parameters are metrics that you should look to improve, and being able to glance at them in the general dashboard makes it easy to track your progress towards a stronger IAM security posture.
The dashboard gives a birds eye view of all the IAM policies and permissions and simplifies achieving least privilege cloud environment.
The most relevant one is the percentage of unused permissions a policy has.
Also, checking policies with a high number of permissions given, even if they are used, may be an indicator that it would be better to split those policies to reduce the risk of being over-permissive.
A quick glance will also tell you which policies contain a wildcard resource or action specification. That is not only a bad practice for being too permissive, but also because new types of resources or actions can be added by the cloud provider that will be affected by these policies without you realizing.
Checking the number of users that share the same policy is useful to clean up those policies that are not assigned to anyone, or to be extra careful of the ones that most users have assigned.
You can click on a policy to see the exact details of their permissions and to obtain a suggested version where only the ones observed as being used are present.
Make sure you validate that the proposed policy covers enough permissions for your use case before applying them, as we follow a conservative approach on giving permissions.
You can also browse focusing on users and roles.
This list allows you to check for:
- Unused permissions assigned directly to them.
- The total number of permissions and policies
Which brings you a different perspective to find weaknesses.
In addition, a last active date column can tell you which users have not logged in for a long time, so you should consider removing them to avoid their credentials being taken over if they live on some old environment that’s not well protected.
When you click on a user, you can check all the attached policies they have, and a count of permissions given and unused grouped per policy.
Conclusion
The Sysdig Secure DevOps Platform provides the visibility you need to confidently run containers, Kubernetes, and cloud. Built on an open-source stack with SaaS delivery, it is radically simple to run and scale.
You’ll be set in only a few minutes. Try it today!