Risk
9/13/2011
05:03 PM
Connect Directly
RSS
E-Mail
50%
50%

Managing The Risk Of Flaws In Third-Party Software

Companies need to focus on finding and resolving vulnerabilities in software libraries on which their own products rely, experts say

Ask a CIO about application security, and many will talk about efforts to cull vulnerabilities from their own products.

Yet in many cases, the risk is not in code that internal developers have written, but in components provided by outside developers, whether open-source libraries or third-party toolkits. Take the open-source renderer WebKit: While many companies know that browsers, such as Apple's Safari or Google's Chrome, rely on WebKit, so do a number of other applications, such as Entourage 2008, Yahoo! Messenger, and Macromedia's Contribute 3.

Companies that rely on third parties for code place the security in the hands of other developers, says Barmak Meftah, vice president of enterprise security products for Hewlett-Packard.

"Companies don't typically think of the risk that third-party software opens them to and the inherent use of open-source software as part of their stack," Meftah says."There is an assumption that vendors and open-source developers have gone through the security checkpoints during the application development process, and that assumption is false."

To secure their software, companies must first figure out which code components have become part of their code base. The first step is to take a census of all the code used for development, says HD Moore, chief security officer with vulnerability management firm Rapid7 and chief architect of Metasploit.

"Even development teams that are pretty well-versed in what they are doing and know what their product looks like may not be aware of what back-end libraries have been used, and that is what you cover during a code audit," Moore says.

As a prelude to any code audit, companies must verify that they are able to assess a software library, whether open-source or close-source. If the libraries are supplied by a third-party developer, then companies must focus on contract language, including the first step of getting permission to analyze the software, HP's Meftah says.

"We are seeing an increasing trend in having contracting clauses that allow the end users to do some analysis on the software," he says.

Once companies have established their rights to analyze the software, the developers and IT security teams need to do an application assessment and find the vulnerabilities in the software, whether through static analysis, by monitoring the developer's support forum, or through an intelligence service that tracks changes to software.

The company can then make an informed decision to patch the software or, if a patch is not practical, use a runtime analysis product to harden the application against exploitation of any critical vulnerabilities.

"Any anomalous activity that goes through that component can be tracked," Meftah says. "You could live with the vulnerable piece of software as long as you have hardened it."

One problem for many companies is that the source of a software library might not be the sole supplier, Veracode's Wysopal says.

"Every third party you are dealing with may have third parties that they're dealing with as well," he says. "So someone who is doing their due diligence should go to their third-party supplier and ask what are they doing for application security."

This so-called nested third-party supply chain problem can hide the actual source of software and make fixing vulnerabilities more difficult, he says.

Even after chasing down the code components on which a certain library might depend, companies still have the problematic task of verifying that patches do not break the applications. The process is an arduous one, but necessary for companies that use third-party components, Rapid7's Moore says.

"You can definitely go on a rabbit hole chasing these down," he says.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-3409
Published: 2014-10-25
The Ethernet Connectivity Fault Management (CFM) handling feature in Cisco IOS 12.2(33)SRE9a and earlier and IOS XE 3.13S and earlier allows remote attackers to cause a denial of service (device reload) via malformed CFM packets, aka Bug ID CSCuq93406.

CVE-2014-4620
Published: 2014-10-25
The EMC NetWorker Module for MEDITECH (aka NMMEDI) 3.0 build 87 through 90, when EMC RecoverPoint and Plink are used, stores cleartext RecoverPoint Appliance credentials in nsrmedisv.raw log files, which allows local users to obtain sensitive information by reading these files.

CVE-2014-4623
Published: 2014-10-25
EMC Avamar 6.0.x, 6.1.x, and 7.0.x in Avamar Data Store (ADS) GEN4(S) and Avamar Virtual Edition (AVE), when Password Hardening before 2.0.0.4 is enabled, uses UNIX DES crypt for password hashing, which makes it easier for context-dependent attackers to obtain cleartext passwords via a brute-force a...

CVE-2014-4624
Published: 2014-10-25
EMC Avamar Data Store (ADS) and Avamar Virtual Edition (AVE) 6.x and 7.0.x through 7.0.2-43 do not require authentication for Java API calls, which allows remote attackers to discover grid MCUser and GSAN passwords via a crafted call.

CVE-2014-6151
Published: 2014-10-25
CRLF injection vulnerability in IBM Tivoli Integrated Portal (TIP) 2.2.x allows remote authenticated users to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.