SEC339 - Actionable threat hunting in AWS

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.

Threat Hunting with CloudTrail and GuardDuty in Splunk

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.

Threat Hunting with Antiope

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

Introducing cftdeploy

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.

Creating a Cloud Security Standard

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.

Top 10 Cloud Security Risks

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.

Recent AWS Security Launches

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

Rethinking Config

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

My Take on the Equifax Report

Earlier this month the US House Oversight and Government Reform Committee released a report on the Equifax breach. You can read the whole thing here Things I liked about the report This is one of the most detailed an interesting reports I’ve seen from a Congressional Committee (second probably to the report of the 9-11 Commission) The usage of the Attack Chain to describe the attacker’s activities during the May 13th to July 30th time frame was very well done (pg31).

AWS re:Invent 2018 Wrapup

It’s been about twonow 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.