Configuring IPS Devices and Applications

For both Network and Host IPS, the configuration of your IPS is crucial for providing a strong defense against attack. Some of the major factors to consider with respect to IPS configuration include the following:

• Signature tuning

• Event response

• Software updates

• Configuration updates

• Device failure

Signature Tuning

Most IPS devices and applications provide a single default configuration or multiple default configurations. Using one of these default configurations is an ideal starting point for your IPS deployment. As you use your IPS, you need to tune specific signatures that generate false positives on your network.

False Positive

A false positive is a situation in which an intrusion system generates an alert or alarm after processing normal user traffic. Analyzing false positives limits the time that your security analyst have to examine actual intrusive activity on your network.

False Negative

A false negative is a situation in which an intrusion system fails to generate an alert or alarm after processing attack traffic that it is configured to detect. Your intrusion system should not generate false negatives, because it means that known attacks being launched against your network are not being detected.

Besides false positives and false negatives, many people describe alarms using the terms true negatives and true positives. Table 3-2 highlights the differences between these different terms.

Table 3-2. Common Alarm Terminology

Network Activity	IPS Activity	Alarm Type
Normal user traffic	No alarm generated	True negative
Attack traffic	Alarm generated	True positive
Attack traffic	No alarm generated	False negative
Normal user traffic	Alarm generated	False positive

True Positive

A true positive is a situation in which an intrusion system generates an alarm in response to attack traffic that it is configured to detect. A true positive is effectively the opposite of a false negative.

True Negative

A true negative is a situation in which normal network traffic does not generate an alarm. A true negative is effectively the opposite of a false positive.

Event Response

Whenever your Network IPS sensor identifies potentially malicious traffic, it must respond to the traffic by performing some type of action. You can usually configure each signature to generate one or more of the following actions:

• Deny

• Alert

• Block

• Log

Note

Many intrusion systems provide filtering capabilities that enable you to limit the hosts or conditions in which signatures actually trigger (perform their configured actions). For example, if a signature is prone to false positives, you might configure the signature to trigger only on traffic that involves at least one external system, thus preventing false positives on traffic between two internal systems.

Deny

If a signature identifies a serious threat against your network, you might want your IPS sensor to stop the traffic. Operating in inline mode, your IPS sensor can selectively drop any traffic that it analyzes, thus preventing intrusive traffic from reaching the target system.

Alert

An alert or alarm is an indication that an attack has been detected by your IPS. Your security operators use the alerts generated by your IPS devices to understand the attacks and other traffic that traverse your network.

Block

Besides denying traffic with inline IPS devices, most IPS devices also enable you to initiate access control lists (ACLs) on other infrastructure devices to block network traffic. These ACLs, however, are applied only after initially detecting malicious traffic.

Log

The final IPS response is to log traffic. Logging traffic enables your security operators to analyze the traffic that an attacker sent to the network. By analyzing the captured traffic, the security operator can more effectively understand what an attacker is doing against your network.

Logging is usually initiated when a signature triggers and continues for a specified amount of time. Either all traffic from the attacking system (or the target system) is logged.

Software Updates

Every IPS is continually being enhanced to identify new attacks against your network. Furthermore, many existing signatures(see Chapter 2), "Signatures and Actions") are revised to make them more effective. Applying software updates to your IPS devices and applications is vital to maintain the optimum operation of your IPS. By keeping your IPS software current, you ensure that your network is being protected as effectively as possible.

Applying IPS software updates involves the following tasks:

• Checking for updates

• Deploying new updates

• Configuring new signatures

• Verifying the update

Configuration Updates

Besides software updates, you also need to identify the process by which you plan to deploy configuration updates to your IPS devices. Configuration updates refer to the changes that you make to the configuration of the IPS software to match the unique characteristics of your network. This information involves settings such as which signatures are enabled and which signatures actions are configured for each signature. As your network grows and changes or when your security policy changes, you need to update the configurations on your IPS devices.

Software Update

Software updates refer to installing new versions of the IPS software. This updated software usually provides enhanced functionality, but it can also fix known bugs with the IPS software. The enhanced functionality can include new software features and/or IPS signatures.

Device Failure

When your IPS devices have problems, you need to understand what the impact is going to be to your security posture. You need to know how your IPS reacts to the following two failure situations:

• Inline sensor failure

• Management console failure

Inline Sensor Failure

If the software on your IPS sensor fails, you need to understand how the sensor handles network traffic. If the sensor software is not functioning, you need to know whether the network traffic is passed without inspection or whether all traffic is dropped while the analysis software is not operating.

Inline Sensor

An inline sensor is a sensor that processes traffic, by acting as a Layer 2 forwarding device. Before forwarding traffic, the sensor analyzes the traffic searching for attacks and other security policy violations. The inline sensor actively forwards network traffic, as opposed to a traditional IDS sensor that passively monitors network traffic.

With Cisco IPS, you have the following three options with respect to software bypass:

• Auto

• On

• Off

Software bypass is the configuration that defines how the sensor processes network traffic when the sensor's analysis software is not operating. In Auto mode (also known as Fail Open mode), a sensor running in inline mode continues to forward traffic even if the sensor's analysis engine stops processing traffic. Although this traffic is not inspected by the sensor, the network is still operational. Auto mode is useful on networks where operation of the network takes the highest priority.

In Off mode (also known as Fail Close mode), a sensor running in inline mode stops forwarding traffic if the sensor's analysis engine software fails or stops. Because the sensor stops forwarding traffic, none of the traffic is allowed to pass the sensor without inspection. Off mode is useful on networks where the security of the network takes the highest priority.

In On mode, a sensor running in inline mode always forwards traffic without inspecting it. This mode is useful in debugging situations when you want to configure the sensor to forward traffic without performing any inspection on the traffic.

Note

With Cisco IPS devices, you can also configure multiple sensors using an EtherChannel group. In this configuration, if any of the individual sensors loses power or stops operating, the traffic is automatically load balanced between the remaining sensors that are members of the EtherChannel group.

EtherChannel

EtherChannel is a functionality provided by Cisco switches that enables you to configure multiple trunk lines to be members of the same VLAN. Traffic for the VLAN is then load balanced between all trunk lines that are members of the EtherChannel group. The Cisco EtherChannel functionality provides fault-tolerant, high-speed links between switches, routers, and servers (see http://www.cisco.com/en/US/tech/tk389/tk213/technologies_white_paper09186a0080092944.shtml).

Management Console Failure

Your management console provides a mechanism for your security operators to view the events that are occurring on your network. The management console needs to retrieve alerts or alarms from your IPS devices or applications (such as the Cisco Security Agent [CSA]). Your management software uses one of the following models to retrieve events from your IPS devices:

• Push model

• Pull model

Note

When managing the devices on your network, you will find it beneficial to have a separate management VLAN or out-of-band management network. Besides minimizing management access to your crucial network devices and thus enhancing your network's security, a separate management network (or VLAN) also prevents you from losing connectivity to your devices if an IPS sensor protecting those devices fails closed.

In the Push model, the IPS devices push events to your management console as they happen. If the management console is unreachable, you can lose events. Therefore, a failure of the management console can impact the security of your network.

In the Pull model, the management console itself retrieves events from the IPS devices when it is ready to receive them. The IPS devices basically buffer a certain amount of alert information, waiting for the management console to retrieve them. Short failures of your management console do not cause any alerts to be lost, as long as your management console retrieves the buffered events before the event buffer on the sensor is exceeded.

Note

The Cisco IPS solution uses the Pull model for both its network and host products. Therefore, a temporary failure of the management console should not result in a loss of event information, because the sensor stores the events in a local circular buffer until they are retrieved by the management console. If the management console fails to retrieve the event information before the buffer starts overwriting events, event information can be lost during a management console failure. On a normal network, however, the circular buffer can easily hold a couple of days' worth of events before the buffer starts overwriting unread events.