Information gathering before deploying a Network IPS

Question

I understand that most NIPS these days have either rules or signatures built in to them and perhaps gathering information prior to deployment may help in fine-tuning the rules / signature once the IPS has been deployed, up and running.

As such what sort of information do we need to gather prior to deploying an NIPS (e.g. OS-es on a network, network segments)?

Opinions, thoughts and suggestions would be greatly appreciated.

Answer 1

In the ideal situation you would put together a list of all assets and threat vectors on your network, including but not limited to:

• Operating system flavors and versions
• Applications
• Network infrastructure
• Anything else plugged into the network

With that you could plow through all of the signatures that are available and include only the ones that apply to you. For instance, if Solaris does not exist on your network, then there is probably no reason to include a signature for CVE-2007-0882 (the telnet auth bypass). In this case you can determine, within some degree of accuracy, which classes of rules need to be enabled before you even insert your first sensor. Keeping in mind that these signatures are constantly being updated and added to, you are better off thinking in terms of types of signature instead of specific signatures.

If you have a tightly regulated network, then go through your CMDB to build out this information. If you don't have a CMDB this might be a good time to get one started. If you are not in a tightly controlled network then you can get started by doing flow analysis or review packet captures. A good vulnerability assessment tool might also help give you a list of what's out there.

In either case, you should assume that whatever picture you develop is incomplete. I would recommend erring on the side of enabling too many rules, and just plan for a pretty intense initial tuning.

Never forget that an IPS/IDS system does have a fair amount of on-going maintenance. As signatures are updated and systems/applications are added/subtracted you will need to evaluate what you're looking for.

Answer 2

In addition to Scott's post which has excellent technical guidance, on the policy side ensure you have a risk register or at least some type of risk classification for each of the assets on your network. This will be invaluable when it comes to defining the protection needed, and may make management simpler by requiring the IPS to monitor less traffic, or by excluding some hosts or network segments entirely.

Answer 3

One benefit to running a SIEM is the correlation capabilities before actions, including automated actions, are enacted.

Q1 Labs QRadar, ArcSight ESM, and OSSIM all have asset and inventory capabilities. OSSIM is made up of many open-source apps that are great for IDS and IPS. The default inventory provider is OCS Inventory NG. In the OSSIM web portal, the Analysis and Intelligence drop-downs will lead to Events/Anomalies (default providers with snort, PADS, p0f, and Ntop) and Correlation controls.

snort-inline could be utilized as the IPS provider from OSSIM. OSSIM also has a Respond capability, which can be used to change firewall/router/switch/IPS configurations. There are plugins for OpenVAS (the default vulnerability management plugin) and Nessus, which can be used to test the IPS once it is blocking. A PDF article the ISSA magazine thread, toolsmith can be found here on [PDF] [OpenVAS-4]3.

Similar functionality is common in most SIEM packages.