Risk
9/18/2012
11:17 PM
Connect Directly
RSS
E-Mail
50%
50%

Real-World Developers Still Not Coding Securely

Though secure development lifecycle advocates have shown the cost benefits of catching vulnerabilities before apps go live, organizations still don't embed security into development

The extreme pressure on developers from line-of-business leaders to push out new web application feature sets as quickly as possible, combined with a lack of security development objectives or actionable security guidance, continues to negatively impact web application vulnerability levels. A new study out this week based on a survey conducted by Forrester Research on behalf of Coverity showed web application incidents still remain expensive as a result of these vulnerabilities and are costing some organizations hundreds of thousands to millions of dollars.

[Learn more about best practices for protecting your databases. See Strategies For Protecting Web-Facing Databases . ]

Advocates have long argued for the benefits of embedding secure development life cycle (SDLC) principles into coders' day-to-day workflow in order to save on costs.

"The industry has been championing over the last couple of years is, if you can find software defects whether they're quality issues or they're security issues earlier in the cycle, it's going to cost you a lot less and take a lot less time to fix them," says Jennifer Johnson, vice president of marketing for Coverity.

But unreasonable development time constraints, impractical security tools that don't work well within real-world development settings and inadequate training on secure coding principles have all conspired together the squash the SDLC ethos at most dev shops. According to survey results, only 51% of organizations currently have coders conduct security testing, and only 40% of organizations report they test during development. And just 42% have any kind of secure coding guidelines in place within their organizations.

These lackluster numbers are directly impacting organization's ability to fend off hackers wise to the good odds of finding Mack-truck-size holes in business web applications.

"Web-facing applications offer hackers today some of the most direct--and easy--routes to compromising sensitive databases when these applications aren't securely coded or configured," says Gyutae Park, head of technology at Money Crashers Personal Finance.

According to Forrester's report, approximately 51% of organizations have had at least one security incident attributable to the exploitation of web application vulnerabilities. Among those reporting these incidents, 42% suffered losses of at least $100,000, with 8% reporting losses of over $1 million as a result of web app vulnerability exploitation.

It would be easy to blame developers for slip-shod work, but security experts say the real truth is that businesses need to do a better job setting coders up for security success.

"While application developers are on the front lines of securing access to applications, I would argue that organizations should do whatever they can to place the responsibility for security where it needs to be – the business--not where it has traditionally been forced to be--the application developer," says Jonathan Sander, senior director of IAM product management for Quest Software. "Developers do the best they can with what they have, which typically isn't enough as far as security and compliance are concerned."

Some of the biggest problems revolve around developer success metrics. While most developers are carefully evaluated on their ability to deliver features and functionality on deadline, their job performance is rarely measured by how securely they deliver that code. According to the Forrester report, 70% of organizations do not assess developers with security-related metrics.

Similarly, many developers feel that they're given inadequate tools to realistically test code in a real-world development environment. Just under a third of developers said they still haven't found suitable application security tools that work well with their development processes. The survey showed that the top three problems developers have with these tools is poor integration with development processes, high false-positive rates and a level of complexity that requires overtaxed developers to become security experts to use them.

"Tools that were designed for security auditors are great for security auditors," Johnson says. "But what we're seeing is they're trying to force fit these technologies into development and just expect them to use them."

Not to say that training isn't critical. It is, says Dylan Evans, vice president of operations for Reveal Digital Forensics and Security.

"The vast majority of web programmers are familiar with SQL injection and its sibling, Cross-Site Scripting, on a conceptual level, and many realize that these vulnerabilities can lead to massive damage for websites," Evans says. "However, understanding why something is dangerous and actively preparing for that danger are two different issues."

But much of the lack of training comes down to a lack of time. Learning secure coding principles and implementing them takes time that the business is just not giving its developers.

"In many cases, convenience and speed wins. Developers can code to get things done and the application to work as fast as possible, as that is the business need," says Stu Sjouwerman, founder of KnowBe4. "But coding for security, with the discipline to test all components for secure programming takes time."

Until that luxury of time is more amply provided, the benefits of SDLC will likely never be fully maximized. Given time constraints and the fact that SDLC can never completely erase every vulnerability before sending an application live, the need for after-the-fact vulnerability management will persist. No matter how great an SDLC program is, penetration tests, vulnerability scanning and application firewalls still will play an important role in managing vulnerabilities on production applications.

"Bottom line," says Rob Rachwald, director of security strategy, Imperva, "SDLCs are nice but vulnerabilities are inevitable and enterprises shouldn't let secure coding practices lull them into a false sense of security."

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
mmulhern76101
50%
50%
mmulhern76101,
User Rank: Apprentice
9/19/2012 | 3:35:12 PM
re: Real-World Developers Still Not Coding Securely
regarding "It would be easy to blame developers for slip-shod work":- you are being too gentle.- As long as managers have ready-made scapegoats available, they have absolutely zero motivation to allocate more resources, that is, time.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.