Analysis: Host Intrusion Prevention

A Host Intrusion Prevention system is relatively new endpoint-protection technology, but to a great extent it builds on existing security systems: From antivirus software HIPS retains virus protection. From anti-malware products, it has co-opted malware scanning. From network intrusion-prevention tools, it adopts network interface monitoring.

An enterprise with all these in place might justifiably wonder, why add another layer?

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

But HIPS brings more to the table than the sum of its parts. Our testing and analysis show HIPS is quite possibly the most comprehensive desktop-protection product segment to date. No creditable vendor will promise to repel 100 percent of zero-day attacks, but HIPS technology can come close by using memory protection against buffer-overflow and heap exploits; by executing protection schemes to keep an attacker from building and executing code in a data segment; and by watching for unauthorized or unusual file access.

And in a time of proliferating attack vectors against machines that must stray from the relative safety of the internal network, HIPS brings new protections as well, giving IT the tools to identify and limit attack sources and shore up weak spots.

The technology is still evolving. Current offerings don't cover all device types, for example--some vendors are looking at offering protection for PDAs and smartphones, but they're not there yet. And questions remain: Does HIPS always require agents? Are they invasive? How does HIPS do its juju?

We examined products from Determina, ISS and McAfee in "The Desktop Is the Perimeter", to answer some of these questions, but the truth is, there's no one route to HIPS because vendors come from diverse backgrounds. The common denominator is the level of protection these products offer your servers and desktops is better than what has previously been available.

Undecided whether your organization needs HIPS? Consider this scenario: A new piece of malware makes it past your firewall--say a user downloaded it. Now that it's in, your NIPS (network-intrusion-prevention system) should prevent it from propagating across the network, right? But the malware is smart. It disguises itself as normal network traffic, slowly spreading across your enterprise, installing a keylogger that is developing a nice collection of your entire organization's passwords. And it reports this information over HTTP, so a content filter will see gibberish, not passwords, going out through an acceptable protocol. Or worse, it's sending out customer credit-card information scrambled.This virus technology is out there. One ill-advised download and your nightmare has begun.

What The Future Holds

There are those interesting points in the development of technologies when, if you lift up your head from the grind and look ahead a few years, you get a glimmer of the future. We see host-based intrusion prevention.

Antivirus software has stayed basically the same for the past 10 or 15 years. Sure, vendors have invested in keeping signatures up-to-date and improving scanning capabilities, but they haven't made any serious breakthroughs--AV software still scans for viruses on command. Granted, some vendors have made "on command" include when files are written to disk or sent out through e-mail, but it's still the same technology, just invoked differently. And most still use signatures, though some have adopted behavioral approaches.

Enter HIPS. These products generally perform the same steps as AV software, but add to the arsenal the ability to detect poorly behaving applications as they're running, find streams entering the system--server or desktop--that are outside the normal bounds of IP communications, and hunt down and kill malware.

Where will this market be in five years? For home and enterprise alike, the AV program as we know it today will not exist. Users want comprehensive protection with less software to install and maintain. Assuming that a given HIPS protects as well as the equivalent AV with added functionality, it's a no-brainer.

Buffer-overflow protection alone makes HIPS worth the cost of upgrading from AV. Developers cannot check every possible overflow condition. So having an automated system in place to catch overflows as they occur is a far sight better than our existing process of responding after the machine has been attacked.Of course, you already own AV, possibly on the cheap. But is it about dollars or about the best protection? Developers make mistakes and will continue to do so. Effective risk management dictates that enterprises take that into account.

Stumbling Blocks

Of course, buying now has risks. Every product segment goes through a maturation process. HIPS is no exception.

First, there's disagreement over what, definitively, comprises a HIPS. Must it include buffer-overflow checking? If it doesn't watch ports for aberrant behavior, is it still HIPS or just prettied-up antivirus? Some believe a product with a mandatory network element--port, stream or traffic scanning--can be considered a HIPS. Adding to the confusion, many vendors have specialized HIPS offerings for specific server software.

No wonder enterprise IT groups looking to justify a HIPS implementation are questioning vendors' vision.Products aimed at protecting applications are not HIPS. They are protection for a given application. By protecting my SQL Server, you're doing me a great service, but you're not protecting the host from intrusion.

Now, some vendors have married application-specific protection with true HIPS functionality--that should be a differentiator, not a deterministic statement about the product. Core HIPS functionality protects the host system, period. Port protection, memory protection, (arguably) AV and file/registry protection are core HIPS functions. All other features are extra and could even be made into separate revenue streams if the vendor is astute.

HIPS Don't Lie

There's FUD afloat about HIPS' performance impact. Vendors must step forward and prove the perception is wrong, or own up to the problems and help users understand the associated costs. Based on our testing, we strongly suspect the performance hit will be measurable, but not excessive. What we need to see is vendors presenting realistic numbers: A server running at 60 percent CPU usage can ill afford 5 percent on top of that, but a desktop running at 1 percent to 2 percent could take on a HIPS with no concerns at all.

Another issue that must be thoroughly addressed by vendors is the fear of hindering end users from performing normal tasks. In our reader survey, nearly 50 percent of respondents using HIPS stated they had experienced one or more cases of employee complaints (read more about our reader poll and find in-depth vendor analysis at nwcanalytics.com). Some of what HIPS do--particularly in the memory-protection arena--happens without notifying the user that remedial action was taken. Imagine saving a file and Excel says, "Cannot write to disk" with no other notification. That's bad news if the file is, say, the corporate budget.This is a perennial fear dogging any product with prevention in its name; vendors must figure out what's wrong and fix it before this problem alone stagnates the growth of a technology we think is the next step in system protection. The situation is not made any easier to stomach by the fact that you'll be asked to deploy this invasive technology to all the desktops in your organization.

The final--and probably most daunting--hurdle for HIPS is related to notification that a process is stopped. If a HIPS is set to active as opposed to learning mode and it detects a piece of code or a stream coming into the machine that it determines is malicious, it cuts it off.

And guess what some of these products do not do? Notify the user. Some notify of attacks, some of everything, but most don't notify of a stopped thread.

Your network diagram, the CEO's annual report, your boss' recommendation that you get promoted ... you want users to know if a request to save or e-mail a file is not processed as expected. In the course of our review (see the synopsis), we discovered that users are not normally notified by the HIPS that it is killing a thread or process, or shutting down a port. Rather, the HIPS relies on the application to notice the failure and notify the user.

We consider this a deal breaker. Sure, a HIPS runs in the background and would have to jump through hoops to correctly identify each application and function it's stopping. We still want notification. Trusting unknown apps to notify IT or an end user that a function failed is a great way to kill a product or technology outright.When you begin to investigate HIPS, make enabling notification a checkbox. Barring notification, insist on a list of applications the vendor has tested against to ensure the user is given some indication if a task is denied. This is better than nothing--you'll still have to worry about in-house and unlisted applications, but at least you'll have an idea of what might've gone wrong.

Getting An Education

Some HIPS functionality requires the system to understand what is normal. This learning comes through watching what's happening on the network and the machine, and logging abnormal behavior. IT must then manually tell the system which behaviors are permitted, or allow the system to decide which behaviors to allow. This is a nod to the fact that our systems and developers are not perfect, and gives IT the chance to say, "That traffic on Port 1337 is okay, one of our developers was being funny."

Learning mode is an excellent idea, but there are some gotchas. First, ask vendors about the need to relearn after a major (or minor) system update. HIPS watch memory, ports and file/registry access, so relearning can be required even after an application upgrade--like patching IE. If you make frequent changes and don't want to devote resources to HIPS re-education, you may decide a product that's more reactive and less dependent on behavioral databases is right for you, or you might wish to turn off learning mode after initial installation and maintain settings in your test environment when vetting upgrades.

We like learning and think re-education is well worth the hours. Maintaining this information manually is error-prone and time-consuming. Better to let the system figure out what it can, then tweak the results.Going Systemwide

HIPS suites have a wide reach--from the network card to what's executing in memory, they cover it all. That means they're invasive. Once a network driver has been inserted into the driver chain and execution has been hooked to allow the HIPS to stop and start threads, you've crossed the line from application to service.

Not only that, these products are right in the execution path, watching buffers for overflow and for the construction of code in data segments. They're deeply tied to the OS they're protecting. So updates to Windows could cause your desktops to lose protection, or worse, cause the system not to boot.

Hey, we never said systemwide protection came free.

In this case, the fee is an ongoing requirement to coordinate major system updates--including anything that changes the base OS code--with the vendor, or test them against your HIPS to detect changes that cause problems. Clearly, implementing a HIPS could slow your upgrade cycle. But we don't see this as a huge concern because HIPS do a good job protecting against zero-day vulnerabilities; we base that on real-world results: Our survey respondents, people we're talking to in the field, all agree HIPS do their job.All the vendors we spoke with have very aggressive testing schedules because they recognize this potential problem. All say they will stay on top of major OS updates and determine their applications' compatibility rather than risk losing business. And since it's the best we can ask for (short of fewer OS updates), we think that's okay.

Manage Me

Like any technology targeted at broad enterprise deployment, a centralized management console is a must for successful HIPS deployment. Most vendors had some form of centralized management or developed it as part of their initial HIPS offerings. Is any vendor's management better than others? Not particularly. The truly important stuff, like centralized management, they all have down.For the best offerings, like those from McAfee and ISS, we could set policies at the corporate level with exceptions at the machine level. Less functional management apps require the central server to operate, assuming the machine will always be on the corporate network--not an acceptable practice.

Finally, some vendors, including ISS, have hooked in to various ID-management tools to offer group management based on established enterprise machine configurations, while others make these distinctions internally. Because a HIPS is machine protection, not user protection, we don't see a particular strength either way, but shops that have all machines defined and grouped in an ID management server might find it painful to go the other route. n

Don Macvittie is an NWC senior technology editor. Previously, he worked as an application engineer at WPS Resources, a Green Bay, Wis., utility-holding company. Write to him at [email protected].

HIPS Vs. NACThere's some confusion in the market about the difference between HIPS and NAC (network access control). Although NAC can certainly contain elements of HIPS, that's not its primary purpose.

NAC products aim to protect your network from unauthorized access or from access by compromised PCs that are authorized. The purpose of HIPS is to keep your PCs from getting compromised to begin with. NAC protects the organization at the expense of the individual machine.

Both technologies have potential, and in the best of worlds they're complimentary. The quest for market dominance will no doubt drive some vendors to blur the line between HIPS and NAC in the future, but we don't see this as a bad thing.

Synopsis: Host Intrusion-prevention Systems

We examined three products offering HIPS functionality without the requirement of a networked appliance. We define HIPS as providing real-time protection of executing applications against attacks, including spyware, viruses, root kits, malevolent Web pages, e-mail exploits and more. Attack delivery mechanisms could include Web page serving, Web page surfing, port intrusion and disk/USB key insertion.PARTICIPATING VENDORS

Determina, Internet Security Systems, McAfee

TESTING SCENARIO

We structured this as a roundup of three products instead of a comparative review. In our evaluation we did not focus solely on attacks. Usability, management and price also played a role.

RESULTSDetermina's Vulnerability Protection Suite 4.0 is not as feature-packed as rivals' offerings, but its usability is excellent. We would have to maintain a signature-based antivirus suite to round out Determina's protection. ISS comes to HIPS with a long history of producing security software. Network (or protocol) protection is part of what ISS has done, and it brings that experience to the table in its Proventia Desktop. On the other hand, it's still working on signature-based antivirus to integrate into Proventia. McAfee Host Intrusion Prevention 6.0 has the widest breadth of functionality, and it also has the easiest-to-use management suite of these products, something we feel is important. McAfee HIP also provides protection for databases and Web server applications.

Find our complete product evaluation at nwcreports.com. Go to nwcanalytics.com for our original in-depth research and analysis on the host-intrusion-prevention market.