Last year’s IDC’s Cloud Security Survey found that nearly 80 percent of companies polled have suffered at least one cloud data breach in the past 18 months.
The top three cloud security threats are security misconfiguration of production environments (67 percent), lack of visibility into access in production environments (64 percent), and improper IAM and permission configurations (61 percent)
According to the Cloud Native Security White Paper, in the Identity and Access Management section, it claims applications and workloads should be explicitly authorized to communicate with each other using mutual authentication.
That’s the role of Identity and Access Management (IAM): controlling who has access to which resource, making it an incredibly important aspect of cloud security. Given its integration with every other cloud service, it has one of the most complex architectures within AWS.
Why you need to secure AWS IAM
IAM aims to ensure that any given identity has access to the right resources (applications, databases, networks, etc.), and within the correct context. For AWS IAM, that means all assets on your cloud account.
To make it more clear: If this service falls into malicious hands, they will have access to your whole cloud infrastructure.
To access account activity history for IAM users and roles, you can query AWS CloudTrail event history, Amazon CloudWatch queries, or Amazon Athena.
Then, you need to compare each audit event against access control policies.
Keep in mind that the more users, applications, and microservices you’ll have in your cloud account, the more information (events) you generate, resulting in not being able to see the forest for the trees.
Common IAM misconfigurations you should check for in your policies are:
- MFA (Multi Factor Authentication) not enabled.
- Not following password best practices.
- Not disabling unused credentials.
- Attaching IAM policies to users instead of groups or roles.
- Not rotating keys frequently.
- EC2 instances without proper access to resources.
- Not applying the least privilege principle.
- Resource-based policies are not attached to a defined resource.
Out-of-the-box Sysdig rules for IAM
Sysdig Secure comes with many out-of-the-box rules related to cloud services like EC2 host instances, Fargate tasks, the Elastic Load Balancing service, and IAM as well.
Right now, we have 30+ different rules that will help you improve the security of your AWS account and ensure you don’t have IAM configuration drift.
You can add as many rules as you need to meet your particular needs by just using the same language you are using to create container and Kubernetes security rules.
If you are new to our rule’s language, a couple of months ago, we released the Rule Tuner to make the process of editing, creating, or modifying rules even easier!
Sysdig rules for AWS IAM deep dive
At the time of writing this article, this is the complete set of out-of-the-box rules for AWS IAM that you can find in Sysdig Secure:
| # | RULE | Description | priority |
| 1 | Add AWS User to Group | Detect adding an user to a group. | INFO |
| 2 | Attach Administrator Policy | Detect attaching an administrator policy to a user. | WARNING |
| 3 | Attach IAM Policy to User | Detect attaching an IAM policy to a user. | NOTICE |
| 4 | Create Group | Detect creation of a new user group. | WARNING |
| 5 | Create Security Group Rule Allowing SSH Ingress | Detect creation of security group rule. allowing SSH ingress. | ERROR |
| 6 | Create AWS user | Detect creation of a new AWS user. | INFO |
| 7 | Create IAM Policy that Allows All | Detect creation of IAM policy that allows all. | CRITICAL |
| 8 | Create Access Key for Root User | Detect creation of an access key for root. | CRITICAL |
| 9 | Create Security Group Rule Allowing Ingress Open to the World | Detect creation of security group rule allowing ingress open to the world. | CRITICAL |
| 10 | Console Login Failure | Detect a console login failure | WARNING |
| 11 | Console Login Without MFA | Detect a console login without MFA. | CRITICAL |
| 12 | Console Root Login Without MFA | Detected a root console login without MFA. | CRITICAL |
| 13 | Deactivate Hardware MFA for Root User | Detect deactivating hardware MFA configuration for root. | CRITICAL |
| 14 | Deactivate MFA for Root User | Detect deactivating MFA configuration for root. | CRITICAL |
| 15 | Deactivate Virtual MFA for Root User | Detect deactivating virtual MFA configuration for root. | CRITICAL |
| 16 | Delete Virtual MFA for Root User | Detect deleting MFA configuration for root. | CRITICAL |
| 17 | Deactivate MFA for User Access | Detect deactivating MFA configuration for user access. | WARNING |
| 18 | Logged in without Using MFA | Detect user login without using MFA (multi-factor authentication). | CRITICAL |
| 19 | Delete Group | Detect deletion of a user group. | WARNING |
| 20 | Password Recovery Requested | Detect AWS IAM password recovery requests. | WARNING |
| 21 | Put IAM Inline Policy to User | Detect putting an IAM inline policy to an user. | NOTICE |
| 22 | Put Inline Policy in Group to Allow Access to All Resources | Detect putting an inline policy in a group that allows access to all resources. | WARNING |
| 23 | Root User Executing AWS Command | Detect root user executing AWS command. | CRITICAL |
| 24 | Update Account Password Policy Not Requiring 14 Characters | Detect updating password policy not requiring a minimum length of 14 characters. | WARNING |
| 25 | Update Account Password Policy Not Requiring 7 Characters | Detect updating password policy not requiring a minimum length of 7 characters. | WARNING |
| 26 | Update Account Password Policy Expiring in More Than 90 Days | Detect updating password policy expiring in more than 90 days. | NOTICE |
| 27 | Update Account Password Policy Not Expiring | Detect updating password policy not expiring at all. | NOTICE |
| 28 | Update Account Password Policy Not Preventing Reuse of Last 24 Passwords | Detect updating password policy not preventing reuse of the last 24 passwords. | NOTICE |
| 29 | Update Account Password Policy Not Preventing Reuse of Last 4 Passwords | Detect updating password policy not preventing reuse of the last 4 passwords. | WARNING |
| 30 | Update Account Password Policy Not Requiring Lowercase | Detect updating password policy not requiring the use of a lowercase letter. | WARNING |
| 31 | Update Account Password Policy Not Requiring Number | Detect updating password policy not requiring the use of a number. | WARNING |
| 32 | Update Account Password Policy Not Requiring Symbol | Detect updating password policy not requiring the use of a symbol. | WARNING |
| 33 | Update Account Password Policy Not Requiring Uppercase | Detect updating password policy not requiring the use of an uppercase letter. | WARNING |
| 34 | Update Assume Role Policy | Detect modifying a role. | WARNING |
Let’s take a deeper look into some of the rules we provide in Sysdig Secure for AWS IAM.
Rule #8 – Create access key for root user
Wait, you can do better.
Do you know what would be smarter than detecting an AWS account root user executing commands? Not having an access key at all!
No problema, we detect that also. :)
Then, if you need administrator access, just create IAM users for each person that will be responsible for those particular tasks.
Remember to place the users into an “Administrators” user group and attach the AdministratorAccess managed policy.
Rule #18 – Logged in without using Multi-Factor authentication.
Another classic IAM security best practice is to set up Multi-Factor Authentication (MFA). MFA aims to protect you by adding an additional layer of security, making it harder for someone with malicious intentions to log in as if they were you.
If thieves need to steal both of your authentication methods, maybe they will think twice.
Enabling MFA authentication for each user on your AWS account is a pretty good starting point.
If someone logs in without an MFA… Sysdig will alert you right away.
Rule #23 – Root user executing AWS command
You don’t use your AWS account root user to execute any AWS command. Period.
The access key for your AWS account root user gives full access to your resources for all AWS services, including your billing information!!!
We know you will never use your AWS account root user to create a new EKS cluster, for instance, so let’s have that in place just in case. If an attacker gains access to your root user access key, it could be devastating.
The rules are very flexible and transparent to users. You can see exactly what the rule does and why a particular event triggers an alert.
We hope you never see this
… in your production account!
If you are already using Sysdig Secure rules for runtime detection, you don’t need to learn another rule policy language just because you are now on the cloud context.
From the same UI, you can create rules for cloud and containers using the exact same language.
Now, from the Insights Cloud Activity view, you can see a complete timeline of your security events, bridging together workload protection (blue box) and cloud security (orange box).
Secure your cloud with Sysdig
If you want to dig deeper into this topic, check our article on how an attacker can perform lateral movement from a vulnerable container, compromising your whole cloud infrastructure. In addition, dig deeper to the 26 AWS security best practices to adopt in production.
With Sysdig Secure for cloud, you can continuously flag cloud misconfigurations before the bad guys get in and detect suspicious activity, like unusual logins from leaked credentials. This all happens in a single console, making it easier to validate your cloud security posture. And it only takes a few minutes to get started!
Start securing your cloud for free with our Sysdig Free Tier!