Chris Farris

Multicloud is Madness!!!!

Your organization is doing a poor job protecting the one cloud you have. Why in heaven’s name would you want to deploy into another cloud? In this two-part blog post, we’ll cover details from my HackCon 2024 talk “Chris Farris in the MultiCloud of Madness” (slides). Part one is here, and it covers all the weirdness between the three major hyperscalers - AWS, Azure, and GCP. The second part will provide checklists to help you establish Minimally Viable Cloud Governance in each cloud.

So earlier this year, I wrote (and then much later published) a blog post ripping AWS Security Hub. That led to conversations with folks on that team, and I got a chance to look at Security Hub’s new Central Configuration capabilities.

In short - this is an improvement for folks who use Security Hub and the built-in Security Standards. Sadly, it doesn’t solve many of the presentation issues that conflate “Compliance” and “Security”.

I’m back from re:Invent and still trying to adjust my sleep schedule (I’m on the East Coast and go to bed early; 6 pm Las Vegas time is my biological clock’s bedtime).

This year was one of my favorite re:Invents. I got to meet old and new co-workers and hang out with a lot of Community Builders and AWS Heroes, talk to service teams about what they should do to make their products work more for the security 99%. I got to a couple of good chalk talks on GenAI and GenAI security, which will help inform my poking at that over the holidays.

As for announcements, in the last seven days, there were 195 things posted to AWS What’s New. These are the ones I care to follow up on.

For simplicity, we’ll break them down into:

• Security Features
• Cloud Governance & Costs
• Serverless Stuff
• GenAI & Bedrock
• Other nifty stuff that may only matter to me
• I just wanna Snark

As has been my tradition the last few years, I prep for re:Invent by reviewing all the interesting announcements that happen in the weeks leading up to the event. This gives me a chance to keep an eye out for sessions and chalktalks related to things I care about, and a chance to corner an SA or product manager at the AWS Booth and go like this:

This year I’ll be attending AWS as a Security Hero. The good news for all 845,000 attendees is that I don’t have to wear tights. Instead I’ll be hanging out in the Heroes lounge with the other Heroes and Community Builders (hopefully sipping mimosas during the keynotes).

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 days¹ 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.