Risk
6/16/2010
10:25 AM
50%
50%

Why Can't Johnny Develop Secure Software?

Security experts agree that there's something wrong with the software development process, but there are differing opinions on how to solve the problem

It's another day in the life of a security pro -- or a hacker. Much of your time is spent searching applications for that one weak point, the one that will lead to the breach of sensitive data. And nearly every day, somebody finds one. Or more.

With all of the security know how offered today -- and all of the advanced tools offered to applications developers -- why is software still riddled with security vulnerabilities? The answers are many, and they don't always agree. And solutions to the problem? Those are even more diverse.

Vulnerabilities start, experts agree, because developers don't understand how to build security into the code they write.

"There's a lot more acceptance of security as part of the process now, but historically developers have never been responsible for security," says Brian Chess, founder and chief scientist at Fortify, a company that makes tools for secure software development. "We all understand locks and keys, but not many of us are locksmiths. That's where most developers are."

Caleb Sima, CEO of secure software development tool vendor Armorize, agrees. "Developers are builders and artists," he says. "They like creating, not tearing things down, to identify flaws. Security is not a natural thing for most of these people -- it's a different mindset."

There have been many initiatives to educate developers about secure software development practices, including certification programs from organizations like ISC(2), which offers a program that trains programmers in security disciplines. But the education process is slow, experts say.

"The talent coming out of schools right now doesn't have the security knowledge it needs," says Paul Kurtz, executive director at SAFECode, a nonprofit organization backed by major software vendors and focused on secure software development practices. "There needs to be a lot more work in our educational institutions to teach them how to develop secure code."

But nearly all experts agree that no matter how strong the training effort, the average developer will never be very security-savvy. "They're always going to be more focused on code quality and trying to meet their deadlines," Sima says. "If I'm a developer, as soon as I've been assigned a project, I'm already behind. If there's a faster way to do something, they're going to take it, because for them speed is more important than security."

So if the average developer can't become a security expert, how can organizations ensure the code written by that developer is vetted and tested to reduce vulnerabilities? Currently, most development organizations have a designated security-savvy person who is responsible for working with less-savvy colleagues to cut down on common vulnerabilities and act as a liaison with the enterprise IT security team, Fortify's Chess observes.

"This is the kind of person you can ask about security problems, or who can recognize when a line of code is going to create a buffer overflow issue," Chess says.

But this approach isn't very efficient because the "security developer" can be a bottleneck or may not recognize all of the vulnerabilities, Chess explains. Some organizations are responding by implementing secure development frameworks, such as BSIMM, which impose secure best practices across the entire development team.

"BSIMM is a good strategy if you have a formalized software development process," Chess says. "But if you don't, you're not going to build that process around security."

Marisa Fagan, an analyst at Errata Security, notes that such formal secure software development programs are often too much for development teams to handle.

"What's wrong with secure software development? The short answer is resources," Fagan says. "These programs have the [not entirely unwarranted] reputation of consuming large amounts of time, people, and money. We need programs that cut out all the fat. The secure coding program needs to fit the size and capabilities of the organization. If we ask too much from the average developer, we're going to get nothing at all."

Recognizing a market opportunity, many vendors are jumping into the secure software development fray in an effort to automate some or all of the process. Fortify, one of the oldest players in the U.S. space, has a framework called Secure Software Assurance and a tool set called Fortify 360. IBM, with its acquisitions of Ounce Labs and Watchfire, is building a broad tool set for secure application development. Armorize, whose tools have deeply penetrated the Asia-Pacific market, is just beginning its U.S. marketing effort.

Earlier today, secure development tool vendor Veracode launched a series of enhancements to its SecurityReview Web application testing service that promises developers a "cloud-based approach" to quickly improve software application security.

"Developers can now upload applications automatically and download line-of-code specific vulnerability identification and remediation instructions directly to defect tracking systems and integrated development environments," the company said. Veracode also issued a white paper on security testing in agile software development environments.

Even Dan Kaminsky, one of the industry's best-known security researchers, is getting into the act. Kaminsky this week launched a startup called Recursion Ventures, whose first product focuses on secure application development.

The trouble with today's model for writing more secure code and sidestepping known injection attacks, Kaminsky says, is it makes development much more difficult and requires more work for developers. The result: Developers often don't bother adopting these practices at all, resulting in insecure code, he says.

"Security development tends not to care how inconvenient it is for developers," Kaminsky says. "[This new venture is] about meeting developers halfway."

Each of these vendors -- and others -- offers a different approach to automating the development of secure code, but they generally agree that the idea is to help developers identify and remediate the most common coding errors and fix them on the spot, during development, rather than waiting until after the code is complete.

"If you go to the development team with one policy that solves 80 percent of the issues, you can get good results," Sima says. "One of the most common vulnerabilities is input validation. You don't need to know security to understand how to do input validation correctly and keep those errors out of your code."

Another key feature to look for in automation tools is the ability to spot vulnerabilities in the development process, as opposed to individual applications, Chess says. "When you go to a restaurant, you don't try to measure the quality and safety of each piece of food," he observes. "What you do is send in an inspector to look at the process to see how the food is being prepared. Did you apply the most common practices to ensure safety and quality? That's what needs to be done in the development environment."

At the commercial-software level, SAFECode also proposes that developers monitor the chain of custody of the code, so that vulnerabilities aren't introduced when it is passed between contractors or when it is distributed to end users, Kurtz says.

"Most of the studies on software development so far have really looked only at the security issue," says Kurtz, whose organization this week issued a white paper on the topic. "What we're saying here is that software integrity and authenticity need to be part of the discussion."

Will this emerging range of automation tools eventually help developers create applications with fewer security bugs? Experts are hopeful.

"When you think about it, the whole concept of code security analysis is still pretty young," Sima says. "Most organizations haven't really gotten started yet -- today, most of the vulnerability identification and analysis is done after the development cycle. But if you can shorten the vulnerability identification cycle and identify code errors right then and there during development, you're going to end up with better, more secure software."

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.

Tim Wilson is Editor in Chief and co-founder of Dark Reading.com, UBM Tech's online community for information security professionals. He is responsible for managing the site, assigning and editing content, and writing breaking news stories. Wilson has been recognized as one ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.