Intrusion Detection

Many intrusion detection systems base their operations on analysis of OS audit trails. This data forms a footprint of system usage over time. It is a convenient source of data and is readily available on most systems. From these observations, the IDS will compute metrics about the system's overall state, and decide whether an intrusion is currently occurring.

An IDS may also perform its own system monitoring. It may keep aggregate statistics which give a system usage profile. These statistics can be derived from a variety of sources such as CPU usage, disk I/O, memory usage, activities by users, number of attempted logins, etc. These statistics must be continually updated to reflect the current system state. They are correlated with an internal model which will allow the IDS to determine if a series of actions constitute a potential intrusion. This model may describe a set of intrusion scenarios or possibly encode the profile of a clean system.

Characteristics of a Good Intrusion Detection System

An intrusion detection system should address the following issues, regardless of what mechanism it is based on:

1. It must run continually without human supervision. The system must be reliable enough to allow it to run in the background of the system being observed. However, it should not be a "black box". That is, its internal workings should be examinable from outside.
2. It must be fault tolerant in the sense that it must survive a system crash and not have its knowledge-base rebuilt at restart.
3. On a similar note to above, it must resist subversion. The system can monitor itself to ensure that it has not been subverted.
4. It must impose minimal overhead on the system. A system that slows a computer to a crawl will simply not be used.
5. It must observe deviations from normal behavior.
6. It must be easily tailored to the system in question. Every system has a different usage pattern, and the defense mechanism should adapt easily to these patterns.
7. It must cope with changing system behavior over time as new applications are being added. The system profile will change over time, and the IDS must be able to adapt.
8. Finally, it must be difficult to fool.

The last point raises an issue about the type of errors likely to occur in the system. These can be neatly categorized as either false positive, false negative, or subversion errors. A false positive occurs when the system classifies an action as anomalous (a possible intrusion) when it is a legitimate action. A false negative occurs when an actual intrusive action has occurred but the system allows it to pass as non-intrusive behavior. A subversion error occurs when an intruder modifies the operation of the intrusion detector to force false negatives to occur.

False positive errors will lead users of the intrusion detection system to ignore its output, as it will classify legitimate actions as intrusions. The occurrences of this type of error should be minimized (it may not be possible to completely eliminate them) so as to provide useful information to the operators. If too many false positives are generated, the operators will come to ignore the output of the system over time, which may lead to an actual intrusion being detected but ignored by the users.

A false negative error occurs when an action proceeds even though it is an intrusion. False negative errors are more serious than false positive errors because they give a misleading sense of security. By allowing all actions to proceed, a suspicious action will not be brought to the attention of the operator. The intrusion detection system is now a liability as the security of the system is less than it was before the intrusion detector was installed.

Subversion errors are more complex and tie in with false negative errors. An intruder could use knowledge about the internals of an intrusion detection system to alter its operation, possibly allowing anomalous behavior to proceed. The intruder could then violate the system's operational security constraints. This may be discovered by a human operator examining the logs from the intrusion detector, but it would appear that the intrusion detection system still seems to be working correctly.

Another form of subversion error is fooling the system over time. As the detection system is observing behavior on the system over time, it may be possible to carry out operations each of which when taken individually pose no threat, but taken as an aggregate form a threat to system integrity. How would this happen? As mentioned previously, the detection system is continually updating its notion of normal system usage. As time goes by a change in system usage patterns is expected, and the detection system must cope with this. But if an intruder could perform actions over time which were just slightly outside of normal system usage, then it is possible that the actions could be accepted as legitimate where as they really form part of an intrusion attempt. The detection system would have come to accept each of the individual actions as slightly suspicious, but not a threat to the system. What it would not realize is that the combination of these actions would form a serious threat to the system.

Intrusion Classification

Start

Intrusion Detection Systems