Black Duck & IBM Present: Application Security in the Age of Open Source
•Als PPTX, PDF herunterladen•
4 gefällt mir•2,074 views
Keeping applications secure, whether you're developing for internal use or for your customers, isn't easy. Today, applications are a mix of open source and custom code. Identifying and resolving security vulnerabilities in both requires the right tools and know-how. Black Duck and IBM are working together to help you keep your applications secure.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Andere mochten auch
Andere mochten auch (10)
Ähnlich wie Black Duck & IBM Present: Application Security in the Age of Open Source
Ähnlich wie Black Duck & IBM Present: Application Security in the Age of Open Source (20)
Mehr von Black Duck by Synopsys
Mehr von Black Duck by Synopsys (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Black Duck & IBM Present: Application Security in the Age of Open Source
- 1. APPLICATION SECURITY IN THE AGE OF OPEN SOURC
- 2. 2© 2015 IBM Corporation AGENDA STATE OF APPLICATION SECURITY HOLISTIC APPLICATION SECURITY SOLUTION NEW CHALLENGES POSED BY OPEN SOURCE
- 3. © 2015 Black Duck Software, Inc. All Rights Reserved. STATE OF APPLICATION SECURITY
- 4. 4© 2015 IBM Corporation WEB APPLICATION VULNERABILITIES XSS AND SQL INJECTION EXPLOITATIONS XSS AND SQL INJECTION EXPLOITS ARE CONTINUING IN HIGH NUMBERS Source: IBM X-Force Threat Intelligence Quarterly, 2014Source: IBM X-Force Threat Intelligence Quarterly, 2014 APPLICATIONS - THE WEAKEST LINK IN THE IT SECURITY CHAIN 25% 20% 15% 10% 5% 0% 2009 2010 2011 2012 2013 WEB APPLICATION VULNERABILITIES 33% OF VULNERABILITY DISCLOSURES ARE WEB APPLICATION VULNERABILITIES 33%
- 5. 5© 2015 IBM Corporation Attack types XSS Heart- bleed Physical access Brute force Misconfig . Watering hole Phishing SQLi DDoS Malware Un- disclosed January February March April May June July August September October November December Source: IBM X-Force Threat Intelligence Quarterly 1Q 2015 SQL INJECTION - STILL RELIABLE FOR BREACHING APPLICATIONS SAMPLING OF 2014 ATTACKS SQL injection accounted for 8.4% of attacks in 2014. Source: IBM X-Force Threat Intelligence Quarterly 1Q 2015
- 6. 6© 2015 IBM CorporationSource: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013 INVESTMENT PRIORITY - WHERE ARE YOUR “SECURITY RISKS” VS. YOUR “SPEND” MANY CLIENTS DO NOT PRIORITIZE APPLICATION SECURITY IN THEIR ENVIRONMENTS 35% 30% 25% 20% 15% 10% 5% APPLICATION LAYER DATA LAYER NETWORK LAYER HUMAN LAYER HOST LAYER PHYSICAL LAYER SECURITY RISK SPENDING SPENDING DOES NOT EQUAL RISK Source: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013
- 7. 7© 2015 IBM Corporation PACECOMPLIANCE RESOURCES RAPID GROWTH IN APPLICATIONS, RELEASES AND TECHNOLOGY EXTERNAL REGULATIONS AND INTERNAL POLICY REQUIREMENTS SMALL SECURITY TEAMS, LOTS OF APPLICATIONS ? • Which applications pose the biggest business risk? • How do we test apps for security in rapid DevOps / Agile shops without slowing down the process / business? • How do we reduce costs and catch security problems earlier in the lifecycle? • Where is my business risk? • How do I set internal policy requirements for app security? • Is my private / sensitive data exposed by apps? • How do I check for and demonstrate application compliance? • How do we prioritize the work for the resources I have? • What do we test and how do we test it? • How do we staff and improve skills and awareness? APPLICATION SECURITY CHALLENGES
- 8. 8© 2015 IBM Corporation OPEN SOURCE EMBRACED BY THE ENTERPRISEOPEN SOURCE EMBRACED BY THE ENTERPRISE OPEN SOURCE • Needed functionality without acquisition costs • Faster time to market • Lower development costs • Broad support from communities CUSTOM CODE • Proprietary functionality • Core enterprise IP • Competitive differentiation OPEN SOURCE CUSTOM CODE
- 9. © 2015 Black Duck Software, Inc. All Rights Reserved. RISE OF OPEN SOURCE RISK
- 10. 10© 2015 IBM Corporation CHANGING DEVELOPMENT ENVIRONMENT BRINGS NEW SECURITY CHALLENGES 2010 20182014 2010 2014 2018 6000 NEW OPEN SOURCE VULNERABILITIES REPORTED SINCE 2014 SOURCE: NATIONAL VULNERABILITY DATABASE (NVD) OPEN SOURCE AS A PERCENTAGE OF CODE BASE IS GROWING. 98% OF COMPANIES ARE USING OPEN SOURCE SOFTWARE THEY DON’T KNOW ABOUT. SOURCE: BLACKDUCK
- 11. 11© 2015 IBM Corporation OPEN SOURCE HAS PASSED THE TIPPING POINT “By 2016, Open Source Software will be included in mission-critical applications within 99% of Global 2000 enterprises.” 0.0 0.5 1.0 1.5 2.0 2007 2009 2011 2013 2015 millions Growth of open source projects accelerating. Will face problems because of no policy. 50% OPEN SOURCE HAS PASSED THE TIPPING POINT
- 12. 12© 2015 IBM Corporation We have little control over how open source enters the code base OPEN SOURCE COMMUNITY INTERNALLY DEVELOPED CODE OUTSOURCED CODE LEGACY CODE REUSED CODE SUPPLY CHAIN CODE THIRD PARTY CODE DELIVERED CODE WE HAVE LITTLE CONTROL OVER HOW OPEN SOURCE ENTERS THE CODE BASE OPEN SOURCE CODE IS INTRODUCED IN MANY WAYS AND ABSORBED INTO FINAL CODE
- 13. 13© 2015 IBM Corporation The shifting application security threat landscapeTHE SHIFTING APPLICATION SECURITY THREAT LANDSCAPE OPEN SOURCE COMPONENTS WITH KNOWN VULNERABILITIES - 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 In 2015, over 8,000 new vulnerabilities in open source components. Source: Risk Based Security’s VulnDB
- 14. 14© 2015 IBM Corporation Open Source is an Attractive TargetOPEN SOURCE IS AN ATTRACTIVE TARGET OPEN SOURCE IS USED EVERYWHERE VULNERABILITIES ARE PUBLICIZEDEASY ACCESS TO SOURCE CODE STEPS TO EXPLOIT READILY AVAILABLE
- 15. 15© 2015 IBM Corporation Who’s responsible for security?WHO IS RESPONSIBLE FOR SECURITY? DEDICATED SECURITY RESEARCHERS ALERTING AND NOTIFICATION INFRASTRUCTURE REGULAR PATCH UPDATES DEDICATED SUPPORT TEAM WITH SLA “COMMUNITY”-BASED CODE ANALYSIS MONITOR NEWSFEEDS YOURSELF NO STANDARD PATCHING MECHANISM ULTIMATELY, YOU ARE RESPONSIBLE COMMERCIAL CODE OPEN SOURCE CODE
- 16. 16© 2015 IBM Corporation How are Companies Managing Open Source Today? Not Well.HOW ARE COMPANIES MANAGING OPEN SOURCE TODAY? NOT WELL. TRACKING VULNERABILITIES • No single responsible entity • Manual effort and labor intensive • Unmanageable (11/day) • Match applications, versions, components, vulnerabilities SPREADSHEET INVENTORY • Depends on developer best effort or memory • Difficult maintenance • Not source of truth MANUAL TABULATION • Architectural Review Board • Occurs at end of SDLC • High effort and low accuracy • No controls VULNERABILITY DETECTION Run monthly/quarterly vulnerability assessment tools (e.g., Nessus, Nexpose) against all applications to identify exploitable instances
- 17. 17© 2015 IBM Corporation A solution to solving this problem would include these componentsA SOLUTION TO SOLVING THIS PROBLEM WOULD INCLUDE… CHOOSE OPEN SOURCE INVENTORY OPEN SOURCE MAP EXISTING VULNERABILITIE S TRACK NEW VULNERABILITIES Maintain accurate list of open source components throughout the SDL Identify vulnerabilities during development Alert on new vulnerabilities and map to applications Proactively choose secure, supported open source GUIDE VERIFY/ENFORCE MONITOR
- 18. 18© 2015 IBM Corporation New Integrated and Secure Development LifecycleNEW INTEGRATED AND SECURE DEVELOPMENT LIFECYCLE OSS Security Requirements OSS Risk Assessment Guided OSS Selection OSS Review Board Broad coverage of Open Source code & snippets Application Criticality Ranking OSS Audit Timely OSS Vulnerability Identification & Reporting Bug Severity Remediation Advice Correlation with Bills of Material OSS Audit Timely OSS Vulnerability Identification & Reporting Bug Severity Remediation Advice Correlation with Bills of Material OSS Monitoring Timely OSS Vulnerability Identification & Reporting Bug Severity Remediation Advice Correlation with Bills of Material Establish Security Requirements Create Quality Gates Risk Assessments Establish Design Requirements Analyze Attack Surface Threat Modeling Use Approved Tools Deprecate Unsafe Functions Static Analysis Dynamic Analysis Fuzz Testing Attack Surface Review Incident Response Plan Final Security Review Release Archive REQUIREMENTS DESIGN BUILD TEST RELEASE OPEN SOURCE CUSTOM CODE
- 19. © 2015 Black Duck Software, Inc. All Rights Reserved. HOLISTIC APPLICATION SECURITY SOLUTION
- 20. 20© 2015 IBM Corporation Custom Code VulnerabilitiesCUSTOM CODE VULNERABILITIES CUSTOM CODE VULNERABILITIES
- 21. 21© 2015 IBM Corporation Open Source Vulnerabilities – Black DuckOPEN SOURCE VULNERABILITIES - BLACK DUCK
- 22. 22© 2015 IBM Corporation OPEN SOURCE VULNERABILITIES Open Source VulnerabilitiesOPEN SOURCE VULNERABILITIES
- 23. 23© 2015 IBM Corporation Holistic View – Custom and Open SourceHOLISTIC VIEW - CUSTOM AND OPEN SOURCE
- 24. 24© 2015 IBM Corporation Key TakeawaysKEY TAKEAWAYS • Application development ecosystem is changing Open source provides increasing large foundation for custom code. • Open source is here to stay (and growing) Saves development costs and accelerates time to market. • New paradigm requires new methodologies Best practices for custom code continues to require automated testing. Best practices of open source requires full visibility and continuous monitoring.
- 25. 25© 2015 IBM Corporation What can you do tomorrow?WHAT CAN YOU DO TOMORROW? • Speak with your head of application development and find out… What policies exist for managing open source? Is there a list of components used in all applications? How are they creating the list? What controls do they have to ensure nothing gets through? How are they tracking vulnerabilities for all components over time?
- 26. © 2015 Black Duck Software, Inc. All Rights Reserved. Q&A
- 27. © 2015 Black Duck Software, Inc. All Rights Reserved. Send questions to ibm@blackducksoftware.com Thank you
Hinweis der Redaktion
- CONSTANTINE: Welcome to our webinar on application security in the age of open source. My name is Constantine Grancharov from IBM Security (PROVIDE BRIEF BACKGROUND, ROL). I’ll be hosting today’s session with Mike Pittenger of Black Duck. MIKE: introduces self, provides brief background and role.
- CONSTANTINE: Over the next 30 minutes or so, our goal is to give you a brief overview on the state of application security and the new challenges that the rise in open source software use is having on it. We’ll then share our perspective on a new holistic approach organizations can take to ensure application security in this new hybrid world.
- CONSTANTINE: First, let’s kick things off with a brief overview on the current state of application security
- One of main weaknesses in the IT infrastructure of organizations is where most people do not expect – it is in the application layer. Many applications are not built with security in mind and they become the weakest link that attackers exploit to carry out a data breach. In fact… SQL injections, a type of application attack, were responsible for 8.1 percent of all data breaches in 2014 Source: The 10 Most Common Application Attacks in Action, April 2015 https://securityintelligence.com/the-10-most-common-application-attacks-in-action/#.VWd6zmN3iyC
- CONSTANTINE: Here is another chart that illustrates that organizations are not paying enough attention to the application security problem. Based on another study done by the Ponemon Institute, the highest security risk is at the application layer. Yet, most organizations focus primarily on the Network layer, and that’s where they allocate most of their resources…
- CONSTANTINE: What are some of the challenges organizations face when it comes to application security?... Compliance –External regulations and internal policy requirements How do I set internal policy requirements for application security? Is my private/sensitive data exposed by apps? How do I check for and demonstrate application compliance? Pace – Rapid growth in number of applications and releases to meet the requirements of the business Which applications pose the biggest business risk? Mobile? Web? Partner? 3rd Party Vendor? How do we test apps for security in rapid DevOps/Agile shops without slowing down the process/business? How do we reduce costs and catch security problems before production/earlier in the lifecycle? Resources–Resource and awareness challenges Where do we start? How do we prioritize the work? What do we test and how do we test it? How do we staff and improve skills and awareness?
- CONSTANTINE: The third, and final challenge faced by application security teams is the changing code base. It not only is comprised of custom code but increasingly, open source components, projects and code that help to [READ BULLETS ABOVE].
- CONSTANTINE: Now, I’m going to turn it over to Mike Pittenger, who will dive into more detail on the unique application security risks posed by open source and how organizations need to think about protecting themselves from such risks.
- MIKE: One of the most challenging aspects of container security is finding open source software vulnerabilities. This is increasingly important. After all, open source software makes up a growing percentage of your code base and containers are commonly built on open source components.
- MIKE: Open source was once viewed with suspicion, but in the past few years has been embraced by organizations, everyone from mobile application developers to the Department of Defense and large financial services organizations. Gartner estimates the 99% of the Global 2000 now use open source components, and over 1.5 million projects are now available for use. Note also that Gartner believes unrestricted use without organizational policies and controls brings risk to organizations.
- MIKE: Managing open source can be a challenge, since it can enter the code base in several ways. You may have policies, and even review and approve open source in design reviews, but developers may reuse internal code that includes older open source components, pull unapproved code from web-based repositories, integrate code from supply chain partners. The end result is deployed code that contains open source, often without the knowledge or review of development managers and security teams.
- MIKE: This new world presents two very different but equally important application security challenges for organizations. They include: One of main weaknesses in the IT infrastructure of organizations is where most people do not expect – it is in the application layer. Many applications are not built with security in mind and they become the weakest link that attackers exploit to carry out a data breach. In fact… SQL injections, a type of application attack, were responsible for 8.1 percent of all data breaches in 2014 Source: The 10 Most Common Application Attacks in Action, April 2015 https://securityintelligence.com/the-10-most-common-application-attacks-in-action/#.VWd6zmN3iyC 59% of banking applications we tracked are vulnerable to a critical disclosure. Source: IBM X-Force Threat Research 1Q 2015 Report http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&appname=SCTE_WG_WG_USEN&htmlfid=WGL03073USEN&attachment=WGL03073USEN.PDF#loaded On mobile devices you get your applications from an app store, not your corporate image, like you do with a laptop. We usually have no idea who built those applications, we have no relationship or support agreement with the developer, and we have no idea how the application works.
- MIKE: Open source is not necessarily less secure, or more secure, than commercial software. There are, however, some characteristics of open source that make it particularly attractive to attackers. Open source is widely used by enterprises in commercial applications Therefore, a new vulnerability in a popular project provides a target-rich environment for attackers. Attackers have access to the code for analysis Vulnerabilities in commercial code are exploitable, but attackers don’t have easy access to the source for analysis. That’s not the case in open source, where everyone has access. Like researchers, attackers can also identify new vulnerabilities When new vulnerabilities are disclosed, we publish them to the world NIST maintains the National Vulnerability database as a publicly available reference for vulnerabilities identified in software, and other sources – most notably OSVDB – focus on all identified vulnerabilities in open source. Proof of the vulnerability (in the form of an exploit) is often included When a vulnerability is discovered, the researcher will typically provide proof of the vulnerability in the form of exploit code, making the attackers’ job even easier Attackers can use these as well – but if they are confused, there are typically YouTube videos available to provide step-by-step instructions
- MIKE: What’s the implication of using open source code? Something many organizations haven’t considered is that the support model is entirely different. With commercial code, there are often dedicated security researchers, whose findings are put out via a robust alerting infrastructure to all their customers. Regular patches means their customers need not worry too much about remediation, as long as their patch management process is fairly robust. And most importantly, dedicated support teams are able to respond to your issues should anything happen. With open source code, security research is often done by “white hat” hackers, academics, and the general open source community. There isn’t necessarily a clear process for making sure all code commits do not introduce new vulnerabilities. Security issues are usually announced on newsfeeds, email lists which you need to subscribe to. There is no proactive alerting for customers since there are no “customers” in the traditional sense of the word. When bug fixes go out, patching usually just means downloading the latest version, which may break the application. There is no one standard way of distributing patches to open source code. And finally, the biggest challenge of all is that your engineering and security teams are ultimately responsible for the open source code you use. In case of a security incident, when it comes to open source there is no vendor you can point a finger at. That means the imperative is on you to be extra-vigilant when it comes to open source vulnerabilities.
- MIKE: In short, many companies are not addressing this. The best practices we have seen in large, multi-national organizations, with mature SDLC practices, would be similar to the 3 activities listed here – question development teams about what they are using, tally the results in a spreadsheet, and react to vulnerabilities that they hear about. Manual tabulation Manual tabulation occurs either at design review (and is therefore dependent on developers adhering to version requirements and not adding additional functionality) or at the end of the development cycle (therefore dependent on the dev teams' memory and best efforts). In both cases, accuracy is dependent on static requirements or managers’ memories. Accuracy at the beginning of the SDLC ignores any changes in requirements, especially in an Agile environment. It is also dependent on developers selecting the approved version of a component Accuracy at the end of the SDLC is subject to recollection and level of effort Maintain results in a spreadsheet Updates to code that include new open source may not be captured Tracking of new vulnerabilities in the components used is decentralized, at best Manual tracking quickly becomes unmanageable On average, 11 new vulnerabilities per day What do you do if you have 100 internal applications, and each uses 10 open source components?
- MIKE: A best-practices solution would combine elements of TRUST, VERIFICATION, and MONITORING: 1 – Starting with TRUST, this is providing developers and architects a way to choose open source components that are free of known vulnerabilities, and have active community support. This is a proactive step that reduces risk downstream in the software development process, and is the most cost-effective means of risk reduction. 2 – VERIFICATION means two things, having an accurate inventory of open source and being able to map than against all known vulnerabilities, in any and all applications, at any point in the SDL 3 – MONITOR means being able to monitor the released code for newly discovered vulnerabilities and alert the right people for remediation. Many organizations end security testing when applications are released. After all, the code base isn’t changing, nor are the security rules in the tools, so why test simply to see the same results again? However, this ignores the fact that while the code base isn’t changing, the threat environment changes constantly. With over 4,000 new vulnerabilities each year, a comprehensive solution should be continuously monitoring this constant stream of new vulnerabilities, and automatically notify you of any new vulnerabilities in the open source you used in deployed applications, including: Which applications use the code How critical the vulnerability is, and How to remediate it
- MIKE: The SDLC has always focused on activities that help build security into applications at each stage of the development process, including the use of appropriate testing tools. A similar set of activities is needed for addressing the security of the open source we use. This includes creating policies for the characteristics of open source you will allow in your applications, then ENFORCING those policies at each stage of the SDLC to ensure that, when you ship code, it is free from vulnerabilities in the open source components. In addition, continuous monitoring of the threat space will provide early notification of new vulnerabilities, and the tools needed to identify and remediate affected applications.
- MIKE: Now I’ll pass the baton back to Constantine from IBM who will show a brief demo of how we manage security vulnerabilities for custom code and open source code in a holistic manner.
- CONSTANTINE AppScan Enterprise --
- CONSTANTINE
- CONSTANTINE
- CONSTANTINE
- MIKE
- MIKE: In summary, we’ve discussed: OSS is pervasive and integral part of app development OSS has unique security and support challenges manual process isn’t sufficient Therefore, level of risk warrants action. If you agree this is a priority for you, the next steps are critical. Most CISOs we speak with want to find out more about the current situation at their organization. The best person to ask is often the head of application development. What you want to know are the answers to the following questions: What policies exist? Is there a list of components? How are they creating the list? Are they tracking vulnerabilities? How do they ensure nothing gets through? These questions will shed light on the current state of how open source is used and managed at your organization and give you a good starting point for further discussions. What would you propose the next steps should be?