AWS IAM Access Analyzer now has an API allowing you to make custom policy checks. Tenable Cloud Security allows you to easily use this API as part of its code scanning functionality. Find out how and why it’s important.

AWS today announced a significant enhancement to AWS IAM Access Analyzer (AA) allowing, among other things, the performing of custom policy checks on IAM and resource based policies to enable security teams to proactively detect nonconformant updates to their policies.

IAM Access Analyzer provides tools to set, verify, and refine AWS IAM permissions through access analysis, policy checks and policy generation. Access analysis generates insights that are easy to visualize and take action. Overall, it guides customers towards least privilege permissions.

As specified in the AWS documentation: AA allows you to “identify resources in your organization and accounts that are shared with an external entity,” “validates IAM policies against policy grammar and best practices” and “generates IAM policies based on access activity in your AWS CloudTrail logs.”

AWS has announced a new ability allowing users to perform custom checks in addition to built-in rules-based checks. When creating a new IAM / resource-based policy or updating an existing one, you will now be able to query an API to check whether a policy / a new version of it:

• adds additional access that wasn’t in the previous version of the policy
• grants access to permissions restricted by your corporate security standards
• grants access outside of a predefined boundary.

According to AWS, this is done using “the power of automated reasoning — security assurance backed by mathematical proof.”

This could potentially be a major utility for security teams everywhere, offering more fine-grained — and as we’ll see later in this post, flexible — verification of IAM policies before deployment.

This new functionality is integrated with Tenable Cloud Security which makes it more accessible to our customers, allowing them to leverage it as part of our existing code scanning functionality — without writing a single additional line of code.

When SCPs don’t apply

To understand the huge potential, we need to understand the difference between this new ability and a different security control which, personally, I’m a big fan of: the Service Control Policy (SCP). With an SCP, you can set a limit on the potential permissions given to identities within an account (it’s evaluated as part of AWS’s policy evaluation logic). It’s a great tool for capping the services, actions and resources that identities in your account may have access to or limiting sensitive / potentially hazardous activity you definitely want to deny from identities in your account. For example, a very popular SCP denies the ability to launch Elastic Compute Cloud (EC2) instances with Instance Metadata Service version 1 (IMDSv1) enabled or modify the existing metadata options of existing instances (so IMDSv1 can’t be enabled), which looks something like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:RunInstances"
      ],
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ],
      "Effect": "Deny",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    },
    {
      "Action": "ec2:ModifyInstanceMetadataOptions",
      "Resource": "*",
      "Effect": "Deny",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalArn": "<PRIVILEGED_ROLE>"
        }
      }
    }
  ]
}

As a side note, it appears that a similar function will also be supported soon on the account level without an SCP.

SCPs have many great use cases for creating data perimeters and applying security best practices, and I highly recommend reviewing the AWS’s Github repository with examples for such SCPs.

As great as SCPs are, it can be risky applying them to an AWS account, when it’s not THAT clear whether or not the actions they deny should, in fact, be denied. This may block needed functionality and compromise legitimate activity (which is basically a Denial of Service — probably the last thing a security team wants to do). For this reason, it’s important to make sure SCPs are properly tested before deployment in production!

As we’ve seen in some cases, this may be learned the hard way: 

And sometimes it might even be difficult to detect that the cause of an Access Denied error is an SCP. Because of this, my Tenable Cloud Security colleague, Noam Forman Dahan has published the access undenied open source CLI tool, which I highly recommend you check out.

The non-boundary boundary

So, what you can NOW do with the new AA functionality is construct a “boundary” without really setting an explicit boundary.

As the AWS feature release statement also indicates: “Security teams can use these checks to streamline their reviews, automatically approving policies that conform with their security standards, and inspecting more deeply when they don't.”

Using this API, a “policy check step” can be added to the process of creating / updating policies in AWS.

This allows the security team to add a customizable enforcement logic and procedure instead of a strict boundary.

At Tenable, we have taken advantage of this new functionality and produced an integration with our product that makes it much easier for our customers to perform this step as part of their continuous integration / continuous delivery (CI/CD) procedure.

As we already offered scanning for our customers to detect potential security misconfigurations, we can now send IAM policies to the AA API and perform these custom checks for both pre-configured rules created by our security researchers (e.g. wide scope and actions allowing privilege escalation) and policies configured by the customer.

Fig. 1: Advanced Policies built-in Tenable Cloud Security for custom policy checks with AA

Image source: Tenable, November 2023

The results of such a scan go into the same location as our scan results:

Fig. 2: Tenable Cloud Security IaC scan results

Image Source: Tenable, November 2023

This allows our customers to get additional *out-of-the-box* insights into their policies before applying them — as Tenable researchers integrate opinionated checks about sensitive / critical action. Customers may also configure their own checks for actions they deem particularly interesting.

This integration can extend to the customer’s CI/CD, enabling significant flexibility for security teams to determine how to respond to a proposed permissions assignment to actions that shouldn’t necessarily be outright denied.

Instead of simply denying the permissions at the point an identity tries to use them, security teams can block a build for a certain environment (e.g. a production environment) at a much earlier phase — when the assignment of the permissions is detected. Then, with their intervention and examination, it would either be excluded from the rule and assigned anyway, or replaced with a less privileged set of permissions to avoid their assignment.

Alternatively, security teams can decide to simply have the finding generate a warning and allow DevOps teams — or even the developers themselves — use their discretion in deciding the best course of action.

Fig. 3: Tenable Cloud Security integration with a CI/CD pipeline (Github Actions)

Image Source: Tenable, November 2023

Integrated with the powerful tools of Tenable Cloud Security, the functionality becomes much more accessible and easy to use.

If you’re interested in seeing a demo of Tenable Cloud Security visit https://www.tenable.com/products/tenable-cloud-security