In-Depth

Case Study: Virtual Patches Defend Web Applications

Web-application firewalls protect against unknown attacks

• By Mathew Schwartz
• 02/09/2005

How can a company protect its all-Microsoft application infrastructure against unknown attacks?

That was the problem faced by Baker Hill, a software company and application service provider (ASP) that provides loan-origination services. Its browser-based LiquidCredit Bank2Business, for example, is a hosted service for small business loans used by over 150 U.S. banks.

About two years ago, “we first went out and looked into the market for a reverse proxy solution,” says Eric Beasley, Baker Hill’s senior network administrator. The company has a three-tiered architecture, all based on Microsoft products. “We have Microsoft IIS for our Web component, of course our middle tier uses COM/DCOM objects, and our third tier is Microsoft SQL Server 2000.”

Cue customers’ security concerns. “Because of [our] reliance on Microsoft, we had some of the larger clients that we were pursuing at the time balk,” Beasley says. “They did not feel comfortable with a purely Microsoft environment, and especially two years ago, when there were so many reported Microsoft IIS vulnerabilities.”

Beasley began investigating ways of making these potential customers happy. “Some of these clients even went to the extreme of saying we will not do business with you unless you put something out in front of this environment to mitigate the fact that it’s all Microsoft.”

First he looked at reverse proxies. While the approach “did a good job of getting in between our client and the Web servers,” he says, it didn’t guard against “SQL injection, forceful browsing, and the like.”

So Baker Hill shifted its focus to Web-application firewalls, a relatively new class of products two years ago, now available from such manufacturers as Imperva, Kavado, Sanctum, and Teros (then known as Stratum8). Baker Hill created a test environment, tested products from Kavado, Sanctum, and Teros, and selected the Teros Gateway.

“It is, in essence, a default-deny firewall,” he says. “The Web application firewall learns what is acceptable use of our Web application, and then by default, it will deny all traffic that does not meet the behaviors it’s learned.” Since this approach doesn’t rely on signatures, he says, it helps eliminate zero-day exploits, an especial concern in his Microsoft environment.

Virtual Patching

One benefit of this technology isn’t just to stop help block attacks, but to give IT more time to test patches before implementing them. In essence, the firewall acts as like a virtual patch.

Gartner estimates that 70 to 80 percent of all attacks today focus on the application layer; Web applications are at risk. Even so, “you don’t just throw things on your mission-critical servers without knowing the impact of them. And that means you’re going to have an exposure,” says Jon Greene, vice president of marketing at Kavado, in Stamford, Conn. “Virtual patching is designed to address that window.”

To enforce correct application behavior, he says, the gateway learns typical Web application behavior. Many Web-application firewall products already come with profiles for such well-known products as Microsoft’s Outlook Web Access, meaning they don’t have a learning curve. Some firewalls, such as Kavado’s InterDo, can also integrate with Web application scanners—in this case, Kavado’s ScanDo—to build a profile of the application in the test or audit environment. This profile then gets exported to the gateway, also eliminating the learning period.

Default-deny application firewalls are tailored to individual applications. In addition, “one of the interesting things about that is you can actually identify what behavior is acceptable for an application based on the properties of that application,” says Greene. For example, a form might not have any need to generate database commands. Thus, any database commands coming from the form are automatically blocked. “We can identify what behavior is acceptable or what isn’t, and only enforce acceptable behavior, which is referred to as a positive security model,” he says. “We say anything that isn’t a good thing is bad.”

The opposite—a so-called negative security model—employs signatures to detect known threats. The downside of this approach is it can only detect known threats.

The firewalls block any activity that has not been approved, buying security managers extra time to test patches before deploying them. “From a patch standpoint, we no longer feel the need to deploy the Microsoft patches immediately after they’ve been released,” says Beasley. “The reason that I feel a lot more comfortable in not pursuing a strategy like that is there is no 100-percent guarantee that the patch is going to leave your application in a working state,” he says.

Realistically, it wouldn’t even be possible for him to patch as quickly as he wants. “In the case of October, we had 11 Microsoft patches, 7 of them critical. That’s just very difficult to have to do in a short period of time,” he says. Baker Hill still implements the patches, but it typically waits, making the patch part of its pre-existing, quarterly code base update. This approach reduces duplicate efforts.

Without a Web-application firewall, Beasley says he’d have to perfect some other plan for patching, one that takes into account the fact that some Microsoft patches—even if they don’t work—are not meant to be uninstalled. “Then you really have to look at what kind of strategy are you going to use to create some kind of snapshot or backup of that server prior to the patch being applied,” he says. Even with a system in place to roll a server back to its pre-patched state, “it’s a lot of work.”

Thus he advocates Web-application firewalls for any company running Web applications. “I feel very sorry for any individual companies out there that are without a product like the Teros, because I’m sure that many of them have been bitten, just like we all have, by a patch gone wrong.”