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

So if " > 0, the event E2 = 0 con rms the anti-hypothesis I and the event E2 = 1 is consistent with the hypothesis I. Knowing a sequence of observations (E2; E3; : : : ; En), we can compute the corresponding odds to see whether or not they con rm or contradict the hypothesis I.

14.4.2 Dempster-Shafer Theory

The theory is a generalization of the probability theory. Dempster [133] laid the foundations and Shafer [464] later generalized it so it can be used for evaluation of uncertainty. The theory is especially applicable for intrusion detection using expert systems [309].

Let = fe1; : : : ; eng be a set of elements. All elements ei are disjoint for i = 1; : : : ; n. Given a function

m : 2 ! [0; 1]

such that m(;) = 0 and P! m(!) = 1. The function m is called basic probability assignment or mass distribution. From an IDS point of view, the collectioncan be seen as the set of all elementary events (also called hypothesis). The

lower bound on the con dence in ! while the plausibility function determines the upper bound.

472 14 INTRUSION DETECTION

Consider two Bel(!) and P l(!). If we de ne the complement of ! as ! =n !, then it is easy to show that

P l(!) = 1 Bel(!):

In other words, Bel(!) = 1 P l(!) measures the amount of evidence against the hypothesis (event) ! while Bel(!) evaluates evidence in favour of !. There are the following possible cases:

1.P l(!) Bel(!) = 1. This means that P l(!) = 1 and Bel(!) = 0 or in other words, all events for which ! is a superset never happen and for the rest of events, ! is a proper subset. So every single observation contains ! as the constant. It is impossible to say anything about ! itself. There is no evidence against and for !.

2.P l(!) = 0 (this implies that Bel(!) = 0). Any event that intersects ! never happens. The hypothesis (event) is false.

3.Bel(!) = 1 (this implies that P l(!) = 1). Any event must be a subset of !. The hypothesis (event) is true.

4. P l(!) = "1 and Bel(!) = "2 ("1 > "2 and "1; "2 2 [0; 1]). There is an evidence in favor of ! (Bel(!) = "2) and there is an evidence against ! (Bel(!) = 1 "1).

Observe that in the probability theory always P (!) = 1 P(!). In the Dempster-Shafer theory this could be translated into the requirement that

P l(!) = Bel(!).

The center piece of the theory is the Dempster rule of combination. Let be the set of elementary events and m1; m2 be two basic probability assignments.

Fig. 14.1. Generic intrusion detection model

Then the combined probability assignment is a function m1 m2 : 2 ! [0; 1] such that

P \ =! m1( )m2( ) P \ 6=; m1( )m2( )

for all ! 6= ;. Brie y, the rule allows to construct a combined probability assignment from two pieces of evidence (two basic probability assignments).

The more \relaxed" setting that allows us to measure somewhat independently, evidence against and for a hypothesis, provides a convenient tool for IDS systems based on expert systems. For more information on the DempsterShafer theory and its applicability to reasoning in the presence of uncertainty, the reader is referred to [309].

14.5 Generic Intrusion Detection Model

One of the earliest proposals of using audit trails and system logs for intrusion detection was presented in [137] in the form of an intrusion detection model. Although dated, the model is still valuable since it is accurate in describing the architecture of many current IDSs (Figure 14.1).

474 14 INTRUSION DETECTION

The Event Generator in the model is purposely generic, and the events may include audit records, network packets or other observable activities. The Activity Pro le represents the global state of the intrusion detection system, and it contains variables that are used to calculate the behavior of the system based on some prede ned statistical measures. The variables are associated with certain pattern speci cations, which come into play when ltering the event records. During ltering, any matching records will then provide data to update the values stored in these variables. Furthermore, each variable is associated with one of the statistical measures built into the system, and is therefore responsible for updating the system state based on the information obtained from the matching record.

Using a history of common activities conducted by a typical user, the Activity Pro le can develop pattern templates that are then applied to newly created subjects (e.g., users) and objects (e.g., les). When new users of new les are introduced into the system, these templates can be used to instantiate new pro-les for them. The Rule Set represents a generic inferencing mechanism, such as a rule-based system. It uses event records, anomaly records, and other data to control the activity of the other components of the IDS and to update their state.

Although the above model of [137] is generic, it does provide the basic framework for the components of an intrusion detection system. Most IDSs follow the basic concept of formulating statistical metric for identifying intrusions, computing their values, and recognizing the anomalies in the resulting values. IDSs di er typically in three aspects, namely:

{in how the rules making-up the Rule Set are determined,

{on whether the Rule Set is xed a priori or if it can adapt itself depending on the type of intrusion,

{on the nature of the interaction between the Rule Set and the Activity Pro le.

The notion that the Activity Pro le module detects anomalies and that the Rule Set performs misuse detection will remain the same in most IDSs. Di ering techniques may be employed in each of the modules without changing the conceptual view of the model.

Audit trails and system logs represent the main source of input data for IDSs. A wide of range of audit data and log types can be obtained, many of

which are dependent on the particular host or network that generated them. Such data can be used in a number of ways [78] in order to:

{review the access-patterns to individual objects,

{provide access histories of speci c users and speci c processes,

{initiate the use of protection mechanisms o ered by the system,

{discover repeated attempts by users and outsiders to bypass the protection mechanisms,

{reveal the exercise of privileges when a user takes on a functionality or role with privileges higher than the usual user privileges,

{deter penetrators from repeatedly trying (successfully or otherwise) to bypass the system protection mechanisms,

{provide assurance to honest users that attempts to bypass the protection mechanisms are being recorded and discovered, and thus are being addressed by system administration.

For the development of trusted systems [145] auditable events are monitored in order to gather auditable data. Events that are typically monitored include (but are not limited to):

{the start and end of user identi cation and user authentication mechanisms,

{the introduction (deletion) of objects into (from) the user address space,

{actions by system administrators (including operators and security administrators),

{invocation and use of external services (e.g. printer servers and printer devices),

{all security-related events (depending on the de nition of these events in a given environment).

The information collected about events are wide ranging, but at the very least should include the date and time of the event, the type of event, the identi er of the subject (user/process triggering the event), the success/failure indication, the name/identity of the objects (introduced or deleted), and the description of the actions taken by the system administrator. In the case of speci c security-related events, the origin of the request for user identi cation/authentication must also be noted.

476 14 INTRUSION DETECTION

14.6 Host Intrusion Detection Systems

Most host-IDSs follow the basic model described in Section 14.5. In the following, we brie y review some of the major e orts in host-based intrusion detection. The motivation of this review is gain an overall understanding of the basic elements that are common in most, if not all, major intrusion detection systems.

14.6.1 IDES

The Intrusion Detection Expert System (IDES) is one of the earliest projects on intrusion detection. Developed in 1985 at SRI International, IDES employs user pro les and an expert system to decide on intrusion events. The general goal of IDES is to provide a system-independent mechanism to the realtime detection of intrusions, hence its focus on providing an expert system that detects anomalous behaviors based on complex statistical methods.

IDES is designed to run continuously, and is based on two beliefs [311]:

1.Intrusions, whether successful or attempted, can be detected by agging departures from historically established norms of behavior for individual users.

2.Known intrusion scenarios, know system vulnerabilities, and other violations of a system intended security policy (that is, a priori de nition of what is to be considered suspicious) are best detected through the use of an expert system rule base.

These two basic assumptions of thought have prevailed in the subsequent prototypes of IDES.

The components of IDES are shown in Figure 14.2. The Receiver module parses the received audit records and validates it, with the results being deposited in the collection of Audit Data. The two main subsystems of IDES consist of the components related to the anomaly detection and those within the expert system. In the statistical anomaly detector, the audit data is rst used by the Active Data Collector that produces Active Data, which consists of information about all user activities, group activities and remote host activities since the last time the pro les were updated. This data is then used by the Anomaly Detector that compares the data against the existing Pro le Data [260]. If an anomaly is found, an anomaly record is created and deposited in

Fig. 14.2. The Intrusion Detection Expert System (IDES)

the Anomaly Data database, which is accessible through the Security Administrator Interface. Daily updates on the pro les are conducted by the Pro le Updater. In the mean time, the Expert System works in parallel with the Active Data Collector, receiving the Audit Data as input. The Expert System checks for actions that can be considered intrusions, based the user's pro le. Although the initial versions of the Expert System su ers from the limitation of working only on known attack methods and vulnerabilities, subsequent versions of IDES have extended its functions to a networked environment, where several interconnected hosts send the audit information to a central site that performs the intrusion analysis.

IDES was developed by SRI over a number of years. An initial prototype system was developed for Sun/2 and Sun/3 systems to monitor a DEC 2065 that was running SRI's modi ed version of TOPS-20. The Intrusion Detection Model [137] framework is the basis for the initial IDES prototype system [310]. This early prototype system was modi ed over many years to incorporate new and more sophisticated detection techniques and interfaces and allows for scalability.

478 14 INTRUSION DETECTION

Fig. 14.3. Haystack components

Furthermore, it was later migrated from an Oracle relational database system using (Pro*C, C and SQL on IBM/DEC/Sun systems with SunView graphical interface environment) to a C based Sun Unix environment using an objectoriented X graphical interface library.

14.6.2 Haystack

Haystack is an intrusion detection system developed by the Los Alamos National Laboratories (LANL), with the initial design and system prototyping carried out by Tracor Applied Sciences and Haystack Laboratories. Haystack was not designed to work in a real-time environment, but rather as an o -line batch system. Its aim was to aid the US Air Force computer system security oÆcers (SSO) in analyzing data by reducing the voluminous audit data on the Air Force's Unisys 1100/60 mainframes. Initially Haystack existed as two components, one part running on the Unisys mainframe and the other on the Zenith Z-248 PC [481]. The model followed by Haystack was that of [137].

The goals of Haystack were:

{to enable a computer security policy to be enforced by improving the ability to detect and respond to security policy violations,

{to develop a software solution that conforms to POSIX and ANSI standards,

{to enable the SSO to monitor large volumes of raw audit data by summarizing and reporting events deemed suspicious.

The components of Haystack are shown in Figure 14.3. Here the audit data on the Unisys mainframe is given as input to a Preprocessor that extracts the relevant details. The result is written to a Canonical Audit Trail (CAT) le and the le written to a 9-track tape. At a later time the PC will then read the le from the tape, logging any obvious anomalies. A new session history record is created for any users appearing in the le. This history is also used to update a database that contains the user's past behavior. Haystack looks for misuses in the following ways:

Pattern based analysis. This is used to select important events that occur in the users session. The audit records are selected based on the following behaviors:

1.Modify Events { these include all successful and unsuccessful events that modify system security.

2.Tagged Events { these are system subjects and objects that have been marked by the security oÆcer as needing more detail logging and analysis.

Statistical based analysis. The statistical analysis is based on two computations (the Cumulative Weighted Multinomial method and the Wilcoxon-Mann- Whitney Rank Test). The rst is computed by comparing a user's session with the expected ranges of behavior, resulting in a \suspicion quotient." Any user whose quotient is outside the acceptable range is reported to the security oÆcer. The second is computed by comparing the user's session behavior with previous sessions, with the aim of detecting users who are slowly trying to adapt their pro les over time, e ectively modifying a normal behavior pattern to one that is unauthorized.

Although Haystack has provided considerable aid to the security oÆcers in analyzing the audit data, one of its shortcomings is precisely its lack of real-time capabilities. This opens a gap in time between the data collection and auditing, which may allow an intruder to break into the system.

14.6.3 MIDAS

MIDAS or Multics Intrusion Detection and Alerting System is an expert system that provides intrusion and misuse detection in real-time. It was designed by the National Computer Security Center (NCSC) for their networked mainframe (called Dockmaster), which is a Honeywell DPS 8/70. The expert system

480 14 INTRUSION DETECTION

Fig. 14.4. MIDAS components

itself has several components, some of which are actually running on a separate Symbolics List machine [463]. Figure 14.4 shows the components of MIDAS.

When Multics system generates an audit record, the Preprocessor lters data, which are not needed by MIDAS. It then formats the remaining data into an assertion for the FactBase, which is sent to the FactBase through the Network Interface that links the two computer systems. The Statistical Database contains statistics for users and the system, and de nes the normal state for Dockmaster. The new assertion that is introduced into the FactBase may result in a binding between the new fact and an existing rule in the RuleBase, and may even cause the ring of several other rules. Thus, the new assertion may change the state of the system and cause a system response to a suspected intruder. Clearly, the performance of MIDAS as a whole is largely dependent on the rules in the RuleBase.

Three di erent types of rules exist, namely, immediate attack heuristics, user anomaly heuristics and system state heuristics. The immediate attack rules only super cially examine a small amount of data items without applying any statistical analysis. The aim is to nd auditable events that are abnormal enough to raise suspicions. The user anomaly rules employ statistical analysis to detect deviations in a user's pro le as compared to previous histories. The system state rules are similar to the user anomaly rules, except these are applied to the system itself.