Sebery J.Cryptography.An introduction to computer security.1989

Fig. 14.5. The Network Security Monitor

14.7 Network Intrusion Detection Systems

NetworkIDSs are intrusion detection systems that work on the basis of monitoring traÆc within a network segment. In contrast to hostIDSs that monitor and detect intrusions within a host, networkIDSs observe raw network traÆc and detect intrusions from that traÆc information. Unlike hostIDSs that are, in e ect, insulated from the low-level network events, networkIDSs can correlate attacks occurring against multiple machines within the monitored network segment. Typically, networkIDSs passively monitors the network, copying packets as they pass-by regardless of the packet's destination.

One major advantage of networkIDSs that carry-out passive protocol analysis is that the action of monitoring occurs at the lowest levels of a network's operation, thereby they are both unobtrusive and diÆcult to evade. In fact, unless an external attacker uses other means to nd out the existence of a networkIDS, typically the attacker will be unaware of the networkIDS.

14.7.1 NSM

The Network Security Monitor (NSM) was developed at University of California, Davis and performs traÆc analysis on a broadcast LAN in order to detect unusual behavior and traÆc patterns, and therefore detect possible intrusions (Figure 14.5). In contrast to host-based intrusion detection systems running on a host and consuming its resources, NSM runs independently of the host being monitored in the LAN. These monitored hosts are in fact unaware of the passive monitoring behavior of NSM. Hence, intruders will also be unaware of the traÆc monitoring that is occurring.

482 14 INTRUSION DETECTION

NSM is based on the Interconnected Computing Environment Model (ICEM) [361], which consists of six layers arranged in a hierarchic fashion. These layers (bottom to top), with one layer providing input for the next layer above it, are:

{Packet layer { accepts bit-stream input from the broadcast LAN, divides input into complete packets and attaches a timestamp to each packet.

{Thread layer { accepts time-augmented packets and correlates them into unidirectional data streams. Each stream represents data transferred from one host to another using a particular protocol (e.g. TCP/IP or UDP/IP) through a given port. The stream or thread is then mapped to a threadvector.

{Connection layer { attempts to pair one thread with another to represent a bidirectional stream or host-to-host connection. The pairs are then represented by a connection vector consisting of combinations of thread vectors. After the connection vectors are analyzed, their reduced representation is passed up to the next layer.

{Host layer { builds a host-vector from the reduced connection vector, representing the network activities of a host.

{Connected-network layer { creates a graph from the host vectors representing the various connections between hosts in the network. Subgraphs (or connected network vector) can be generated and compared against historical connected subgraphs. Here, the user can begin to query the system about the resulting graph (e.g. existence of path between two hosts through intermediate hosts).

{System layer { creates a single system vector from the collection of connected network vectors, representing the entire network.

The host vectors and connected network vectors are used as the rst type of input to an expert system within NSM. The components of these vectors that are of interest to the expert system are host ID, host address, security state (an evaluation value of a given host), number of data paths to a host, and the data path tuples. A tuple has four elements representing a data path to/from a host (other-host address, service ID, initiator tag, and security state).

The second type of input is the expected traÆc pro le, which is the expected data paths (or connections) between hosts and a corresponding service pro le (that is, the expected behavior things such as telnet, mail, nger, and others). The next type of input is a representation of the knowledge of the system regarding the capabilities of the services (for example, a telnet service has more

capabilities than ftp). The fourth input is the level of authentication needed for each service. The fth is the level of security for each of the machines in the host (based, for example, on the ratings by the National Computer Security Center (NCSC)). The last input to the expert system is the signatures of past attacks to hosts.

NSM employs the notion of the security state that represents the \suspicion level" associated with particular network connection. When deciding on the security state for a connection, four factors are taken into consideration:

1.Abnormality• of a connection { refers to the probability of the connection occurring (i.e. often or rare) and the behavior (i.e. traÆc volume). This is established by comparing against the pro le for that connection. Thus, for example, if a connection is rare and traÆc is unusually high in one direction, then the abnormality of the connection is high.

2.Security• level used for the connection { is based on the capabilities of the service and the authentication typically required for that service. For example, TFTP (high capability, no authentication) is given a high security level. Telnet (high capability, requires authentication) has lower security level than TFTP.

3.Direction• of connection sensitivity level { is based on the sensitivity level of the connected hosts and which host initiated the connection. For example, if a low-level host attempts to connect to a high-level host, then the direction of connection sensitivity is high.

4.Matched• signatures of previous attacks.

NSM has been used with interesting results. During a two-month period at UC Davis, NSM analyzed over 110,000 connections. Within these, NSM correctly detected 300 intrusions, whereas only 1 percent of the intrusions were detected independently by the system administrators.

14.7.2 DIDS

The Distributed Intrusion Detection System (DIDS) [483, 484] is a project representing an extension of the NSM, with the aim of adding two features missing from NSM. These are the ability to monitor the behavior of a user who is connected directly to the network using a dial-up line (and who therefore may not generate observable network traÆc), and the ability to allow intrusion

484 14 INTRUSION DETECTION

Fig. 14.6. The Distributed Intrusion Detection System (DIDS)

detection over encrypted data traÆc. The DIDS project is sponsored by UC Davis, the Lawrence Livermore National Labs (LLNL), Haystack Laboratory, and the US Air Force.

The architecture of DIDS consists of three components (Figure 14.6), namely Host Monitors, the LAN Monitor, and the DIDS Director. Each host in the monitored domain runs the Host Monitor, scanning their individual audit trails for suspicious events and other events relevant to the network (e.g. rlogin and rsh attempts). The data from these Hosts Monitors augment the data received from the LAN Monitor, which are the reported to the DIDS Director. The LAN Monitor is used for each broadcast LAN segment. The DIDS Director contains an expert system that analyzes all incoming data related to the monitored domain.

DIDS allows the tracking of users who move around within the domain. It does so by introducing a network-user identi cation (NID) for all users within the network. This tracking, however, can only be done when users move across monitored hosts. The issue of movements to unmonitored hosts was not addressed by DIDS.

The Host Monitor has two main components, namely, the host event generator and the host agent. The host event generator collects audit records from the host operating system, and scans them for notable or unusual events. These are forwarded to the Director. The host agent is responsible for all communications between the Host Monitor and the Director. The LAN Monitor also has a LAN event generator (currently a subset of NSM) and a LAN agent. The LAN monitor observes all traÆc on a given LAN segment, noting network related events,

such as host connections, traÆc volumes and services invoked over the network. The DIDS Director has three components on a single dedicated workstation, namely, an expert system, a communications manager and a user interface for the security oÆcer. The communications manager handles all communications with the Host Monitors and the LAN Monitor. The Director may in fact request more data from these monitors through the communications manager.

14.7.3 NADIR

The Network Anomaly Detector and Intrusion Reporter (NADIR) [245] is a system for network intrusion detection developed and tailored for the Integrated Computing Network (ICN) at the Los Alamos National Laboratory (LANL). NADIR employs an expert system that analyzes audit data as a supplementary method to the manual audit done by the security oÆcer. From the network audit records, it generates weekly summaries of the activities of the network and of individual users.

NADIR is tailored for the compartmentalized or \multilevel" arrangement of security classi cations in the ICN network. Following the Bell La Padula model [21], a computer system may only access computer systems within the same compartment or partition, and those at a lower-classi ed compartment (the \read-down" rule of the model). The compartments are linked by a collection of dedicated service nodes that carry out many security-related tasks (e.g. access control, le access, le storage, le movements).

Each user account is associated with a value called the level of interest, which indicates the current level of suspicion regarding that account being compromized by an intruder. The weekly summary is generated from data that includes the user's activities. The parameters reported include the host compartment or partition, the host ICN machine number, the destination partition, the destination host classi cation level, and others. NADIR has a graphical interface, which highlights the suspicious activities and users, bringing them to the security oÆcer's attention.

14.7.4 Cooperating Security Manager (CSM)

Another e ort towards developing network intrusion detection is the Cooperating Security Manager (CSM) system developed at the Texas A&M University

486 14 INTRUSION DETECTION

Command

Admin

Monitor

Interface

Intruder

Handler

Fig. 14.7. Cooperating Security Manager (CSM)

[527]. One of the primary goals of the CSM project was to move away from the centralized intrusion detection system (as in DIDS). Instead, each host would run the CSM and together the hosts would set up a mesh of intrusion detection system that share information in a cooperative manner. Hence, intrusion detection would be achieved in a distributed manner.

The distributed nature of the intrusion detection makes the e ort scalable (as compared to the centralized approach). For the distributed intrusion detection to work, however, each of the hosts in the networked environment must be running CSM. When a user at a host in the network connects to another host (both running CSM) the CSM at both hosts would cooperate in monitoring the user's behavior. Hence, if an attacker decides to use one host as a platform for further attacks in a hop-by-hop fashion, the CSMs on the linked hosts would work together to detect the intruder.

The basic components of the CSM is shown in Figure 14.7. The Command Monitor captures the user's input and passes them to the Local IDS that has the task of detection intrusion for that host. Network-related activities are reported to the Security Manager that communicates with other CSMs at other hosts. In e ect, the Security Managers coordinate the distributed interaction among the CSMs. When a host communicates to another host, all the user actions at the rst host are considered to be occurring in parallel at the second host. Thus, intrusion detection processes occur on both hosts. If a user is connected over several hosts in a chain and one of the CSM in that chain determines that

an intrusion activity is occurring, that CSM will notify all other CSMs along the chain. The Administrative Interface is used by the security oÆcer to query the CSM about the security status of the current host, and to further query a (suspect) user's origin and trails. A level of suspicion can be requested for a given user.

Again, for the concept to succeed all the hosts within the network must run the CSM. It is unclear how the concept of the CSM can be implemented in the near future where not all hosts run the CSM and where the origin (or destination) of a connection to or from a CSM-based host does not itself run the CSM. That is, the issue of the interaction at the boundary of a CSMbase network and a non-CSM network remains to be seen.

14.8 Limitations of Current Intrusion Detection Systems

Although a number of research prototypes and commercial IDSs have been developed, in general, there are some aspects of IDSs that need to be addressed.

14.8.1 General Limitations

{Lack of generic development methodology { Current costs for developing IDSs are substantial, due to the lack of a structured methodology to develop such systems. Although there is a growing body of knowledge about IDSs, not many structuring insights have emerged (at least within the public literature). This may be due the fact that the eld of IDSs is still relatively young, that it is an area that borders on several elds (e.g. arti cial intelligence, operating systems, networking), and that there is a lack of agreement on the suitable techniques for intrusion detection.

{EÆciency { Some IDSs have attempted to detect every conceivable intrusion, which in many circumstances is impractical. Thus, in reality expensive computations, such as that for anomaly detection, need not be done for every event. Some systems employ an expert system shell that encodes and matches cases or attack signatures. Unfortunately, these shells typically interpret their rule set, and thus present a substantial runtime overhead.

{Portability { Many IDSs are developed for a particular target environment, often in ad hoc and custom-design fashion. This is largely true because many of the systems are dependent on OS-speci c functions and therefore tailor

488 14 INTRUSION DETECTION

their detection to that OS. Reuse of an IDS for a di erent environment is diÆcult to perform, unless the system was designed in a generic manner (in which case it would probably be ineÆcient and have limited capabilities).

{Upgradability { Retro tting an existing IDS with newer and improved detection techniques requires a considerable e ort in reimplementation. This aspect is related to the lack of development methodology for IDSs.

{Maintainability { Maintaining an IDS typically requires skills in elds other than security. Often modifying or upgrading the rule set requires specialized knowledge about expert systems, the rule language and some familiarity with how the system manipulates the rules. Such expertise is necessary in order to prevent the added rules from creating undesirable interactions with the rules already present. Similarly, modi cation of the statistical metrics within the statistical component of the IDS requires equal expertise. This aspect, unfortunately, is diÆcult to address due to the inherent complexity of AIbased systems.

{Benchmarking { Hardly any data on IDS benchmarks exist in the literature, and very little data on the performance of IDSs for a realistic set of vulnerability data and operating environment have been published. Similarly, little coverage data exists about any system. Such coverage data reports the percentage of intrusions detected by an IDS in a real environment. This aspect is diÆcult to solve due to the inherent diÆculty in accurately verifying the types of frequencies of intrusions in large environments. Related to this issue is the diÆculty of testing IDSs using a developed set of attack scenarios.

14.8.2 Network-IDS Shortcomings

One major drawback of network-IDSs is their lack of ability in knowing (or determining) the events within a computer system that results from that system receiving a message or packet. That is, although a network-IDS observes (and copies) a packet destined to a particular computer system, there is no direct way for the network-IDS to discover whether the packet was accepted (or rejected), and if accepted, what reaction it had on the recipient computer system.

When an attacker (internal or external) is aware that an IDS is monitoring his or her activities, the IDS itself can instead become the main target of attack. In the case of a network-IDS, an intelligent attacker will realize that, although he or she may not be able to directly attack the network-IDS to disable it, he

or she may still have the ability to cheat or mislead the detection system within the network-IDS. Assuming that an internal attacker has a valid account on the machines in the network (e.g. malicious valid user or external attacker who has created an undiscovered account), the attacker can send dummy traÆc to himself/herself through a valid session. In this manner, the detection system may gradually modify its rule set (if it is dynamic), e ectively being cheated by the internal attacker.

There are two main shortcomings of network-IDS [418, 399]:

{Lack of information { Typically a network-IDS is a separate machine from those that it monitors. Through passive monitoring, the network-IDS aims to predict the behavior of the networked machines using protocol analysis and its rule-set. Although the network-IDS obtains a copy of every packet sent to a machine, it does so at a slightly di erent time frame and it is never sure of how that packet was treated by the machine. Hence, a discrepancy can occur between the detection system and the machines it monitors. As an example, consider an IP packet with a bad UDP checksum. Although most machines will reject this packet, some may ignore the bad checksum and accept the packet. The network-IDS must be able to know whether each machine will accept/reject the packet.

{Denial of service { Denial-of-service attacks are aimed at reducing the level of availability of a computer system, and if possible to disable the system (i.e. system crash). When discussing the failure of a security system, the issue of the mode (fail-open or fail-closed) of the system after it fails becomes important. In fail-open, the disabled system ceases to provide any protection, while in fail-closed the disabled system leaves the environment still protected. Clearly, a good network-IDS must be fail-closed. As an analogy, consider therewall. A fail-open rewall that crashes will leave the network available, and thus will leave it open to attacks. From a security perspective, a good rewall must be fail-closed, closing the entire network when it crashes.

There are a variety of possible attacks that can result in the detection system of a network-IDS becoming misled. When an attacker can exploit the use of dummy packets, which the valid destination rejects (but which the network-IDS thinks it accepted), the attacker can e ectively insert data into the network-IDS. This problem is due to the network-IDS being less strict than the destination system in its packet processing. To solve this problem, the network-IDS can be

490 14 INTRUSION DETECTION

tuned to be maximally strict. This approach, however, may lead to the opposite situation where a packet accepted by the destination system is rejected by the network-IDS, leading to an evasion attack.

14.9 The Common Intrusion Detection Framework (CIDF)

The Common Intrusion Detection Framework (CIDF) is a recent standardisation e ort, which began in early 1997 among all the DARPA-funded intrusion detection projects. The idea of a common framework arose when a desire arose on the part of DARPA to make all the intrusion detection systems that it was funding to inter-operate, and to make the bene ts arising from these projects therefore more useful and accessible to the wider community.

Although initially con ned within these DARPA projects, in April 1998 the work of the CIDF community was put forward to the IETF (LA Meeting) with the aim of creating an IETF working group on CIDF. As mentioned in the CIDF speci cation document, the goal of the CIDF speci cation is twofold [222]:

1.The speci cation should allow di erent IDSs to inter-operate and share information as richly as possible.

2.The speci cation should allow components of IDSs to be easily reused in the context di erent from those they were designed for.

All CIDF components deal in GIDOs (Generalised Intrusion Detection Objects) that are represented via a standard common format. GIDOs are data that is moved around in the intrusion detection system. GIDOs can represent events that occurred in the system, analysis of those events, prescriptions to be carried out, or queries about events.

The CIDF speci cation covers a number of issues related to the creation of a framework:

{A set of architectural conventions for how di erent parts of IDSs can be modeled as CIDF components.

{A way to represent GIDOs, where GIDOs can

{describe events that occurred in the system,

{instruct an IDS to carry out some action,

{query an IDS as to what has occurred,

{describe an IDS component.