Network Intrusion Detection Systems (IDS) monitor computer network traffic and attempt to identify, alert, and present all anomalous activity to the user. The basic premise is that if a transmission is not allowed on the network, the IDS will have the ability to recognize and report the illegitimate traffic. The key to any Intrusion Detection System is to maximize accurate alerts (true-positive) while at the same time minimizing the occurrence of non-justified alerts (false-positive). This is much easier in theory than in practice, as attested by the variety of intrusion detection methods. These methods include but are not limited to Artificial Immune System , Control-Loop Measurement , Data Mining , Statistical , and Signature-Based (Rule-Based ). The most popular of these methods is Signature-Based Intrusion Detection. While there are many approaches to intrusion detection, this document specifically focuses on Statistical-Based Intrusion Detection Systems, Spade, and the deployment of Spade in concurrence with a current IDS.
Some of the more popular Signature-Based IDSās are NFR , RealSecure , Dragon , Snort , and Cisco Secure IDS . It has been shown that Signature-Based Intrusion Detection has many benefits, such as the potential for low alarm rates, accuracy of detection, and detailed textual logs . With verbose signatures, it is relatively simple to specifically identify packets of interest. For example, it would be trivial to write a rule to alert on all TCP packets with the SYN flag set. Not all IDSās allow independent rule development, but some, like Snort and Dragon, accept user created rules. Nearly all IDS vendors provide rules for their products with variable numbers of signatures, usually in the range of 500-1500+ rules. Rules are developed over time as the security community identifies new vulnerabilities and scanning techniques. The extensiveness and speed with which these rules are developed by the vendor is a good benchmark for how effective the IDS will ultimately be. While the Signature-Based approach to intrusion detection is acceptable, it leaves much to be desired. With vendors coming out with new signatures on a weekly or daily basis it is difficult for an already overburdened security professional to keep up to date with the latest rule sets. A far more serious shortcoming of the Signature-Based IDS approach is the inability to detect new and previously unidentified attacks. A Signature-Based IDS is only as strong as its rule set, and if the attack is new, there will simply not be any signatures developed to identify the probe. Signature-Based Intrusion Detection also has a limited ability to detect port scanning. In fact, most IDSās use the rudimentary approach, whereby, if X events of interest are detected across a Y-sized time window , the system will generate an alert. By limiting the number of packets targeted at a network over a specified time frame, an attacker can easily escape detection by the IDS. These deficiencies are inherent in the Signature-Based model, which is why different methods of detection are needed to address the inadequacies of the Signature-Based approach.
An Introduction To The Statistical Approach
Statistical-Based Intrusion Detection Systems (SBIDS) can alleviate many of the aforementioned pitfalls of a Signature-Based IDS. Statistical-Based systems rely on statistical models such as the Bayesā Theorem , to identify anomalous packets on the network. To identify an anomaly, the system uses data compiled from previous network behavior. Since warnings are based on actual usage patterns, statistical systems can adapt to behaviors and therefore create their own rule usage-patterns. The usage-patterns are what dictate how anomalous a packet may be to the network. Anomalous activity is measured by a number of variables sampled over time and stored in a profile. Based on the anomaly score of a packet, the reporting process will deem it an alert if it is sufficiently anomalous; otherwise, the IDS will simply ignore the trace. The reporting process will alert the user if the packetās anomaly score is greater than or equal to the threshold level set by the user. So, the SBIDS identifies and tracks patterns and usage of the network data and then assigns an anomaly score to each packet. Once this is accomplished, the reporting facility will generate an alert if the anomaly score is greater than the alert threshold. As an example, letās say that every morning, you wake up and read the morning paper that is waiting outside the door. After a few days or weeks of this behavior, it becomes normal; you expect the paper to arrive at the door in the morning. One morning, the paper is not waiting at the doorstep. Instead, the paper is lying in the driveway. This is not normal; it is clearly anomalous activity, but probably not enough to warrant investigation. Now, letās say you continue to see approximately the same pattern of a few papers landing on the driveway every week. Then, one day, you wake up to no paper at all, or even worse, the paper is thrown through the window. Neither of these events is normal, and both would warrant some degree of investigation. If an anomaly number is associated with these events, we can begin to see how a SBIDS works. The action of receiving a paper at the door in the morning would be deemed ānormalā activity. The system would recognize the pattern and learn that this is normal behavior. Other activities would be judged based on the number of occurrences and how āuniqueā they were in relation to normal activity. The importance of the threshold level is shown in this example as well. If the threshold is set to a low number, the SBID would have generated an alert for any discrepancy from the norm, so there would have been an alert produced when the paper landed on the driveway. If set it too high, an alert would be created only when the paper broke through the window (and maybe not even then). Optimally, a report will be generated on all significant anomalous activity. What constitutes āsignificantā can and will vary from user to user. Therefore, it is ultimately up to the user to decide how many alerts are generated for a specific environment. The particular environment is crucial to the proper functioning of a SBIDS. The SBIDS will ālearnā what is ānormalā for a network. Each Statistical-Based IDS in every individual environment will alert to discrepancies based on its specific knowledge of the network at hand. The benefit of this approach is that the system does not have to have predefined signatures to identify an anomaly on the network; instead, the IDS is free to flag anything it deems unusual. For example, H4x0r has a brand new exploit she wants to use on the network. She launches the attack knowing that there is no signature for this exploit because the vulnerability was found recently. If one of the systems is exploitable by the attack, it will be compromised and no alert will be generated because a Signature-Based IDS will not recognize this new attack (signature). If, on the other hand, there is a Statistical-Based IDS in addition to the current Signature-Based IDS, the results of the attack would differ greatly. The SBIDS would see the packets and may recognize that the properties were inconsistent with the traffic that usually traverses the network. Following this detection, the Statistical-Based system would compute a high score for the packets in the attackers packet stream (like the newspaper breaking through the window), which would lead to an alert generation. While notification of an attack on the systems is a highly desirable feature for an IDS, so too is the detection of an enemy trying to enumerate the network through portscanning.
A SBIDS can provide a more accurate notification of portscanning activities. Portscan detection is a byproduct of the methods in which SBIDS gather data, due to the fact that the scan will be anomalous. At least some of the portscan is likely to be highly anomalous traffic relative to the usual traffic distribution. If this packet has unusual features (i.e. is a crafted packet), this will be still more true . With this in mind, even the portscans that are distributed over a lengthy time frame will be recorded because they will be inherently anomalous. SBIDS give us the ability to detect portscanning packets with much greater accuracy than the āX packets in a Y-sized time frameā method that RBIDS must rely on. The problem with the Statistical-Based system is not the detection of the portscan packets; they will be identified, as any other anomalous activity on the network will be. The problems lie in the dissemination and correlation of the data once it is collected. Correlation is beyond the scope of this document but Silicon Defense is currently developing a correlation engine called Spice. Refer to the Silicon Defense web site for more information.
While there are many advantages to the Statistical-Based approach, there are also some shortcomings with this technology. To begin, a Statistical system must ālearnā what is ānormalā traffic for a particular network (SBIDS need a good baseline of network traffic). Unlike a Signature-Based system, which has the benefit of being implemented and immediately utilized, the Statistical-Based systems must initially adapt to the network at hand. The longer a SBIDS is placed on a specific network, the more accurate the results will be (assuming the network traffic doesnāt significantly alter in form). The second issue with the Statistical-Based approach is related to the adaptive nature of the systems. SBIDS detect anomalies based on discrepancies in ānormalā network traffic. If the ānormalā network traffic is malicious, the SBIDS will be rendered useless. For example, if the SBIDS sees a numerous number of SYN scans on a network over a period of time the system will eventually assume that this is normal behavior and cease to alert on the activity. This example, while drastic, is a possible scenario. Finally, the alerts that a SBIDS will generate will be relatively difficult to assess compared to a Signature-Based system. The alerts will simply be packet information with no immediately obvious reason for the alert. This analysis will require the services of a trained security professional with the ability to identify abnormalities in traffic at the packet level. Although Statistical-Based systems have some deficiencies, the positive effects of this technology far outweigh the growing pains that will be experienced upon implementation.
The benefits of the statistical-based approach are threefold. Not only do we now have notification for previously unknown attacks, we also have a system that doesnāt need constant signature updates, and we have a method to detect port scans that span extensive timeframes as well.The Statistical Packet Anomaly Detection Engine: Spade
Spade is an anomaly detector publicly released under GNU GPL . It can be downloaded from http://ww.silicondefense.com/software/spice/. Spade is a Snort  preprocessor plug-in. Spade uses joint probability measurements to decide which packets are anomalous. Spade uses Snortās input/output facilities to grab packets and put them into tables, which are used to determine an anomaly score . The anomaly score is assigned by evaluating the source IP, source port, destination IP, and destination port, among others. Based on the user specified threshold level, Spade will either flag the packet or allow it to pass through the network without notification. The threshold setting is critical in Spade because if it is set too high, the user will miss critical packets; if it is too low, the analyst will see many false-positives. Spade also has an option that will perform automatic threshold adjustment to let Spade decide what the critical threshold number should be. Spade can also generate other reports of importance such as a survey about the distribution of anomaly scores and various reports about the feature statistics such as entropy and conditional probabilities. For more specifics on how Spade calculates anomaly scores, threshold numbers, and probabilities, refer to the documentation present on the Silicon Defense web site .
The most critical output for the security analyst
will be the Spade alerts, which look very similar to the Snort alerts.
The list below is comprised of four Spade-generated alerts.
Review the Snort documentation  for specifics on how to read these alerts.