Join the conversation #DevSecCon

BY TIM MACKEY – BLACK DUCK SOFTWARE

A Question of Trust – When

Good Containers Go Bad

#whoami – Tim Mackey

• Current roles: Senior Technical Evangelist; Occasional coder• Former XenServer Community Manager in Citrix Open Source Business

Office

• 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 ( https://twitter.com/TimInTech )• SlideShare: slideshare.net/TimMackey• LinkedIn: www.linkedin.com/in/mackeytim

Security Driven Development and Deployment

• Developers are empowered with security information

• Clear security driven release policies exist

• Trusted components are used as dependencies

• CI processes incorporate security testing

• Binary artifacts are only created when release policies are met

• Releasable binaries are digitally signed

• Container images are built from trusted base images

• Produced images are stored in trusted container registries

• Containers are only deployed from trusted registries

Data Breaches are Serious Business

• Average cost of data breach: $7.35 Million • Lost business: $4.03 Million• Average time to identify and contain a breach: 206 days

Source: 2017 Cost of Data Breach Study – Ponemon Insitute

Prediction: Rate of Security Disclosures To Increase

• e.g. GDPR

• Anyone operating with data on EU person

• Corporate location irrelevant

• Violation has fine of 4% global turnover or 20 Million Euro (which ever is greater)

• Applies equally to controllers of data and processors of data

• Breach notification required within 72 hours

• Requires “Privacy by Design”

Control Domain

NetworkingCompute Storage

Hypervisor

Container VM

Minimal OS

We’re Protected – Infra Team’s Got It!

Co

nta

iner

Co

nta

iner

Co

nta

iner

Container VM

Minimal OS

Co

nta

iner

Co

nta

iner

Co

nta

iner

Secu

rity

Ser

vice

Co

nta

iner

Control Domain

NetworkingCompute Storage

Hypervisor

Container VM

Minimal OS

Or Did They?

Co

nta

iner

Co

nta

iner

Co

nta

iner

Container VM

Minimal OS

Co

nta

iner

Co

nta

iner

Co

nta

iner

Secu

rity

Ser

vice

Co

nta

iner

Container VM

Minimal OS

Vu

lner

able

Co

nta

iner

Co

nta

iner

Co

nta

iner

Co

mp

rom

ised

C

on

tain

er

Co

mp

rom

ised

C

on

tain

er

Question Everything and Continually Evaluate Trust

• Where does your base image actually come from?

• What is the health of that base image?

• You’re updating it at build time, but from what cache?

• You trust your build servers, but who controls them?

• Is there any way a foreign container can start in your environment?

• Who has rights to modify container images?

• What happens if base image registry goes away?

• What happens if base image tag goes away?

• What happens if an update mirror goes down?

• When a security disclosure happens what’s the process to determine impact?

• How are images being updated and deployed in the face of new security disclosures?

Join the conversation #DevSecCon

Why all this matters

i.e. Please don’t get sacked

CLOSED SOURCE COMMERCIAL CODE

• TRADITIONAL PROCUREMENT PROCESS• ALERTING AND NOTIFICATION INFRASTRUCTURE• SUPPORT AVAILABLE THROUGH EOL• STAFFED WITH SECURITY RESEARCHERS• REGULAR PATCH UPDATES• DEDICATED SUPPORT TEAM WITH SLA

OPEN SOURCE CODE

• AD-HOC ADOPTION MODEL• MONITOR NEWSFEEDS YOURSELF• EOL MAY CREATE DEADEND• “COMMUNITY”-BASED CODE ANALYSIS• NO STANDARD PATCHING MECHANISM• ULTIMATELY, YOU ARE RESPONSIBLE

Proprietary Software Rules Aren’t Open Source

Attackers are Clever and You Need to be Cunning

Potential Attack

Iterate

Test against platforms

Document

Don’t forget PR department!

Deploy

Join the conversation #DevSecCon

Let’s Make it Real – Decompose a Vulnerability

Media Coverage

Embargo Expires

Oct 21 2016

Git://id

Upstream Patch

Vuln: CVE-2016-5195 – AKA “Dirty Cow”

Oct 18 2016

Patches Available

Embargoed Vulnerability Awareness

Patches Available

Media Coverage

Embargo Expires

Oct 21 2016

Git://id

Upstream Patch

Vuln: CVE-2016-5195 – AKA “Dirty Cow”

Oct 18 2016

NationalVulnerabilityDatabase

VulnPublished

Nov 10 2016

Highest Security Risk

Timing is Opportunity

Security Analysis Isn't Only SAST/IAST/DAST

All possible security vulnerabilities

Static, Injection and Dynamic Analysis

- Discover common security patterns

- Challenged by nuanced bugs

- Focuses on your code; not upstream

Vulnerability Analysis

- Identifies vulnerable dependencies

- 3000+ disclosures in 2015

- 4000+ disclosures in 2016

- Most vulnerabilities found by researchers

We’re all Researchers – Report What You Find

• Distributed Weakness Filing• Open Source specific CAN

• Designed for Open Source projects without an existing CAN

• Increasing vulnerability awareness• Reinforce security collaboration

• Reduce islands of knowledge

https://iwantacve.orghttps://github.com/distributedweaknessfiling/

Heartbleed: Why in 2017?

Don’t Give Attackers Opportunities

OpenSSH (CVE-2004-1653): AllowTCPForwarding creates open IoT proxyApache Struts (CVE-2017-5638): Vulnerability response time matters

1649 Days 144 Days7 Days

The Tale of CVE-2017-5638 and Equifax

Code Bug

Introduced

August

2012

Struts 2.3

Released

November

2012

Struts 2.5

Released

May

2016

Patches

Available

March 6

2017March 7

2017

Disclosure

Published

NVD

Details

March 14

2017

Hacks

Successful

May 13

2017

Hacks

Discovered

July 29

2017

Join the conversation #DevSecCon

Open Source Risk Maturity Model

LEVEL 1 – BLISSFUL IGNORANCENo policies in place to manage open source security and licensing risks. Unknown versions and dependencies. No documentation of intent.

LEVEL 2 – AWAKENINGInconsistent manual processes to identify and report on open source usage. Conceptual awareness of license requirements. Unaware of security implications of open source usage.

LEVEL 3 – UNDERSTANDINGManual review processes, and basic tooling. Primary focus on license compliance. Accuracy is difficult to maintain. Provides limited insight into security vulnerabilities.

Tools: Spreadsheets, low cost tools, sporadic security scans

LEVEL 4 – ENLIGHTENMENTAutomatic identification of open source components and versions. Direct mapping to licenses and disclosed vulnerabilities. Integration with developer, issue management, CI/CD and deployment tools.

Join the conversation #DevSecCon

We Need to Automate This – Don’t We?

Obtain Enlightenment and make information flow your friend

Focus on Factors Impacting Risk

• Use of vulnerable open source components• What are my dependencies and where are they coming from?

• Is component a fork or dependency?

• How is component linked?

• Impact of Point in Time Decisions• Can you differentiate between “stable” and “dead”?

• Is there a significant change set in your future?

• API versioning

• Security response process for project

• Commit velocity and contributors

We Don’t Patch Containers – But Patches Matter

Support Gating of Artifact Builds for Risk Elements

DEVELOP BUILD PACKAGE

RISK ASSESSMENT

BUG TRACKING

Build a Risk Profile for All Containers In SDLC

Registry

SCM TriggerDeployment

TriggerGit

Build Pipelines

Production Trigger

Registry Registry

Security Scan

Staging Tests

SCM TriggerGit

Support Ongoing Monitoring for Changes in Risk

DEVELOP BUILD PACKAGE DEPLOY PRODUCTION

BUG TRACKING

TEST

AUTOMATION

RISK ASSESSMENT

Evaluate Security Information Throughout SDLC

Developer Experience

IDEs

Release Engineering

SASTDAST

Artifact Storage

Production Deployment

Package management

CI

Problem:

Security response times are too long

Automate awareness of open source

dependencies while operating at DevOps speed

Black Duck OpenShift Integration

Component Identification

Black Duck KnowledgeBase

Customer Hosted Black Duck Hosted

Integrated Registry

ImageStream Events

Policy Engine

Hub Scan Engine

Hub Scan Controller

Hub Notifications

Image Annotation

External Registries

Layer Container Security For Maximum Impact

Secure Platform with Red Hat OpenShift Container Platform and Atomic Host

Administer DISA STIG: CVE, CCE, CPE, CVSS, OVAL, and XCCDF

OVAL formatted patch definitions for Red Hat products

Scan all container images in an OpenShift deployment as the are created, modified and used

Provide visibility into open source components regardless of source

Annotate images and image streams with vulnerability information

Annotations automatically updated as new disclosures occur – without the need for rescan

10,000DATA SOURCES

530TERABYTES OF CONTENT

2,500LICENSE TYPES

12YEARS OF OSS ACTIVITY

100,000OSS VULNERABILITIES

KnowledgeBase is Critical

• Designed with Open Source behavior traits including forks and merges

• Vulnerability information enhanced through dedicated security research team

• Real time updates as security issues occur

• Map vulnerabilities to public exploits

Managing Open Source Security Requires End-End Visibility

INVENTORY

Open Source Components

MAP

To Known Vulnerabilities

IDENTIFY

Open Source Risks

MANAGE

Open Source Governance Policies

ALERT

For New Vulnerabilities

Automation and workflow

Integration with DevOps tools and processes

Stay Out of the News for the Wrong Reasons

• 2 ½ days of keynotes, breakout sessions, and networking

• Four conference tracks: Dev & DevOps, Security,

Legal & Compliance, Research & Innovation

Register at: https://www.blackducksoftware.com/flight

FLIGHT 2017 Join us at the Boston Seaport Hotel & World Trade Center November 7-9, 2017

Register using the code TIM99 to

save $1196 on the conference price

Join the conversation #DevSecCon

Thank You!