Security Hub gives me imposter syndrome

I’m about 30 days1 into building my fourth cloud security program. I want to avoid the mistakes or the past and focus on meaningful risk rather than compliance and security theater.

Coming on board, Security Hub was being used, and not wanting to rock the boat too much, I decided to enable it everywhere and use it for my KRI measurements.

Sadly, Security Hub failed to provide any valuable metrics. It generated so many findings that even I, someone who allegedly knows about cloud security, wanted to give up and raise Alpaca in North Georgia.

So, sit back and enjoy my review of AWS Security Hub.

Defining the Sensitive IAM Actions

Way back when I was working at Turner and deploying security audit roles, there were concerns over the level of access the ReadOnlyAccess policy would provide. We would have access to data that we were legally obligated to protect, but due to licensing and competition reasons, we could not be allowed to access. At the time, the specific division I was working with only stored this data in S3 and DynamoDB, so crafting a workaround that met everyone’s needs was reasonably straightforward.

Fast forward five years. AWS has gotten more complex, there are more services, and there still is no clear delineation between the access needed to audit an environment vs the access to the data in the environment.

Deploying Terraform using CodePipeline

There is no canonical way to use Terraform in CodeBuild, with CodePipeline as the method to review plans before applying them. This post defines a Cloudformation template and the buildspec files needed to create a CodePipeline that runs terraform plan, allows a human to review it, then runs terraform apply.