Regula, our open-source infrastructure as code (IaC) policy engine, now supports AWS CloudFormation. This means you can use Regula to perform static analysis of CloudFormation YAML or JSON templates for security vulnerabilities and compliance violations – including templates that use the Serverless Application Model. For instance, if a template declares an EBS volume that does not have encryption enabled, Regula’s report will show which template – and which specific resource – failed the check.

Regula can be run with a script locally, with Docker, and soon with a CLI. You can hook Regula into your CI/CD processes to fail builds when Regula detects a high-severity vulnerability in your CloudFormation templates, for example. And Regula can identify misconfiguration vulnerabilities involving multiple resources and help you meet CIS AWS Foundations Benchmarks 1.2.0 and 1.3.0.

In this walkthrough, we’ll demonstrate how to use Regula to assess two CloudFormation templates: a “good” one with compliant resources, and a “bad” one that intentionally contains security vulnerabilities. (Don’t create this stack in AWS!)

Let’s get started!

Prerequisites

To get set up, we’ll install Regula and then clone the example IaC repo.

1. Install Regula via Homebrew (macOS and Linux) or prebuilt binary (all platforms). (Tip: Regula is available as a Docker image, too!)

2. Clone the regula-ci-example repo containing the sample CloudFormation templates:

git clone https://github.com/fugue/regula-ci-example.git

3. Move into the regula-ci-example directory:

cd regula-ci-example

Setup complete!

The infrastructure

Now, let’s take a look at the “bad” CloudFormation template we’re going to evaluate. It describes 9 IAM resources:

• 6 policies
• 1 role
• 1 user
• 1 group

You’ll see that some resources are named “Invalid” and some are named “Valid.” That’s because all but 3 of the resources were intentionally written to violate at least one rule in the Regula library. Which resources violate which rules? We’ll run Regula to find out!

Running Regula

It’s easy to evaluate CloudFormation with Regula. To run Regula against any IaC, you execute the run command:

regula run [input...] [flags]

So in our case, you’d just run this command to check the “bad” template against Regula’s  entire library of rules:

regula run infra_cfn/cloudformation.yaml

… And that’s it! It’s really that simple. Now, let’s go over the output, and we’ll find out which resources have security vulnerabilities.

Reviewing Regula’s report

The Regula report is chock-full of useful data, formatted as JSON for easy integration into testing tools. There are two main components: a list of rule results and a summary.

Each time Regula evaluates a resource against a rule, it returns a rule result with a value of PASS, FAIL, or WAIVED (yes – Regula supports  waivers! Regula has a flexible mechanism to waive rules that you don't want to apply). For each rule result, Regula shows accompanying metadata such as the evaluated resource ID, rule description, rule severity level, and more. It also shows compliance controls mapped to the rule. For instance, “CIS-AWS_v1.2.0_1.22” represents control 1.22 in CIS AWS Foundations Benchmark v1.2.0.

Here’s one of the rule results from our test:

{
  "rule_results": [
    {
      "controls": [
        "CIS-AWS_v1.2.0_1.22",
        "CIS-AWS_v1.3.0_1.16"
      ],
      "filepath": "infra_cfn/cloudformation.yaml",
      "platform": "cloudformation",
      "provider": "aws",
      "resource_id": "InvalidPolicy01",
      "resource_type": "AWS::IAM::Policy",
      "rule_description": "IAM policies should not have full \"*:*\" administrative privileges. IAM policies should start with a minimum set of permissions and include more as needed rather than starting with full administrative privileges. Providing full administrative privileges when unnecessary exposes resources to potentially unwanted actions.",
      "rule_id": "FG_R00092",
      "rule_message": "",
      "rule_name": "cfn_iam_admin_policy",
      "rule_result": "FAIL",
      "rule_severity": "High",
      "rule_summary": "IAM policies should not have full \"*:*\" administrative privileges"
    },
    ... cut for length ...

Above, we can see that InvalidPolicy01 violates the rule “IAM policies should not have full "*:*" administrative privileges.” Taking a look at the CloudFormation template itself, we can see that the policy does indeed allow "*:*" privileges for all principals. That’s not very secure!

     PolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Action: '*'
          Resource: '*'

The second part of the Regula report is the summary. You’ll see a list of filepaths evaluated; the number of FAIL, PASS, or WAIVED results; and the severity of the failing rule results:

 "summary": {
    "filepaths": [
      "infra_cfn/cloudformation.yaml"
    ],
    "rule_results": {
      "FAIL": 7,
      "PASS": 10,
      "WAIVED": 0
    },
    "severities": {
      "Critical": 0,
      "High": 6,
      "Informational": 0,
      "Low": 1,
      "Medium": 0,
      "Unknown": 0
    }
  }
}

Checking multiple templates at once

Now, let’s add an example compliant CloudFormation template to the check. We can see that it declares 1 IAM role and 1 IAM policy, neither of which allows full "*:*" admin permissions:

AWSTemplateFormatVersion: '2010-09-09'
Resources:
  ValidRole01:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Principal:
            Service: ['ec2.amazonaws.com']
          Action:
          - sts:AssumeRole

  ValidPolicy01:
    Type: AWS::IAM::Policy
    Properties:
      Roles:
      - !Ref ValidRole01
      PolicyName: valid_policy_01
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          Effect: Allow
          Action:
          - 'ec2:StartInstances'
          Resource:
          - '*'

Run the following command to check both templates at once:

regula run infra_cfn/cloudformation.yaml infra_valid_cfn/cloudformation.yaml

The new report indicates that there were 7 FAIL and 13 PASS rule results, and you’ll note that Regula lists both filenames:

 "summary": {
    "filenames": [
      "infra_cfn/cloudformation.yaml",
      "infra_valid_cfn/cloudformation.yaml"
    ],
    "rule_results": {
      "FAIL": 7,
      "PASS": 13,
      "WAIVED": 0
    },
    "severities": {
      "Critical": 0,
      "High": 6,
      "Informational": 0,
      "Low": 1,
      "Medium": 0,
      "Unknown": 0
    }
  }
}

Resolving the CloudFormation template security issues

Pretty cool, right? But we’re not done yet! For the final step of this tutorial, we’re going to fix the CloudFormation misconfigurations.

For this part, you’ll need to edit the regula-ci-example/infra_cfn/cloudformation.yaml file, so open it up in your favorite text editor.

On the following lines, change Allow to Deny:

• Line 78
• Line 90
• Line 102
• Line 115
• Line 128
• Line 144

On line 85, insert a new line and paste in the following two lines:

     Groups:
      - !Ref InvalidGroup01

Finally, comment out lines 87-94.

The entire InvalidUser01 block (lines 82-94) should look like this now:

 InvalidUser01:
    Type: AWS::IAM::User
    Properties:
      Groups:
      - !Ref InvalidGroup01
      # Policies:
      # - PolicyName: invalid_user_01
      #   PolicyDocument:
      #     Version: '2012-10-17'
      #     Statement:
      #     - Effect: Deny
      #       Action: '*'
      #       Resource: '*'

We just changed all of the “allow all” policies (both inline and managed) to be “deny all,” which resolves the rule “IAM policies should not have full "*:*" administrative privileges.” This is just an example, though. In a real-world scenario, you'd want a carefully crafted policy that allows the required permissions -- and only those permissions, of course!

As an added bonus, we’ve also resolved the rule “IAM policies should not be attached to users” by adding InvalidUser01 to the InvalidGroup01 group and removing the user's inline policy. (What's this rule about? It corresponds to control 1.15 in CIS AWS v1.3.0, "Ensure IAM Users Receive Permissions Only Through Groups." Per CIS, assigning a user privileges via a group makes access management easier, which reduces the chance of excessive permissions.)

Run the command again:

regula run infra_cfn/cloudformation.yaml infra_valid_cfn/cloudformation.yaml

You should see that all 20 of the rule results pass! Check out the new summary:

 "summary": {
    "filenames": [
      "infra_cfn/cloudformation.yaml",
      "infra_valid_cfn/cloudformation.yaml"
    ],
    "rule_results": {
      "FAIL": 0,
      "PASS": 20,
      "WAIVED": 0
    },
    "severities": {
      "Critical": 0,
      "High": 0,
      "Informational": 0,
      "Low": 0,
      "Medium": 0,
      "Unknown": 0
    }
  }
}

Congratulations! You just checked two CloudFormation templates for security and compliance violations using Regula and fixed the vulnerabilities. Now you can run Regula on your own IaC! In fact, for extra credit, you can even write your own rules. Regula supports multi-resource rules, which can identify misconfigurations that span more than one resource, and even identify missing resources.

What’s next?

Regula works independently of Fugue, but you can use Fugue to apply the same Rego rules to assess the security posture of your cloud infrastructure environments. If you had created the vulnerable CloudFormation stack (and we hope you didn’t!), Fugue would identify the violations and help you remediate them. Fugue will also catch violations introduced to your cloud environment outside of CloudFormation. 

To learn more about Regula, see the Regula documentation.

The Fugue Guarantee

Fugue guarantees your success: Gain a complete, actionable view of your cloud environment and security posture in 15 minutes, and bring your cloud into compliance in 8 weeks under the Fugue FastTrack package. Learn more here.