Securing AWS IAM with Sysdig Secure

By Alba Ferri - AUGUST 5, 2021


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:

1Add AWS User to GroupDetect adding an user to a group.INFO
2Attach Administrator PolicyDetect attaching an administrator policy to a user.WARNING
3Attach IAM Policy to UserDetect attaching an IAM policy to a user.NOTICE
4Create GroupDetect creation of a new user group.WARNING
5Create Security Group Rule Allowing SSH IngressDetect creation of security group rule. allowing SSH ingress.ERROR
6Create AWS userDetect creation of a new AWS user.INFO
7Create IAM Policy that Allows AllDetect creation of IAM policy that allows all.CRITICAL
8Create Access Key for Root UserDetect creation of an access key for root.CRITICAL
9Create Security Group Rule Allowing Ingress Open to the WorldDetect creation of security group rule allowing ingress open to the world.CRITICAL
10Console Login FailureDetect a console login failureWARNING
11Console Login Without MFADetect a console login without MFA.CRITICAL
12Console Root Login Without MFADetected a root console login without MFA.CRITICAL
13Deactivate Hardware MFA for Root UserDetect deactivating hardware MFA configuration for root.CRITICAL
14Deactivate MFA for Root UserDetect deactivating MFA configuration for root.CRITICAL
15Deactivate Virtual MFA for Root UserDetect deactivating virtual MFA configuration for root.CRITICAL
16Delete Virtual MFA for Root UserDetect deleting MFA configuration for root.CRITICAL
17Deactivate MFA for User AccessDetect deactivating MFA configuration for user access.WARNING
18Logged in without Using MFADetect user login without using MFA (multi-factor authentication).CRITICAL
19Delete GroupDetect deletion of a user group.WARNING
20Password Recovery RequestedDetect AWS IAM password recovery requests.WARNING
21Put IAM Inline Policy to UserDetect putting an IAM inline policy to an user.NOTICE
22Put Inline Policy in Group to Allow Access to All ResourcesDetect putting an inline policy in a group that allows access to all resources.WARNING
23Root User Executing AWS CommandDetect root user executing AWS command.CRITICAL
24Update Account Password Policy Not Requiring 14 CharactersDetect updating password policy not requiring a minimum length of 14 characters.WARNING
25Update Account Password Policy Not Requiring 7 CharactersDetect updating password policy not requiring a minimum length of 7 characters.WARNING
26Update Account Password Policy Expiring in More Than 90 DaysDetect updating password policy expiring in more than 90 days.NOTICE
27Update Account Password Policy Not ExpiringDetect updating password policy not expiring at all.NOTICE
28Update Account Password Policy Not Preventing Reuse of Last 24 PasswordsDetect updating password policy not preventing reuse of the last 24 passwords.NOTICE
29Update Account Password Policy Not Preventing Reuse of Last 4 PasswordsDetect updating password policy not preventing reuse of the last 4 passwords.WARNING
30Update Account Password Policy Not Requiring LowercaseDetect updating password policy not requiring the use of a lowercase letter.WARNING
31Update Account Password Policy Not Requiring NumberDetect updating password policy not requiring the use of a number.WARNING
32Update Account Password Policy Not Requiring SymbolDetect updating password policy not requiring the use of a symbol.WARNING
33Update Account Password Policy Not Requiring UppercaseDetect updating password policy not requiring the use of an uppercase letter.WARNING
34Update Assume Role PolicyDetect 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!

Subscribe and get the latest updates