Host Intrusion Prevention Capabilities

A recent search of the Internet listed over 700,000 pages containing the words Host Intrusion Prevention. We found hundreds of different Host Intrusion Prevention products among the results. Knowing which products are actually HIPS and which are not presents a challenge, especially given the overwhelming volume of available information. The challenge is exacerbated by the lack of a formal definition for the category that is accepted by all HIPS vendors.

To help you distinguish HIPS products from the rest, this section lists the capabilities you can look for to determine whether or not a product is a HIPS. This section does not attempt to define standards of quality for HIPS, just a specific set of capabilities. We believe that to qualify as a HIPS, a product should have the following capabilities:

• Blocks malicious code actions

• Doesn't disrupt normal operations

• Distinguishes between attacks and normal events

• Stops new and unknown attacks

• Protects against flaws in permitted applications

Blocking Malicious Code Activities

A HIPS must be able to do more than generate an alert or log when malicious code attacks a host. It must be able to actively block the actions of the malicious code. If the actions are blocked, the attack will not succeed. HIPS products should also keep a log and be able to generate alerts so that users will know what the HIPS did, but the differentiating requirement is that it be able to take action.

For example, one way for malicious code spread from a system it has compromised to other hosts is to copy itself to open network shares. Some security tools might be able to detect the malicious code's copy attempt but not take action against it. A HIPS should be able to detect the attempt and actively block it.

Not Disrupting Normal Operations

One way to secure a host is to unplug it from the network. Disconnecting it from the network would indeed make it more secure, but it would also deprive it of the network services business users rely on. Disconnection is not a very usable security countermeasure because it completely disrupts normal operations.

HIPS is similar in that it must be able to operate without disrupting normal operations. For example, e-mail attachments might pose a security risk because the attachment could contain malicious code. One way to mitigate the risk is to strip all messages of their attachments. However, e-mail attachments are often an essential part of normal operations. A product that deletes all e-mail attachments does not qualify as a HIPS product because it disrupts operations.

Distinguishing Between Attacks and Normal Events

A security product that treated attacks as normal events and normal events as attacks would be virtually useless. HIPS products must be accurate enough to correctly determine which events are attacks and which are normal. You should expect some false positives when you first implement HIPS, but you should find mechanisms within the product to remove the false positives without removing the product's capability to detect attacks.

Stopping New and Unknown Attacks

You can employ numerous methods to stop a published and well-known attack. For example, you can apply a software patch to the host to remove the vulnerability the attack uses. You can also update your antivirus signatures or reconfigure your network appliances to prevent the attack from entering your network. For each new vulnerability or attack, you might need to repeat the update and reconfiguration process.

A technology that requires update or reconfiguration to stop a new and unknown attack (see the note that follows) is not a HIPS. HIPS products must be able to stop new and unknown attacks without reconfiguration or update. The way the HIPS product stops the attack or its success rate is not relevant information in this section. It simply must have the capability.

Note

New and unknown attacks are attacks for which the target is unprepared. The target might be unprepared because a patch has not been applied or security countermeasures have not been configured to mitigate the attack. The target might also be unprepared because attack has not been seen "in the wild," so no updates or reconfiguration instructions are available.

Protecting Against Flaws in Permitted Applications

To derive benefit from hosts and networks, organizations must allow applications to run on the hosts and access the network. A product that prevents permitted applications from using the resources it needs does not meet the "doesn't disrupt normal operations" criteria. By the same token, a HIPS must not allow the permitted application to be compromised by an attack. Thus, HIPS products must have the capability to protect against flaws in permitted applications.

Internet-facing web servers, for example, are permitted to accept connections from unknown hosts on the Internet. That makes it easier for attackers to take advantage of any flaws in the web server application. A HIPS should be able to allow the web server to accept connections from the Internet but also prevent the web server from being compromised.