9.4 Tuning the IDS


9.4 Tuning the IDS

When initially installed, an IDS will generally require some sort of tuning. This is because there will be a number of false positives. This means that normal user traffic on the network looks like some sort of attack according to whatever method of IDS you are using. The amount of tuning an IDS requires can be significant, depending on what rules are being checked and the type of traffic on the network. It is significant enough that more than one network manager has decided against an IDS altogether, as he or she perceives that the amount of work to simply get an IDS to the point of being useful to the network is excessive. The amount of work involved in tuning an IDS is also significant enough to serve as a powerful marketing tool for IDS vendors that claim that their product requires minimal tuning and can be operational virtually out-of-the-box.

Along with false positives, there is also the matter of false negatives. False negatives are attacks that do not trigger the IDS alerting system; they are undetected attacks. False negatives are even more troubling for an IDS administrator because, by definition, you do not know that they have occurred. It is also this uncertainty that keeps network administrators up at night, even when they have just installed the latest, greatest IDS product.

Part of the tuning process also involves figuring out what to do with the information that an IDS produces. An IDS, depending on the vendor, has the ability to notify network administrators in many ways. Many vendor products will support paging, e-mail, or printing output to a screen. Despite the differences between vendors, IDS information comes down to either generating an alert or logging information.

Alerts are generally events that the network administrator has determined require immediate attention. For example, an attack that the IDS classifies as a backdoor attack would generally be something that a network administrator would want to know about immediately. A port scan directed at the network would be something that has a low risk and would therefore be logged for review at a later time.

The biggest mistake that network administrators or managers make when configuring their IDS alerting system is to alert the network administrators to every network "hiccup" the sensor picks up. Generally, the volume of alerts quickly becomes so overwhelming that the alerting feature ends up getting shut off altogether. What is required to make effective use of this system is the ability to prioritize alerts.

The most common way of prioritizing IDS alerts is to use a method very similar to a risk analysis in assigning severity to the information that the IDS captures. It is a simple fact of the networked environment that your network will come under either casual scanning, the digital equivalent of rattling a doorknob as you walk down the hall, and the focused attack — someone trying to kick down the door and make off with whatever he or she can get their hands on. Because most IDSs will allow the network administrator to set the logging level for individual devices, it makes sense to do a thorough inventory of network assets prior to tuning an IDS. If you have properly created a security policy, much of this work should have already been completed during the risk analysis.

When an inventory of network services is complete, a listing of the relative priority of the services should be completed. Some systems and some applications are more important than others. For example, an enterprise resource planning (ERP) or customer relationship management (CRM) system would be considered a much higher priority than a print server. A mail server might be considered more important than a file server, or vice versa. Based on the value of this information, at some point there will be a threshold where the network administrator will wish to be alerted of a suspected attack in progress on the ERP servers while a log of a suspected attack on the print server will suffice until it can be reviewed.

Along with the priority of resources, the priorities of the attacks should be considered. For example, if you were certain that your ERP servers were patched against common IP fragmentation DoS attacks (as most modern operating system network stacks should be), then such an attack may only warrant a log. On the other hand, if a new attack vector has recently been made public and you know that your servers may yet be vulnerable, then any activity of this type should generate alerts.

In a network where security is a priority and care has been taken to cover all the bases, the network may not be 100 percent secure, but it should be resistant to the common script-kiddie attacks — precompiled, one-click, hacking programs available for downloading on the Internet. These attacks, while they will be common, should be considered a low priority — to a point. Thus, patterns that match common scripted attacks should be logged until they reach a certain threshold, at which point an alert may be in order. On the other hand, any attack that potentially gives attackers administrative access to a system should be considered a high priority and generate alerts accordingly.

The position of the IDS sensor that is capturing traffic should also be considered when determining the relative priority of alerts. In a segment of the network that serves as a server farm for internal LAN systems, alerts should receive a much higher priority than a sensor that is monitoring Internet traffic to the outside of the firewall.

Finally, the work of tuning IDS alert levels will be greatly simplified if the network itself is in good shape from the point of view of security. That is, all operating systems have been properly secured and documented as such; applications and operating systems are all at the appropriate, most recent patch level and users employ encryption and authentication in a prudent manner. Knowing that your network, as a whole, is in this state because security is a priority on the network and proper documentation procedures have been followed makes the job of administrating an IDS that much easier. It allows a great number of attacks to be logged only and minimizes the time that network administrators spend following up on common attacks that ultimately failed anyway.

The task of tuning an IDS can be time-consuming. The IDS must be taught to ignore false positives and only log low-priority alerts. The end result of this work, however, is a concise and confident view of the threats that your network has faced and, with any luck, successfully repelled.




Network Perimeter Security. Building Defense In-Depth
Network Perimeter Security: Building Defense In-Depth
ISBN: 0849316286
EAN: 2147483647
Year: 2004
Pages: 119
Authors: Cliff Riggs

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net