One way vendors enter a market is by showing product differentiation. Although each IDS may have unique characteristics that provide value beyond other tools at a site, the net impact on the customer is that many products are needed rather than one. Some IDS builders focus on network intrusions; others focus on system intrusions; some provide real-time analysis; and others concentrate on periodic assessments. Having all of these options in a single tool suite would be beneficial to the marketplace. The consolidation of IDS vendors into larger security companies appears to be the way to achieve this goal.

An important issue to consider with respect to the data source chosen by an IDS product is whether this information is already being captured at your site. If you are not currently running the audit subsystems of UNIX or NT systems, adding this overhead will have to be considered if the IDS product you choose requires this as a data source. On the other hand, if you truly want to assign accountability and know details of system activities, auditing is the best way to get this information.

Network data sources are less problematic because the traffic is already available for analyzing. A network IDS does not introduce a new data source, nor does it alter any existing data sources. One problem you will have is trying to analyze encrypted network traffic. If two sites are protected by an IP tunnel, the network IDS must be placed at the point in the network where the traffic is decrypted. Unfortunately, if applications at your site have employed application-level encryption, a network IDS cannot examine these packets because they are not decrypted until they reach the application layer.

If you adhere to the belief that much of the network traffic in the future will be application specific and encrypted for each application, you should wonder about the long-term role of the network IDS. The services provided by network IDSs will still be needed; it’s just that they might be embedded in other components of the system, such as in the application decryption routines in which the packets finally appear in the clear.

The choice of data source also affects what the IDS can discover. Recall from the discussion on firewalls that access control in network traffic is affected by the type of firewall. Network packet filters operate on packet concepts such as IP address and port numbers. Application gateway firewalls can form access control rules that contain application-specific information such as specific URLs for a Web proxy. The same arguments apply to intrusion detection data sources.

Information about failed logins, failed file accesses, planted Trojan Horses, and other system events can be found easily in the audit logs. However, system audit logs contain limited information about network activities. Attacks such as Ping of Death and SYN Flood are not surfaced in the audit trail. Instead, these attacks must be detected at the IP layer itself by the operating system, a firewall, or a separately attached network IDS. Conversely, information about buffer overflow attacks and higher level system abstractions (UID, GID, file, and printer) does appear in the audit trail. This same information is not readily available when you are sniffing network packets.

Therefore, a system-level IDS can detect intrusions that a network-level IDS cannot and vice versa.

Needless to say, any application-level abstractions are meaningful only to the application itself. For a network sniffer to be able to watch packets and detect application-specific attacks, the sniffer must contain at least enough of the application knowledge to be able to extract meaning out of the packets. In a trivial sense, this practice would require that the sniffer have the capability to combine various packets destined for the application into meaningful groups, which is precisely what a good deal of the application code itself does. Another way to phrase this is to say that the network IDS must have a substantial portion of the application knowledge to catch application-level attacks.

RealSecure from ISS detects some application attacks by sniffing network packets. For example, it detects the rlogin -froot AIX bug, and rlogin is certainly an application. The right architecture in the long run is for the applications to invoke IDS service routines in order to make their own decisions about intrusive behaviors. Another argument for this architecture is the increasing use of application-level encryption. Only the application itself ever sees the data in the clear.

A Generic IDS Model

Dorothy Denning (1987) introduced a generic intrusion detection model that is shown in Figure 5.6. The model is widely applicable to intrusion detection systems today. The three main components are the Event Generator, the Activity Profile, and the Rule Set. Early intrusion-detection systems often relied on expert system techniques and consequently the idea of a rule base appears in the generic model.

Figure 5.6  A generic intrusion detection model.

In order to make decisions about whether security problems exist, some form of instrumentation must be provided by the system(s) being monitored. The Event Generator is the component of the model that provides information about system activities. Events are derived from system audit trails, from network traffic, or from application-specific subsystems such as firewalls or authentication servers. Sometimes in the literature, an event is defined as a higher level abstraction than a primitive such as this file was opened. In other words, a series of audit records from the operating system might be combined into a single notable event.

The Rule Set is best thought of as the inference engine that decides whether an intrusion has occurred. Rule-based expert systems frequently were the preferred inferencing tool for early IDSs. However, Denning’s model allows for statistical approaches as well. The best way to think of the Rule Set is as a generic detector engine examining events and state data using models, rules, patterns, and statistics to flag intrusive behavior.

The Activity Profile maintains the state of the system or network being monitored. As events appear from the data source, variables in the Activity Profile are updated. New variables might be created as well depending on the actions dictated by the Rule Set.