Tuning The IDS
In tuning your IDS, you might want to take the "low hanging fruit" approach first. Once you have the system up and running, and your alerting is working properly, start by finding signatures that generate a lot of alerts and can be positively confirmed as false positives. For example, say you get a ton of ICA alerts to a Citrix Server. That is the function of the server, so that type of traffic is expected and normal.
How do you want to tune this? You want to be efficient and not make the system inspect any more traffic than it has to, and also be mindful you don't do it in a way that filters out traffic you might want to see. You might decide to change the signature and modify it so it only alerts on connections from external or non-trusted networks to an internal host. This would affect all Citrix Servers on your network, which might be what you want. You need to determine risk vs efficiency here.
Or you might want to apply a filter to only your internal sensors for any traffic to that server(s). If you want even less risk, you might write your filter to ignore only your internal network segments going to those servers.
You may maintain different sets of signatures for different types of sensors, too. You could have a library for external Internet servers, another for internal servers, and yet another for the corporate frame or intranet. By doing so you can exclude signatures that would require a lot of tuning. It all depends on your risk model for that connection.
Another way to tune out alerts you may not care about would be to disable ones not relevant to your network. If all of your Internet facing servers run Windows, you could disable signatures for exploits against Linux or Solaris. If you're strictly a IIS shop, you may not care about blind attacks against Apache Web servers. On the other hand, it IS hostile traffic directed at you. You have to determine how much risk you're willing to accept to increase the performance of your system.
I've heard of network security admins who say they're not willing to accept ANY risk, and they want to run every signature available for their system. This is a really bad idea for a couple of reasons.
Tuning is done primarily for two reasons. One, to filter out the background noise of false positives or true positives that have no effect on you, and two, to streamline the performance of your sensors. Each signature you apply means your sensor has to inspect packets traversing it for those particular attributes. Running all signatures puts a huge load on your sensors, and generates so many alerts it's very difficult to focus on the relevant ones.
There are a lot of ways to tune an IDS, and you won't ever reach a point where you sit back and say "I'm finally done tuning this thing.."
An IDS needs constant care, maintenance and tuning. If you're the lone network security person where you work, you may find you spend a significant part of your day working on it. It will need tuning as new signatures are added, new circuits are deployed and new applications are rolled out. Oh, and on top of all this, you need to allow a little time to actually LOOK at the alerts. That's pretty important too!
How do you want to tune this? You want to be efficient and not make the system inspect any more traffic than it has to, and also be mindful you don't do it in a way that filters out traffic you might want to see. You might decide to change the signature and modify it so it only alerts on connections from external or non-trusted networks to an internal host. This would affect all Citrix Servers on your network, which might be what you want. You need to determine risk vs efficiency here.
Or you might want to apply a filter to only your internal sensors for any traffic to that server(s). If you want even less risk, you might write your filter to ignore only your internal network segments going to those servers.
You may maintain different sets of signatures for different types of sensors, too. You could have a library for external Internet servers, another for internal servers, and yet another for the corporate frame or intranet. By doing so you can exclude signatures that would require a lot of tuning. It all depends on your risk model for that connection.
Another way to tune out alerts you may not care about would be to disable ones not relevant to your network. If all of your Internet facing servers run Windows, you could disable signatures for exploits against Linux or Solaris. If you're strictly a IIS shop, you may not care about blind attacks against Apache Web servers. On the other hand, it IS hostile traffic directed at you. You have to determine how much risk you're willing to accept to increase the performance of your system.
I've heard of network security admins who say they're not willing to accept ANY risk, and they want to run every signature available for their system. This is a really bad idea for a couple of reasons.
Tuning is done primarily for two reasons. One, to filter out the background noise of false positives or true positives that have no effect on you, and two, to streamline the performance of your sensors. Each signature you apply means your sensor has to inspect packets traversing it for those particular attributes. Running all signatures puts a huge load on your sensors, and generates so many alerts it's very difficult to focus on the relevant ones.
There are a lot of ways to tune an IDS, and you won't ever reach a point where you sit back and say "I'm finally done tuning this thing.."
An IDS needs constant care, maintenance and tuning. If you're the lone network security person where you work, you may find you spend a significant part of your day working on it. It will need tuning as new signatures are added, new circuits are deployed and new applications are rolled out. Oh, and on top of all this, you need to allow a little time to actually LOOK at the alerts. That's pretty important too!