Ending Soon! Get a new iPad, Samsung Galaxy Tab A or take $350 Off Your OnDemand or vLive course by May 10!

IDFAQ: Can the volume of network traffic get high enough to exceed the capability of the detectors?

The volume of packets transmitted over a network segment is an important consideration when using intrusion detection on that segment. There is a limit to the number of packets that a network intrusion detection sensor can accurately analyze for potential intrusions in a given period of time. The portion of network traffic volume that exceeds this volume threshold is subject to not getting complete and accurate intrusion analysis. The higher the network traffic level and the more complex the analysis, the higher the error factor may be.

It is important to know the threshold for the intrusion detection product and configuration that you use and how the product reacts when the volume exceeds this performance threshold. The failure of intrusion detection monitors are evident in high traffic conditions and generally caused by an onset of sensor processing errors prior to the onset similar process errors in the network itself. These errors are generally the premature discard of copied network packets in the analysis phase of processing to accept more incoming packets.

Compaq Computer Corporation published the results of a performance analysis of RealSecure from Internet Security Systems, Inc. (ISS) in their active Answers (November 1998 ECG077/1198). The study indicated:
‚Performance testing was conducted using the tools from the National Software Testing Labs (NSTL) firewall software methodology and Netperf by Hewlett Packard for generating small, medium, and heavy data traffic loads with the HTTP protocol. The Netperf program was used to simulate Telnet sessions. Using both tools allowed for the standardization of data loads in all three categories: small, medium, and heavy. These data loads were used in each test. Refer to the firewall performance white papers at http://www.compaq.com for more information about the NSTL firewall benchmarking methodology.‚

In a Windows NT environment the results of the Compaq performance analysis were as follows:

Test Load NSTL Mb/s load % Of Events Logged by RealSecure
NSTL (~T1) ~2 Mb/s 66
NSTL (~5 Mb) ~5 Mb/s 67
NSTL Small ~13 Mb/s 75
NSTL Medium ~25 Mb/s 33
NSTL Heavy ~49 Mb/s 10

"As the load increases from small to heavy, the number of attacks logged by RealSecure dramatically decreases. Using very small loads to simulate traffic in a typical environment under 10 Mb/s, both the 2 Mb/s and 5 Mb/s loads logged 66% of the echo events. For the small load, RealSecure recorded 75% of all attacks. For the normal load, RealSecure recorded 33% of the events. Lastly, for the heavy load, only 10% were recorded."*
Each intrusion detection product has a different level of processing efficiency threshold and the threshold will likely improve with future versions of their product.

The strategy for defending against this situation generally requires the use of multiple sensor locations (defense in depth) and to review each packet at various points in the architecture. This may include the deployment of sensors in networks segments away from network choke points where the traffic volume is high. This may result in inspecting the same packet multiple times or even in certain packets never being inspected, depending on how the packet traverses the network. Alternatively, divide the analysis for attacks between sets of optimized high performance sensors on the same network segment. The concept is to divide the analysis load over these multiple sensors in such a way that the full spectrum of analysis is performed on each packet, but each packet inspected for a different hazard by each sensor. Packets that are not subject to review in one network segment can be reviewed in others or even at the host or database level.

Phil Bandy, Michael Money & Karen Worstell
SRI Consulting

* Results of "Intrusion Detection Performance with RealSecure from Internet Security Systems, Inc. (ISS) published on active Answers by Compaq Computer Corporation. (November 1998-ECG077/1198)