Risk Rating Overview
Threat Rating Overview
Inline Mode Event Actions
Promiscuous Mode Event Actions
Protection from unintended automated action responses
Using Event Action Filters and Never Block
Careful Use of Event Actions
High Base Risk Rating Events
The deep packet inspection and automated response mechanisms of the Cisco Intrusion Prevention System (IPS) can improve the overall security of an organization by providing network-based detection and mitigation capabilities that are currently not available in other Cisco products. Often times, these automated response mechanisms are poorly deployed, resulting in inadvertent blocking of legitimate traffic and the disabling or ineffective use of this functionality. However, through judicious deployment, automated response actions can be effectively leveraged to prevent or minimize initial exploitation and outbreaks, thus easing the burden of the incident response staff. With a focus on features available with IPS version 6.0 and later, this document provides an overview of and demonstrates how to effectively leverage automated response mechanisms in order to reduce the impact of threats to the network.
Typically, the IPS is deployed in either Inline or Promiscuous mode. Inline mode positions the IPS directly in the packet flow, allowing it to perform actions directly on the packet flow. In Promiscuous mode (IDS), the IPS/IDS receives a copy of packets on the network instead of being directly in the packet flow. For traffic analysis purposes, Promiscuous and Inline modes are similar. However, when determining risk or performing event actions, Inline mode offers several benefits for calculating risk rating and improving Event Action capabilities in order to prevent attacks. Even with the benefits, Inline capabilities are typically not used because they introduce another potential point of failure within the network through software or hardware failure. This additional point of failure can be partially resolved by using either Auto Bypass mode in case of software failure or by Hardware Bypass mode on supporting models. Additionally, redundancy can be achieved by deploying in a manner that causes failover to be provided through another means, such as modules in an ASA firewall pair.
To understand how the IPS device views events, it is necessary to understand the IPS risk rating. The IPS risk rating is applied to all detected events and provides contextual quantification of the event risk as it pertains to the network being monitored. The risk rating relies on several attributes to provide an event-specific, contextual rating. The rating can be used to derive actionable responses, automated or otherwise. The following provides an overview of the risk rating calculation and its associated attributes.
The risk rating is calculated on all detected events. The formula is as follows:
Risk Rating = ((ASR) Attack Severity Rating * (TVR) Target Value Rating * (SFR) Signature Fidelity Rating / 10000) + (ARR) Attack Relevancy Rating – (PD) Promiscuous Delta + (WLR) Watch List Rating
Attack Severity Rating: Attack Severity Rating (ASR) quantifies the potential severity of the event. The IPS uses four different severity ratings that correspond to the following numerical ratings for risk rating calculation:
Informational = 25
Low = 50
Medium = 75
High = 100
Target Value Rating: Target Value Rating (TVR) is a user-defined variable that allows customers to quantify the relative criticality of a host or subset of hosts. A customer may use this to assign higher values to critical targets, affecting the overall risk rating for events triggered against that target. The following are the possible values for TVR. The default value is Medium and is assigned a numerical value of 100.
Low asset value = 75
Medium value = 100
High asset value = 150
Mission Critical = 200
Signature Fidelity Rating: The Signature Fidelity Rating (SFR) is defined for each signature and quantifies the degree of attack certainty. The SFR value can be any number between 55 and 100 with high values reflecting a high probability that the attack is valid and not caused by anomalous network traffic such as a false positive.
Attack Relevancy Rating: The Attack Relevancy Rating (ARR) is an IPS-generated value that indicates if the attack target may be vulnerable to an event-specific attack. This information is normally gathered through passive operating system identification but can also be defined by a user or gathered through integration with the Cisco Security Agent Management Console. If the operating system of the targeted device is unknown, there is no change to the risk rating. However, if the targeted device operating system is discovered to be relevant, the risk rating increases by 10 in both Inline and Promiscuous modes. If the targeted device operating system is found to be irrelevant, the risk rating in Promiscuous mode is reduced by 10, and no change occurs in Inline mode.
Promiscuous Delta: When an IPS is deployed in Promiscuous mode rather than in Inline mode and under certain conditions, attack recognition may not be accurate. In such instances, Promiscuous Delta (PD) is used to lower the overall risk rating of the event.
Watch List Rating: The Watch List Rating (WLR) value only applies when the IPS is integrated with the Cisco Security Agent. The IPS generates the value that is based on a user-configurable value, which is configured through the external product interface section of the IPS.
Risk Rating Examples: The following example applies the risk rating to signature 5913 (PIX/ ASA/ FWSM MGCP DOS). The attributes associated with the signature are as follows:
Severity = 75 (Medium)
Fidelity = 85
Promiscuous delta = 15
If the signature triggers an event on a device that is deployed in Inline mode, then Promiscuous delta will not be applied, making the base risk rating as follows. Note that the following calculation will not factor in WLR or ARR variables. Additionally, the IPS does not use floating point math for the calculation, therefore, for example, 63.75 is a risk rating of 63.
IPS deployed in Inline mode:
(ASR * TVR * SFR / 10000) + ARR - PD + WLR
(75 * 100 * 85 / 10000) + 0 - 0 + 0 = 63
If the IPS is deployed in Promiscuous mode, then the PD attribute will lower the risk rating of the event.
IPS deployed in Promiscuous mode:
(ASR * TVR * SFR / 10000) + ARR - PD + WLR
(75 * 100 * 85 / 10000) + 0 - 15 + 0 = 48
As a result, this signature would have a base risk rating of 63 in Inline mode and a base risk rating of 48 in Promiscuous mode. If the administrator sets a target value rating of High to the Firewall IP address, the base risk rating would change only for that destination IP address or addresses. The following example demonstrates this concept when the IPS is deployed in Inline mode. Note that the target value rating cannot be applied to an IP address and a signature but rather only to an IP address. As a result, all events for the specified IP address will show a similar increase in the base risk rating. The following example shows that by altering the Target Value Rating attribute, the risk rating becomes 95.
IPS deployed in Inline mode with a high target value rating for signature 5913:
(ASR * TVR * SFR / 10000) + ARR - PD + WLR = RR
(75 * 150 * 85 / 10000) + 0 - 0 + 0 = 95
Threat Rating quantifies the associated risk level after the IPS has performed a mitigation action. A higher Threat Rating indicates a more severe immediate threat. Threat rating builds upon risk rating and is specified as:
Threat Rating = Risk Rating - Event Action
The associated values for event actions are listed below:
40 deny-attacker-victim-pair- inline
35 deny-connection- inline
35 deny-packet- inline
35 modify-packet- inline
In the preceding example for signature 5913 (PIX/ASA/FWSM MGCP DOS), if the IPS was deployed in Inline mode and the target value rating was set to High, the risk rating would be 95. If the event used an Event Action of deny-attacker-Inline (45), the Threat Rating would be the Risk Rating minus the associated Event Action. As a result, the Threat Rating would be 50 (95-45). However, if the TVR is high and the IPS is deployed in Promiscuous mode, the risk rating would be 80. If the event used an Event Action of request-block-host, the Threat Rating would be 60 (80–20). Note that the risk rating is lower for Promiscuous mode due to the Promiscuous delta attribute.
Event actions and their benefits and associated risks are detailed in the following section.
When the IPS has triggered an event, the IPS can take one or several predefined actions. These actions can be signature-based, specified per signature, or risk rating-based, based on the overall risk rating and applied to all events within the specified risk rating range. When event actions are performed on pre-defined risk rating levels, this is referred to as an event action override. This creates a flexible framework for administrators to define and respond to detected events. The following provides an overview of the most common event actions that an administrator may want to perform in order to mitigate attacks, as well as the benefits and associated risks of each event action.
The following actions require the device to be deployed in Inline mode and are in affect for a user- configurable default time of 3600 seconds (60 minutes).
Deny attacker inline: This action is the most severe and effectively blocks all communication from the attacking host that passes through the IPS for a specified period of time. Because this event action is severe, administrators are advised to use this only when the probability of false alarms or spoofing is minimal.
Deny attacker service pair inline: This action prevents communication between the attacker IP address and the protected network on the port in which the event was detected. However, the attacker would be able to communicate on another port that has hosts on the protected network. This event action works well for worms that attack many hosts on the same service port. If an attack occurred on the same host but on another port, this communication would be allowed. This event action is appropriate when the likelihood of a false alarm or spoofing is minimal.
Deny attacker victim pair inline: This action prevents the attacker from communicating with the victim on any port. However, the attacker could communicate with other hosts, making this action better suited for exploits that target a specific host. This event action is appropriate when the likelihood of a false alarm or spoofing is minimal.
Deny connection inline: This action prevents further communication for the specific TCP flow. This action is appropriate when there is the potential for a false alarm or spoofing and when an administrator wants to prevent the action but not deny further communication.
Deny packet inline: This action prevents the specific offending packet from reaching its intended destination. Other communication between the attacker and victim or victim network may still exist. This action is appropriate when there is the potential for a false alarm or spoofing. Note that for this action, the default time has no effect.
Modify packet inline: This action enables the IPS device to modify the offending part of the packet. However, it forwards the modified packet to the destination. This action is appropriate for packet normalization and other anomalies, such as TCP segmentation and IP fragmentation re-ordering.
The following event actions can be deployed in Promiscuous mode. These actions are in affect for a user-configurable default time of 30 minutes. Because the IPS sensor must send the request to another device or craft a packet, latency is associated with these actions and could allow some attacks to be successful. Blocking through usage of the Attack Response Controller (ARC) has the potential benefit of being able to perform to the network edge or at multiple places within the network.
Request block host: This event action will send an ARC request to block the host for a specified time frame, preventing any further communication. This is a severe action that is most appropriate when there is minimal chance of a false alarm or spoofing.
Request block connection: This action will send an ARC response to block the specific connection. This action is appropriate when there is potential for false alarms or spoofing.
Reset TCP connection: This action is TCP specific, and in instances where the attack requires several TCP packets, this can be a successful action. However, in some cases where the attack only needs one packet it may not work as well. Additionally, TCP resets are not very effective with protocols such as SMTP that consistently try to establish new connections, nor are they effective if the reset cannot reach the destination host in time.
Event actions can be specified on a per signature basis, or as an event action override (based on risk rating values – event action override only). In the case of event action override, specific event actions are performed when specific risk rating value conditions are met. Event action overrides offer consistent and simplified management. IPS version 6.0 contains a default event action override with a deny-packet-inline action for events with a risk rating between 90 and 100. For this action to occur, the device must be deployed in Inline mode.
Automated event actions can have unintended consequences when not carefully deployed. The most severe consequence can be a self denial of service (DoS) of a host or network. The majority of these unintended consequences can be avoided through the use of Event Action Filters, Never Block Addresses, Network spoofing protections, and device tuning. The following provides an overview of methods used to prevent unintended consequences from occurring.
By using these capabilities, administrators may prevent a miscreant from spoofing critical IP addresses, causing a self inflicted DoS condition on these critical IP addresses. Note that Never Block capabilities only apply to ARC actions. Actions that are performed inline will still be performed as well as rate limiting if they are configured.
Administrators can minimize spoofed packets that enter the network through the use of Unicast Reverse Path Forwarding. Administrators can minimize spoofing within their network through the use of IP Source Guard. The white paper titled Understanding Unicast Reverse Path Forwarding provides details on configuration of this feature. More information on IP Source Guard is available in the document titled Configuring DHCP Features and IP Source Guard.
By judicious use of event actions that block unwanted traffic, such as using the high signature fidelity rating, and not using automated actions on signatures that are easily spoofed, administrators can reduce the probability of an unintended result. For an event to have a high risk rating, it must have a high signature fidelity rating unless the risk rating is artificially increased through the use of Target Value Rating or Watch List Rating, which are IP specific increases.
By tuning the signature set to minimize false positive events, administrators can reduce the chance of an event action that has an unintended consequence.
In most cases, events with a high base risk rating or a high signature fidelity rating are strong candidates for automated event actions. Care should be taken with protocols that are easily spoofed in order to prevent self DoS conditions.
The Cisco IPS product offers capabilities for detection and mitigation that are currently not available in other Cisco products. To maximize these capabilities, administrators should fully understand how the IPS provides contextual analysis as well as how the IPS can respond to the events. By using the full suite of capabilities inherent to the device and tailoring them to their specific network, organizations can further improve their security and operational efficiency.
Kevin Timm (firstname.lastname@example.org)
Network Consulting Engineer
Risk Rating and Threat Rating: Simplify IPS Policy Management //www.cisco.com/en/US/prod/collateral/vpndevc/ps5729/ps5713/ps4077/prod_white_paper0900aecd806e7299.html
This document is part of Cisco Security Research & Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.