Detecting IAM Security Misconfigurations

All the attacks shown were possible because of misconfigurations somewhere in the environment. The use cases shown might seem unlikely, but are you sure you have a clear picture and really know what permissions are applied in your environment? Even more important, how can you track and validate the changes applied?

Detecting Malicious Cloud Changes

Fortunately, when the attacker uses the privileges attached to the compromised user, they are going to leave very recognizable tracks. Also, when someone is performing changes in the infrastructure, it will leave tracks showing what action has been performed and over what type of service.

AWS provides strong capabilities to understand what is going on in the environment. CloudTrail [9] records actions taken by a user, a role, or an AWS service from the AWS Management Console, AWS CLI, and AWS SDKs and APIs. With this tool, you can see the operator calling the UpdateAssumeRolePolicy, along with the target role and other context information (Figure 17).

Figure 17: CloudTrail attacker trail.

With the use of another AWS feature, CloudWatch [10], it's possible to create alerts from CloudTrail events. In this case, Listing 1 creates an alert if someone enables the specified events.

{ ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Put*Policy") || ($.eventName = "Attach*") || ($.eventName = "Detach*") || ($.eventName = "Create*") || ($.eventName = "Update*") || ($.eventName = "Upload*") || ($.eventName = "Delete*") || ($.eventName = "Remove*") || ($.eventName = "Set*")) ) }
{ ( ($.eventSource = "iam.amazonaws.com") && (($.eventName = "Add*") || ($.eventName = "Attach*") || ($.eventName = "Change*") || ($.eventName = "Create*") || ($.eventName = "Deactivate*") || ($.eventName = "Delete*") || ($.eventName = "Detach*") || ($.eventName = "Enable*") || ($.eventName = "Put*") || ($.eventName = "Remove*") || ($.eventName = "Set*") || ($.eventName = "Update*") || ($.eventName = "Upload*")) ) }

Difficulties Detecting IAM Security Misconfigurations

Detecting attackers once they have successfully compromised a user is difficult because they aren't displaying malicious behavior per se. Running instances or updating AssumeRolePolicyDocument are legitimate actions if done by the right people. How, then, can you know whether a user is really authorized to perform a specific action and proactively take measures before something bad happens?

To answer this question, you need to have a clear view of your environment and the application of security best practices. Best practices for cloud IAM come in handy when you need to assess the privileges attached to each user or group. For example, if you have applied the least privilege concept in your environment and see that the dev group has policies attached related to IAM, you can easily understand that something wrong is in place for this specific group.

However, applying best practices isn't enough. To be sure to enforce best practices and proactively take remediation action, you need to know what is in place in your environment. Of course, it's not that easy to have a nice, clear picture of which policies and roles are applied to a group, user, or service account. You have to rely on security tools that continuously monitor for anomalous activity in the cloud and can generate security events from there. In the case of AWS, you can gather traces from CloudTrail events, among other sources. With the right tools, you can easily assess and strengthen your cloud security.