AWL vs. HIPS: What's in a name?

Having spent a bunch of time working in a marketing capacity for security vendors over the past decade, I've become rather jaded relative to positioning, differentiation, and trying to "create" a new category. OK, maybe I started a bit jaded, but seeing the hijinx many vendors use on a daily basis to convince customers to buy something doesn't help my general cynicism. That's why in my research efforts I always focus on the problem a typical end user organization needs to solve, not the problem the vendor's product addresses. If I stay focused on the end user - all of the vendor marketing hyperbole, baseless claims, and general mudslinging fade into the background.

Let's take a look at one of the biggest problems a security professional has in the data center: the compromise of a server device, which potentially provides an attacker with full control of a server device to sniff traffic, install malware, and access all sorts of juicy data. Yeah, that's a bad day for anyone with security in his/her title.

Optimally, we'd like to harden our servers to reduce the likelihood that one of these critical devices is compromised. Most attacks involve some kind of malware installed on the device, either within memory or persistently on the disk. Hardening happens in multiple ways, ranging from implementing a security configuration and patching the device in a timely fashion. Organizations also implement a variety of network controls to restrict (or monitor) the traffic dynamics of that server. Additional you could implement a change control mechanism to alert when any configuration or software is updated on the device. All of these are good controls, but doesn't necessarily address the attacker installing malware. By the time these controls kick in it may already be too late.

Thus we want to get closer to the point of attack, and potentially stop an attack before it starts. This means stopping the installation of the malware. As we've been discussing on this site for over a year, traditional signature-based anti-virus isn't very effective against today's targeted attacks. So scratch that control from the list of options (regardless of what your friendly PCI assessor tells you). That leaves us with HIPS (host intrusion prevention) or application white listing (AWL). Queue the religion, since depending on who you talk to, AWL and HIPS may be the devil or vice-versa.

Now for those of you that read my day to day ramblings over at Securosis, you know I detest security religion. I pray at the temple of whatever keeps the bad guys out of your stuff. A lot of the HIPS vendors will position against AWL saying it's inflexible and can break a key server application, requiring too much day to day management. The AWL camp will talk about the challenges of keeping the HIPS heuristics and behavioral rules current and whether it will miss new types of attacks.

But both camps seem to miss that the technologies have more in common than they have differences. It's like the Hatfield's and McCoy's. They've been at war so long, they fight just to fight. As both technologies have evolved, they are both taking on characteristics of the other to address shortcomings. If you think of AWL and HIPS as overlapping circles on a Venn Diagram, you are seeing those circles coming closer together.

For example, many of the HIPS offerings do have simple white lists of applications that are allowed to run. And a bunch of the AWL products do memory analysis and look for signs of memory tampering, buffer overflow and other attacks, which was traditionally a HIPS approach. Why do you have to decide anyway? Depending on the nature of the device needing protection, the answer could be both; assuming the resource realities of the overhead of running multiple security controls each device are acceptable, or it could be one or the other.

So how do you choose? Basically you need to do a threat model for your key applications/business processes. Depending on the type of attack/attacker, HIPS or AWL may be the right fit. Although, don't buy into the hyperbole and don't disqualify either technology based on history or security religion. Pick the technology based on what attacks you need to defend against. If you start there, the answer should become clear.