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-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web