Best Practices for Managing Risk from Open Source Libraries and Components

803
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
803
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Best Practices for Managing Risk from Open Source Libraries and Components

  1. 1. BEST PRACTICES FOR MANAGING RISK From Open Source Libraries and Components February 5th at 1pm ET Jim Routh & Joshua Corman
  2. 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. 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. 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. 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. 6. FS-ISAC Third Party Software Security Working Group Control Types
  7. 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. 8. FS-ISAC Third Party Software Security Working Group Component Usage Has Exploded Control 3 Open Source Policy Management
  9. 9. FS-ISAC Third Party Software Security Working Group Policy Management Capability
  10. 10. FS-ISAC Third Party Software Security Working Group FS-ISAC Third Party Software Security Working Group Whitepaper www.fs-isac.com
  11. 11. WHAT’S CHANGED?
  12. 12. COST, COMPLEXITY, AND RISK
  13. 13. CONSEQUENCES: VALUE & REPLACEABILITY http://blog.cognitivedissidents.com/2011/10/24/a-replaceability-continuum/
  14. 14. CountermeasuresSituational AwarenessOperational ExcellenceDefensible Infrastructure
  15. 15. CountermeasuresSituational Awareness Operational Excellence Defensible Infrastructure
  16. 16. Countermeasures Situational Awareness Operational Excellence Defensible Infrastructure
  17. 17. Countermeasures Situational Awareness Operational Excellence Defensible Infrastructure
  18. 18. Life Rights CritInfr IP PII CCN Counter- measures Situational Awareness Operational Excellence Defensible Infrastructure REPLACEABILITY
  19. 19. 90%Assembled Software Evolution Written 20 HOW MUCH CODE DO WE “WRITE” THESE DAYS?
  20. 20. 90%Assembled Software Evolution Written 21 HOW MUCH CODE DO WE “WRITE” THESE DAYS?
  21. 21. Component Selection Open source usage is EXPLODING Yesterday’s source code is today’s OPEN SOURCE 201320122011200920082007 2010 2B1B500M 4B 6B 8B 13B
  22. 22. A Sea Change in Hacker Targeting Now that software is assembled… 23
  23. 23. 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 !
  24. 24. 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
  25. 25. 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.
  26. 26. CLM IN ACTION
  27. 27. BACK TO… CONTROL TYPES
  28. 28. 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?
  29. 29. 31 Global Bank Software Provider Software Provider’s Customer State University Three-Letter Agency Large Financial Exchange CVE-2013-2251: WIDESPREAD COMPROMISE
  30. 30. 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
  31. 31. Software Evolution 33 BIG IMPACTLittle Effort,
  32. 32. WE NEED BETTER LEVERAGE! Most security programs are getting a little bit better everywhere; but not sufficiently better anywhere... Earlier. Easier. Effective.
  33. 33. 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
  34. 34. 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
  35. 35. 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

×