Risk
4/30/2013
01:42 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Building A Detente Between Developers And Security

Don't give a long list of software defects to the developers if you value a good working relationship

Running static code analysis on software to pinpoint potential security flaws will generally turn up a long list of issues that need to be triaged.

Yet sending the list to developers and expecting them to fix the issues is a quick way to create a dysfunctional software-security life cycle. Instead, security teams need to understand developers' priorities before requesting that they fix their code. Using members of the security team who have development experience, for example, can help the two side more effectively communicate, says Chris Wysopal, chief technology officer and co-founder of application-security firm Veracode.

"Developers can smell a nondeveloper really, really quickly," says Wysopal. "A lot of security teams don't have the knowledge of how to fix these issues."

All software companies have difficulties eradicating software flaws. In 2012, the number of vulnerabilities publicly reported grew 26 percent to 5,225, according to security testing lab NSS Labs. Of the 10 software developers with the most vulnerabilities disclosed, only four had fewer vulnerabilities than their previous year, and only Microsoft did better than its 10-year average.

No wonder, then, that executives are concerned about the state of software security. More than 70 percent of C-level executives rated application vulnerabilities as their top security concern, according to the (ISC)2 Global Information Security Workforce Study released at the RSA Conference in February. The previous year's study found the same trend, says W. Hord Tipton, executive director of (ISC)2.

"This is one of the few times I've seen the same concern, the same top-priority issue surface on top of the list of things that keep people awake at night," Tipton says. "The problem is that we keep finding the same bugs, [and] we don't even fix the simple things."

Poor communication and significant friction between developers and the software-security team is a key reason that software issues continue to go unaddressed. While managers and executives worry about application security, that rarely translates into a broad business-focused effort to improve software security: Only about 12 percent of the security professionals have a role in software development, according to the (ISC)2 study.

[Fear of business disruption and downtime often leaves enterprises hesitant to scan the critical applications that hackers are most likely to target in their quest for exploitable vulnerabilities. See Too Scared To Scan.]

To cross the divide between the two groups, companies should first educate their developers in the importance of software security and how vulnerabilities can impact the business's bottom line, says Jacob West, chief technology officer for Hewlett-Packard's Enterprise Security Products group. Developers should also be trained in how to avoid common mistakes and write more secure code. Furthermore, to ease the burden on developers, the software security lead should attempt to automate any task that may slow down the process.

"We should be automating those small tasks as much as possible, so we are not adding unnecessary overhead to the developers' lives," West says. "A lot of those little things -- run a scan here or turn on an option there -- are some of the things that make a new security initiative really annoying."

The Denim Group, for example, has created a tool to help security teams track and analyze software vulnerabilities that have been submitted for analysis. The results of a vulnerability scan can automatically be added to the current prioritized list and any duplicates removed.

Companies should also select someone from the development group as a security lead and anoint them as the resource for security.

"Having that sort of resource as part of your team can really streamline the interaction between the security group and the development organization," West says.

Finally, companies should have tangible goals and metrics associate with the development process, so that developers and the security team have a yardstick by which to measure their progress, he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Robert Lemos is a veteran technology journalist of more than 16 years and a former research engineer, writing articles that have appeared in Business Week, CIO Magazine, CNET News.com, Computing Japan, CSO Magazine, Dark Reading, eWEEK, InfoWorld, MIT's Technology Review, ... View Full Bio

Comment  | 
Print  | 
More Insights
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