In-Depth
Virtual Patching Secures Web Applications
Discovering Web application vulnerabilities—which account for a staggering majority of all vulnerabilities seen in the wild—is the easy part. Keeping them fixed is another story.
At least 75 percent of information security attacks are aimed at Web applications, according to Gartner Group. Attackers are attracted by the easy access Web applications give them to a company’s internal systems.
Such vulnerabilities are rampant and easy to exploit. A recent white paper from security vendor Imperva Inc. reports that in professional penetration tests conducted by the company’s researchers, critical vulnerabilities were found in 92 percent of Web applications tested.
Discovering Web application vulnerabilities is one thing; fixing them is another. As the Imperva report notes, “Even after a vulnerability was identified, corrected, and confirmed fixed, the same type of vulnerability reappeared at a later date in 60 percent of the applications.”
For a variety of reasons, organizations have difficulty keeping their Web applications secure. While non-secure coding practices may be partly to blame, there are often more classic development problems at work. For example, experts say many companies don’t see—or choose to overlook—security flaws encountered during development because of the rush to get applications into production. Furthermore, developers may create multiple versions of the code before it ever undergoes security testing, and by then it might be too late.
This approach is a legacy of traditional development practices: design first, secure later. “People who write the applications, and do the QA, and prepare the software—traditionally they’ve then thrown the software over the wall to operations, who are responsible for protecting it,” notes Alan Norquist, Imperva’s vice president of marketing and business development.
Thus when vulnerabilities appear, they may not get fixed. Norquist recounts an episode that occurred recently at a customer site. Security personnel identified flaws in Web application code which their firewalls couldn’t block, so they asked the developers to fix the problem. According to Norquist, “The application guys say, 'We have tight deadlines for our next release, we can’t fix that.'” So the problems got taken to their boss—the head of application development. He responded in a similar manner. “Finally they had two VPs discussing if they were going to free up a couple of days of developers’ time. You can imagine how the CIO felt about this.”
Eliminating Web Application Development Silos
To ensure more-secure code, organizations have several options—none mutually exclusive. For example, while they can school developers in the art of writing secure code to help secure future applications, such action doesn’t magically fix code already in production.
What can companies do when they find flaws in existing, production code? One option is scrambling to fix them. Another is getting a better defense, say by using Web application-level firewalls able to learn correct Web application behavior, then block any deviations. This technology is available from such companies as Breach Security, F5, Imperva, netComtinuum, Protegrity (which purchased Kavado earlier this year), and Teros.
In general, Web application firewalls “not only model the application, but also the attack scenarios,” says Norquist. “So we don’t block people when they do something unusual, but we block things when we know there’s a problem.” In addition, many such firewalls deploy quickly because developers don’t need to change an application.
Instead the appliance sits upstream in the network from the Web application, learns correct behavior, then enforces it, or at least watches for attacks. For example, “we don’t block deviations automatically, since sometimes changes in the application are because application developers made a change in the application and didn’t tell you,” say Norquist. “So what we actually do is look at the attack and see if it’s significant.”
Virtual Patching
Besides guarding against attacks, Web-application firewalls also effect “virtual patching.” That is, if correct Web-application behavior is enforced, then even if there are vulnerabilities, companies don’t have to scramble to fix them. Instead, they can just schedule upgrades as part of the typical application-upgrade cycle.
Otherwise, organizations must take programmers off development projects and have them fix flawed code immediately, which inevitably hits the bottom line. “If you could instead do that fix as part of the regular QA cycle, then the costs almost go away,” notes Norquist. In fact, many organizations compute their return on investment for Web application firewalls “from not having to do the patch” right away.
In some organizations, off-cycle fixes also just aren’t possible. Sometimes “you have customers and service providers where the customers won’t let them do the patch,” he notes. Alternately, “if you have a legacy application, you may not have the resources to go in and patch.”
Related Articles:
Q&A: Monitoring What Web Applications Divulge
http://esj.com/Security/article.aspx?EditorialsID=1542
Q&A: Targets Shift for Application Security Attacks
http://www.esj.com/Security/article.aspx?EditorialsID=1505
About the Author
Mathew Schwartz is a Contributing Editor for Enterprise Systems and is its Security Strategies column, as well as being a long-time contributor to the company's print publications. Mr. Schwartz is also a security and technology freelance writer.