How do organizations build secure applications, given today's rapidly moving and evolving DevOps practices? Join Black Duck and our customer experts on best practices for application security in DevOps.
You’ll learn:
-New security challenges facing today’s popular DevOps and Continuous Integration (CI) practices, including managing custom code and open source risks with containers and traditional environments
-Best practices for designing and incorporating an automated approach to application security into your existing development environment
-Future development and application security challenges organizations will face and what they can do to prepare
1. Software Security
Assurance for DevOps
Mike Pittenger, VP Security Strategy, Black Duck Software
Lucas v. Stockhausen, Sr. Product Manager HPE Fortify
2. • Challenges impacting application security in
DevOps
• Strategies for overcoming these challenges
• 5 Things you can do tomorrow
Agenda
2
3. Why We Partnered
• Organizations today manage application security for both custom and open
source code
• HPE Security Fortify is a market leader in the application security space for
customer code; Black Duck is a market leader in the application security
space for open source
• Together, we allow customers to manage security risk in custom and open
source code, through a single interface
3
4. GROWING ATTACK SURFACE NEW DEPLOYMENT MODELS
Web, Mobile, Cloud, IoT
Containers, IT and Small Security
Teams
• Which apps are people using?
• How do I set internal policy
requirements for app security?
• Is my private / sensitive data
exposed by apps?
• Who is developing the apps?
• 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?
OPEN SOURCE
Increasing Portion of Code Base
• What policies are in place for
open source use?
• How are those policies enforced?
• Who is tracking usage for new
vulnerabilities
Application Security Challenges
4
5. • Web applications
• Cloud applications and services
• IoT
Changing Attack Surface
5
“If perimeter control is
to remain the paradigm
of cybersecurity, then
the number of
perimeters to defend in
the Internet of Things is
doubling every 17
months.”
Dan Geer
In-Q-Tel
RSA 2016
6. Up to 90%
Open Source
TODAY
50%
Open Source
2010
20%
Open Source
20051998
10%
Open Source
Open Source is the Foundation of Modern Applications
6
7. @FUTUREOFOSS
#FUTUREOSS
GROWING OPPORTUNITY
FOR POLICIES &
PROCEDURES
50%
Nearly
2016
INSIGHTS 4
@FUTUREOFOSS
#FUTUREOSS
UNDERSTANDING YOUR OPEN
SOURCE CODE
Top ways companies review
their code for open source
Development teams
manually keep track of
open source use
48% 30% 21%
Ask developers about
open source content
Use third party tools
to scan for open
source content
2016
INSIGHTS 4
@FUTUREOFOSS
#FUTUREOSS
HOW ARE COMPANIES
HANDLING KNOWN OPEN
SOURCE VULNERABILITIES?
of companies have
no process for
identifying,
tracking or
remediating known
open source
vulnerabilities
Nearly
1/3
2016
INSIGHTS 4
Open source Use has Outpaced Process Maturity
Everybody is using open source, but many organizations still do not have
adequate processes or tools in place to manage it.
7
9. OPEN SOURCE CODE
DELIVERED CODE
Open Source Enters Your Code in Many Ways…
DEVELOPER DOWNLOADS
OUTSOURCED DEVELOPMENT
THIRD PARTY LIBRARIES
CODE REUSE
APPROVED COMPONENTS
COMMERCIAL APPS
…and security, compliance & quality risks can come with it.
11. • Automated testing finds common vulnerabilities in
the code you write
• They are good, not perfect
• Different tools work better on different classes of bugs
• Many types of bugs are undetectable except by trained
security researchers
Static Analysis Does Not Help With Open
Source
All possible
security vulnerabilities
FREAK!
12. Four Factors That Make Open Source Different
12
Easy access to code
Exploits readily availableVulnerabilities are public
Used Everywhere
13. Who’s Responsible for Open Source Security?
13
Commercial Code Open Source Code
• 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
14. Bad Guys Have Quotas Too (Non-Targeted Attacks)
Rational Choice Theory
• Criminals make a conscious, rational choice to commit crimes
• Behavior is a personal choice made after weighing costs and benefits of
available alternatives
• The path of least resistance will be taken
18. • HPE Security Fortify + Black Duck Technology
Alliance Partnership
• Address pervasive, rapidly-growing Security &
Compliance risks with Open Source
• Gain visibility on risks across Custom Code and
Open Source Code
• Integrate governance and remediation as part of
Software Security Assurance
Black Duck Integration with HPE Security
Fortify SSC
Risks in Open
Source Code (Black
Duck Hub)
Manage Risks in Open
Source as part of HPE
Security Fortify SSC
Risks in Custom
Code with SAST,
DAST, & RASP
20. Overview Shows Black Duck Results Within HPE Security Fortify
Open Source
vulnerabilities (3rd Party
Components) from Black
Duck analysis
Custom Code vulnerabilities
from Fortify SCA analysis
26. • Speak with your heads of application security and software 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?
• How do they account for the different testing requirements for custom code v. open
source?
• What is the best security automation strategy for your organization?
What Can You Do Tomorrow?
26
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.
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
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.
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…
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!
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.
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
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 -
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.
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
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
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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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?
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: