Automating infrastructure code audits with tfsec

Unless you’ve been living under a rock for the last few years, you’ll know a few things about the Cloud:

• Functionality and capabilities released by Cloud vendors are expanding at an exponential rate.
• DevOps paradigm is (seemingly) here to stay – the several cold days of building physical hardware sat on the floor of a datacentre where I started my career are a rarity.
• Infrastructure as Code makes it ridiculously easy to quickly deploy a vast inventory of resources

All of the above are excellent, and each re:invent, ignite, etc get me as excited as my little kids in the run-up to Christmas, just thinking about all those potentially new goodies to play with. But even as an overly excited security monkey, keeping track of ALL that functionality is near impossible, and ensuring that you don’t introduce a weakness into your environment when leveraging the latest and greatest tech is fraught with danger.

There are many platforms to help identify configuration weaknesses; within AWS I’ve been a great fan of SecurityHub since it’s announcement in 2018, especially after the release of the Foundational Security Best Practice standard earlier this year – but as useful as SecHub is, it’s a bit stable-door-y, in that it’s identifying issues after they’re in your environment. What if there was a better way?….

TFSec

With the advent of Infrastructure as Code (IaC) referenced above, I’ve been building a lot of cloud architecture as code; and the environment’s I’ve been working within have tended to leverage Terraform’s platform for this purpose. TFSec is a tool to identify potential security issues with a projects plans/designs before you commit to deploying the resources into your production environment. And taken a step further, tfsec’s design can be leveraged to implement into your existing CI/CD pipeline (either passive or blocking), allowing common security issues to be identified automatically during the standard deployment process, without needing any specific input from the security team.

Sound good? Let’s take a closer look….

Install

I’ll not steal any thunder from the tfsec documentation, but I found installation surprisingly straightforward, a one-liner with your favourite package manager was all it took to get the binary on my system

choco install tfsec

Running

Running the tool is equally straightforward from your local system. Simply navigate to the directory containing the project you have concerns about, and:

tfsec

Yes, it really is that straightforward.

Example/demo time…

Using the AWS Access Key Honeypot hobby project I’ve been working on recently as an example, tfsec ran a quick audit and identified that the SNS Topic used for notifications, whilst working perfectly for happy-path use-case, wasn’t encrypting it’s messages in transit.

code\Access-Key-Pot>tfsec     

Problem 1

  [AWS016][ERROR] Resource 'aws_sns_topic.honeypot-notifications' defines an unencrypted SNS topic.
  C:\Users\awaite\Documents\code\Access-Key-Pot\cloudwatch.tf:9-31

       6 |   name = var.cloudtrail_logs
       7 | }
       8 |
       9 | resource "aws_sns_topic" "honeypot-notifications" {
      10 |
      11 |   name            = "honeypotAlarmsTopic"
      12 |   delivery_policy = <<EOF
      13 | {
      14 |   "http": {
      15 |     "defaultHealthyRetryPolicy": {
      16 |       "minDelayTarget": 20,
      17 |       "maxDelayTarget": 20,
      18 |       "numRetries": 3,
      19 |       "numMaxDelayRetries": 0,
      20 |       "numNoDelayRetries": 0,
      21 |       "numMinDelayRetries": 0,
      22 |       "backoffFunction": "linear"
      23 |     },
      24 |     "disableSubscriptionOverrides": false,
      25 |     "defaultThrottlePolicy": {
      26 |       "maxReceivesPerSecond": 1
      27 |     }
      28 |   }
      29 | }
      30 | EOF
      31 | }
      32 |
      33 | resource "aws_cloudwatch_log_metric_filter" "honeyuser-metric" {
      34 |   name           = "HoneyUser_Activity"

  See https://tfsec.dev/docs/aws/AWS016/ for more information.

  disk i/o             9.4633ms
  parsing HCL          0s
  evaluating values    3.6542ms
  running checks       1.8473ms
  files loaded         4

1 potential problems detected.

A feature that I found really helpful when starting to work with tfsec, is that it maintains specific documentation for each configuration issue it checks against, including an explanation for why the finding is a problem, as well as a reference example of what a secure/resolved configuration looks like. In the case of the above, all details can be found at: https://www.tfsec.dev/docs/aws/AWS016/

In my case, the message content expected via the SNS Topic isn’t overly sensitive; and key management configuration is outside the scope of a demo project designed as a starting point for people to implement the same in their own environments (as all KMS key configurations, policies etc. could be different) – I may deal with this issue later, but for now I was happy with the single finding; but how to inform tfsec of this acceptance?

All findings/checks can be ignored within your code base, sticking with the above example, I added the below line to the SNS Topic’s resource block. Both telling tfsec to ignore the finding on output, and providing documentation of said decision, all trackable in source control as standard.

#tfsec:ignore:AWS016 - SNS topic encryption beyond scope of demo deployment

And with that, analysis of the updated project returns clean:

code\Access-Key-Pot>tfsec

  disk i/o             9.4636ms
  parsing HCL          0s
  evaluating values    500.5µs
  running checks       499.1µs
  files loaded         4

No problems detected!

Additional integrations

Whilst the above use case of manually checking your projects has a lot of merit, I believe the true potential value of tfsec (and similar tooling) comes from integration with the automated deployment pipelines leveraged by modern dev teams. Triggering a security audit of planned infrastructure on every change, and feeding the findings back into the project’s issues via (for example) Github Actions should make continuous security auditing painless, seamless, and all within platforms already familiar to your dev and infrastructure colleagues. Example (‘borrowed’ from tfsec’s documenation) below.

Cloud Agnostic

The other advantage tfsec provides over my previous example of AWS Security hub (or Azure’s Sentinel); is it’s ability to identify security issues across multiple IaaS vendors, currently covering the big 3 of AWS, Azure and GCP. If you’re concerned of being tied to one vendor, tfsec can help keep your toolset and skills transferable if (when?) your business unit changes direction to a different vendor, your change employer entirely, or simply find that ShadowIT platform that Bob from finance spun up on the weekend that needs an emergency review and lockdown.

Summary

So, go ahead, add tfsec into your deployment pipelines, throw the binary locally at the project you’re currently working on (or that ‘legacy’ platform that Sharon built years ago, and no one has had the confidence (/naivety?) to touch since she left….

—
Andrew