The introduction of an IDS into a organization’s network can be sensitive and often has political implications with the network staff, and thus a checklist written from the perspective of an outside consultant (even if the IDS is deployed internally) that appeases all parties can be useful to ensure a successful implementation. While this topic is broad, there’s sufficient information and planning required to form the basis of the checklist.
When installing an IDS a policy needs to be developed to ensure responsibilities are clearly defined. This is especially important when delivering an IDS capability remotely or to another organisation’s network. The Junction Of Maintenance (JOM) defines where your responsibility for the hardware starts and finishes, and this will usually be the network switch port or tap with which the IDS connects to the target network.
On the subject of failing hardware, people administering the target network must be made fully aware that if network taps are used, even fail safe taps can take up to a second for the interfaces to re-negotiate and could potentially disrupt services, though recent improvements have reduced this latency considerably. If the network is remote then it is advisable for the policy to reflect that the target network manpower can be called upon for a predefined duration for power resets, etc. Attempting this retrospectively through contractual alteration, if required, can be expensive and time consuming.
If you rely on the distant network for support, ensure you have a telephone authentication system in place and don’t fall victim to a social engineering attack. It’s all too easy for an attacker or Pen Tester to call the local staff where your IDS is installed and ask them to power it down. Most of these issues can be avoided if you are willing to have your IDS application reside on one of the target network’s hosts, though in my experience it can never be completely trusted and raises the question of who maintains the software and OS deployed on the system. If an OS update corrupts the IDS application, then who takes responsibility for fixing it?
Finally, discuss and set in policy the rules of engagement for automated response. This is especially important when you are deploying Intrusion Prevention Systems. An Intrusion Prevention System or inline IDS will block packets that meet the criteria of an event signature.
These packets could have legitimately been accepted by the firewall and allowed through. As signatures can block packets in a fashion similar to a firewall, there are some that advocate replacing firewalls with IPS is a dangerous step. An IPS complements the firewall very well and they work well together, but the firewall should be left in place.
The myth that an IPS will kill a network through its false positives doesn’t have to hold true. Rather than blocking packets in line, it can craft various responses: TCP resets to the source or destination (or in some cases both) of the offending packet, crafting unreachable/unauthorized replies and spoofing the border device. For example, you might want to retain corporate knowledge by blocking any document that contains the word “prototype”, from leaving the network through the use of an IPS signature.
Once the IDS starts chattering you can revisit those “practises dangerous to security”. Policy also needs to be defined regarding how you respond to an incident and should include statements that direct forensics and evidence preservation activities. The availability of up-to-date network diagrams is essential not only for locating the best site for an IDS, but also post installation. You have to identify your requirements for the installation such as rack space, switch/hub ports, power outlets, UPS, cooling, taps and any mandatory local requirements like fiber infrastructure and fail over.
The first coarse tuning should have occurred by using the site’s policy to define the initial IDS policy. Rather than attempting this on an event-by-event basis, wait a week and look at the historical information, sorted by count.
More info: [url=http://www.securityfocus.com/infocus/1754]http://www.securityfocus.com/infocus/1754[/url]