Event Action Overide Risk Category

PWCSinfosec · ‎10-09-2009

By default the "HIGHRISK" risk category has a risk range of 90-100. I am attempting to be much more aggressive in proactively stopping potential threats to my network. Has anyone experimented or currently using a wider range with this "HIGHRISK" range?

If I drop the low end of the "HIGHRISK" category, 90, to say 70, will this apply the event action override policy action to low, medium, and high alert signatures with a risk rating of 70, or only high alert signatures?

marcabal · ‎10-09-2009

Alot of what you are asking really depends on what you are using to configure your sensor.

If you are just using the CLI, then the ranges like "HIGHRISK" don't really mean anything.

The default Event Action Override for Deny Packet InLine is set for the range 90-100.

You can just as easily go directly through the CLI and manually change this configuration to make the Range 80-100, or 70-100, by just changing the numbers.

The CLI ignores the category names and ranges. It will store the name and ranges in the configuration, but the CLI doesn't make any more use of them.

Only IDM (and maybe CSM) make actual use of the Risk Category names.

But they do so mainly just for visual representation purposes.

Now if you wanted to change the HIGH RISK Category to be 80-100, and do a Deny Packet InLine for everything in the HIGH RISK category this it is usually a multi-step process.

You would go through IDM, and change the HIGH RISK Category to be 80-100, and Apply the Change.

THEN if you looked at the default event action it will likely show the range 90-100 instead of the Risk Category HIGH RISK.

So changing the range for the HIGH RISK Category often does not automatically change what underlying ranges are actually used in the override.

So your next step is to then go and change the Override configuration so the Deny Packet InLine will be done for the HIGH RISK category (in other words the Range on the override itself has to be changed to 80-100).

There have been a few bugs found in IDM when trying to make these types of changes, so it may take a few tries to get the configuration the way you want it.

I tried it while I was typing this, and the override disappeared completely on my first attempt, and I had to try the change again.

NOW if you try to change it to 70-100, then this coudl be done in 2 different ways.

You could leave the definition of HIGH RISK alone, and instead go to the Override configuration and just simply Add MEDIUM RISK to the overrides for Deny Packet Inline.

This will cause the configuration of the Deny Packet Override to be changed to 70-100 in order to encompass both MEDIUM RISK (70-89), and HIGH RISK (90-100).

The other alternative is to change HIGH RISK to be 70-100, and then edit the Overrides to set HIGH RISK with deny packet inline override (remember like I talked about above it is a multi-step process).

BUT if you simply jump straight to setting HIGH RISK to have a Risk Threshold to be 70, you will get an error.

This is because MEDIUM RISK already is set to have a Threshold of 70.

So change MEDIUM RISK to have a Threshold of 60 first, and then change HIGH RISK to 70.

Then go and edit the override configuration.

So the HIGH RISK, MEDIUM RISK, and LOW RISK are just names that IDM uses when displaying the Ranges used in the overrides.

The sensor itself doesn't care about the names, and just stores them for IDM.

It is the actual Numerical number that matters on the sensor.

Now when you say low, medium, and high alerts it is hard to determine what you mean.

Low, medium, and high get used in multiple different places.

They are levels of Severity, as well as the names of Risk Categories.

And just because the alert has a Medium Severity does not always mean it will have a Risk in the MEDIUM RISK category.

And when it comes to Overrides, the severity of the alert doesn't matter, and from the sensor's perspective the name of the Risk Category doesn't matter either.

It is only the actual Risk Rating number that really matters.

marcabal · ‎10-09-2009

As for your question about whether or not others have experimented with different Risk Ranges for the deny packet inline override, this is something I hope other users will jump in and reply on.

It really comes down to how much time you want to spend tuning your sensor, and how much trouble it will cause if the sensor starts denying good connections.

The default 90-100 range was put in because with the default configuration only the High Severity alerts with fairly high Fidelity will wind up with HIGH RISK in the 90-100 range and be denied.

So it is unlikely to cause the sensor to deny good connections.

Changing it to a 70-100 range for the deny packet inline override will increase the number of alerts that will be denied.

It will likely deny more attacks, but you also run a higher risk of denying good connections.

When a good connection is denied you will need to go into the sensor configuration and make an edit of some kind. Either disabling the signature, or creating a filter to remove the deny action for that signature, or for the specific ip address/ signature combination.

So will your company tolerate the denial of good connections between the time that the signature is triggered, and when you are able to get the filter in?

If you have a 24X7 staff that is allowed to make filter edits immediately as needed, then it might be fine. Your staff could create the filter as soon as they hear about good traffic being denied.

But if your company prevents configuration edits with multiple levels of approval and only during designated hours, then the time between finding out good traffic is denied and being able to put in the filter could be days worth of delay.

If you do want to consider lowering the range, then here is what I suggest:

1) Start by looking at what alerts are you currently seeing between 70 - 89, and see if there are enough in this range to make a real difference in how secure your network is.

2) Look to see if any of these alerts are already triggering on good traffic, and go ahead and start making filters (or disabling signatures) in order to prevent them from triggering again.

3) Closely monitor the 70-89 Risk alerts over the next several days to ensure your filters are working right so you are only seeing real attacks in this range.

4) Then change the range for the override. You might even consider changing the range only 5 points at a time, and start with 85-100.