Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

DevSecCon London 2017: when good containers go bad by Tim Mackey

229 visualizaciones

Publicado el

DevSecCon London 2017: when good containers go bad by Tim Mackey

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

DevSecCon London 2017: when good containers go bad by Tim Mackey

  1. 1. Join the conversation #DevSecCon BY TIM MACKEY – BLACK DUCK SOFTWARE A Question of Trust – When Good Containers Go Bad
  2. 2. #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
  3. 3. 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
  4. 4. 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
  5. 5. 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”
  6. 6. Control Domain NetworkingCompute Storage Hypervisor Container VM Minimal OS We’re Protected – Infra Team’s Got It! Container Container Container Container VM Minimal OS Container Container Container SecurityService Container
  7. 7. Control Domain NetworkingCompute Storage Hypervisor Container VM Minimal OS Or Did They? Container Container Container Container VM Minimal OS Container Container Container SecurityService Container Container VM Minimal OS Vulnerable Container Container Container Compromised Container Compromised Container
  8. 8. 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?
  9. 9. Join the conversation #DevSecCon Why all this matters i.e. Please don’t get sacked
  10. 10. 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
  11. 11. Attackers are Clever and You Need to be Cunning Potential Attack Iterate Test against platforms Document Don’t forget PR department! Deploy
  12. 12. Join the conversation #DevSecCon Let’s Make it Real – Decompose a Vulnerability
  13. 13. 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
  14. 14. Patches Available Media Coverage Embargo Expires Oct 21 2016 Git://id Upstream Patch Vuln: CVE-2016-5195 – AKA “Dirty Cow” Oct 18 2016 National Vulnerability Database Vuln Published Nov 10 2016 Highest Security Risk Timing is Opportunity
  15. 15. 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
  16. 16. 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.org https://github.com/distributedweaknessfiling/
  17. 17. 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
  18. 18. 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 2017 March 7 2017 Disclosure Published NVD Details March 14 2017 Hacks Successful May 13 2017 Hacks Discovered July 29 2017
  19. 19. Join the conversation #DevSecCon Open Source Risk Maturity Model
  20. 20. LEVEL 1 – BLISSFUL IGNORANCE No policies in place to manage open source security and licensing risks. Unknown versions and dependencies. No documentation of intent.
  21. 21. 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.
  22. 22. 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
  23. 23. 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.
  24. 24. Join the conversation #DevSecCon We Need to Automate This – Don’t We? Obtain Enlightenment and make information flow your friend
  25. 25. 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
  26. 26. We Don’t Patch Containers – But Patches Matter
  27. 27. Support Gating of Artifact Builds for Risk Elements DEVELOP BUILD PACKAGE RISK ASSESSMENT BUG TRACKING
  28. 28. Build a Risk Profile for All Containers In SDLC Registry SCM Trigger Deployment TriggerGit Build Pipelines Production Trigger Registry Registry Security Scan Staging Tests SCM TriggerGit
  29. 29. Support Ongoing Monitoring for Changes in Risk DEVELOP BUILD PACKAGE DEPLOY PRODUCTION BUG TRACKING TEST AUTOMATION RISK ASSESSMENT
  30. 30. Evaluate Security Information Throughout SDLC Developer Experience IDEs Release Engineering SAST DAST Artifact Storage Production Deployment Package management CI
  31. 31. Problem: Security response times are too long Automate awareness of open source dependencies while operating at DevOps speed
  32. 32. 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
  33. 33. 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
  34. 34. 10,000 DATA SOURCES 530 TERABYTES OF CONTENT 2,500 LICENSE TYPES 12 YEARS OF OSS ACTIVITY 100,000 OSS 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
  35. 35. 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
  36. 36. Stay Out of the News for the Wrong Reasons
  37. 37. • 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
  38. 38. Join the conversation #DevSecCon Thank You!

×