Intrusion detection / prevention - a close tie to network forensics
What many people seem to forget when thinking about IDS and especially IPS-systems is the important tie they have to performing network forensics. Not all attacks will be blocked, and the ones that are detected by other means needs to be investigated. What equipment is better suited for that than a device that sits inline, at the perimiter or core, monitors all sessions entering and leaving the premises, and that at least tries to identify possibly malicious elements of the monitored traffic. That’s right, none. The true value of a modern monitoring system is that they are a tool for investigating security incidents - not just blocking them.
Having this in mind, this puts new requirements on the IDS/IPS. Not only should they have a good detection rate and low false positive rate, they should also have the necessary information available to actually investigate the indications that alerts truly are, but also investigate traffic that isn’t tied to an alert. Further more, which is one of the crucial elements of performing forensics, is to avoid informing the potential attacker about your knowledge of an attack. This is lesson 1A in incident handling - never try to contact the source of the alerts; never visit the website that the attack is coming from etc. All these actions might inform the attacker of your knowledge of the compromise, and as such will cripple your ability to investigate it.
Related to this is the fact that most IDS/IPS systems, and some firewalls aswell for that matter, does lookups of source and target IPs in the alerts. This feature, which is intended to make the alerts more easily readable, might in fact inform the attacker that some system has processed the traffic from him. When an alert fires the system will automatically try to do a reverse lookup on the IP, the host will contact the root server and follow it’s trail down to the DNS server that has information about the IP in question. This DNS-server could very likely be run by the attacker who now sees someone doing lookups on his IP. See how the solution itself contributes to the problem?
A possible solution to this, which doesn’t involve turning of name resolution entirely, is to be able to configure the system to use 3:rd party dns-servers or dns-proxies for external IP:s. I learnt of a tool that has implemented the support for this, namely the excellent network security monitoring console Sguil.
