In-Depth

Q&A: Monitoring What Web Applications Divulge

Watching inbound and outbound Web applications communications for signs of attack

• By Mathew Schwartz
• 10/25/2005

Almost all attacks today aim to exploit known vulnerabilities in Web applications. Organizations are employing Web-application firewalls able to learn and enforce correct application behavior.

As an added measure of security, some appliances can also monitor the information Web applications divulge—and whether such information should leave the organization. To learn more, we spoke with Marc Shinbrood, the CEO of Breach Security Inc. in Carlsbad, Calif.

How big a shift is Web application security from network-based security?

We make a fundamental distinction there. What most people understand is that network security [involves] firewalls, antivirus, intrusion detection, and prevention devices. Basically it’s like dragging a net through the water if you’re going to go fishing—you randomly catch fish. You don’t know which fish you’re catching; you’re randomly catching fish. … [These are] viruses, worms.

Application security, on the other hand, is always targeted. Nobody breaks in the first time. What they do is study, review your Web site; the hacker will go after a specific item in your Web site. And it’s become a societal issue, this application security, because no penetration tester or hacker anymore goes at the network; they go at the simplest way to get your corporate data, which is at your Web site. They do it through trial and error—they figure out how to get at your Web data right through your Web applications.

What percentage of attacks aim for Web applications?

John Pescatore at Gartner Group would tell you it’s 85-90 percent. … There are implications. The Conference Board just came out with a study that says consumers’ online purchases are down 41 percent over last year at this point. They say the consumer now is being very cautious about what they do online. …

A good example of that would be if you’ve tried to contribute to any [Hurricane] Katrina funds. If you go out and try to donate to Katrina, you’re going to see 400-500 funds just on animal rights, and there’s no way you can tell what’s a valid Web site and what’s not.

So [Web application security] really has become a societal issue. In fact, in USA Today recently, the article on the front page of their Money section was “Meth Addicts Hack into Identity Theft.” You need to just know that people are paying between $10 and $20 per valid Visa credit card number with a credit card limit of over $10,000. The idea that your credit cards are vulnerable is just ridiculous, and your identity is also very vulnerable.

What are common types of Web application attacks today?

There’s SQL injection; that’s particularly onerous, because most of the databases behind a Web application today are SQL, so if you can figure out what the database looks like, you can make requests that get to corporate data.

For example, take a large toy manufacturer [who prefers to remain anonymous]. They advertise through television and media in general. But your kids, when they get to be seven years old, will get on the [toy company’s] Web site and play games. And when they score well, they get a coupon toward the purchase of toys; which is a really cool marketing gimmick. What’s interesting is the first day they turned that system on, they got 300,000 hits on the Web site, and 200 of the kids maxxed out on the coupons the first day, and the reason was, they figured out which back doors were left over by the programmers—on the first day. Kids know that 999999, or FFFFFF, if you’re hexadecimal, are the high values that programmers sometimes leave for their [own] passwords. These are things that come out all the time.

How do Web application firewalls tackle the problem?

Our product is a behavioral product. The bottom line is that every Web application is different; there are no basic signatures such as for antivirus and such. What you need is an interdisciplinary kind of approach—an approach that says, if I look at behavior, and it’s anomalous—not normal—I need to raise my hand and say there’s something funny going on.

So I correlate those funny or not-normal behavior items with real, known dangers. [Plus] I know what HTML and HTTP statements are supposed to look like, and if I see that there’s a syntax difference, I can flag that. So there are lots of different ways to look at this, but the bottom line is to look for lots of different types of attacks.

Don’t a number of companies also offer tools that learn proper Web application behavior, then block anomalies?

The way we’re unique is, we don’t just look at what goes into the system—what requests are being made—but what requests are going out, which we call exit control. … Basically you can say, "This is what my Web site has on it, and here’s some key data I don’t want leaving the organization." For example, if you’re a pharmaceutical company, that might be a pharmaceutical formula; if you’re a credit card company, it might be credit card numbers. …

We can monitor anything you think is privileged information, and if someone is requesting that, first we can raise a flag, then if they try to leave the Web site with it, or any volume of it, we can just identify it and stop it immediately.

Other products don’t vet information as it’s leaving the organization?

They look for it on the input, but they don’t look for it leaving. As an example, let’s say someone gets away with 20 credit card numbers [from] your database, but you have 100,000 in your database. I can identify not only which 20 left, and give you that forensic information, so that you only have to notify those 20, or stop it before even they get away.

So that’s one other differentiator [between products]. The other differentiator is the difference between in-line solutions and non-in-line solutions.

What’s the difference between in-line and non-in-line Web application firewalls?

In-line solutions you’re familiar with: intrusion detection devices, prevention devices, they’re inline in the network. There are first and second generations of tools in the Web application firewall [space], from such companies as NetContinuum, Sanctum (now F5), Kavado (now Protegrity), Teros. … They install these products in the network path itself, and the problem with that is … they become a point of failure, and a point of latency, and they drive network professionals nuts because they may block something they shouldn’t block, and they slow down the network.

What we’ve done is we built the product as a non-in-line device, meaning all we do is a network tap—let’s call it a scan port for the sake of argument—and we communicate with your existing devices to do the blocking. So our box doesn’t do the blocking, our box sends the message to do the blocking.

Which devices does this work with?

It can be [anything able to receive] a TCP Reset, a TCP/IP command. It can also be—Check Point firewalls have this OPSEC format, their own API; we do that with Cisco and Check Point, for example. So we communicate in their language.

Don’t you need firewalls to be in-line, to be quick enough to detect and stop attacks?

That’s true for network attacks, because they can get you the first time. That’s not true for application attacks, because they don’t get you the first time—they do a lot of study and research. So what you want to do is catch them the first time they’re doing research.

Related Articles:

Putting IPS Claims to the Test
http://esj.com/Security/article.aspx?EditorialsID=1512

Q&A: Targets Shift for Application Security Attacks
http://www.esj.com/Security/article.aspx?EditorialsID=1505