AppSec USA 2014 Denver, Colorado Project Monterey or how we learned to stop worrying and love the cloud

Kevin Glisson Introduction Cloud Security Engineer – Working on all forms of security automation and operations (SSL, AWS, PCI, and more.) – Lover of all things Python and AngularJS Mountain Biker Pizza Aficionado

50+ million subscribers 47+ countries 700+ compatible devices 34% of US peak evening Internet traffic 700+ applications Netflix

High Performance Culture Fail Fast, Learn Fast … Get Results Core Value: “Freedom & Responsibility” Engineering Culture DevOps means engineering teams own – New deployments and maintenance – Capacity planning & procurement Netflix Culture

Acts as a consultancy – Pentest applications – Evaluate application security design/implementation Define best practices Trust but verify Create tools to manage and secure cloud infrastructure (e.g. Security Monkey) Cloud Security

Monterey Tons of apps and lots of code changes (a/b testing, canaries, etc.) There are no traditional security roadblocks or gateways Using traditional tool chains is very human intensive (we are a small team) Monterey was created as a tool to help application security engineers, identify and evaluate application security state

Overview Discovery Uses APIs from other systems to detect and enroll applications Inventory Allows for ad hoc or automated asset creation Scanning Leverages open source and commercial tools (best in category philosophy) Results Presents and filters relative findings depending on severity

Monklets Basic unit of work Simple and dumb Integration point between Monterey and external applications or resources Not limited to scans, monklets can be used for discovery or result processing Scalable and distributed A monklet’s only goal in life is execute jobs. It has no state; has no awareness of where it is in the execution chain, it simply receives a job and executes it.

Third Party Tools Most of the heavy security lifting is accomplished by established tool chains (NMAP, ZAP, Arachini, Threadfix etc.). This allows us to: Be tool agnostic Leverage best in class toolsets Use both upstream and downstream tools

How a task is executed 1.Asset monitoring or a user executes a scan 2.Scan is evaluated, a task is created for each asset and each configuration associated with it 3.Tasks are published to an SNS topic for each individual monklet 4.Monklet receives SNS notification and pulls job off of the associated SQS queue 5.Monklet executes the task 6.Monklet persists any task data to S3

Demo Time!

Road Map Build monklet specific auto scaling into Monterey Authentication and User Management Workflow and use case development Continue to evaluate new tools that could be used as monklets Open Source! Get feedback from community about interest, approach, etc.