In-Depth

Application security comes under attack

• By Linda L. Briggs
• June 1, 2006

Application development managers commonly assume that making their software more secure increases the cost of tools and lengthens the time it takes to get an app out the door. That isn't necessarily true, according to studies from Gartner and others, which show that integrating security best practices into the software dev lifecycle reduces overall costs by increasing efficiency and boosting customer satisfaction.

For many companies, however, that kind of ROI could be a long time coming. The immediate challenge is to break the cycle of releasing software with security vulnerabilities, which anger customers, whether internal or external, and are costly to fix after the fact.

Although many software vendors have long recognized the advantage of securing the application layer in development, there's new focus on the problem. That's partly because network-based attacks have been brought under control through now-mature technologies such as firewalls, intrusion prevention and other network-based control mechanisms. "People are now attacking through applications, because it's easier than through the network layer," says Forrester Senior Analyst Michael Gavin.

Blame it on the Web
The proliferation of Web-based apps also has exposed more kinds of software to attack. Without security controls, Gavin points out, Web apps are, by their very design, extremely vulnerable. "The entire point of HTTP is to allow two sides to communicate, so if there isn't any application-specific security put into place, there's nothing to stop you from injecting SQL into a Web-based form that's looking for information to go query a database."

Another problem, according to Gartner analyst John Pescatore: The culture of rapid change to Web server software makes it particularly vulnerable to attack. "Web servers are typically on the shortest development cycles and [under] the least development rigor," Pescatore says. "It's definitely almost one-for-one that the quicker you develop software, the more likely that vulnerabilities are going to come in."

It's difficult to assess the size of the problem, partly because companies are reluctant to talk about security breaches unless required by regulations. However, most states have no such laws, so incidents tend to be vastly under reported. One exception: California's Database Security Breach Notification Act (SB 1386), which requires anyone doing business with California residents to disclose any security breach of unencrypted, personally identifiable information that was likely viewed or acquired by an unauthorized person.

Security estimates such as the annual survey by the FBI and Computer Security Institute are more guesses than anything, Forrester's Gavin says. The Web Application Security Consortium, or WASC, recently started to publicize security breaches that have occurred via Web apps and the number of people affected by them.

Security testing tools divided by two

Gartner divides application security testing tools into two categories: a fairly mature group of scanner tools, used for checking fully functional systems before they're released to production, and newer tools for source code testing, used during the dev process.

Scanner tools are typically used against production systems by the security group; they can also be used by QA or the audit group before a product is released to production.

Source code analysis tools tend to be used by auditors or software QA before production.

Although source code analyzer tools can be used in dev, Gartner analyst John Pescatore says that less than 5 percent of enterprises are using them that way. "That's the biggest growth area" in software testing tools, he says. Process changes and developer training remain key, he adds.

Scanner tools are available from vendors such as WatchFire, SPI Dynamics, Compuware and Cenzic, which offers an open-source product. Source code analysis tool companies include Fortify, Compuware, Coverity and Ounce Labs. Although some scanner tools had initial problems with false positives, Pescatore says that problem has largely been solved.
-Linda L. Briggs

More talk than action
Despite the security chatter, there's still a basic lack of understanding of the application security problem-and how to address it. "A lot of people think a firewall solves everything," says Jeremy Epstein, senior director of product security and performance at webMethods. "I talk to customers all the time from Fortune 500 companies who say, 'Oh, I don't have to worry about that. I'm behind the firewall.'"

Even with all the focus on security, experts say most companies still don't have a handle on successfully building or testing for secure apps. That's partly because getting control of the app-dev lifecycle to add security measures is just plain tough. "Pick a vendor," Gavin says. "When vulnerability is found, look what they go through to develop a patch and test it before they release it. That's why we suffer [long] delays before patches become available. Meanwhile, we know these vulnerabilities are out there."

It's all about process
At Adobe Systems, taking a hard look at the software dev process has paid off. "There are lots of places where companies have run into problems in the past when it comes to process," observes Adrian Ludwig, Adobe's manager of secure software engineering.

Adobe, he says, has had success in shifting resources to an earlier point in the dev lifecycle. "We've really emphasized looking at design, really emphasized the need to think about security when you're thinking about customer requirements, industry standards," Ludwig says. "Having that early on is a critical part of the process."

The art of app security testing

"Solid app security starts with a look at the entire development process," says Chris Wysopal, CTO at security startup Veracode and a known security expert. "If you look at the application development process, there's no single procedure or tool you can use. You need to span the whole process... I'm a big proponent of embedding security into every step."

Some security procedures are costly and involve re-engineering processes, acquiring tools and hiring experts. However, Wysopal points out that although reviewing a program's design for security can be manually intensive and requires specific security expertise, other changes are much simpler. Adding security testing techniques to the QA cycle doesn't necessarily require expertise, he says, "just some paradigm shifting in the minds of QA people, to start thinking of security flaws as a subset of the defects that they need to find."

Wysopal, under the name Weld Pond, was a member of the well-known hacker research group L0pht in the 1990s, which later merged with computer security startup @stake and was acquired by Symantec in 2004.

At Veracode, Wysopal is working to develop a security product that uses static analysis to perform automated code reviews at the binary level. Along with Symantec's Nelson and several other security experts, Wysopal is working on an upcoming book on app security, "The Art of Software Security Testing," that focuses on how to train developers and QA testers to use software testing tools more effectively.
-Linda L. Briggs

Adobe is starting to realize a return on its security investment, Ludwig says. "For the most part, where we're seeing ROI is on the bottom line." Having more efficient processes has minimized time spent later finding, resolving or preventing an issue.

"Imagine investing 6 to 9 months, only to realize that there's a design mistake and you need to redo a lot of that," Ludwig says. "As we push things earlier into the development lifecycle, we're reducing the time that needs to be spent...modifying things."

A big part of writing more secure code comes from changing how developers think about security throughout the lifecycle. There's more to it than eliminating common coding mistakes or simply expecting developers to write more secure code. "It's a little unrealistic to ask developers to start coding securely, on top of all the other requirements they have, [without specifying] the security requirements they need to code to," Gavin says. See related story, "Not every security problem is a new one."

Seven deadly sins
Companies working to shore up application security usually regard both training and tools as critical components. "Very few developers you're hiring have a background in writing secure code," says Mark Fallon, Oracle's senior release manager, who is responsible for the server technologies division's secure development initiatives. "There's a certain amount of training you have to put them through." Along with developer training, Oracle uses commercial tools such as Fortify Software for static code analysis, in combination with its own in-house tests, continually throughout the development cycle. See related story, "The art of app security testing."

At webMethods, the company uses a combination of developer training and product testing to combat vulnerabilities in its code, all of which is written in Java. Because the company sells a Web app platform that customers use to develop their own products, security is a high priority. According to Epstein, who heads the company's product security work, tools are an essential part of building secure software, but commercial products are only now maturing. "Up until now, the tools really haven't been good enough. Now they're getting [better]. That's why we're experimenting with them." Larger companies like Microsoft and Oracle are using tools effectively, Epstein says, but mid-size and smaller companies aren't yet.

As part of its strategy, his security group has prepared a proprietary list of "seven deadly sins," which development managers must avoid. Epstein says that although the listed items represent only a handful of security issues, that's not the point. "There are hundreds of things that can go wrong [with an application's security]," he admits. "We picked the seven most significant... The idea of having a handful of things that you can point to is really powerful. Lots of security people make the mistake of saying, 'we have to solve everything.' It's impossible to solve everything. Seven things is manageable."

Tooling up for security
Training can teach developers to eliminate perhaps half of an application's vulnerabilities, Gartner's Pescatore says. Testing tools can help spot and eliminate many of the rest. See related story, “Security testing tools divided by two.”

"Frankly, there are too many things for developers to do, [and their] job isn't to do security, it's to deliver the applications," webMethods' Epstein says. "There isn't a chance we'll ever be able to do all of it just by educating developers. We have to have tools."
One cutting-edge approach webMethods is looking at is automated source code analysis tools to find potential loopholes. Almost no one is doing this routinely outside research labs.

Not every security problem is a new one

On one hand, software security is hugely complex and difficult. On the other hand, security experts tend to see the same coding problems over and over-problems like buffer overflows and SQL injections, for example.

One of the most obvious problems occurs with authentication and authorization, including inadequate segmentation of privilege levels. "That's the first place a hacker is going to try to attack," says Symantec's Lucas Nelson, who reviews code for customers and probes their apps for vulnerabilities.

Another challenge is encryption, including where to store encryption keys. "That's always difficult," Nelson says. "Even the best programmers have trouble with it. That's tough to solve without getting hardware involved."

Perhaps the biggest problem area, Nelson says, is input validation. "We like to say that 90 to 95 percent of attacks can be stopped by input validation. That's how data gets into the system, right? The only way an attacker can attack the system is by putting data in somewhere. So if you could validate all your input and make sure it's what you're expecting...you'd prevent all these attacks." The challenge for developers: Foreseeing what types of strings will affect a program negatively.

A common problem with Web apps, according to Chris Wysopal, CTO at security startup Veracode, is session identifiers, or cookies. "Unless that's implemented securely, it becomes a huge vulnerability," he explains. "Someone who can sniff that cookie can become that user. Wysopal and his coauthors address this issue in their upcoming book, "The Art of Software Security Testing." "We go through techniques for collecting cookies and analyzing them for those kinds of vulnerabilities," he says.

Another testing method Epstein says webMethods has considered: automated penetration testing tools, used at the application level. "They've existed for a number of years, and used to require lots of expertise," he says, "they're getting better."

In any case, companies need to perform both source code analysis and penetration testing on apps, Epstein says, because neither approach does both.

Enterprises fortunate enough to start thinking about security before a line of code is written can incorporate security techniques such as threat modeling and standard use cases at the design phase.

"We can catch a lot of major issues at the design phase," says Lucas Nelson, a senior security consultant at Symantec. "If you design modules correctly early on...it's a huge boon to your security."

"You need to do things like threat modeling at the design stage," Forrester analyst Gavin says. "If an attacker tried to break the system, what could they do? Wherever one component talks to another component, developers and designers need to think, 'OK, what if someone was able to spoof one of my communicants here. What are the ramifications? What can I do to limit the problems that would be caused? Is requiring SSL between two components a realistic thing to do and does it solve the problem?' Whenever there's an application that allows you a route to sensitive information, you need to ask these questions."

Tools for security testing are evolving rapidly and in synch with the rising interest in app security. However, they're still not good enough for industrial-strength app dev, many developers say.

Security now, not an afterthought
To Forrester's Gavin, today's focus on security in software dev echoes the discussions around app performance in the 1960s and 1970s. "We worried about performance afterward, while making design decisions that hurt performance," he recalls. For software to work efficiently, companies learned, they needed to design for performance in the first place. That sort of bolt-security-on-at-the-end approach is where far too many software dev efforts are today. However, with better tools, training for developers, and buy-in from above, there's less reason to plug in security as an afterthought.