What can the financial services industry learn from the U.S. Department of Homeland Security? In this third segment of my blog series on open source component security as it relates to the recently updated Financial Services Information Sharing and Analysis Center (FS-ISAC) guidelines, I explore the need for speed: humans vs. machines.
One mantra of the Homeland Security Agency is – “if you see something, say something” – which works on a human level to keep us safe. This same mantra has been used across the open source community to keep components secure, by identifying vulnerabilities and sharing that knowledge through public channels like the Common Vulnerabilities and Exposures (CVE) database. But it is now time we recognize that “if you see something, say something” only works for open source at human speed.
Just as the U.S. Department of Homeland Security relies on electronic surveillance to keep citizens safe, the open source software community also needs to embrace this approach. To properly ensure open source is secure, we need to work at machine speed.
We have longed surpassed a tipping point in open source development and usage of open source components. Not only do custom applications rely heavily on such components, so do the open source components themselves. Let’s take the Java developer community as an example.
- There are an estimated 10 million Java developers now worldwide.
- Java developers initiated over 13 billion requests of open source components last year from the Central repository.
- The average component depends on 5 other components (which depend on a bunch of their own and so).
Looking at the Maven ecosystem and traffic associated with the Central Repository, you can readily see years of exponential growth of open source component downloads. The same patterns appear with RubyGems, NPM and other major open source ecosystems. We have entered an era of massive and highly effective component re-use, where everyone can, paraphrasing Einstein, stand on the shoulders of open source giants.
Recent research also shows that 64 million vulnerable Java open source components were downloaded in 2013. While developers can rely on the Common Vulnerabilities and Exposures (CVE) database, manual review of this database for every component is simply not feasible if an organization wants to release its software on time.
Making the challenge more considerable, organizations also have trouble keeping track of which components, including the specific versions, are used in which applications. And further amplifying the concern, you need to consider the component dependencies (five on average, but can range to hundreds).
I would argue that a manual approach today is truly impossible given:
- the volume of components used
- the complexity of each component
- the cadence with which new vulnerabilities and new component versions are announced
The better approach is to have humans establish risk thresholds and supporting policies. To have machines automate and enforce those policies. And to have humans manage the inevitable exceptions.That is, we need to complement human speed approaches with machine speed capabilities.
Whether organizations use software-based technologies and data services from Sonatype or other vendors, we are now well beyond maintaining open source security at human speed. Would you agree?
In my recent blog, ‘Financial Services Organizations have Open Eyes on Open Source‘, I shared how Sonatype’s company mission aligns with the recent FS-ISAC guidelines put out by the third party software security working group. In short, open source security can’t be an after thought. Security isn’t only the responsibility of ‘security professionals’ but instead a shared responsibility for all parties involved in developing or managing an organization’s software supply chain. Better put in the FS-ISAC guidelines, ”the most appropriate type of control for addressing the security vulnerabilities in open source, including older versions of the open source, is one that addresses vulnerabilities before the code is deployed—i.e. by applying policy controls in the acquisition and use of open source libraries by developers.”
The Drive to Secure Applications
Which brought us to the question, do developers consider themselves an application security driver or consumer? Preliminary results on 275 responses to a new survey by the Trusted Software Alliance (TSWA) showed that 67% of developers consider themselves a primary driver for application security (positive news for sure). While the developers considered themselves a primary driver for security, we have also seen survey results revealing 55% of participants “do not have clear policies” or “have policies that are not effectively enforced”. Being a primary driver of application security does not always mean that you have the policies in place to support that drive or responsibility.
Advice from the Front Lines
While developing policies could help developers and others driving application security efforts, another approach would be to ensure these policies are built into the tools developers and others use today. This is an approach echoed in a recent interview with Jim Routh, Chief Information Security Officer and lead for the Global Information Security function at Aetna (he is also Chairman of the FS-ISAC Products & Services Committee and a former board member).
Listen to Jim Routh’s 2 part interview on the Trusted Software Alliance.
Routh shared, “We have to apply techniques that address both the quality and security attributes of open source components as they are acquired. By doing so, we can improve confidence in the LEGO-like assembly process [of downloading and assembling components] used by developers.”
“The developers can then use those components with some level of confidence and certainly understand the tradeoffs between quality and security”, Routh continued. “That technology is just emerging today and is likely to mature over the next several years.”
In addition to defining policies and making them more accessible to employees companies should start looking to where their investments in application security are focused. It’s not far to say, financial services firms aren’t properly investing in application security. Billions are being spent everyday searching and testing for vulnerabilities of applications that are already in production.
The change we’re hoping to see is for companies to look deeper into their application development supply chain for potential vulnerabilities that might be introduced when 3rd party components are consumed allowing developers to make better decisions about the components they integrate into their software projects and ensure those projects remain secure overtime.
Want a simple place to start?
Sit down with your developers and ask them how they are taking advantage of open source components in the software development lifecycle. You’ll likely find the approach varies and data shows it’s because of the lack of standardized policies and tools that ensure security is built into the development process from the start.
To learn more about the FS-ISAC guidelines and the need for ‘Policy Management and Enforcement for Consumption of Open Source Libraries and Components’, read the full FS-ISAC whitepaper.
For details on the announcement, watch the full video http://youtu.be/jQWdBwUbW-I.
Today Sonatype and HP announced Sonatype’s Component Lifecycle Management (CLM) analysis technology has been integrated into HP’s cloud-based software security solution – HP Fortify on Demand. HP Fortify on Demand customers will have access to an Open Source Application Scan using the Sonatype CLM analysis technology from directly within the Fortify on Demand user experience.
HP Fortify on Demand delivers comprehensive, accurate and affordable security assessments that identify vulnerabilities in any application —web, mobile, infrastructure or cloud. Sonatype provides analysis and identification of third party and open source components commonly used as building blocks in modern applications – with a focus on security, license, quality, and policy issues. Together, these capabilities deliver a new level of visibility and analysis into overall application security and risk.
For more detailed information about this new breed of application security from HP and Sonatype, please visit http://www.sonatype.com/fortify.
Let me open your eyes to a tidal wave of change that has already flooded the development organizations across Financial Services and other industries:
“Software applications are no longer coded from scratch. They are assembled from building blocks — commonly known as open source components.”
This is not a prediction about a tidal wave to come. The wave is already on shore. In 2013, developers downloaded 13 billion open source components from the Central Repository — one of the largest web repositories for components. Why is this happening? Simple, it speeds development. Time to production is a critical objective for developers and operations, and building blocks are simply easier to work with than coding everything from scratch. Today, 90% of a typical application is composed of open source and third party components. Component-based development is a good thing for the financial services industry, but it does not come risk free.
First, allow me to share some simple facts:
- In 2013 there were 46 million downloads of vulnerable components from the Central Repository.
- There are approximately 18 million developers worldwide.
- This means every developer on the planet downloaded an average of 2.5 vulnerable components last year.
And to make this matter real, these components make it into production applications everyday. The applications that run critical business systems for large fortune 500 companies. The applications you use for online banking, for investment tracking, for managing insurance claims, and so on. In fact, in Sonatype’s Open Source Software Survey, our data indicated ‘71% of applications contain one or more critical or severe vulnerability.’
To ease your mind some, you should know the risk associated with the use of open source components in financial services has not gone unnoticed. In 2013, the Financial Services Information Sharing and Analysis Center (FS-ISAC) published a report detailing appropriate security controls types for third party service and product providers. One of the three “control types” detailed in the report addressed open source libraries and components. Here are two brief excerpts from that report:
“Control Type 3…is included as a control because it represents how the supply chain is feeding internal software development processes within financial institutions today . The majority of internal software created by financial services involves acquiring open source components and libraries to augment custom developed software . The Central Repository (formerly Maven Repository) is one of the largest open source code repositories . Open source code is available freely and reviewed by many independent developers, but this does not translate into software components and libraries free from security vulnerabilities”.
“When application developers seek to build new functionality to meet business needs, they turn to open source libraries for access to components that dramatically improve the time to market of their delivery . The most appropriate type of control for addressing the security vulnerabilities in open source, including older versions of the open source, is one that addresses vulnerabilities before the code is deployed—i .e . by applying policy controls in the acquisition and use of open source libraries by developers. Therefore a combination of using controlled internal repositories to provision open source components and blocking the ability to download components directly from the internet is necessary for managing risk . In fact, Gartner recommends that “if open source is used, ensure that the frameworks and libraries used are legitimate and up-to-date, and that the compiler used hasn’t been compromised.”
Sonatype is already addressing the needed features to apply lifecycle management controls for open source components. As Sonatype CEO, Wayne Jackson shares, “Our mission is relatively simple. We just want to help developers make better decisions about the components they integrate into their software projects, and to help them keep those projects secure over time.”
Watch the full video, http://youtu.be/9I_g_VKey3E.
We’re excited to see this mission also reflected in the FS-ISAC guidelines outlined in their recent report ‘Appropriate Software Security Control Types for Third Party Service and Product Providers‘. Combining the controls recommended for financial services firms as well as the addition of A9 to the OWASP Top 10, ‘using components with known vulnerabilities’, its time to put this on your priority list. Don’t wait till your CISO comes to you with a question about where and how you’re using 3rd party components with known vulnerabilities, start incorporating policy enforcement during the development lifecycle now.
A sneak peek at interim results from the “Developers and Application Security: Who is Responsible?” 2014 survey are in, and there’s still time for you to participate. Here’s a little something for you to think about.
Once upon a time, we used to develop our own software. But these days, we are developing 90% of our applications from open source software (OSS) components. With the need for speed (to market) pressuring development organizations coupled with the convenience of OSS, the days of “write your own code” are gone forever – and that is good news.
The bad news: there are no “free puppies” in open source. While OSS benefits are tremendous, they do come with responsibilities we cannot overlook. The ease of downloading pre-built components should not distract us from our responsibilities to be vigilant about their quality, security, and licensing.
Early results from a Trusted Software Alliance survey of 225+ DevOps and AppSec professionals shows vigilance around OSS security concerns are top-of-mind. Where functional defects rank as the top security concern, 63% of those surveyed ranked open source vulnerabilities second overall.
Got 5 minutes? You can take the survey now. Then, you can share the results with your colleagues to spark conversation, highlight a critical need, or compare how your practices rank among your peers.
Date: January 14, 2014
Affected Versions: Nexus OSS/Pro versions prior to and including 2.7.0-06Summary:
A critical security vulnerability has been discovered by Sonatype in Nexus requiring immediate action. The vulnerability makes use of an execution path in an open source library that we have now (with the available patch) added a mitigating control for. This advisory provides the pertinent information needed to properly mitigate this vulnerability, along with the details on how to reach us if you have any further questions or concerns.
We identified this vulnerability during our security research activities and are not aware of any active exploits taking advantage of this issue. However, we strongly encourage all users of Nexus to immediately take the steps outlined in this advisory.
The identified vulnerability can allow an attacker controlled remote object creation and arbitrary code execution in the running Nexus instance without requiring user authentication. Although not every version of Nexus has been proven to allow for arbitrary code execution and object creation we are still considering the possibility that such a condition may exist, and we are highly recommending all instances of Nexus have the patch, detailed in this advisory, applied.
We are taking steps to mitigate this vulnerability in public forge instances and are also providing remediation guidance to the overall Nexus user community. We are currently coordinating with NIST as part of the vulnerability disclosure process and further details will become publicly available as soon as that process is complete. The placeholder identifier for this vulnerability is CVE-2014-0792.
The vulnerability is fixed in Nexus 2.7.1, which can be downloaded from the links below:
If you want to patch an existing instance to address this vulnerability see below.Compatibility of Patch:
This patch can be installed on any Nexus 2.x version. If you are running a 1.x version of Nexus you must upgrade before applying this patch. For detailed information on upgrade compatibility, please see:
The latest versions of Nexus can be found here:
Archived 2.x releases can be found here:
This patch works by building a white-list of allowed classes which can be instantiated. This mechanism will cover all Nexus use cases, but it may not cover all third party (non-Sonatype) Nexus plugins. We advise testing the patch in a non-production instance if you are using third party plugins.
If there is an issue related to the patch it will manifest itself in response to HTTP requests failing with error 400. In the logs you will see a message such as the following:
WARN: …whitelist.TypeWhitelist – Type NOT allowed: <classname>
ConversionException: No converter specified for class <classname>
If you encounter this error see the Configuration section below for instructions on how to remedy the problem.Installation:
- Copy xstream-1.4.6-SONATYPE-02.jar into $NEXUS_HOME/nexus/WEB-INF/lib/
- Shut down Nexus
- Remove the old $NEXUS_HOME/nexus/WEB-INF/lib/xstream-<version>.jar
- Start Nexus
After successful installation you will see a message like this in the $NEXUS_HOME/logs/wrapper.log file:
2014-01-07 14:43:47 INFO [jetty-main-thread-1] – com.thoughtworks.xstream.XStream – Version: 1.4.6-SONATYPE, white-list support available
Note: The message is logged too early to be seen in the nexus.log fileConfiguration:
If you are using plugins which are not supplied by Sonatype that register with xstream in a non-standard way it may be necessary to extend the whitelist. Please see the configuration article for instructions.Support:
Q: What is the risk associated with this vulnerability?
A: Nexus can be compromised, allowing an attacker to execute arbitrary code or allow for arbitrary class instantiation. The compromise is limited to the boundaries of privileges of the Nexus server process. This implies an attack could result in tampering or otherwise exfiltrating data from the Nexus instance.
Q: What preconditions must be met in order to be vulnerable?
A: An attacker must have network access to the Nexus instance. Therefore, internet accessible instances of Nexus imply available access by very a large audience versus the more limited audience associated with non-internet accessible instances. Nexus 2.7.0 is known to be vulnerable to arbitrary code execution and other versions may be. All versions are subject to arbitrary class instantiation, which could lead to system compromise.
Q: Are there implications associated with this advisory itself?
A: Public disclosure unfortunately means bad actors may try to take advantage. While we have initially limited the information to the minimum details necessary for users to affect an appropriate fix, this merely slows down a would be attacker. As such, we are advising all organizations utilizing Nexus to immediately assess their individual impact and take appropriate action in response.
Q: Where can I obtain more information associated with the vulnerability?
A: Sonatype will be releasing details of this vulnerability as part of a standard CVE disclosure process. At this time, and in the interest of best protecting our user community, we are limiting the information released to that absolutely required in order to assess impact and affect remediation.
Q: How did Sonatype discover this vulnerability?
A: The vulnerability was identified during our internal security research activities. Specifically, this was not in response to known attacks, and therefore allowed for a proactive response.
Q: Was Sonatype’s CLM platform used in response to this vulnerability?
A: Yes. In this particular case, the open source component at the core of the issue may not be vulnerable in and of itself. This debate is still ongoing. At a minimum though, certain uses could result in exposing a vulnerability, and we found this to be the case in Nexus. While CLM did not alert us to a particular vulnerability, it was used to identify the applications within our overall portfolio that were using this particular component and pinpoint the locations requiring further investigation. If it is decided that the underlying component is in fact vulnerable, that information will be added to the CLM feed and thus all customers using this component would receive an alert about their own potential vulnerability via the CLM platform.
Q: Why is Sonatype making this information publicly available?
A: This is part of a responsible disclosure process. Given Nexus is an open source project used by over 20,000 organizations worldwide, notifying the user base will invariably lead to broad dissemination. We are taking a concerted and proactive approach in our outreach activities and an effort to achieve the most rapid remediation possible.
Q: How can I be sure I am notified of new advisories in the future?
A: Sonatype periodically publishes vulnerability announcements for popular components as part of our CLM security research. Any notable alerts on Sonatype products will also be published to this list. You may subscribe to this low volume advisory list here: http://www.sonatype.org/advisories/subscribe/