How to Prevent a Breach From Spring Break

Spring Break, the latest named vulnerability, is more serious than the moniker implies. Spring Break is a critical remote code execution vulnerability in Pivotal Spring REST, one of the most popular frameworks for building web applications, and the effects of this vulnerability are widespread.

A patch for Spring Break has been available since September of last year, but the vulnerability broke into the news only last week, after the researchers who discovered Spring Break published their findings. The researchers agreed to hold back publishing until now, allowing organizations more time to update their applications. Pivotal recommended patching the vulnerability as soon as possible, in a blog post from Spring Data Project Lead Oliver Gierke. Yet even after six months, many organizations with applications built using the Spring REST component are likely still unpatched.

The attention Spring Break is getting in the media and in security circles is warranted, because of the urgency in patching affected applications, and because it raises serious concerns about application security as a whole. It’s notoriously difficult for businesses to maintain their software and patch vulnerabilities in components, whether they be commercial or open source libraries and frameworks. That’s because many developers are unaware of the components in their applications, and no one is assigned the responsibility to update components when a new version is available.

The consequences of inaction are severe. We don’t know at this point if the easily-exploitable Spring Break vulnerability was used in any attacks, but a similar RCE vulnerability found in Apache Struts last year was the root of a recent mega-breach, which put at risk the data of 143 million Americans.

With so much of our economy dependent on software, we can’t afford to leave it to chance that unpatched applications will not be discovered or exploited by bad actors. Fortunately, there are some essential but achievable steps organizations can take to secure their applications from known vulnerabilities in components.

1. Set a policy

Set a policy establishing that component vulnerabilities are important to the business, just like other non-functional requirements such as availability. Having a policy can also ensure that there’s traceability between security requirements and regulations. Several industry regulations, including the recently enacted New York Department of Financial Services rules, along with healthcare and PCI rules, require organizations to manage risk from third-party components.

2. Create a baseline inventory

There are several ways to build an inventory, including looking at source control or component repositories. One of the most reliable methods may be leveraging security testing you are already doing. Some static analysis providers may already be creating an inventory of components for you through software composition analysis. An inventory can be invaluable to the security team’s response to a newly announced vulnerability, allowing you to focus your efforts on the applications that you know have the vulnerable component.

3. Educate developers

Some developers may be unaware that they need to monitor for new security patches, or that the components they use may rely on other components that may not be secure. Veracode research last year found that a vulnerability in Apache Commons Collections (ACC) had spread to more than 80,000 other components that used the ACC component. Fortunately, a focus on developer education leads to measurable results. Our research for the State of Software Security shows that organizations using developer education, whether delivered in one on-one sessions or through self-training video courses, saw improvements in flaw reduction.

4. Integrate security testing throughout the development lifecycle

As development teams make more changes to their applications, it’s important to keep the inventory, and the security picture, up to date. Software composition analysis makes this easy by collecting information about your application’s open source components at the same time that static analysis is conducted – including open source components used by compiled libraries for which you have no source code.

5. Shift the mindset

The functionality open source components deliver can be an asset to a development team, but keep in mind that the asset is offset by technical debt that requires regular payments, in the form of applying regularly released updates to the open source library. And just as with regular debt, failure to make regular payments on technical debt can have catastrophic consequences downstream.

Too often we begin to focus on preventive measures like these after the damage has been done. It’s time to take action to make sure you don’t get breached by the next Spring Break, whatever it may be called.

----

To learn more about how to reduce risk from third-party components, watch a short video and download our whitepaper. Check out the video below, with Veracode VP of Research Chris Eng, explaining how to determine whether a branded vulnerability, like Heartbleed, Shellshock or Spring Break, requires fast action or is more hype than harm.

[nid-embed:26706]