Chris Farris

(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.

This post is contains all the queries from my talk SEC339 at re:Invent 2019. Yes, it is very similar to the talk I gave at re:Inforce. The focus is on the Preparation & Identification aspects of the SANS Incident Response framework. Preparation The tools we need here are: Centralized CloudTrail Centralized GuardDuty Antiope Splunk. CloudTrail We centralize all our CloudTrail events from all our accounts into a single bucket.

This post is the reference section of my dev-chat at the first ever AWS re:Inforce conference in Boston. You can find my slides here. The purpose was to give the audience a brief overview of how to conduct basic threat hunting in their CloudTrail and GuardDuty. We throw in a bit of Vulnerability Hunting and awareness with Antiope at the end. Tools The tools we need here are: Centralized CloudTrail Centralized GuardDuty Antiope Splunk.

(This article was drafted on the plane to the SANS Cloud Security Summit but I never got around to publishing it. I dive deeper into the ThreatHunting topic for my DevChat at AWS re:Inforce to be published June 26th) One the purposes for Antiope is to provide a platform for Cloud Threat Hunting. Traditional Threat Hunting looks for evidence of compromise. In this case what we’re really hunting are threats from misconfiguration.

Back in November of 2015 I taught myself CloudFormation on the Amtrak ride from DC to NY. As I was building out my ultimate VPC template, I began to discover the limitations of CloudFormation. There was no clean way to link the output of a stack to the inputs of another stack. All the examples I’d seen at work had all the settings defined as defaults. Meaning that sharing CFTs was a risky proposition and code-reuse was very limited.

I’ve written here in the past about how I’ve created Cloud Security Scorecards to help our account holders fix security issues and to help management hold the account holders accountable for their security posture. Today I’m going to discuss the Cloud Security Standards against which we measure our cloud accounts. Our first major decision was not to have a single standard for the three public clouds we operate in. The differences between AWS, GCP and Azure are major, and creating a document that addressed configuration in the abstract would create confusion.