Chris Farris

I got a bug to tell everyone about the sessions I’m looking forward to at re:Invent this year. Check it out.

At BSides Atlanta today I gave a talk on how to handle an incident in AWS. The talk and this post is intended to help those already familiar with the principles of Incident Response to understand what to do when the incident involves the AWS Control Plane. You can find the Slides here.

A cheerful ghost of cloud security yet to come. I’ll talk about where CloudSec really needs to focus - on the pipeline and ultimately on the cloud developer or engineer. Finally, I’ll close out with a one-year roadmap for how I’d build a third (fourth) program if I’m crazy enough to do this again at my next job.

Following up on the Tar-Pit of CSPM, I feel the need to offer something more constructive for CloudSecurity practitioners to do. Cloud Security Posture Monitoring is “here’s a spreadsheet of issues, go fix them”. There are other ways, but none of them are a panacea.

It’s been a little less than five years since I moved from a media production cloud nerd to a cloud security nerd. As I ponder what I’m going to do next, I want to reflect on some of the things I got right and some that didn’t work out as expected.

The Southeast Collegiate Cyber Defense Competition is an annual competition where eight teams from various colleges have to defend their systems from Red Team attacks while also executing on management-type business challenges. This is my second year helping Kennesaw State University run the SECCDC in AWS. This year we not only ran the Regional competition on-site at KSU, but we also hosted 26 teams for the preliminary round. In previous years the scenario was HALCORP, a fictional company that did nothing but generate compliance paperwork.

As part of my work setting up free domains in Google, I realized I needed a way to receive email. My normal process for getting emails on secondary domains I own was to add them as a User Alias Domain attached to room17.com. However, for these Google Cloud Identity domains I couldn’t do that. A domain can’t be both it’s own Cloud Identity domain, and a User Alias Domain. So I started experimenting with AWS SES.

Note: this is the first in what I hope will become a series of GCP Security 101 posts. Most cloud governance or cloud security folks have never created a Google Organization from scratch. Typically you come into an organization that has already implemented some form of Google. Most likely, that implementation was organic. There was no planning, no design, it’s was just there. I’ve also found that cloud engineers typically only have access to https://console.

Last week was re:Invent. It was great to be back in Vegas, and I loath Vegas. The crowds this year were smaller, which meant I could typically get into whatever session I wanted to. However it still took forever to get from Wynn, to Venetian, to Caesar’s to Mirage (where I was staying). I probably walked as much last week as I did during the entire pandemic. The Expo floor was smaller, but it didn’t seem smaller.

Welcome to the American Thanksgiving holiday, which for us cloud peeps is the quiet period between pre:Invent and re:Invent. Traditionally the run up to AWS re:Invent is chock full of feature releases (and some product releases) that don’t merit mention in Andy Adam’s or Werner’s keynotes. Last year I was busy with a new job, hiring a new team, and helping to launch a streaming service. This year I have another new job (same company, new role), and did have time.