Managing Container

Risk
OpenShift Commons Briefing
Tim Mackey – Senior Technologist – Black Duck
Software
Security Driven Development and Deployment

1. Developers are empowered with security information

2. Clear security driven release policies exist
3. Trusted components are used as dependencies
4. CI processes incorporate security testing
5. Binary artifacts are only created when release policies are met
6. Releasable binaries are digitally signed
7. Container images are built from trusted base images
8. Produced images are stored in trusted container registries
9. Containers are only deployed from trusted registries
Is Your Job Safe with Security Driven Development?

• 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
We’re Protected – Our Infra Guys Have Thought of Everything!

Control Container Container

Security Service
Domain VM VM

Container

Container

Container

Container

Container

Container
Minimal OS Minimal OS

Hypervisor

Compute Networking Storage

 Or Did They?

Control

Compromised
Container
Compute

Container
Security Service
Container
Container
Minimal OS
Domain Container VM

Compromised
Vulnerable Container
VM

Container
Hypervisor

Container
Container

Minimal OS

Networking

Container

Container
VM

Storage

Container
Container

Minimal OS
Question Everything and Continually Reevaluate Trust

1. Where does your base image actually come from?

2. What is the health of that base image?
3. You’re updating it at build time, but from what cache?
4. You trust your build servers, but who controls them?
5. Is there any way a foreign container can start in your environment?
6. Who has rights to modify container images?
7. What happens if base image registry goes away?
8. What happens if base image tag goes away?
9. What happens if an update mirror goes down?
10. When a security disclosure happens what’s the process to determine impact?
11. How are images being updated and deployed in the face of new security disclosures?
Why all this matters
i.e. Please don’t get fired
Open Source Doesn’t Play by Commercial Software Rules
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
Attackers are Resourceful and You Need to be Cunning

Deploy
Potential Attack
Test against platforms

Document
Iterate

Don’t forget PR department!

Let’s Make it Real
– Decompose a
Vulnerability
 Embargoed Vulnerability Awareness

Upstream Embargo
Patch Expires

Media
Git://id
Coverage

Oct 18 2016 Oct 21 2016

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

Patches Available
 Timing is Opportunity

Upstream Embargo Vuln

Patch Expires Published

Media
Git://id National
Coverage
Vulnerability
Database

Oct 18 2016 Oct 21 2016 Nov 10 2016

Vuln: CVE-2016-5195 –
AKA “Dirty Cow” Highest Security Risk
Patches Available
Security Analysis Isn't Only SAST/IAST/DAST

Static, Injection and Dynamic Analysis

- Discover common security patterns
- Challenged by nuanced bugs
- Focuses on your code; not upstream

Vulnerability Analysis
- Identifies vulnerable dependencies
All possible security vulnerabilities
- 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 CNA
• Designed for Open Source
projects without an existing CNA

Increasing vulnerability awareness

• Reinforce security collaboration
• Reduce islands of knowledge https://iwantacve.org
https://github.com/distributedweaknessfiling/
Attackers Find Weaknesses – Don’t Give Them Opportunities

OpenSSH
Apache(CVE-2004-1653):
Struts (CVE-2017-5638):
Heartbleed:
AllowTCPForwarding
WhyVulnerability
in 2017? response
creates open
time IoT
matters
proxy
 Open Source
Development Risk
Maturity Model
LEVEL 1 – BLISSFUL IGNORANCE
No policies in place to manage open
source security and licensing risks.
Unknown versions and dependencies.
No documentation of intent.
LEVEL 2 – AWAKENING
Inconsistent 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 – UNDERSTANDING
Manual 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 – ENLIGHTENMENT
Automatic identification of open
source components and
versions. Direct mapping to
licenses and disclosed
vulnerabilities. Integration with
developer, issue management,
CI/CD and deployment tools.
 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 Need to Question Patching
Support Gating of Artifact Builds for Risk Elements

BUG TRACKING

DEVELOP BUILD PACKAGE

RISK ASSESSMENT
Build a Risk Profile for All Containers – Even the Builders

Deployment
Git SCM Trigger
Trigger

Registry

Security Staging
Scan Tests
Registry Registry
Production
Git SCM Trigger
Trigger

Build Pipelines
Support Ongoing Monitoring for Changes in Risk

BUG TRACKING

TEST
DEVELOP BUILD PACKAGE DEPLOY PRODUCTION
AUTOMATION

RISK ASSESSMENT
Black Duck Value Across the SDLC

Developer Experience Release Engineering Production

Deployment
IDEs Package CI SAST Artifact
management DAST Storage
 Problem:
Security response times are too long

Automate awareness of open source

dependencies while operating at DevOps speed
 Integrated Registry

Hub Scan Component

Controller Identification

Hub Scan
Engine
External
Registries
Image Annotation
Black Duck
Hub Notifications Policy Engine KnowledgeBase

Black Duck OpenShift

Integration

ImageStream Events
Customer Black Duck
Hosted Hosted
Layer Container Security For Maximum Impact – Success
Criteria

 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
 Is this real or just boring slides?

Maybe if we quack nicely he’ll

give a quick demo?
KnowledgeBase is Critical
12
YEARS OF OSS ACTIVITY
• Designed with Open Source behavior traits including
forks and merges 530
TERABYTES OF CONTENT

• Vulnerability information enhanced through dedicated

security research team 100,000
OSS VULNERABILITIES

• Real time updates as security issues occur 2,500

LICENSE TYPES

• Map vulnerabilities to public exploits

10,000
DATA SOURCES
Managing Open Source Security Requires End-End Visibility

INVENTORY MAP IDENTIFY MANAGE ALERT

Open Source To Known Open Source Open Source For New
Components Vulnerabilities Risks Governance Vulnerabilities
Policies

Automation and workflow

Integration with DevOps tools and processes

Stay Out of the News for the Wrong Reasons
FLIGHT 2017
Join us at the Boston Seaport Hotel & World Trade Center
November 7-9, 2017

• 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

Register using the code TIM99 to

save $1196 on the conference price