| I l@ve RuBoard | |
We have mentioned ways to sidestep an IDS. In this section, we present the general criteria to consider when evaluating an IDS for purchase. Consider that if you are able to monitor every bit of traffic and analyze it, nothing will get by you. However, for large networks, this is not possible. Therefore, you are going to have to let some traffic get through without inspecting it. No matter how effective an IDS is, there is the chance that a hacker will get around it. What you need to do is limit that chance as much as possible. In this regard, simply by having an IDS installed on a network does not by itself make the network any more secure. It must be the right IDS for the network and properly configured to be effective.
Our approach is to examine a network to understand the kind and quantity of traffic that is likely to travel on it. You don't want this normal traffic to generate alerts. If you can understand the network traffic patterns, you can create rules specifically designed to omit normal traffic and allow you to capture the rest—which hopefully will include all hacker activity.
Keep the following 15 criteria in mind when designing an effective IDS.
Performs real-time monitoring. Most modern IDSs have this capability.
Can monitor all common types of traffic. The IDS should be able to monitor all commonly used protocols that may run on your network, such as telnet, FTP, RPC, DNS, SMTP, and so on. If your network is designed for a less common or proprietary network protocol, you may need to obtain an IDS that can be configured to understand and monitor that protocol.
Provides meaningful alerts and responses to events. The alerting capability should also include the ability to send an alert to the management console and a page or an e-mail to the security administrator. An X-window pop-up message on the administrator's machine is a good start. Additionally, an IDS's ability to make temporary changes to a firewall's rule set, terminate suspect sessions, or execute commands or scripts in response to detected network traffic can be very helpful for actively defending the network. This is a new area for IDSs, and not all available products can perform these types of activities.
Features a large and continually updated signature database. You will want an IDS with a large database of signatures and one that updates the signatures frequently to keep up with new attacks. An outdated IDS may be ineffective against more recent exploits. Updating the signature database is the vendor's responsibility, but you need to ensure the vendor will do this. These updates should still allow users as much flexibility as possible in creating their own rules. In other words, any customized or specially crafted rules should not be deleted when the signature database is updated.
Has the capability to log events. An IDS should be able to log captured activity, such as the alerts it generates and the actions it takes, as well as events it witnesses, such as successful connections. While there may not be an interest in logging all successful connections, such as telnet, FTP, SSH, and so on, the IDS should provide the option for performing session capture and playback or at a minimum the ability to capture the session handshake/logon portions.
Along these lines, the IDS should be able to examine packet headers of the various types of traffic it captured. As a bonus, if the IDS can allow the administrator to perform trend identification and traffic analysis, it can be helpful for developing a very efficient rule set over time.
If the IDS has the ability to write log files to separate machines, this may be even better since log files are often targets for hackers who want to cover their tracks.
Is fault tolerant. An IDS should not lose stored information if the host system crashes. This is important since some hackers may attempt to crash the host system in an effort to circumvent the IDS or corrupt the log files to remove evidence of their activities. Along these lines, the IDS should be able to monitor the sensors at all times and should trigger alerts if the sensor is down or is being inundated with network traffic. This can function as an early warning of a denial-of-service attack.
Can generate clear and useful reports. The IDS should be able to generate effective, easy-to-read, user-configurable reports. These reports should contain details (for example, a listing of attacks, source and destination IP addresses and ports, definitions of attack rules or signatures involved and recommended fixes, and so on) that can allow an administrator to view the data and explain it to others within the organization. Further, the ability to report on specific sessions, connections, and traffic from a particular IP address or domain is valuable. The format of the report (text document, comma-separated values, and so on) should also be configurable.
A reporting capability is not a reflection of an IDS's technical and functional usefulness, but a good reporting capability will go a long way in justifying to management the need for and use of an IDS. Further, it can present an overall view of the possible attacks being launched against your network, which can help identify areas of weakness and places where additional security measures should be taken.
Combines the network-based and host-based approaches. While there is overlap in the network- and host-based IDSs, they are aimed at protecting different assets, and therefore an overall system should combine both approaches. These sensors should report to a common management console so an administrator can view the entire network at once (or at least the portion for which that administrator is responsible).
Is able to process the quantity of traffic to which it will be exposed. The IDS needs to have the necessary technical resources (such as memory and processor speed) at its disposal in order to effectively monitor the network. Often, if the level of traffic grows beyond the IDS capability, it will simply let traffic pass without comparing it to its signature database—in which case, it will not be providing any security at all.
Is placed in the appropriate location on the network. Following the last point, the IDS sensors must be located where they will be able to see the traffic of interest in order to provide optimum network security. Finding the right place involves understanding which servers and segments of the network are critical, in terms of both business need and likelihood of attack. Network sensors should be placed inside choke points protecting such segments. Host-based sensors should be placed on the critical hosts or servers.
We are often asked, “Why not place network sensors in front of choke points so that the traffic and all alerts can be compared between the sensors in front of and behind the choke point?” Sensors in front of choke points tend to become overwhelmed with network traffic and flood administrators with alerts, more than they can ever follow up. By configuring the IDS to ignore false positives (alerts caused by normal or legitimate network traffic), you lose the benefits of comparing traffic in front of and behind the choke point.
A better scenario is to configure the filtering router or firewall that is the choke point to block and log unauthorized activity; the IDS behind it can then be used to catch anything that comes through. In this scenario, the administrator tends to get fewer alerts and is more likely to be able to follow up on them.
When placing an IDS sensor on a network segment with a very well-defined and limited type of traffic expected, such as a DMZ for a Web server expecting only HTTP traffic, system administrators may be tempted to configure an IDS to trigger on any other kind of traffic at all. The logic is that since other traffic is not anticipated, any occurrence of other traffic should generate an alert since it may be indicative of an attack. This may be true to some extent, and a sensor on such a network can have a broader rule set than usual. However, as a general rule, we do not recommend this since several IDSs do not function well at all if placed under too much load. Often, having to compare even a moderate amount of traffic with a very comprehensive set of signatures becomes too much of a processor load. Before such a sensor is configured, the processing capability of the IDS (and host on which it runs) must be evaluated.
For a network-based IDS, it is important to place the sensor in a location on the networks where it can view all the traffic on the wire. Switched networks, where traffic is directed only to its destination host, require a switch capable of spanning the ports or mirroring traffic onto a selected switch port or the use of VLANs so that the sensor can access the traffic it needs to monitor.
Features secure communication between sensors and the management console. Communication between a sensor and the management console should be secured through an encrypted tunnel, out-of-band management, or some other means. The IDS should support strong authentication between sensor and console with digital certificates or another secure method. If a hacker can compromise your IDS and gain administrator rights on a sensor or console, you are in deep trouble.
Is configured properly. An IDS is only as good as its configuration. An IDS straight out of the box is not usually very effective. You need to perform a large amount of configuration and fine-tuning to reduce the rates of false positives and false negatives. If the IDS is not properly configured to eliminate false positives, it will bury an administrator in so many false alerts that he or she may not be able to adequately follow up on them. In such cases, the IDS is not providing any network security at all.
Developing a good rule set for an IDS is definitely an iterative process. You will need to create a rule set and examine the IDS data for a period of time, modify the rule set to reduce false positives and false negatives, and go through the process numerous times. In truth, the IDS rule set will have to be updated periodically throughout the life of the system.
Also, the IDS should be able to escalate alerts based on the recurrence of events. For example, a single failed FTP session authentication should cause a low-level alert, three failed connection attempts to the same user account within a minute should be a mid-level alert, and ten attempts should be a red alert indicating a possible brute force attempt.
Is implemented in accordance with procedures that enforce proper monitoring and response to alerts. Once an alert is generated, there must be a proactive response to ensure that it is an attack, not a false positive, and to then respond to any real attacks. If proper response procedures are not developed an administrator may take incorrect action and waste resources, miss a legitimate attack, or damage forensics data.
Is implemented in a layered approach with firewalls and/or filtering routers. A firewall and an IDS act as a good one-two punch for securing networks.
Is regularly tested to verify the system is working as required. We recommend placing the IDS on regular testing cycles to verify its effectiveness.
In addition to the above, there are other issues that are worth mentioning but are beyond the scope of this book. Before selecting an IDS, it is important to consider its interoperability with previously existing technology. The labor needs with respect to implementation and ongoing maintenance of an IDS should be considered. Having a system that you are not able to fully understand or use is of little value. We have also not discussed the cost factor since cost often depends on the number of licenses purchased, the size of the deployment, and any service agreement reached with the vendor. All of these issues are important and must be considered before dedicating any resources and making a purchase.
Also, it is not the intention of this section to suggest or promote any one IDS over another. We simply present a set of criteria that can be used to assist in a purchase decision.
| I l@ve RuBoard | |