Monitoring Policies

One unresolved issue is the difference between the preventative security policy you define and the need for a separate monitoring policy. When you configure an IDS, you can decide which events to monitor and how to respond to them. Unfortunately, you cannot make broad statements such as the following:

P1: Alert me anytime someone reads a file that they should not be accessing.

The monitoring policy needs to be more specific, such as the following:

P2: Alert me anytime someone reads a file for which they do not have explicit read access.

Huh? How can someone read a file if they are not explicitly given read permission? The answer lies in that recurring them on behalf of semantics. A user with UID=231 can access a file by running a program that has enough privileges to read the file on behalf of the user. In UNIX this is accomplished via the SUID and SGID bit settings. In NT escalating privileges to SYSTEM or Administrator accomplishes a similar goal.

No good mechanism exists today for specifying a single security policy that different products will read and enforce or monitor. One reason is that no particular vendor provides both a comprehensive preventative tool and an equally strong monitoring tool. If this mechanism were available today, the vendor would immediately realize how much trouble it is to define both a prevention policy and a monitoring policy. Stated somewhat differently, defining a series of access control rules in one product and then configuring events to monitor in another is a problem that only the enduser faces today. Having a single tool in which to enter a comprehensive policy would be useful, even if the prevention and monitoring policies are not identical.

Simple or Complex Attacks

By far the largest number of attacks detected by IDSs involve a single event. Examples include the following:

•  A nonprivileged user changes a privileged program by writing to its location on disk.

•  A nonprivileged user reads a privileged file.

•  A program deletes too many files in successive operations.

•  Someone creates a filename with special characters.

•  A privileged user runs a program whose full path name is incorrect, such as /home/joe/ls instead of /bin/ls.

•  A spoofed IP address packet.

After this initial category are thresholds of events:

•  N failed login attempts

•  Port scanning from the same source IP address

•  Resource flooding, such as sending too many ping packets

Sequences of events form the next level of difficulty in detecting an intruder:

•  A normal user executing a privileged program, which in turn forks a root shell on a UNIX system (likely evidence of a buffer overflow attack)

•  Three failed attempts to su to root followed by success (evidence of a guessed password)

If you take the set of attacks defined by a single event and you combine them with each event separated by an OR, you have one large IDS pattern. If you take some single events, like failed login, then combine them with an AND, you have sequences and thresholds. Taking single events and joining them into graphs with many AND and OR operators leads to the next category. Activities represented as complex graphs, possibly requiring metadata, constitute the most difficult category of attacks. An example in this category would be failed login thresholds successively exceeded for each user, with events in the same order as the users listed in the password file or registry. The metadata used in the pattern is knowledge about the order of entries in the password file. The sequence of events is a series of failed logins. If the sequence is followed by a successful login, an intrusion definitely occurred.

Prepare to Scan for Weaknesses

In this chapter you have seen how some intruder events are detected easily, and how others are more complicated to uncover. The focus of a particular IDS can be at the network level, system level, or application level. As the IDS industry matures, products are beginning to look for problems at all three levels.

Regardless of the focus of a product, some data source must be relied upon for catching intruders. The choice of datastream, a technique for capturing data, and the method of analysis all impact the types of problems that the IDS can find. Also affected by IDS design choices are whether the event is captured in real time, detected after the fact, and assigned to the appropriate UID if possible. Tracking hackers across multiple systems was shown to present special challenges, particularly for accountability.

In the next chapter, you will learn about specific attacks against your systems and how you can deploy a vulnerability scanner to start looking for holes before they are exploited.