Risk
11/13/2012
03:29 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

Enterprises Pressure Software Vendors To Clean Up Their Apps

New Veracode software security report, BSIMM4 findings show enterprises driving third-party software vendors to write more secure code

More businesses are flexing their procurement muscles to pressure software vendors into supplying them with more secure code as their own in-house secure development programs mature.

New data gathered from software security testing-as-a-service vendor Veracode found that software vendors actually do a better job following their customers' application security policies than those of the industry: While 38 percent of vendor-supplied applications comply with their enterprise customers' policies for secure software, only 10 percent of software vendors' products tested by Veracode comply with OWASP's Top 10, and just 30 percent with the CWE/SANS Top 25. The enterprises covered in the report make more than $500 million in revenues.

"The realization that's happening now is that the supply chain is a big part of application security problems," says Chris Wysopal, CTO and co-founder of Veracode, which based its report on data from 939 application builds submitted to the company between January 2011 and June 2012. "Attackers are going more after the application tier, [including elements] that were not built by [the enterprise], but by someone else."

[Vulnerable technology supply chains have become a concern of security professionals and politicians alike, but a few steps could help minimize the possibility of attacks. See Preventing Infrastructure From Becoming An Insider Attack.]

The number of vendors getting their applications security-tested by Veracode grew nearly 50 percent during that 18-month period, much of which was prompted by prospective or existing customers requiring their vendors do so. The financial services, software/IT services, and technology industries are leading the way, according to Veracode's findings, accounting for more than half of the software assessment projects.

This trend jives with the latest findings of the Building Security In Maturity Model (BSIMM) study, BSIMM4, which was released in September by Cigital. Large enterprises, especially in the financial, pharmaceutical, and energy industries, for example, are driving the testing of third-party software, says Sammy Migues, a principal at Cigital who works on BSIMM. BSIMM is basically a case study of real-world software security initiatives, based on in-depth measurement of major enterprises.

"Firms are saying, 'I know you, software producer, don't have security compliance requirements, but I have compliance requirements out the wazoo, and you can no longer sell me software that makes it difficult for me to achieve compliance. That's unacceptable,'" Migues says.

Migues says some BSIMM participants are concerned about bugs popping up in external code they are deploying. "They are seeing more bugs in other people's code," but, of course, BSIMM participants are enterprises that are employing secure software development practices, he says. Some of these organizations then must have binary analysis performed on the external code or perform static analysis on the external code integrated into their apps, he says.

Some 22 of the 51 enterprises participating in the BSIMM4 report say they now include software security responsibilities in their service-level agreements with vendors, Migues says. "The next level of maturity for activity is creating an SLA boilerplate with legal and slapping it into the majority of outsourcing projects. Twenty-one of the 51 firms, about 40 percent, are doing that," he says.

Conventional wisdom used to be that if you don't ask for security requirements in software, you won't get them, and if you do, you're probably not going to get them, either, says Mano Paul, software assurance adviser for the ISC2. But that's now changing, he says.

"There has been awareness and recognition that, in fact, we are losing control of the software development process. But that cannot continue because losing control of security aspects are relevant when we outsource and procure software," Paul says.

The best bet is not to accept on face value that software vendors have cleaned up their code, but rather, verify it, he says.

"In the early days, security was always an afterthought. Now security is being asked for and mandated by regulations and other driving forces that make it become part of the product itself to integrated it or make it part of the SDL [secure development lifecycle]," he says. "The trend is [going] in the right direction ... but fully secure software is not going to happen."

It's more about making it harder for attackers to exploit software, he says, by adopting best practices and writing more secure and clean code.

Veracode, meanwhile, also found that most of its enterprise customers are still in the early phase of formal vendor software-testing programs: Less than one in five of its enterprise customers asked for a code-level test from at least one vendor. The SaaS vendor split enterprises into two categories: those with a formal or an informal method for choosing apps for testing. Those with a formal protocol had buy-in from security, business, and procurement teams, and strongly mandate vendor application testing. Others use more of a case-by-case, informal approach.

Some 45 percent of vendor applications became compliant within a week under the more formal enterprise programs, and 28 percent in the ad-hoc ones, according to Veracode's data. A tough security policy wasn't necessarily successful, however. "Setting a less rigorous compliance policy that vendors perceive as achievable encourages higher vendor participation," the report says.

Next Page: Vendor Fail Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DarkReadingTim
50%
50%
DarkReadingTim,
User Rank: Strategist
11/14/2012 | 1:57:26 AM
re: Enterprises Pressure Software Vendors To Clean Up Their Apps
Readers, do you think software developers should be required to get some sort of security certification?-Š (Posted by Tim Wilson, editor)
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web