Previous | Table of Contents | Next |
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:
The monitoring policy needs to be more specific, such as the following:
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.
By far the largest number of attacks detected by IDSs involve a single event. Examples include the following:
After this initial category are thresholds of events:
Sequences of events form the next level of difficulty in detecting an intruder:
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.
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.
Previous | Table of Contents | Next |