Chris Farris

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 or Werner’s keynotes. As I was slammed with work things, I wasn’t following pre:Invent (and will probably miss much of the lame online re:Invent), so I’m going back and reviewing all the announcements for things of note to a serverless nerd or security geek.

Building a public cloud security program from scratch is a lot of work. There are a ton of things you need to do and figuring out what you need to do and the priority is critical. CIS publishes a list of 20 Critical Security Controls. While primarily focused at traditional IT data-center centric organizations, the concepts and the order of the 20 Controls provides a reasonably good road map for anyone looking to start their cloud security journey.

I seem to be spending a lot of time discussing the Cloud Service Provider’s (CSP) side of shared responsibility, and no where near enough time discussing our side of shared responsibility. Time to throw down more thoughts on why you need to worry less about AWS, Azure and GCP’s engineering, and spend more time focused on your own security hygiene. Don’t lose sight of the fact that "95 percent of cloud security failures will be the customer’s fault.

“Architect for the AWS you have, not the AWS you want” –Chris Farris, 2017 AWS is constantly innovating. This is both a blessing and a curse. It’s a blessing because things are getting better, cheaper, and faster. It’s a curse because the best way to accomplish an objective is constantly changing. I’m interested in auto-remediation. How do I revert a bad state to a good state without asking a human to fix something.

Defining a new term: Networkless Computing

(With apologies for the click-bait headline. It seems to be what all the cool kids are doing when they’re not on TikTok) (2024 update: Daniel Grzelak has penned an excellent write up of how S3 encryption works, and demonstrated that S3 encryption is nothing more than an additional layer of access control. Check out S3 Bucket Encryption Doesn’t Work The Way You Think It Works) I have spent way too much of my life the last three years in the cloud compliance and cloud security posture monitoring space.

What is Cloud Governance In the past few years while I’ve been doing cloud security, I’ve observed how governance and other cloud activities work. Cloud Governance really focuses on three things: Security/Legal/Compliance (aka risk reduction) Cost Optimization Providing the business value which is why you’re in the cloud in the first place. Typically these functions are split in different parts of the organization. Your InfoSec team cares about cloud security, your finance department is asking questions about how you’re spending so much money and why can’t you spend less.

I’ve been engaged in a lot of merger & acquisition (M&A) activity over the past year. One of the things that entails is understanding how organizations are using AWS, what controls they have in place and how they are using AWS’s security features. This a general list of things you want to look at when evaluating an AWS environment for the first time. Security & Governance Tooling CloudTrail Is CloudTrail enabled?

The Origin Story This adventure began, like most do, with wizard crashing a party: Turns out, Jerry had been doing some open-bucket discovery and found several with the patten of letters “cnn”. At the time we had somewhere around 80 AWS accounts and our financial tool didn’t seem to find any hits. As we’d been building out the concept of the Security Account we had the ability to go cross-account to list all the buckets, so I wrote a small script to do just that.

Much has been written about establishing a multi-account strategy. From the Code Spaces incident onward, putting all your AWS eggs in a single basket has been an design choice AWS and most cloud and cloud security professionals have spoken against. As of writing this, my current employer has 830+ AWS accounts. That’s not at the extreme end (I recall hearing at re:Invent that Fidelity has over 10,000), but it is certainly beyond the “we can do this by hand” stage of cloud maturity.