The document summarizes a presentation on best practices for managing risk from open source libraries and components. The presentation was given by Jim Routh and Joshua Corman and covered the following topics: an introduction to the FS-ISAC Third Party Software Security Working Group; the group's recommended control types including policy management and enforcement for open source components; how software development has changed with most code now being assembled rather than written; and how component lifecycle management can help address issues by enforcing policies in the development process.

1. BEST PRACTICES FOR
MANAGING RISK
From Open Source
Libraries and Components
February 5th at 1pm ET
Jim Routh & Joshua Corman

2. 2 1/28/2016
FEATURED SPEAKERS
JIM ROUTH, CISO JOSHUA CORMAN, CTO
Certified with CSSLP & CISM
Chairman of FS-ISAC Committee
20+ Years in Application Security
Co-founder of Rugged Software
Previously w/ Akamai & 451 Group
Trusted Security Professional
@joshcorman

3. TODAY’S AGENDA
3 1/28/2016
• What is the Third Party Security Working Group
• What are the recommended control types
• Why policy management & enforcement
• What changed?
• Dependence (disproportional)
• Component Lifecycle Management in action

4. FS-ISAC Third Party Software Security Working Group
Third Party Software Security
Steering Committee Members
1. Jerry Brady, Morgan Stanley
2. Mark Connelly, Thomson Reuters
3. Mahi Dontamasetti, DTCC
4. Paul Fulton, Citi
5. Keith Gordon, Capital One
6. Royal Hansen, Goldman Sachs
7. Chauncey Holden, RBS Citizens Bank
8. Rich Jones, JP Morgan Chase
9. Ben Miron, GE
10. Jim Routh, Aetna
Working Group Members
1. David Smith, Fidelity
2. Don Elkins, Morgan Stanley
3. Matt Levine, Goldman Sachs
4. David Hubley, Capital One
5. Tim Mathias, Thomson Reuters
6. Rishikesh Pande, Citi
The Third Party Software Security Working Group was
established with a mandate to analyze control options and
develop specific recommendations on control types for member
firms to consider adding to their vendor governance programs.
These recommendations on control types are captured in the
FS-ISAC Working Group whitepaper, “Appropriate Software
Security Control Types for Third Party Service and Product
Providers.”

5. FS-ISAC Third Party Software Security Working Group
Recommended Control Types
vBSIMM Process Maturity
Binary Static Analysis
Policy management and enforcement for consumption
of open source libraries and components
1
2
3

6. FS-ISAC Third Party Software Security Working Group
Control Types

7. FS-ISAC Third Party Software Security Working Group
Control 3 - Policy management
and enforcement for consumption of
open source libraries and components
This control type identifies consumable open source libraries for a given Financial
Institution, identifies the security vulnerabilities by open source component and enables
the Financial Institution to apply controls or governance over the acquisition and use of
open source libraries.

8. FS-ISAC Third Party Software Security Working Group
Component Usage Has Exploded
Control 3 Open Source Policy Management

9. FS-ISAC Third Party Software Security Working Group
Policy Management Capability

10. FS-ISAC Third Party Software Security Working Group
FS-ISAC Third Party Software Security
Working Group Whitepaper
www.fs-isac.com

11. WHAT’S CHANGED?

12. COST, COMPLEXITY, AND RISK

13. CONSEQUENCES: VALUE & REPLACEABILITY
http://blog.cognitivedissidents.com/2011/10/24/a-replaceability-continuum/

15. CountermeasuresSituational AwarenessOperational ExcellenceDefensible Infrastructure

16. CountermeasuresSituational Awareness
Operational Excellence
Defensible Infrastructure

17. Countermeasures
Situational Awareness
Operational Excellence
Defensible Infrastructure

18. Countermeasures
Situational Awareness
Operational Excellence
Defensible Infrastructure

19. Life Rights CritInfr IP PII CCN
Counter-
measures
Situational
Awareness
Operational
Excellence
Defensible
Infrastructure
REPLACEABILITY

20. 90%Assembled
Software Evolution
Written
20
HOW MUCH CODE DO WE “WRITE” THESE DAYS?

21. 90%Assembled
Software Evolution
Written
21
HOW MUCH CODE DO WE “WRITE” THESE DAYS?

22. Component
Selection
Open source usage is
EXPLODING
Yesterday’s source
code is today’s
OPEN SOURCE
201320122011200920082007 2010
2B1B500M 4B 6B 8B 13B

23. A Sea Change in Hacker Targeting
Now that software is assembled…
23

24. Today’s approaches
AREN’T
WORKING
Component
Selection
DEVELOPMENT BUILD AND DEPLOY PRODUCTION
COMPONENT
SELECTION
46m
vulnerable
components
downloaded
!
71%
of repos
have 1+
critical or
severe
vulnerability
!
90%
of repos
have 1+
critical
vulnerability
!

25. A Massive Supply Chain Problem
No
Visibility
No
Control
No
Fix
No visibility to what components are used,
where they are used and where there is risk
No way to govern/enforce component usage.
Policies are not integrated with development .
No efficient way to fix existing flaws.
25

27. FROM THE FS-ISAC WHITE PAPER
27
• Enabling application architects to control versions of
software.
• Accelerating the development process by encouraging
the consumption of open source libraries that are
resilient.
• Reduce operating costs since the cost of ripping out
obsolete components from existing applications is high
assuming the older versions can be identified in the first
place.

28. CLM IN ACTION

29. BACK TO… CONTROL TYPES

30. Notional Exposure Active Risk
Snapshot Report
Repository Health Check
Application Health Check
What have I downloaded ?
What’s in my repo? Are my apps
vulnerable?

31. 31
Global Bank
Software
Provider
Software
Provider’s Customer
State University
Three-Letter
Agency
Large Financial
Exchange
CVE-2013-2251: WIDESPREAD COMPROMISE

32. How can we choose the best components
FROM THE START?
Shift Upstream = ZTTR (Zero Time to Remediation)
Analyze all components
from within your IDE
License, Security and Architecture data for each
component, evaluated against your policy

33. Software Evolution
33
BIG IMPACTLittle Effort,

34. WE NEED BETTER LEVERAGE!
Most security programs are getting
a little bit better everywhere; but
not sufficiently better anywhere...
Earlier. Easier. Effective.

35. 35 1/28/2016
DEVELOPERS & APPLICATION SECURITY:
WHO’S RESPONSIBLE?
Take the Survey: https://www.surveymonkey.com/s/Developers_and_App
63% of people
concerned with open
source

36. 36 1/28/2016
“A new approach in the market is Component
Lifecycle Management (CLM) which offers the ability
to enforce policies in the development process.”
LEARN MORE
To learn more about the
‘Component Lifecycle
Management Approach’, read
the OVUM report.
http://www.sonatype.com/resources/whitepapers

37. BEST PRACTICES FOR MANAGING RISK FROM
OPEN SOURCE LIBRARIES AND COMPONENTS
Thank you for attending today’s event, please contact us with any questions.
http://www.sonatype.com/contact/general-inquiry