So I did it again. Proving I’m the most incompetent Security Hero EVER, I committed eight different access keys to a public GitHub repository for eight different AWS Accounts.
What is fascinating is the consistently inconsistent response of AWS support. Behold a tale of seven cities and a professor.
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.
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.
I’ve apparently been selected as one of the first cohorts of AWS Security Heroes. I was hoping for the title of Microsoft Security Villian, but I’ve got to admit I’m pretty honored.
Last year, I did a two-day training at BSides Augusta focused on conducting incident response in AWS. I had fun, the students gave me positive feedback, and BSides Augusta has invited me back to do it again.
This past weekend I spoke at BSides Nashville - Get outta my host and into my cloud: A primer for offensive operations in AWS. This talk was similar to my talk last year on Incident Response in AWS at BSides Atlanta. The intent was not to teach pentesting or red teaming, but rather helping to spread cloud knowledge to those who do that on a daily basis.
I deliberately published an Access Key and Secrets. Here’s what happened.
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.
With ChatGPT being all the rage, I decided to see if she (it?) could write my next blog post for me. I’d already written all the Steampipe queries and determined the security value behind the blog post. I just didn’t feel like writing it.
The post’s topic was on enumerating your network-plane cloud perimeter.
My third annual pre:Invent roundup is posted over on Steampipe’s blog. You can also check out 2021 and 2020 if you’re so inclined.
Back in 2018, I wrote a semi-serious post on what you as a security practitioner should be looking for as it relates to re:Invent announcements.
There were a few hot-takes that didn’t warrant mention on my work post, so I’ll include them here for your general amusement.
