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