Determining where to place the sensors in an intrusion detection/prevention system is one of the first decisions that need to be made when deploying a new system (or replacing an existing system). To the extent that it has been determined what kind of sensors will be deployed (IPS or IDS, in line or promiscuous), placement can then be considered, regardless of what vendor will be used.
There are various types of placement deployments that can be used, such as using edge or “umbrella” sensors. This deployment model identifies the egress points at the edge of the network and situates a sensor there to monitor all traffic in and out. This is usually (optimally) deployed at some point behind the firewall that is performing address translation on the IP addresses. This allows traffic associated with a compromised host to be readily identified. Because of its location behind the firewall, the analyst does not need to deal with traffic that has been shunned at the edge router or dropped by the firewall.
Vint Cerf, one of the “founding fathers” of the Internet, once famously said, “The wonderful thing about the Internet is that you’re connected everyone else. The terrible thing about the Internet is that you’re connected to everyone else”. So it is with edge sensors. The wonderful thing about them is they see all traffic entering as network at that particular point. And that is their weakness as well. Tuning and filtering is a constant challenge at that point, especially if the sensors monitoring point is place outside the firewall, and all the malicious traffic that would be rejected is added to the flow.
Tuning can be accomplished much more readily with a dedicated sensor near the assets it will be protecting. For example if you have an Apache Web farm off your DMZ, a sensor located in front of it can run a tuned, minimalistic base of signatures looking for exploits against Apache and the OS you’ve deployed the Web servers on. Umbrella sensors need to run a comparatively larger signature set to be able to detect anything in the general flow of traffic coming in.
Consider fragmentation reassembly. If your sensor will protecting hosts that reassemble with both the favor old and favor new methods for handling overlapping offsets, your IDS/IPS will need to be able to reassemble traffic this way as well. Some IDS platforms, like Enterasys Dragon, give you an either/or choice. You can only choose which method the majority of the hosts use and hope for the best with the others, if you’re employing only an edge sensor. However, if your entire Web server segment is Linux servers, and all your database servers are running MS-SQL , you can tune the focus sensor according to the methodology used.
Note: Snort’s frag4 processor allows you to specify ranges of IP’s to be processed in one of the two methods.
Another consideration concerning focused sensors is reduced bandwidth. Obviously, a sensor only monitoring traffic to a specific segment or group of servers will see considerably less traffic than the sensor at the perimeter of the network. This can translates to a lower initial cost on licensing in addition to decrease in tuning and filtering.
All said, does that mean sensors should never be deployed at the perimeter? That is a decision for the intrusion analysis team to discuss with management and depends on the breadth of the deployment. The more places a flow of traffic is seen, the more likely an alert will be triggered. This loosely fits in with the general concept of defense in-depth (though true defense in depth would deploy different technologies to mitigate attacks). However, if the perimeter sensor is sitting physically beyond filtering devices such as firewalls, UTM, reverse proxies, application firewalls and the like, aggressive tuning to filter our noise will probably be in order.
Another consideration is whether or not to deploy the sensors exclusively from one vendors offering. Having a heterogeneous environment has the advantage of different signatures and security policies monitoring the traffic. You may have multiple monitoring points going deep into your internal network, but if an attack evades a signature, and all sensors are running the same signature, you’re blind to the traffic. Instead, by deploying another vendor’s sensor at some of the monitoring points, you now have two possible chances at detection.
In the end, where (and what) to deploy will need careful consideration and input from multiple parties. There is no one size fits all solution and this important decision should be at the front end of any deployment of intrusion detection technology.