10.6 Intrusion Detection Systems

As the threats of hacker attacks and other type of break-ins increase in complexity and number, new software tools and services for analyzing networks attacks, known as IDSs, are being developed. These security programs and services are capable of investigating network traffic in order to recognize suspects, irregular patterns, and possible attacks. IDSs are automated applications designed to monitor systems and networks, providing alerts when a suspected unauthorized event occurs.

An IDS will typically work with the audit records of operating system calls, including such data as the following:

A resource, which draws data from the CPU, memory, I/O, etc.
A subject, which identifies a user, a session, or a location
An object, which identifies what the subject acted upon
An action, which identifies the action attempted
A timestamp or an error code

The most common way to detect intrusions is using the audit data generated by the operating system. An audit trail is a record of activities on a system that are logged to a file in a chronologically sorted order. Since almost all activities are logged on a system, it is possible that a manual inspection of these logs can allow intrusions to be detected. However, the incredibly large size of audit data generated make manual analysis impossible. IDSs automate the drudgery of wading through these log files. Audit trails are particularly useful because they can be used to establish the guilt of perpetrators for prosecution, and they are often the only way to detect unauthorized, but subversive, user activity. As such, IDSs can increasingly be used as forensic tools for prosecution purposes, documenting the break-in and trail taken by cyberper-petrators.

An IDS attempts to detect both an intruder breaking into a system and a legitimate user misusing system resources. A key advantage of an IDS is that it runs constantly, working away in the background, only notifying the administrator in real-time when it detects something it considers suspicious or illegal. Most IDSs only take preventive measures when an attack is detected and leave it up to the human administrator to determine the course of action after an alert is issued. Some IDSs base their operations on analysis of these operating system 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 subsequently compute metrics about the system's overall state and decide whether an intrusion is currently occurring or a system has been jeopardized.

The IDS may also perform its own system monitoring and keep aggregate statistics about 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, or number of attempted logins. These statistics must be updated continually to reflect the current system state. They may be correlated with an internal model that will allow the IDS to determine if a series of actions constitutes a potential intrusion. This model may describe a set of intrusion scenarios or possibly encode the profile of a clean system. Ideally, an IDS should address the following issues, regardless of what mechanism it is based on:

It must cope with changing system behavior and configuration as new applications and users are added; the IDS must be able to adapt.
It must impose minimal overhead on the system without slowing the network.
It must resist subversion; the system must be able to monitor itself to ensure that it has not been compromised.
It must be fault-tolerant, able to survive a system crash without loosing its content at restart.
It must be difficult to fool; some inherent intelligence must be designed into the IDS.
It must run continually in the background of the system being observed.
It must be easily customized to a system and its usage patterns.
It must observe deviations from normal behavior.

As with all classification problems, an IDS is subject to system errors. These can be 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 in fact it is a legitimate action. A false negative occurs when an actual intrusive action has occurred but the system allows it to pass as nonintrusive behavior. A subversion error occurs when an intruder modifies the operation of the intrusion detector to force false negatives to occur.

As with the problem encountered in the previous chapter involving fraud detection, if too many false positives are generated by an IDS, the administrator will come to ignore the output of the system over time, which may lead to an actual intrusion being detected, but ignored. 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. Subversion errors are more complex and tie in with false-negative errors. An intruder could use his or her knowledge about the internals of an IDS to alter its operation, possibly allowing anomalous behavior to proceed. The intruder could then violate the system's operational security constraints, but it would appear that the intrusion detection system was still working correctly.

Another form of subversion error is fooling the system over time. As mentioned previously, an IDS is continually updating its usage patterns profiles. 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, although they really formed 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. It would not realize that the combination of these actions was a planned to mask an attack of the system.