Don’t Let Your Applications Get You Down

Talking Points

  • 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.”

Security Vulnerability Testing Products

Company and URL Products & Features
Cenzic Hailstorm - An enterprise software suite for automated application security assessment and compliance. Hailstorm is designed to enable security experts, QA professionals, and developers to work together to assess, analyze, and remediate applications for security vulnerabilities, and verify compliance with security policies.
Coverity Prevent and Extend - Prevent automatically analyzes millions of lines of software code and provides 100% path coverage. Extend allows for the creation and enforcement of custom coding rules unique to different companies.
Fortify Software Source Code Analysis Engine - A suite of products that automate security processes during development, including Data Flow Analyzer, Semantic Analyzer, Control Flow Analyzer and Configuration Analyzer. Multiple language support and x-tier tracking.
Kavado ScanDo - A Web application scanner designed to allow enterprises to automatically conduct ongoing risk assessments to identify the vulnerability of Web applications at any stage of the application lifecycle, including development, QA, deployment, maintenance and auditing.
Klocwork inForce - The product performs an ongoing automated analysis of C, C++, and Java source code. Integrates into standard development environments—Klocwork provides integrations for emacs, GVIM/VIM, Eclipse, Microsoft Visual Studio and Microsoft Visual Studio .NET.
Ounce Labs Prexis/Engine - An automated source code analysis technology designed to deliver vulnerability analytics and measurement for enterprise-wide software risk management. Uses an innovative security compiler technology to pinpoint such vulnerabilities as buffer overflows, insecure access control, privilege escalations, denial of service, cross-site scripting and SQL injection.
Parasoft Security testing solutions suite - Allows developers and testers to verify that an application's security functions operate correctly. Available for Java, C++, .NET, HTML, XML and Web services environments.
Secure Software CodeAssure Workbench - Automated discovery and assessment of security vulnerabilities and policy violations in source code. Uses static analysis technologies and a knowledgebase of security problems to highlight insecure code during the development process. For programs written in Java, C and C++.
SPI Dynamics DevInspect and SecureObjects - Tools for constructing secure Web applications; tightly integrated with Microsoft Visual Studio .NET 2003. SecureObjects is used to identify weaknesses, validate inputs, manage security logging, and automatically fix vulnerabilities; DevInspect is used to scan components to verify that existing vulnerabilities have been fixed and that no new ones have been introduced.
Watchfire AppScan DE - A real-time security testing and coding tool for Web app developers. Automates testing, produces defect analysis, and offers recommendations for fixing the security flaws it detects. Also identifies the location of each defect, produces detailed inline fix recommendations, and helps developers perform a granular analysis of each test and response.

Sidebar: CLASP process helps developers integrate security

More on

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