Software Security Assurance for Devops

Editor's Notes

• #2: PITTENGER: Welcome! My name is Mike Pittenger and I’m the Vice President of Security Strategy here at Black Duck Software. I’m joined by Lucas von Stockhausen, Sr Product Manager for HPE Security Fortify. Today’s webinar will focus on application security for DevOps and what Black Duck and HPE Security are doing together to help.
• #3: PITTENGER There are 3 Challenges impacting application security in a DevOps world Expanding attack surface Agile + New Delivery Models Rise of open source Strategies for overcoming these challenges Security testing in agile environments Custom and open source Talk about automation 5 Things you can do tomorrow
• #4: Stockhausen HPE Security Fortify and Black Duck recently announced a partnership. The goal of our partnership is to empower organizations with a software security solution, that provides visibility into the security posture of applications across your enterprise, in both custom code and open source libraries. With the partnership and integration, security vulnerabilities identified from Black Duck can now be viewed through Fortify Software Security Center.
• #5: PITTENGER: While automation has addressed the challenge presented by agile development, there are other challenges organizations face when it comes to application security in a changing world. Expanding Attack Surface – * Not only are we seeing a huge increase in the sheer number of web facing applications, but also many more devices in the workspace managing critical data. This can include mobile devices, cloud services, and IoT New Deployment Models * With changing development models and companies moving to an Agile environment, we are also seeing a change in the way applications are being deployed. This leads to new security strategies to address things like the secure use of containers – The greater use Open Source Open source is used virtually everywhere today. This presents some new security challenges from a testing and monitoring perspective. Now, let’s look at each of these in a bit more detail…
• #6: Stockhausen In the connected world of today, when we think of attack surface we're typically discussing web applications. But, it’s not enough to only scan/test your critical web applications.  The number of apps continue to increase substantially and companies have come to the realization that applications are a competitive differentiator that sets them apart. As they create complex web apps, mobile apps, and IOT apps, their attack surface expands. There are an ever increasing numbers of web apps which provide customers and adversaries with a way to reach our data and critical assets. But there are other ways in which we’re exposing ourselves to hackers. If we consider IoT apps and device deployments are exploding across commercial, home products, and the automotive industries. Particularly infotainment systems in the connected car. Less visible are business to business and vertical apps, including critical infrastructure. Gartner Research estimates that the installed base of IoT devices, which has almost doubled in the last 2 years, will increase 3–fold in the next 4 years. Dan Geer of In-Q-Tel, the investment arm of the CIA, paints the picture in another way. By looking at the number of CPU cores, device drivers for bluetooth, GPS, video and USB ports, he estimates that the actual attack surface is doubling every 17 months!
• #7: PITTENGER: One of the most challenging aspects of applications and container security is finding open source software vulnerabilities. This is increasingly important. After all, open source software makes up a growing percentage of a companies code base, and containers are commonly built on open source components.
• #8: PITTENGER Open source has been adopted widely, but this has presented new challenges. Primarily, how do organizations manage the code they use. The 2016 Future of Open Source survey shows that Nearly half the companies had no policies for what 3rd party code could be used. Keeping tack of open source is a manual process without controls – about half claim to track manually. As we will see later, this greatly underestimates the amount of open source used Nearly a third of the companies had no process for tracking new vulnerabilities in the code they used. This is compounded, of course, by the fact that most companies have no reliable way of even knowing which open source projects they are using, and the fact that vulnerabilities vary by version
• #9: PITTENGER : Open source is being embraced by organizations, including the federal government. How important is it to understand what your organization is using? Our recent study on open source in commercial applications showed: Go through stats We as security professionals need to recognize that open source and custom code require defense in depth -
• #10: PITTENGERManaging open source can be a challenge, because it can enter into an organizations code base in several ways. An org may have reviewed and approved open source in design reviews, but developers maybe using reused internal code that includes older open source components that have not been approved, or they have pulled unapproved code from web-based repositories, or integrated code from supply chain partners. In all of these scenarios, you are exposing and increasing risk to your organization. The end result is organizations are deployed code that contains open source, often without the knowledge or review of development managers and security teams.
• #11: PITTENGER: There are two very different but equally important application security challenges for organizations. You may recognize the logo’s shown here, but think for a moment about what they have in common They are all vulnerabilities in well known and widely used open source components They were all present in the code for years, in spite of thousands of instances of testing using traditional security tools and pen tests They were all found by security researchers and disclosed responsibly to the public While vulnerabilities like Heartbleed, GHOST, ShellShock, DROWN are well known, they represent a tiny fraction of the vulnerabilities reported in open source. In fact, the National Vulnerability Database has reported over 6,000 new vulnerabilities in open source software since 2014 alone. As you can see in the chart, we see a pretty consistent flow of new vulnerabilities based on the work of security researchers. The spike in the graph shows how the discovery of Heartbleed 2 years ago spurred increased research and scrutiny of open source. And again, while Heartbleed made the evening news, there have been over 70 additional vulnerabilities – just in OpenSSL – since then. The problem this presents is two-fold, visibility to the components you use, and visibility to the vulnerabilities
• #12: PITTENGER Organizations should use static and dynamic analysis to find bugs in the code they write, but… Open source vulnerabilities are too complex and too nuanced to be found by automated tools If the tools were effective at finding vulnerabilities in open source, the vulnerabilities would have been found long ago HeartBleed was present in OpenSSL for 2+ years, despite constant testing using automated tools 50+ vulnerabilities in OpenSSL since Heartbleed have all been found by researchers. Vulnerabilities in open source are almost exclusively found by researchers manually inspecting the code and conducting experiments Of the 4,000 vulnerabilities identified last year, fewer than 10 we Very useful in identifying common security bugs in custom code Typically responsibility of security team Some can integrate into the build Provide a snapshot of security vulnerabilities that each tool can identify Exploitability of an issue can easily change Results require review and scrubbing #1 complaint – too many useless issues Typically used late in the SDLC Often require compiled application and/or test environment re identified by automated tools
• #13: PITTENGER : 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 easier Attackers can use these as well – but if they are confused, there are typically YouTube videos available to provide step-by-step instructions
• #14: PITTENGER: The predominant method for tracking open source in organizations is a manually compiled spreadsheet that is created at the end of the SDLC. While that’s a problem by itself, it’s exacerbated by the lack of visibility into the thousands of vulnerabilities reported in open source each year. Why is this? * Start – open source is no more or less secure than commercial code. However, Characteristics of open source that make it attractive to attackers * support model
• #16: PITTENGER : Now let’s turn it over to Lucas von Stockhausen from HPE Security Fortify to take a look at the some of the available technologies for automating application security testing and implementing the concept of gates / controls.
• #17: Stockhausen: There are a variety of technologies on the market for assessing the security of application. First I’d like to start with Static Analysis. Fortify’s Static Code Analyzer identifies security vulnerabilities in source code during development. It pinpoints the root cause of a vulnerability with line of code detail so that developers can easily ID and quickly remediate issues. It prioritizes results & provides best practices so developers can code securely. SCA also helps organizations identify issues early in the software development lifecycle when they are the easiest & least expensive to fix. Open Source Scanning such as Black Duck also integrates into the build process. This technology assesses your applications to identify known vulnerabilities in the open source components. These vulnerabilities are almost exclusively found by researchers manually inspecting the code and conducting experiments. Dynamic Analysis, Fortify WebInspect is for QA testers & security professionals to help identify and prioritize security vulnerabilities. It simulates real world attacks on your running applications and provides a comprehensive analysis of complex web applications and their services. Runtime is a technology that helps organizations manage and mitigate risk in production applications. Fortify Application Defender is able to actively monitor and protect applications that have known and unknown security vulnerabilities. It also provides visibility into the malicious activity and will identify the root cause. So as orgs are transitioning to an agile environment, processes and greater collaboration across dev, QA and security Ops has to get automated further. The traditional approach is to deploy static and dynamic testing technologies during the build and QA process and although this testing is still important, it is no longer enough. New trends have emerged and we now have a new SDLC – Secure developement is shifting left and empowering developers to find and fix vulnerabilities as they code. This happens entirely within the developers native environment. We do this by continuously testing and providing remediation guidance on the source code as it is being developed. Today, applications have to embed and build-in security testing tools such as Fortify and BlackDuck which can tightly integrate into existing DevOp tools sets
• #19: Stockhausen With this integration, customers that already manage vulnerabilities in Fortify Software Security Center can now incorporate issues that have been identified by BlackDuck. This provides added value, visibility and governance to your entire application security program.
• #20: PITTENGER Black Duck scans are kicked off concurrent with the Fortify scans, typically as part of the build process. The result is an inventory, or bill-of-materials, listing all of the open source identified down to the version level. Once identified, we map information from our knowledgebase on over 1.5 million open source projects about known vulnerabilities, license information, and operational risk from poorly supported projects.
• #21: Stockhausen This is one example demonstrating the usefulness of having Black Duck issues incorporated into Software Security Center. At the issue level, you can see the flexibility that SSC offers. Users can combine filtering with grouping to identify specific types of issues.
• #22: Stockhausen This is one example demonstrating the usefulness of having Black Duck issues incorporated into Software Security Center. At the issue level, you can see the flexibility that SSC offers. Users can combine filtering with grouping to identify specific types of issues.
• #23: This slide will set up the discussion on automation PITTENGER or RIGHT Moving from a waterfall environment to DevOps has changed the way organizations are creating and deploying their applications. The advantages of integrating Development and IT Operation teams, and moving to a continuous and frequent production releases cycle, provides faster time to value, allows companies to react quickly to market needs, and helps to stay ahead of a very competitive environment. A new approach to development also requires a new approach to security testing. As companies transition to a DevOps environment they need to find ways to further automate their application security testing efforts and process. It is even more crucial now to make sure testing processes are built into your SDLC.
• #24: PITTENGER Most continuous integration infrastructures contain a similar collection of components including: IDE’s integrated development environments, version control systems, bug tracking tools, binary repositories, and test automation tools, The most common component is a continuous integration solution such as Jenkins, TeamCity, or Bamboo to orchestrate and schedule all of the critical steps of the build. <ANIM> Application scanning can be implemented in a number of locations within the ecosystem, including automated scanning as part of the continuous integration process which provides visibility into security vulnerabilities within your code.
• #25: PITTENGER Security testing technologies that are integrated with a CI tools provides the most flexibility and reduces friction in the devops environment. For example, using your CI tools to initiate Static and Open Source analysis with each build provides rapid feedback on vulnerabilities in both customer and open source code, giving companies a complete assessment of the risk in an application. As a final check before deployment, a good practice is to run an open source analysis of both the application layer and the Linux stack to identify known vulnerabilities, and if you choose, prevent vulnerable containers from being deployed live.
• #26: PITTENGER To achieve consistency in the build and delivery process, continuous integration solutions can take advantage of pipelines. A pipeline is simply a chain of events that can be scheduled or triggered and are kicked off within your CI system. They can be quite simple and only involve a few tasks or complex and contain many tasks and can include both serial and parallel paths. There is no such thing as a standard pipeline but most incorporate unit tests, acceptance tests, packaging, reporting and deployment phases. It’s not unusual for your CI team to have several software build pipelines constructed to accommodate different types of builds. For example: <ANIM> Pipeline 1 may be invoked each night and only used internally to test the code that was committed to that day. <ANIM> <ANIM> Other pipelines might include more automated testing and deployment and packaging tasks to ready the software for general release and public consumption. <ANIM> You may choose to only include scanning on a subset of your pipelines where you need visibility into security, licensing, and operational risk. You need to be careful not to get in the way of downstream activities such as QA testing. So, if you are adding scanning to your nightly or weekly QA builds, you probably don’t want to fail the builds and slow down the software development testing process. However, prior to releasing software to customers, you may want to leverage the build pass / fail options to monitor configured policy violations and fail the build if they arise. <ANIM> In these situations, the build will be halted and downstream tasks will not be completed. Notifications can be distributed to key personnel to inform them of the failure so it can be addressed. GO TO NEXT SLIDE
• #27: PITTENGER: In summary, we’ve discussed: The application development environment is changing rapidly Security testing in these environments requires further automation to meet the needs of an agile environment OSS is pervasive and integral part of app development OSS has unique security and support challenges Therefore, level of risk warrants action. If you agree this is a priority, the next steps are critical. 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 security and software 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? What steps are they taking to automate their processes? 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?
• #28: At this point, we’d like to open it up to questions and answer those that have already come into the Chat window…. If you have further questions, please contact us at: