• United States



Bob Violino
Contributing writer

Decoding Application Security

Oct 14, 200415 mins
Technology Industry

Today’s Web-connected applications need more than just firewalls. Application-security gateways can’t grow up fast enough

Ah, the Web.

It has generally made business easier and cheaper, but specifically made information security harder and more expensive. Companies in all sorts of industries are rushing to create Web-accessible applications so that their customers can more easily get at data or manage their own accounts. Alas, these new systems draw along in their wake a bevy of new, application-specific attacks.

And so application security is a top-of-mind issue for CISOs. Consider the case of Depository Trust Clearing Corporation (DTCC), which provides clearance, settlement and information services for a variety of financial-services transactions. Its Web applications include a service called Domestic Tax Reporting Service, which accumulates year-end tax information on various investment types in a centralized database. Customers log in to double-check their tax reporting. Not the kind of application a company wants hackers rifling through. So in addition to the usual stable of firewalls, DTCC is using application-security gateways from Teros to protect against common application-level attacks such as buffer overflows and SQL injection – both of which involve a hacker tricking the host system into executing unwanted commands. DTCC has been testing the Teros product (which costs about $US25,000) since September 2003, and DTCC CISO Paul de Graaff is sufficiently pleased with the results to plan installing more devices this year. Eventually DTCC will use the gateways to protect transaction-based and consumer Web applications, both customized and off-the-shelf.

“Application security has become my number-one priority,” says de Graaff.

CISOs’ number-one priority, of course, usually becomes security vendors’ number-one market opportunity. Security product purveyors are responding, launching products specifically designed to provide application-level security that traditional firewalls don’t deliver. CSOs and CISOs report some early successes with application-security efforts, but also a number of important reasons to consider treading lightly as application-security products and processes mature.

Your Buffer Overfloweth

Unlike certain worms and viruses that exploit network security weaknesses, Web application attacks go after flaws in the applications themselves. For example, an intruder could tamper with part of an HTTP request and use buffer overflows to corrupt a Web application by having it execute arbitrary code. In this way, the attacker could in effect take control of a Web or application server.

There are several approaches to preventing this kind of attack. One is code inspection: trying to secure your homegrown applications by more carefully examining your source code, looking for common coding errors and vulnerabilities. (For more on this approach, read “Code Violations” page 38) Another approach is scanning your Web applications from the outside – as an actual attacker might. This is most commonly done by an outside provider, often under the heading of vulnerability assessment. Application-security gateways, such as those DTCC is deploying, are a third approach. Gateways scan incoming network traffic in greater detail than does the conventional perimeter firewall. Typically, a firewall lets HTTP requests pass through – HTTP being the standard protocol for transmitting Web pages. An application-security gateway, however, can be set to sift through the HTTP data stream, looking for SQL code embedded in places where it shouldn’t be. (If a Web application includes a field for customers to fill in their password or address, and instead the “customer” types in a long string of nonsense with embedded SQL commands, that’s a pretty reliable sign that there’s malice afoot.)

One of the distinctive features of Web-application security is that it employs a positive security model that monitors applications to ensure they behave as originally intended, without relying on attack signatures, says Richard Stiennon, vice president of research for network security at Gartner (US). The products learn normal application behaviour and differentiate it from abnormal behaviour such as buffer overflows and SQL injection. “Most attacks on the application side are customized for a particular application,” and the positive model – recognizing appropriate behaviour instead of trying to learn the signature of every possible inappropriate attack – is more effective at blocking these hacks, says Stiennon.

Why are application-specific attacks so rapidly on the rise? Aside from the quick proliferation of Web-attached applications, Stiennon says it’s not all that difficult to exploit application vulnerabilities – probably easier than writing a virus. DTCC’s de Graaff also observes that many programmers lacking Web expertise have been pressed into writing Web applications quickly (for competitive reasons), which results in a lot of vulnerable code.

For many organizations, the solution will be application-security products such as Web application gateways. The Yankee Group estimates the market for Web application-security products and services will grow to $US1.74 billion by 2007 from $US140 million in 2002. “CSOs and CISOs recognize the need for this, and they are aggressively evaluating products,” Yankee Group Senior Analyst Eric Ogren says. “I’m not sure many are ready to take the plunge, but a lot of the vendors have lots of pilots going on.”

Indeed. Among those providing Web application gateways are Kavado, NetContinuum, Sanctum and Teros. Check Point and NetScreen have begun working application-security features into conventional firewall products. Vendors such as Sana Security, SPI Dynamics and StillSecure feature some aspects of application security in their products as well. For example, Sana last year launched host intrusion-prevention software called Primary Response, which detects and blocks attacks at the application and operating-system level. The software is based on a technology that analyzes application code and builds profiles of normal behaviour, then continuously monitors applications to find abnormal behaviour. StillSecure offers a product called StillSecure VAM, a vulnerability-management system that detects security weaknesses in databases, Web servers, application servers and e-mail servers.

Cautious Optimism

Early adopters, like DTCC, report promising results with these technologies.

Will Pelgrin, director of the New York State Office of Cyber Security Critical Infrastructure Coordination, says the state is exploring application-security products to complement its firewalls, intrusion-detection systems, and vulnerability scanning, and has included application-security best practices in an April 2003 security policy being implemented by all state agencies. “We believe very much in defence in depth – security needs to be in layers – and application security is an important aspect of that,” says Pelgrin. He won’t disclose specific application-security products the state is considering but says it’s exploring a variety of technologies.

Similarly, the US Department of Energy has been evaluating a gateway from NetContinuum since May 2003 and has seen a significant drop in its vulnerability to application-level attacks, says John Dias, senior security analyst at the department’s Computer Incident Advisory Capability (CIAC). One of CIAC’s functions is to conduct penetration tests of all the Energy Department’s Web sites, and Dias says the group threw most of the known application-specific and server-layer HTTP attacks against the gateway to test it. “They were all very easy for the gateway to detect and block,” he says. “These things would have gotten past the firewalls.” Dias also notes that his group has “a small army of people watching all the application vendor sites [for vulnerabilities and fixes], but when you look at the amount of information you have to deal with, it’s no longer practical” to protect applications that way.

De Graaff notes an extra benefit: Feedback from its gateways will help DTCC application developers write better software. For example, information from the gateway tells programmers that an application is not performing proper input validation. Look across several applications and most common errors will emerge. At DTCC this data will eventually be used to create a list of things to avoid in future application development, de Graaff says.

Yet despite such positive feedback, and the pressing nature of the application-security problem, industry watchers like The Yankee Group’s Ogren say gateways have a way to go before they’re considered as mainstream as virus scanners and intrusion-detection systems. What’s holding application security back? Round up the usual suspects: concerns about performance, complexity, maturity, budgeting and training.

For starters, some CISOs are concerned about using application-security products because of the potential impact on application performance, says Howard Schmidt, vice president and CISO at eBay, and a former adviser to the White House on cybersecurity. “But the [latest] products are doing a better job of making sure they don’t have an impact on the application other than to protect it,” he says.

Second, there’s complexity. Implementing application security is not without hurdles and management issues, and the technology is still maturing. De Graaff says application gateways are additional components to monitor in an increasingly complex security environment. Scalability of the gateways isn’t a concern at this point, he says, but might become an issue as companies run more applications through the devices. If they can’t handle the increased workload and DTCC has to purchase more devices, that will add to the complexity.

Third, the technology is still new and relatively untested in large-scale rollouts. Despite the promised benefits of application security, Schmidt believes some organizations might be hesitant to deploy products. “It will take extra work [by vendors] to convince people that this will not have a negative effect on systems,” he says. For example, will application-security products interpret a once-a-month reporting function as out-of-the-ordinary activity and therefore shut down an application? Schmidt is also concerned about how application-security products will work with customized applications where “normal” behaviour is not always clearly understood.

“As there are more deployments and case studies about companies that have implemented application security, there will be more [evidence] that this is something good,” Schmidt says.

Pelgrin says effective deployment of application security depends as much on management as on technology. Effective product deployments will have to be accompanied by a cultural change, including greater awareness of application vulnerabilities and educational programs about how employees can protect against these vulnerabilities.

Another issue is the difficulty of getting funding for yet another layer of security. Jack Jones, CISO at Nationwide Insurance, says, in general, it’s tougher to get approval for security investments than in the past, and that applies to application security as well. Nationwide uses application-security products such as scanners that check code in new applications, and has launched training and awareness programs about application security and vulnerabilities. Jones says he was able to justify a budget request by doing a critical analysis that showed several components of the risk landscape had changed over time. For one thing, the sheer volume of attacks had risen. For another, vulnerability increased because hackers had become more adept at exploiting applications and more applications were Web-enabled. Third, the potential impact on the business increased because the company was offering more products and services online.

As with all new technologies, training is a key issue for application security, says Greg Murray, CISO at Information Resources Incorporated (IRI), a sales and marketing research company that recently began using Check Point’s FireWall-1 NG with Application Intelligence and is evaluating other application-security products. “We’re constantly training people to make sure they understand how the technology works and know what the results should be,” Murray says. Creating business-partner awareness about application-security vulnerabilities and safeguards is also critical; “This is a supply chain issue,” he says.

Facing a few hurdles, some organizations will remain hesitant to adopt application security. Many of those companies will likely face a rude awakening such as having corporate Web sites taken over by intruders, Gartner’s Stiennon predicts.

Smart security leaders won’t wait that long.

If your CEO demands a 30-second lift ride explanation of application security, these (almost) jargon-free analogies might come in handy

Buffer overflowImagine a hospital waiting room that gets so overcrowded that the extra people spill into the next room, which is foolishly unlocked, and which happens to be the patient records room. Hackers make this happen intentionally (by cramming too much information into a Web site’s input field) in order to get access to the areas they shouldn’t.

SQL injectionSQL injections are like technical Jedi mind tricks. Your Web application asks for an input such as a password, but instead the hacker types in a command (written in the SQL language, hence the name). If your application has a weak mind, it can’t tell that the input isn’t a valid password, and it does whatever the command specifies.

Stateful inspectionNetwork firewalls normally act like mailroom clerks who just look at the addresses on the outside of each envelope. Stateful inspection means opening the envelope (and making sure there’s no mysterious white powder) before passing it along to the addressee. – B Violino

The AVDL standard may help infosecurity devices create better defences by sharing information

A GROUP OF information security vendors is pushing an XML-based interoperability standard for vulnerability data, aiming for industry-wide acceptance. The final draft of the standard – called Application Vulnerability Description Language (AVDL) – was approved by the Organization for the Advancement of Structured Information Standards, or Oasis, in February and was under public review throughout March. Proponents say AVDL is gaining momentum among security vendors and enterprises. With up to 40 new patches and vulnerabilities announced every week, security managers have an increasingly small window in which to react to vulnerabilities.

The XML specification defines and classifies application vulnerabilities in a standardized form that can be understood and used by security products throughout the application-security life cycle. The standard is designed to make it easier for application-development tools to share information about potential security risks in the preproduction phase; application firewalls to set policies based on new vulnerabilities; security auditors to compare vulnerability reports and security event logs from disparate products; and patching products to read vulnerability assessments from different scanning tools.

Among the primary vendors driving the effort are Citadel Security Software, GuardedNet, NetContinuum, SPI Dynamics and Teros. Others involved in the standards development effort include Bank of America, Cisco Systems, IBM, Microsoft and the US Department of Energy (DoE). Some of the security vendors have demonstrated AVDL-enabled products to show how the standard allows disparate products to work together and exchange data.

Security executives applaud the efforts. “Any commonality between security platforms is going to be helpful to us,” says Edward Liebig, assistant vice president of global IS security at Manufacturers Life Insurance. “For example, when companies have proprietary operating systems, their error logs all mean something different. When you try to troubleshoot programs, you don’t want to need experts in everything. You’d rather have a common language between all these products.” Liebig says Manulife has deployed or is considering products that will use the standard, including SPI Dynamics’ WebInspect.

The DoE’s Computer Incident Advisory Capability (CIAC) response team recently launched a Security Incident Response Portal based on a Web-services architecture that is “AVDL-aware”. The portal will automatically interpret new alerts published in AVDL format and disseminate the information to DoE security managers, ensuring they receive only alerts relevant to their environments. – B Violino

Using gateways to examine incoming traffic isn’t the only option CSOs and CISOs have for making their software more secure

In a perfect world, the flaws commonly exploited by application-level attacks wouldn’t exist in the first place. Sadly, we won’t arrive in software utopia anytime soon, but some vendors provide services and products that inspect software throughout the development process. Research indicates that 10 common coding errors (things with scary names like unvalidated input, cross-site scripting vulnerability and injection flaws) account for the vast majority of application-level vulnerabilities (for details, see the Open Web Application Security Project at Therefore, it shouldn’t be terribly difficult to make dramatic improvements in application security just by scanning code for those particular flaws.

CISOs already spending a bundle on intrusion detection, virus scanning and the like may need more budget-justification ammo to spend on another layer of information security. One of the big selling points many of these code inspection companies have latched onto is regulatory compliance. Sarbanes-Oxley, Gramm-Leach-Bliley and other regulations give brownie points for third-party validation of good internal controls and risk-reduction measures.

Whether you’re in compliance mode or simply focused on keeping hackers at bay, here are several vendors ready to help whip your code into shape.

Reasoning www.reasoning.comReasoning started providing code inspections strictly for quality purposes. With the growing number of security exploits aimed at coding flaws, President and CEO Bill Payne says turning Reasoning into a security company seemed natural. Reasoning works as a service provider, charging on a per-line basis to run C and C++ application code through algorithms that test for buffer overflows and other common security lapses. In addition to identifying the location and nature of individual code flaws, the company produces higher-level reports to help clients identify their most frequent errors and improve the initial development process.

Primeon www.primeon.comPrimeon performs source code audits, dubbed DeepSource Solutions, using third-party tools (such as Sanctum’s AppScan software) plus proprietary processes and expertise. Primeon compares clients’ source code to a knowledge base of known application security flaws. The company says it examines code on several levels: data level, front end and business rules.

SPI Dynamics www.spidynamics.comThe company’s flagship software line, WebInspect, uses agent-based technology to dynamically catalogue aspects of the application in question; it analyzes these results and then launches attack algorithms to find vulnerabilities and characterize their severity.WebInspect also offers a version integrated with Mercury Interactive’s TestDirector quality assurance software, which allows for identification of security flaws earlier in the software development life cycle.

Fortify www.fortifysoftware.comFortify addresses application security at two levels (with more evidently in the pipeline). Like Reasoning, the company offers code inspection throughout the development life cycle, although Fortify sells its software rather than acting as a service provider – which may prove cheaper in the long run for users who want to perform multiple inspections at each development stage. Fortify also does run-time testing, along the lines of what SPI Dynamics or Sanctum offer. – D Slater