(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.
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.
Towards the end of the year I read a top-10 list of cloud security threats for 2019 and it had me thinking about the Cloud Security risks that people are not talking about. I can’t find that original list, and I’ve been sitting on this post for the last two months.
So with out further ado, here is my take on cloud security risks you’re not reading about in the press.
This post came out of a need for me to review my Cloud Security Standards after re:Invent. I knew of the re:Invent announcements, I didn’t recall all the other things that have happened recently. Drop me a tweet, LinkedIn or email if this is useful and I should do this again in a few months. This list is sorted chronologically and categorized as good, bad and ugly.
The Good Amazon GuardDuty Optimizes AWS CloudTrail Analysis Reducing Cost for Customers Announced On: Nov 1, 2018
A few folks have asked “How does Antiope differ from AWS Config”? Darn good question. I had looked at Config back in 2015 or so, and found it to be not that useful. If I dug around enough in the Console I could figure out who made a change, but honestly I have CloudTrail for that. When I took on the Cloud Security role I briefly looked at is with an eye towards “We should enable this everywhere, and dump the data to S3 in case someday we needed it for an investigation”.
It’s been about two now three weeks since AWS re:Invent 2018 wrapped, and I’m finally starting to recover. Six days in Vegas and a red-eye flight back to Atlanta have me not wanting to travel any more in 2018. So what happened of interest?
First off, my two Chalk Talks with Suman and Damindra went well. I’m glad that at least two people out of the 58,000 present thought my session was they best they’d attended.
Managing a large number of cloud accounts across the global footprint that cloud providers offer is a herculean task for small security and governance teams.
Turner has been leveraging AWS native services to conduct continuous inventory and compliance as part of its Cloud Security Program. Today I’m releasing Antiope (PRONO An-Tie-Oh-Pee). It is intended to be an open sourced framework for managing resources across hundreds of AWS Accounts. From a trusted Security Account, Antiope will leverage cross-account roles to gather up resource data and store them in an inventory bucket.
In my last post I described how we improved our cloud security via the scorecards and spreadsheets. This post describes how we generate scorecards on an hourly basis using the basic building block of AWS.
The goal was to use native AWS services, with a secondary goal of avoiding the use of EC2 Instances that would need patching and other TLC. AWS is like Legos, they give you lots of parts and you have to put them together.
We’re a week away from AWS re:Invent and the level of cloud activity is reaching a fervor pace. Two things I’d like to share this morning. 1) How to Do re:Invent and 2) what all this re:Invent craziness means to a security professional.
If you’re lucky enough to go to re:Invent (and as far as I’ve heard it’s not sold out) a few things to bear in mind:
This is Vegas.
I’d like to share some of the things we’ve done to improve our AWS and Public Cloud Security posture. This was as much a cultural effort as it was a technical and security effort. Like all security/culture things, YMMV.
When I returned to Turner in my Cloud Security role I knew we had our work cut out for us. We had about 30-40 AWS accounts across three payer accounts (due to acquisitions etc).
