Secure application

deployment

#whoami – Tim Mackey

• Current roles: Senior Technical Evangelist; Occasional coder• Previously XenServer Community Manager

• Cool things I’ve done• Designed laser communication systems• Early designer of retail self-checkout machines• Embedded special relativity algorithms into industrial control system

• Find me• Twitter: @TimInTech• SlideShare: slideshare.net/TimMackey• LinkedIn: www.linkedin.com/in/mackeytim

Security reality

No solution is perfect. Defense in

depth matters.

Attacks are big business

In 2015, 89% of data breaches had a financial or espionage motive

Source: Verizon 2016 Data Breach Report

EASY ACCESS TO SOURCE CODE

Open source ubiquity makes it an easy target

OPEN SOURCE ISN’T MORE OR LESS SECURE THAN

CLOSED SOURCE – ITS JUST EASIER TO

ACCESSVULNERABILITIES ARE PUBLICIZED

EXPLOITS ARE PUBLISHED

Anatomy of a new attack

Potential Attack

Iterate

Test against platforms

Document

Don’t forget PR department

Deploy

DELIVERED CODE

OPEN SOURCE CODESUPPLY CHAIN CODE

LEGACY CODE

REUSED CODE/CONTAINERS

COMMERCIAL CODE

INTERNALLY DEVELOPED CODE

OUTSOURCED CODE

How open source enters a code base

CLOSED SOURCE COMMERCIAL CODEDEDICATED SECURITY RESEARCHERSALERTING AND NOTIFICATION INFRASTRUCTUREREGULAR PATCH UPDATESDEDICATED SUPPORT TEAM WITH SLA

OPEN SOURCE CODE“COMMUNITY”-BASED CODE ANALYSISMONITOR NEWSFEEDS YOURSELFNO STANDARD PATCHING MECHANISMULTIMATELY, YOU ARE RESPONSIBLE

Who is responsible for code and security?

TRUST BUILD FILES, MANIFESTS, PACKAGE MANAGERS, FILE NAMES

EVIDENCE-BASED IDENTIFICATION OF OPEN SOURCE BY SCANNING FILES IN CONTEXT

Without evidence, nothing else matters

Are packages complete? Determine package context

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 20150

500

1000

1500

2000

2500

3000

3500Open Source Vulnerabilities Reported Per Year BDS-exclusive nvd

Reference: Black Duck Software Knowledgebase, NVD

INCREASING NUMBER OF OSS VULNERABILITIES

Automated tools miss most open source vulnerabilities

Static & Dynamic Analysis Only discover common vulnerabilities

3,000+ disclosed in 2014Less than 1% found by automated tools

Undiscovered vulnerabilities are too complex and nuanced

All possible security vulnerabilities

What do these all have in common?

Heartbleed Shellshock GhostFreak Venom

Since:

Discovered:

2011

2014

1989

2014

1990’s

2015

2000

2015

2004

2015

Discovered by:

Component: OpenSSL

Riku, Antti, Matti, Mehta

Bash

Chazelas

OpenSSL

Beurdouche

GNU C library

Qualys researchers

QEMU

Geffner

Integrating into tools and processes

DEVELOP SCM BUILD PACKAGE DEPLOY PRODUCTION

BUG TRACKING

REMEDIATE AND TRACK LICENSE COMPLIANCE AND SECURITY VULNERABILITIES

FULL APP SEC VISIBILITY VIA IBM APPSCAN

INTEGRATION

BUILD / CI SERVERSCAN APPLICATIONS

WITH EACH BUILD VIA CI INTEGRATION

DELIVERY PIPELINESCAN APPLICATIONS AND CONTAINERS BEFORE DELIVERY

CONTINUOUS MONITORING OF VULNERABILITIES

Misaligned security investment

A solution should include these components

Choose Open Source

Proactively choose secure, supported

open source

SELECT

InventoryOpen Source

Map ExistingVulnerabilities

Maintain accurate list of open source components

throughout the SDL

Identify vulns during development

VERIFY

Track New Vulnerabilities

Alert new vulns in production apps

MONITORREMEDIATE

FixVulnerabilities

Tell developers how to

remediate

We need your help

Knowledge is power• Know what’s running and why• Define proactive vulnerability response process• Don’t let technology hype cycle dictate security

Invest in defense in depth models• Don’t rely on perimeter security to do heavy lifting• Do look at hypervisor & container trends in security• Make developers and ops teams part of the solution• Do embed security into deployment process

Together we can build a more secure data center