Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Charlie Stokes about Intrusion Prevention Systems. Charlie works as an Intrusion Prevention Systems (IPS) technical marketing engineer and has been a network security specialist for over eight years. Charlie came to Cisco as part of the Wheelgroup acquisition in 1998 that brought Intrusion Detection Systems (IDS) technology into Cisco. After the acquisition, he worked in the Technical Assistance Center (TAC) for two years covering the Security and VPN products. Since 2000, Charlie has been covering IDS/IPS products as the lead technical marketing engineer.
Remember to use the rating system to let Charlie know if you have received an adequate response.
Charlie might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through February 10, 2006. Visit this forum often to view responses to your questions and the questions of other community members.
psrwal - Very good question. I hope my answer is clear.
The IPS sensor will first determine that a packet belongs to a valid flow, using its normalization engine. If a packet is not valid the normalize engine will either modify the packet to correct it or drop the packet (this is a general description).
If packets are valid, then they will pass through the various detection engines.
If a signatures fires the IPS appliance will first look at "event action over-rides" to determine an action to take, if it doeesn't find an over-ride it will take the action defined by the signature.
The only signatures set to drop by default are those in the normalization engine. When you tune your IPS sensor, you make the decision at what level to drop packets. Generally speaking you would use event override and tell it to deny packets if the risk rating is greater than 85. Risk rating is calculated the following algorithm:
RR = Fidelity * Severity * Target-Value-Rating/(100*100*100)
Fidelity = 0-100 Set by Cisco Systems, Inc.
Severity = 25-Information, 50-Low, 75-Medium, 100-High
Target Value = 75-Low, 100-Medium, 150-High, 200-Critical
If you find valid traffic is being dropped with a risk rating of 85 and up, then you would start tuning event action override and set it to something higher than 85 (perhaps 90) and then tweak it until it's correct in your environment.
I have a question. No matter how I work the math, the algorithm for figuring out the Risk Rating appears to be invalid. Can you show me how it's supposed to work? For example, if you take Fidelity of 100, Severity of 100, and Target Value of 200, and plug those values into the algorithm, you have the following:
IMO, the algorithm should be RR = Fidelity + Severity + Target-Value-Rating/4
This gives the Target Value Rating a weighted value over the Fidelity and Severity and gives you a more accurate number. If you take (100+100+200)/4, you get your RR of 100, which makes sense. If you have say a fidelity of 85, a severity of 100, and a target of 150, you get (using my algorithm aforementioned) 83.75 for your Risk Rating.
Anyway, tell me if I am calculating Cisco's algorithm incorrectly or if my algorithm is the correct one.
The formula is actually off. Its not showing another currently unused variable (or hasn't left off it's divisor).
Basically it's a geometric mean of the data.
In any case, the answer does come out to 200, and the sensor lowers this to the final risk rating of 100. So regardless of where the number might end up by formula it's always normalized to give a value between 0 and 100.
If the formula is off... how do I calculate. I am testing event-action-overides now, and am having issues. I would like to take the signatures and do the calculations myself before I try it out. I do not have the luxory of a lab so I really need to know.
On another note. If you have a sig set to "produce alert" and an "event action overide" of deny-packet is the net result both actions? or does the deny-packet overide the produce alert.
The formula in the product isn't off, it's just the documentation. So in the case described previously, you would have ended up with a value of 200 which the sensor normalizes to 100. So the final risk rating would have been 100.
As to testing, it's fairly simple to prove the formulas yourself. Take a High sev/100 fidelity event and adjust the Target value rating for the destination to all possible values and record the final risk rating. Take a info sev/ 100 fidelity event and do the same. It should be fairly clear what the formula is and what effect the target value rating has.
To see what is known as base risk rating (the part of risk rating that is static (sev and fidelity)), open up IDM on v5.1 sensors (5.0 does not have this feature) and look in the sig config area and scroll the window to the right to find the Base Risk Rating column.
Event Action Overrides add in actions (Never subtract or modify) so you can rest assured that any actions you have specific on a per sig basis won't get changed when they go through the overrides.
Filters on the other hand come after the overrides and therefore filters do have the power to remove any action already defined.
I don't understand how can we use RRs if the formula is off too... Also, it is unclear what promisc-delta is used for:
I don't understand why are promisc. mode alerts are less important for an admin than inline mode alerts?
One more question: when will IPS take into account OS type of the target system? I would like not to see alerts about Unix attacks hitting my Windows systems. CTR did this. Why IPS don't?
Sorry, when I said the formula is off, I meant the formula displayed in the forum above:
This should be:
Then the final number gets normalized to between 0-100 so values over 100 get reduced to 100. In the case above, 100*100*200/100*100 = 200 => normalized to 100 Risk Rating final value.
The promiscuous delta is used only for alerts generated in promiscuous mode and is the difference between what risk rating means in inline mode and promiscuous mode. In inline mode, the main purpose of the RR value is to determine whether a Deny action should occur (deny packet/connection/attacker, etc). In promiscuous mode, the RR is the means by which customers should place priority on event validation and inspection, so a high RR event from an inline sensor may not be that important if the sensor denied the packet and blocked the attacker. That same packet from a promiscuous sensor may be very important to an administrator (and here's the key), but the sensor is less certain of it's importance in promiscuous mode. Because the uncertainty factor includes how specific this alarm is for such factors as target OS, service and application, it's possible that even though the sensor saw a possible buffer overflow on a specific application/service that runs on a very specific OS, because it is so specific, the confidence that the sensor has that the reported data is very accurate (as measured by the likelihood of the attack succeeding) is reduced.
When the sensor takes OS info into account, the uncertainty factor will mostly go away and be replaced by the Attack Relevancy factor in the RR calculation (a new factor).
CTR did this post event processing (after the event had fired). Because the sensors of today need to be able to operate in IPS mode, they can't do this sort of processing after the fact and need to be able to apply this sort of network intelligence on events as they occur to make accurate decisions about deny/passing the associated packets. Check with your Cisco Account Team for the latest information concerning new features in upcoming releases.
1. I got it. Because the promiscuous sensor is uncertain of the attack relevancy it may lower the RR by subtracting promiscuous delta. Consequently Event Action Override will not add such actions as BlockAttacker or BlockConnection and the (possibly relevant) attack will succeed. Very nice logic though.
2. Ok, is it possible to filter alerts which are produced as a result of Windows attacks going to Unix boxes manually? I know that I can define address range variables in "service event-action-rules rules0" and use them in event filters. The question is: how can I define OS-specific signature groups? 4.1 allowed me to define variables to group signatures.
Very simply in 5.0 and 5.1 code, the default behavior for any signature (signatures not in the normalizer engine) is to alert. There are no default Deny actions in the product. This behavior is easily accomplished by inserting an Event Action Override in for Deny Packet for events with a specific Risk Rating or higher. You can start at 100 and as your confidence and desire to block attacks grows, you can lower that threshold to include more events. A good starting point is 85-100 to Deny Packets. That, in fact, will be the default in version 6.0 in the setup command.
So, to reiterate, unless a sig has a specific action tied to it and there is no Event Action Override that adds in actions, nothing else will cause the sensor to Deny a packet. Once you have an Override with a specific threshold set to Deny packets on, anything that effects the RR can increase of decrease the likelihood of an event hitting the threshold for the override.
My next question is about 5.0/5.1 licensing. One of my 5.0 sensors does not have a license key installed, but I was still able to apply S214 Sig update. Documentation says the following: "You can install the first few signature updates for 5.0 without a license". The question is: what does this exactly mean? How many sig updates I will be able to install without a license? Are there any differences between 5.0 and 5.1 here?
Licensing has been a confusing area for many.
"the first few signature udpates" has so far included everything from S149 to the latest signature update.
Originally licensing was going to be enforced within a month or 2 after 5.0 was released (at around S160).
But there were issues with converting users to the new Cisco Service for IPS service contracts which were necessary for them to get their licenses.
Also many customers did not have enough warning to budget properly for the increased cost of the Cisco Service for IPS service contracts.
So it was decided to wait on the enforcement of the licenses until a later time.
When 5.1 was released there was a new feature callaboration with Trend that required us to begin enforcing licenses on all 5.1 sensors.
So on a 5.1 sensor you must have license to install a signature update (began with S206).
We were going to begin enforcing licensing on the 5.0 sensors at the same time as 5.1. But because of remaining contract conversion issues, and customer budget issues, it was once again decided to further delay the license enforcement on 5.0 sensors.
(So S206 requires a license on 5.1 but not 5.0)
In fact we even posted a generic all sensor license on CCO back in November that expired earlier this week on Jan 31st. This was to give customers that need 5.1 functionality to go to 5.1 and have an additional 2 months to get contracts and licenses.
So we are still in a situation where the 5.0 license enforcement is still delayed, and where 5.1 does enforce licensing.
At some point in the future we will begin enforcing licenses on the 5.0 sensor for signature update (just as we already do for 5.1). But when that date will be is still up in the air.
Once we have ensured that all contracts are correct in Cisco's internal tracking system, and that all customers have had ample warning and time to budget for the contracts; then 5.0 license enforcement will begin.
It could be a a few weeks from now, or it could be a few months from now.
So you need to ensure your sensor is covered under contract and properly licensed as soon as possible in order to ensure you can always install any new signature updates.
You need to use the IPSMC/VMS 2.3 for auto updates. here's an excert from a 5.1 read me that should be posted in the next 20 days or so...
Q. Will VMS 2.3 support both automatic download AND installation of IPS Signature Updates?
IPS MC polls CCO for updates. The user has 3 choices in IPS MC 2.3 when dealing with signature updates.
1) Check only - This allows the IPS MC to check for new updated and notify the user
2) Check and download - This checks for new updates and downloads them to the IPS MC
3) Check, download, auto-update - This checks for new updates, downloads and automatically pushes them out to sensors.
Is there any capability with the 5.0 platform to modify the default interfaces names for the monitoring interfaces? For sensors with 4 monitoring interfaces that are watching different network segments, it would be beneficial to be able to customize the interface name to be able to sort on this information in VMS.
Sensing interface information does not get sent to reporting devices. Reporting is sourced from the management port and that is the source address you will see in VMS or with CS-MARS. There is not way to name this interface on the IPS appliance. If you have a DNS entry for the management interface it will show up as the source in your reporting devices. This is one of the very nice things about CS-MARS, it will show the event and include the network topology showing you where in your network the event was detected. Currenly there are no plans to add this function to VMS.....Please re-post if I've misunderstood your question - thanks....