Best practise for configure signatures

[rmv72]

By default a lot of signatures is disabled. What should i enable ( i mean signatures)? Is't exist guide for typical configure IDS?

[rmv72]

If i use only WinOS based computers and servers should i disable in Signature Groups - OS - MacOS,Netware and Unix?

[a.arndt]

IMHO, disabling signatures is driven entirely by two factors: environment and risk acceptance.

Environment is easily defined. As you've suggested, a network that is entirely populated by MS-based systems would not be normally be subject to attacks aimed at MacOS, Netware, Unix or Linux. As a result, one might consider disabling signatures that are designed to detect attacks exclusive to these various OS's since they are not applicable to the network being monitored (aka - environment).

The other factor, risk acceptance, is a little more challenging to state. In a small network environment, where a handful (or less) of administrators tightly control the introduction of new systems, it may be safe to accept the risk and assume that your MS-only environment will remain this way (which can be confirmed using standard VA techniques). If however you're dealing with an enterprise-sized network, it may not be reasonable to make this assumption. If you did in fact turn off non-MS OS alarms, you may leave yourself wide open to a slew of undetected problems because you cannot absolutely guarantee that only MS-based OS's are running on the systems connected to your monitored network. It would only take one or two vulnerable systems running an non-MS OS to be introduced to you network unknowingly for you to become the source of attacks against other networks, whether your own or those of someone else.

In the end, you'll have to choose a stance that lies somewhere between these two levels. As long as you consider your potential exposure prior to disabling signatures, and if you use regular VA to confirm what is indeed active on your network, it is usually safe to turn signatures off. If you’re a touch paranoid (or if your policy dictates that you must monitor for all possible attack vectors; not uncommon in .edu and .gov environments), then you won’t ever want to turn off any signature, save for when it is proven to be out-of-date or ineffective. You'll probably pursue an aggressive course of signature tuning and exclusions instead.

Again, this is just my take on this. I invite others to chime in on this. This topic isn’t discussed nearly enough in our circles and many of us (I feel) leave it up to the vendors to decide when it is the right time to turn off signatures for us.

I hope this helps,

Alex Arndt

[0c-pacheco-low]

Alex, thank you for your response to the query. This is a topic I am concerned about. Beyond your discussion of disabling signatures, I wonder about tuning. For ease of discussion, let's talk about a single platform, say MS. If our servers are all hardened and scanned prior to install on network, I can safely assume somewhat, that at that point in time, they are not vulnerable to attacks for which they are patched. Tuning the filters will 'hide' any activity aimed at that signature to that server. However, if a change is made to the server and it becomes vulnerable, I will now not see an alarm. VA will detect weaknesses, but only periodically, not constantly, real-time. Vulnerable devices on the WWW have been detected in only a few minutes. Not tuning produces overload of alarms..what's the compromise or best-practice?

[a.arndt]

That's the rub and I'm not aware of any specific "best practice" for this that anyone has put forth as a standard to follow. That being said, I would like to share my take on the subject.

In some environments, systems that are commonly noted as the target of a specific alarm for which the vulnerability identified is one that they are not susceptible to are often filtered out. You are quite right however to point out that if these systems should somehow become vulnerable again, you'll be none the wiser should they be exploited (or just simply probed) using that same method that was detect by the signature you have now filtered. As a result, you should revisit your filters on a regular basis and confirm that they are still valid.

Other environments learn to accept that a certain amount of alarm overhead will occur. In their case, situational awareness is used to determine the validity of the alarm. What I mean by this is quite simple; if a system is noted as being the target of a particular attack, the monitoring team has the information available to them (OS, application version, patch level, etc.) so that they can decide whether or not to react. Obviously, this method is quite effective at keeping tabs on everything but it requires that you have a significant level of knowledge about your monitored environment. Unfortunately, you may not have this luxury, particularly in a monitored environment for which you have no operational control. This information can be built up from scratch but it is an involved process. You will spend a lot of time talking to both the network and system owners in order to develop this situational analysis.

IMHO, if you are monitoring a network for which you have a direct feed WRT how it is configured (especially the critical hosts deployed within), it is more effective to filter out what can be considered a “false positive” alarm for your environment. By filtering out known false positives, you lower the “noise floor” for you network, at least from the perspective of the IDS. This in turn allows your monitoring to focus on watching for what you’re still exposed to. The key point is to remember is that you need to know what is filtered, why it is filtered and then check from time to time that the filters are still relevant. Unfortunately, this raises a new issue and that is “when should I revisit my filters?” The answer is again dependant on your environment. It can either be time-based or driven by specific events (patch rollout, SP deployment, etc.). You’ll have to decide which, if not both, are more suitable to meet your needs.

I hope this helps,

Alex Arndt