In-Depth

Don’t Let Your Applications Get You Down

• By John K. Waters
• July 1, 2005

Talking Points
APPLICATION SECURITY IS BAKED IN

• Black-hat hackers and other malicious circumventing network-based security and exploiting
• It’s 50 times more costly to fix a security than it is to fix it before software QA, according
• The key to start getting security built into start thinking of security as a feature.

Most enterprises have figured out that firewalls, antivirus software and intrusion detection systems, although essential to their overall security posture, no longer provide adequate protection. Black-hat hackers and other malicious intruders are increasingly circumventing network-based security and exploiting loopholes in applications.

These vulnerabilities are costing enterprises a bundle. The National Institute of Standards & Technology reports that companies are spending about $60 billion a year identifying and correcting software errors. Exploited software flaws cost the U.S. financial services industry more than $3 billion per year, according to NIST.

Part of the problem is the changing nature of enterprise software, says Gartner analyst John Pescatore. Databases that were once kept in centralized data centers and accessed primarily or exclusively by apps within the enterprise’s security fences are now connected to customers, partners and suppliers around the world through the Web.

Another part of the problem is the nature of software development, he says. Application development organizations are rewarded for delivering features and meeting deadlines, so developers tend to focus on those things. Consequently, application security becomes an afterthought, and developers address vulnerabilities only if they are discovered after the applications have been developed.

Not doing the security work up front can quickly become expensive. Gartner figures it’s 50 times more costly to fix a security vulnerability on a production system than it is to fix it before software QA.

What’s worse, Pescatore observes, the most common forms of attack—such as buffer overflows and SQLinjections, which exemplify most of the attacks of the past 5 years—take advantage of known vulnerabilities. “We’re not saying that it’s app-dev’s responsibility to make software perfect,” Pescatore says. “But it’s their responsibility to make sure that we’re not building in known flaws.”

It’s high time enterprises began instilling in their developers the same level of security consciousness they’ve inspired in their operations people, says Mike Armistead, VP of marketing and co-founder of application security company Fortify Software. “Everyone can see that the threats have changed,” he says. “The vehicle hackers are using today is the software. But too much of the focus is on the hackers. There will always be hackers. It’s the software that’s letting you down.”

Defective detective on the job
Application security vulnerabilities come in many forms: flaws in the design, implementation and/or testing of internally developed code; flaws in vendor-supplied application infrastructure products, such as Web and app servers; tainted code from external sources, or with code that is being outsourced, such as shopping cart CGIs that store price information within hidden fields; and backdoors and debug options left open deliberately within the application.

The most important thing for developers to remember about application security flaws, says Yankee Group analyst Andrew Jaquith, is that they’re just another type of software defect that should be eliminated as early as possible in the development lifecycle. (See chart at the end of the article, “Security Vulnerability Testing Products.”)

To give developers a place to start, Jaquith recommends three basic strategies:

1. Standardize on some library common routines for validating user input and sanitizing output. “The most common classes of vulnerabilities happen because applications trust user input blindly without checking to make sure that it’s not, say, a thousand characters with some crafty buffer overflow code tacked on,” he says.
2. Use standard libraries for authentication and access control. “In the Web application arena, the J2EE spec and .NET frameworks reflect a lot of hard work and learning,” he says. “Developers should leverage these as much as possible.”
3. Use type-safe languages, such Java or C#. “Modern just-in-time compilers are good enough, and hardware is cheap enough, that the so-called ‘speed advantage’ of C/C++ or hand-crafted assembly is no longer a factor,” he says.

“Although some developers pride themselves on knowing how to use C/C++ memory routines safely, there are many more that don’t. Type-safe languages tend to be ‘fast enough,’ easier to learn and maintain, and well-supported—and they almost completely eliminate the dreaded buffer overflow.”

The key to getting security built into the applications, says Gartner’s Pescatore, is to get developers to start thinking of security as a feature. “The standard argument is that the dev shop is focused on deadlines and whiz-bang functionality,” he says. “OK, then managers should get security in there on that list of features that are going to be tested as part of the formal software Q&A code integration test.” (See related story, “CLASP Process Helps Developers Integrate Security.”)

“It’s also important for managers to remember that software development isn’t really an engineering discipline,” he adds. “And when clever, innovative people create software, they are going to focus on features and then maybe sprinkle on a little security at the end. In their minds, they’re not the bad guys. They’re the good guys who are trying to do something new. And we want that innovation.

The trick is to get them to start thinking of security as a feature.”

App security is a feature
“Most companies today know enough to have a good firewall and a secure physical infrastructure,” says Garry Hallee, EVPof technology at Financial Engines. “But they forget about the applications. If an application goes into production with a vulnerability, that’s not something a firewall is going to detect.”

No one has to tell the developers at Financial Engines to think of security as a feature. The provider of retirement and financial services advice to individual investors, retirement plan sponsors and financial institutions has been integrating security best practices into its development processes for some time.

Financial Engines’ 75-to-80-person IT organization maintains about 2 million lines of code, Hallee says. That code base includes the company’s engine applications, which analyze fund data and arrive at personalized investment recommendations, as well as a user interface designed to support a growing range of users, from plan members accessing Web-based features to call-center advisers. The group also has to deal with a high level of data connectivity to financial institutions—about 25 different connections, Hallee says, through an XMLbased exchange linking to organizations such as Vanguard and JP Morgan over the Internet.

“Our normal process is to do daily builds,” says Hallee. “We compile all our code, and then we run what we call a smoke test, which is basic testing to make sure that when someone wrote code that day they didn’t break something and that all the standard features work.”

Financial Engines also conducts its own internal security audits; so do many of its customers, and it’s not uncommon for several security audits to be going on simultaneously, Hallee says. A chief information security officer conducts the audits and signs off on all new releases. “I’m a big believer in clear accountability,” Hallee says. “Designating a senior executive to be responsible for the security of the application is one of the best ways I know to avoid finger pointing when there’s a problem.”

But a security officer is more than a scapegoat, Hallee says. He can also be a resource for the developers, promoting good development practices.

“This field is changing so rapidly,” says Hallee, “that it’s hard for software developers, who are worried about getting the next feature squeezed into a release, to be up to date on everything that’s going on in application security—important things like bad or sloppy practices that could expose your code to the outside world. That’s where it helps to have the CISO; they can keep up on all this stuff, because that’s a big part of their job, and they can educate the individual contributors.”

Hallee is also a big believer in automation, which is why his company is in the process of integrating Fortify’s Source Code Analysis tool into its development processes.

Fortify’s flagship product searches newly written code for approximately 40,000 known vulnerabilities, alerts developers to the flaws and suggests fixes. Other Fortify products scrutinize patterns of coding behavior to find mistakes and enable developers to try hacking their own code.

“You really need a tool that can automate these types of checks,” Hallee says. “If you’re doing it manually, when you look at the code for the first time, you can do a pretty good job; when you’re looking at it for the tenth time, it’s a lot harder to give it the same attention to detail. But with a computer program, once you get the rules in place and the system configured—once you get it checking for the right things—you’re going to get the same level of attention every time.”

It’s not Fort Knox all over again
As they face the challenge of building secure applications, developers should keep in mind that they are not being asked to take on vastly new responsibilities—to think like a black hat, to keep up with the latest security innovations, or to build Fort Knox every time they write a piece of software, says Gartner’s Pescatore.

“Take some baby steps,” he advises. “It’s like security at your home. You’ve got deadbolts on all the doors, and that’s good enough. Chances are you don’t have dogs and laser beams. Most software is equipped with screen doors. Start by stating in the requirements that, at the very least, if somebody leans on the door, it won’t fall in.”

IPLocks lays down laws of risk management
By John K. Waters

RSA provides policy-based app security
By John K. Waters

Traveling at a zillion events per second
By John K. Waters

PHOTO-ILLUSTRATION BY ANN ELLIOTT CUTTING