Internet Engineering Task Force IDWG Internet Draft Debar/Huang/Donahoo draft-ietf-idwg-data-model-01.txt IBM Corp./The Boeing Company/AFIWC 21 January 2000 Expires: July 20th, 2000 Intrusion Detection Exchange Format Data Model draft-ietf-idwg-data-model-01.txt Herve Debar IBM Corporation deb@zurich.ibm.com Ming-Yuh Huang The Boeing Company Ming-Yuh.Huang@boeing.com David J. Donahoo AFIWC ddonahoo@cmet.af.mil STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. This Internet Draft expires July 20th, 2000. Debar/Huang/Donahoo [Page 1] Internet Draft IDEFDM 21 January 2000 Table of Contents 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Conventions used in this document . . . . . . . . . . . . 4 3 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Problems addressed by the data format . . . . . . . . . . 4 3.2 How the data model answers these questions . . . . . . . 5 3.3 Design goals . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1 Representing events . . . . . . . . . . . . . . . . . . . 6 3.3.2 Content driven . . . . . . . . . . . . . . . . . . . . . 6 3.3.3 Relationship between alerts . . . . . . . . . . . . . . . 6 4 Data analysis . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Examples of network-based IDSes alert data . . . . . . . 7 4.1.1 Port scan attack . . . . . . . . . . . . . . . . . . . . 7 4.1.2 IP spoofing . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3 SYN Flood Attack . . . . . . . . . . . . . . . . . . . . 9 4.1.4 Buffer overflow . . . . . . . . . . . . . . . . . . . . . 10 4.1.5 PHF attack . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.6 Aggregation and summary for network-based IDSes . . . . . 11 4.2 Examples of Host-based IDSes alert data . . . . . . . . . 13 4.3 Analysis summary . . . . . . . . . . . . . . . . . . . . 14 5 The data model . . . . . . . . . . . . . . . . . . . . . 15 5.1 Principles . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1 Relationships . . . . . . . . . . . . . . . . . . . . . . 15 5.1.1.1 Inheritance Relationship . . . . . . . . . . . . . . . . 15 5.1.1.2 Aggregation Relationship . . . . . . . . . . . . . . . . 16 5.1.1.3 Multiplicity Indicator . . . . . . . . . . . . . . . . . 17 5.1.1.4 Types and default values . . . . . . . . . . . . . . . . 17 5.2 Data model overview . . . . . . . . . . . . . . . . . . . 18 5.3 The core of the data model . . . . . . . . . . . . . . . 20 5.3.1 The ALERT class . . . . . . . . . . . . . . . . . . . . . 20 5.3.2 The ANALYZER class . . . . . . . . . . . . . . . . . . . 22 5.3.3 The TARGET class . . . . . . . . . . . . . . . . . . . . 22 5.3.4 The SOURCE class . . . . . . . . . . . . . . . . . . . . 23 5.4 The support classes . . . . . . . . . . . . . . . . . . . 24 5.4.1 The IDENT class . . . . . . . . . . . . . . . . . . . . . 25 5.4.2 The ADDRESS class . . . . . . . . . . . . . . . . . . . . 26 5.4.3 The USER class . . . . . . . . . . . . . . . . . . . . . 27 5.4.4 The HOST class . . . . . . . . . . . . . . . . . . . . . 28 5.4.5 The PROCESS class . . . . . . . . . . . . . . . . . . . . 29 5.4.6 The SERVICE class . . . . . . . . . . . . . . . . . . . . 30 5.4.7 The NETWORK class . . . . . . . . . . . . . . . . . . . . 30 5.5 The extension mechanism . . . . . . . . . . . . . . . . . 31 5.5.1 The EXTENDEDALERT class . . . . . . . . . . . . . . . . . 31 5.5.2 The ADDITIONALDATA class . . . . . . . . . . . . . . . . 32 6 Examples of use of the data model . . . . . . . . . . . . 33 6.1 Use cases for denial of service attacks . . . . . . . . . 33 Debar/Huang/Donahoo [Page 2] Internet Draft IDEFDM 21 January 2000 6.1.1 The teardrop attack . . . . . . . . . . . . . . . . . . . 33 6.1.2 The ping of death attack . . . . . . . . . . . . . . . . 34 6.1.3 The SYN-flood attack . . . . . . . . . . . . . . . . . . 35 6.2 Use cases for scans . . . . . . . . . . . . . . . . . . . 35 6.2.1 Connection to a denied service . . . . . . . . . . . . . 35 6.2.2 Simple port scanning activity . . . . . . . . . . . . . . 36 6.3 Use cases for local attacks . . . . . . . . . . . . . . . 37 6.3.1 The loadmodule attack . . . . . . . . . . . . . . . . . . 37 6.3.2 The PHF attack . . . . . . . . . . . . . . . . . . . . . 38 6.4 Use cases for system policy usage . . . . . . . . . . . . 39 6.4.1 Night login . . . . . . . . . . . . . . . . . . . . . . . 39 6.4.2 Modification of a protected file . . . . . . . . . . . . 40 7 Security considerations . . . . . . . . . . . . . . . . . 40 8 Bibliography . . . . . . . . . . . . . . . . . . . . . . 41 Debar/Huang/Donahoo [Page 3] Internet Draft IDEFDM 21 January 2000 1 Abstract The purpose of the Intrusion Detection Exchange Format is to define data formats and exchange procedures for sharing information of interest with intrusion detection and response systems, and with the management sys- tems that may need to interact with them. This Internet- Draft describes a proposed data format to represent the information exported by the intrusion-detection systems, including the rationale for this format. Examples are given to illustrate the use of the format. 2 Conventions used in this document The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC-2119[1]. 3 Introduction This document defines a proposed data structure for the Intrusion Detec- tion Exchange Format (IDEF), which is the intended work product of the Intrusion Detection Exchange Format Working Group (IDWG). IDEF is planned to be a standard format that automated Intrusion Detection Sys- tems can use for reporting alerts that they have deemed to be suspi- cious. 3.1 Problems addressed by the data format This document does not address the need for a common exchange format for intrusion-detection alarms. This need is detailed in the requirement document of the IDWG working group, currently an Internet draft[2]. The reasons for proposing an object-oriented model as the data represen- tation format of the IDWG are: 1. Alert information is inherently heterogeneous. Certain alerts are defined with very little information, such as origin, des- tination, name and time of the event. Other alerts provide much more context, such as ports or services, processes, user information, and others. Therefore, it is important that the data representation proposed is flexible enough to accommodate different needs. 2. Tool environments are different. Some tools detect attacks by analyzing network traffic while others use operating system logs, or application audit information. The same attack reported by tools with different information sources will not Debar/Huang/Donahoo [Page 4] Internet Draft IDEFDM 21 January 2000 contain the same information. 3. Tool capabilities are different. Depending on the environment, one may install a lightweight tool providing little informa- tion. More complex tools that will have a greater impact on the running system provide more detailed information about the alerts observed by the intrusion detection system. The data model must allow for conversion to formats used by tools other than intrusion detection sensors, for the purpose of further processing the alert information. 4. Operating environments are different. Depending on the kind of network, or operating system used, attacks will be observed and reported with different characteristics. The data model should accommodate these differences. 5. Commercial vendor objectives are different. Depending on the constraints set forth for the development of the tool, or on the operating environment, vendors may wish to deliver more or less information about certain attacks. 3.2 How the data model answers these questions Each point in this section constitutes an answer to the corresponding question raised in the previous section. 1. An object-oriented model has a natural extensibility via sub- classing. Although the data model limits the places where sub- classing can be used as an extension mechanism, it is still a viable mechanism for introducing flexibility without loosing compatibility between different implementations. 2. The data model defines support classes that accommodate the differences in data sources among tools. In particular, the notion of target and source for the alert are represented by the combination of HOST, USER, PROCESS and SERVICE classes. 3. The data model defines extensions to the basic schema that allow carrying both simple and complex alerts. Debar/Huang/Donahoo [Page 5] Internet Draft IDEFDM 21 January 2000 4. The reporting flexibility is brought by the definition of the HOST and SERVICE support classes. 5. Vendors may want to provide more information about alerts. Again, the object-oriented approach allows this flexibility while specifying how the subclassing mechanism must be used. 3.3 Design goals 3.3.1 Representing events The goal of the data model is to provide a standard data structure to represent that an occurrence of unusual activity was detected by a(n) intrusion detection analyzer/sensor. These events may be simple or com- plex, depending on the capability of the analyzer/sensor that created them. 3.3.2 Content driven The design of the data model is content-driven. This means that new objects are introduced to accommodate additional content, not semantic differences between the alerts. This is an important goal as the task of classifying and naming computer vulnerabilities is extremely difficult and subjective. The data model must be unambiguous. This means that we allow tools to be more or less precise than one another, but we do not allow them to pro- duce divergent information about an alert. 3.3.3 Relationship between alerts Intrusion detection alerts can be transmitted at several levels. This draft applies to both very simple alerts (those alerts that are the result of a single action or operation in the system, such as a failed login report) and to more complex alerts (the aggregation of several actions in the system to generate the alert, or the aggregation of sev- eral simple alerts). As such, the data model must provide a way to describe the relationship between low level and high level alerts. 4 Data analysis This section provides an analysis of the alert information provided by some intrusion detection systems. It is limited to the documentation made publicly available by the intrusion-detection system vendors. Debar/Huang/Donahoo [Page 6] Internet Draft IDEFDM 21 January 2000 4.1 Examples of network-based IDSes alert data This section shows the information reported by three different intrusion detection systems when faced with four attacks. 4.1.1 Port scan attack A port scan is a preliminary attack aimed at recognizing the services offered by a given host, along with possibly additional information such as banners or version numbers. -------------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------------- Sensor Name | | Sensor Name -------------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------------- Actual Alarm String | | -------------------------------------------------------- Severity Level | | -------------------------------------------------------- Source IP | Source IP | Source IP -------------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------------- Port Count | | -------------------------------------------------------- Application Name | | -------------------------------------------------------- | Protocol | -------------------------------------------------------- | List of Ports | -------------------------------------------------------- | | Port Scan Range -------------------------------------------------------- Debar/Huang/Donahoo [Page 7] Internet Draft IDEFDM 21 January 2000 4.1.2 IP spoofing IP spoofing is an attack that masquerades the originator's IP address. --------------------------------------------------------------- IDS-A | IDS-B | IDS-C --------------------------------------------------------------- Sensor Name | | Sensor Name --------------------------------------------------------------- Date/Time | Date/Time | Date/Time --------------------------------------------------------------- Actual Alarm String | | --------------------------------------------------------------- Source port | | --------------------------------------------------------------- Destination port | List of port intervals | --------------------------------------------------------------- Severity Level | | Severity Level --------------------------------------------------------------- Source IP | | Source IP --------------------------------------------------------------- MAC Address | | --------------------------------------------------------------- | | Protocol --------------------------------------------------------------- | | Begin Time --------------------------------------------------------------- | | End Time --------------------------------------------------------------- Debar/Huang/Donahoo [Page 8] Internet Draft IDEFDM 21 January 2000 4.1.3 SYN Flood Attack The SYN flood attack is a denial of service attack that aims at prevent- ing a host from answering connection requests by exhausting system resources. -------------------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------------------- Sensor Name | (not documented) | (not documented) -------------------------------------------------------------- Date/Time | | -------------------------------------------------------------- Actual Alarm String | | -------------------------------------------------------------- Severity Level | | -------------------------------------------------------------- Source IP | | -------------------------------------------------------------- Destination IP | | -------------------------------------------------------------- Half Open Connections | | -------------------------------------------------------------- Terminated Connections | | -------------------------------------------------------------- Debar/Huang/Donahoo [Page 9] Internet Draft IDEFDM 21 January 2000 4.1.4 Buffer overflow The buffer overflow attack is aimed against a program that does not properly check size boundaries for incoming data. -------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------- Source IP | Source IP | Source IP -------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------- | Protocol | Protocol -------------------------------------------------- | Attack Data | Program Text -------------------------------------------------- | | Program Name -------------------------------------------------- | | Begin Time -------------------------------------------------- | | End Time -------------------------------------------------- | | Severity -------------------------------------------------- Debar/Huang/Donahoo [Page 10] Internet Draft IDEFDM 21 January 2000 4.1.5 PHF attack The PHF attack is aimed at exploiting the vulnerable PHF script avail- able in early versions of the apache web server. -------------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------------- Source IP | Source IP | Source IP -------------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------------- Source port | Source port | Source port -------------------------------------------------------- Destination port | Destination port | Destination port -------------------------------------------------------- URL | URL | URL -------------------------------------------------------- Script | | Script -------------------------------------------------------- | | Method -------------------------------------------------------- 4.1.6 Aggregation and summary for network-based IDSes The following table aggregates the various kinds of information elements found in the network-based intrusion detection systems sampled. The first 8 lines show generic information that is reported in all cases, i.e. the origin of the detection (the sensor), date and time stamps, some severity, and target and source information. The remainder of the table shows specific information reported by the tools in different cases of attacks. Debar/Huang/Donahoo [Page 11] Internet Draft IDEFDM 21 January 2000 ----------------------------------------------------------- IDS-A | IDS-B | IDS-C ----------------------------------------------------------- Sensor Name | | Sensor Name ----------------------------------------------------------- Date/Time | Date/Time | Date/Time ----------------------------------------------------------- Actual Alarm String | | ----------------------------------------------------------- Actual Host IP | | ----------------------------------------------------------- Priority | | Severity Level ----------------------------------------------------------- Attack Host IP | Source IP | Source IP ----------------------------------------------------------- Attacked Host | Destination IP | Destination IP ----------------------------------------------------------- Protocol Type | Protocol | Protocol ----------------------------------------------------------- DOS Count | | ----------------------------------------------------------- Packet Size | | ----------------------------------------------------------- Ports Count | | ----------------------------------------------------------- | List of Ports | ----------------------------------------------------------- | | Port Scan Range ----------------------------------------------------------- Application | | Program Name ----------------------------------------------------------- MAC Address | | ----------------------------------------------------------- | Attack Data | Program Text ----------------------------------------------------------- Session Duration | | ----------------------------------------------------------- | | Begin Time ----------------------------------------------------------- | | End Time ----------------------------------------------------------- | User name | ----------------------------------------------------------- | Password | ----------------------------------------------------------- Attack pattern | Attack Strings | ----------------------------------------------------------- Debar/Huang/Donahoo [Page 12] Internet Draft IDEFDM 21 January 2000 Half Open Connections | | ----------------------------------------------------------- Terminated Connections | | ----------------------------------------------------------- The common information in the model will be reported as an ALERT, along with the proper TIME and ANALYZER (sensor in the table) information. Additional common information, including hosts, programs and ports, is reported in the model as TARGET and SOURCE with the appropriate associ- ations. 4.2 Examples of Host-based IDSes alert data This section is not organized by attacks. It is already a summary of the information we have observed in the case of host-based intrusion-detec- tion systems. ----------------------------------------------------------------------- IDS-E | IDS-F | IDS-G ----------------------------------------------------------------------- Name | Event Type | Signature ----------------------------------------------------------------------- | | Module ----------------------------------------------------------------------- Date/Time | Date/Time | Date/Time ----------------------------------------------------------------------- | | Audit identifier ----------------------------------------------------------------------- User Name/Source IP | User Name/Source IP | Source IP ----------------------------------------------------------------------- Target System (IP/Name) | System Name | Target hostname ----------------------------------------------------------------------- Priority | | Severity ----------------------------------------------------------------------- Details | | ----------------------------------------------------------------------- | Sys Software | ----------------------------------------------------------------------- | Process ID# | ----------------------------------------------------------------------- | Session ID# | ----------------------------------------------------------------------- | Action Text | ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 13] Internet Draft IDEFDM 21 January 2000 | Text Size | ----------------------------------------------------------------------- | Misc Pointer | ----------------------------------------------------------------------- | Recursion Counter | ----------------------------------------------------------------------- | Match Clause | ----------------------------------------------------------------------- | Event Policy | ----------------------------------------------------------------------- | Rule Matched | ----------------------------------------------------------------------- | Action Clause (response) | ----------------------------------------------------------------------- | | URL ----------------------------------------------------------------------- | | Compound data ----------------------------------------------------------------------- As with network-based intrusion-detection systems, the common identifi- cation of the tool that sent the alert, the time-stamp, what the alert name/signature is, and the source/target are included. Then, additional information depends very much on the technique and data source used by the intrusion-detection system. 4.3 Analysis summary Some techniques for intrusion detection have not been surveyed in this very short analysis. For example, we expect intrusion-detection systems based on application data (spanning multiple hosts) or on alert data (correlation) to appear shortly, either as prototypes or commercial products. The data model MUST take these emerging technologies into account. The information reported by different intrusion-detection systems con- cerning the same attack can be fairly different. This means that the proposed data model has to strike a sensible balance between information that is commonly regarded as important for describing the alert, and additional information (enhancements) proposed by the intrusion-detec- tion vendor. The former must be part of the core class design, whereas the later can be accommodated through subclassing the core classes. Intrusion-detection sensors report the same kind of information under different names and formats, depending on their capabilities. For exam- ple, a network-based intrusion-detection system is more likely to pro- vide network addresses, and a host-based system more likely to provide host names and user names. The data format needs to accommodate these Debar/Huang/Donahoo [Page 14] Internet Draft IDEFDM 21 January 2000 different ways to convey the same information, and this is achieved in the data model through the use of support classes. These support classes also allow to create the relation between these multiple views of the same object. Many of the intrusion-detection systems surveyed do not include reaction information with the alert, but encode it in a separate message. The data model therefore MUST be able to support transmission of counter- measure information either as an attribute of the alert, or as a sepa- rate stand-alone alert. 5 The data model 5.1 Principles The data model is described using the Universal Modeling Language (UML) [3]. UML provides a simple framework to represent entities and their relationships. UML define entities as classes. In this document we have identified the classes with the associated attributes. The symbols used in this document to represent class and attributes are: +---------------------+ | CLASS | +---------------------+ | Attribute | | Attribute | | Attribute | | ... | +---------------------+ Please note that attributes for a class do not appear in all diagrams which use the class. 5.1.1 Relationships This data model currently uses only two relationships, the inheritance relationship and the aggregation relationship. 5.1.1.1 Inheritance Relationship Inheritance denotes a superclass, subclass type of a relationship where the subclass inherits all the attributes, operations and relationships of the superclass. This type of relationship is also referred to as an "is-a" or a "kind-of" relationship. The subclasses have additional Debar/Huang/Donahoo [Page 15] Internet Draft IDEFDM 21 January 2000 attributes or operations which apply only to the subclass and not to the superclass In this document, inheritance is represented by the /_\ symbol. In the example below we are stating that an Extended Alert is a kind of alert. It contains all the attributes of Alert as well as any attributes con- tained in the extended alert class. (Note: purpose of Extended_Alert will be discussed latter in this document). +---------------------+ | ALERT | +---------------------+ /_\ | | +---------------------+ | EXTENDED_ALERT | +---------------------+ Figure 1: Inheritance relationship example 5.1.1.2 Aggregation Relationship Aggregation is a form of association in which the whole is related to its parts. This type of relationship is also referred to as a "part-of" relationship. In this case the aggregate class contains all of it own attributes and as many of the attributes associated to it parts as required and specified in the multiplicity indicators (discussed in the next paragraph). In this document the symbol <> is used to indicate aggregation. It is placed at the end of the association line closest to the aggregate (whole) class. Debar/Huang/Donahoo [Page 16] Internet Draft IDEFDM 21 January 2000 +---------------------+ 1 +---------------------+ | ALERT |<>----------| ANALYZER | +---------------------+ +---------------------+ | | | | 1 +---------------------+ | |<>----------| TIME | | | +---------------------+ | | | | 0..*+---------------------+ | |<>----------| TARGET | | | +---------------------+ | | | | 0..*+---------------------+ | |<>----------| SOURCE | +---------------------+ +---------------------+ Figure 2: Aggregation relationship example 5.1.1.3 Multiplicity Indicator Multiplicity defines the number of objects within a class that are linked to one another. Typically multiplicity indicators are placed at each end of the association line. In this document if a multiplicity number is left off it is assumed to be 1 (one). Standard symbol, as used in this document, are: 1 = Exactly One 0..* = Zero or More 1..* = One or More 0..1 = Zero or One 5..8 = Specific Range (5,6,7, & 8) In the example above an Alert contains all the attributes of it's own class and the attributes of exactly one Analyzer and the attributes of 1 time. I may contain the attributes of zero or more target(s) and the attributes of zero or more source(s). 5.1.1.4 Types and default values Debar/Huang/Donahoo [Page 17] Internet Draft IDEFDM 21 January 2000 Attributes of the classes defined by the data model are typed. This type information is not a requirement on the implementation; it is rather an indication of the qualification of the data carried by the attribute. For example, the INTEGER type indicates that the data model requests the value to be an integer, regardless of size. ---------------------------------------------------------- Name Default Definition value ---------------------------------------------------------- BOOLEAN FALSE Boolean = TRUE,FALSE. ---------------------------------------------------------- INTEGER 0 The value provided must be an integer. ---------------------------------------------------------- CHARACTER \0 UTF-8 encoded character. ---------------------------------------------------------- STRING "" UTF-8 encoded string. ---------------------------------------------------------- BYTE 0 Byte (8-bits, no parity). ---------------------------------------------------------- An analyzer can choose not to fill any attribute of the classes of the data model. In this case, the analyzer can decide not to send the unfilled attributes to the manager. In that case, the manager MUST assume the default value of the table above according to the type of the missing attribute. However, implementors of the IDWG format SHOULD consider filling as many attributes as possible, in particular the attributes of the ALERT, TIME and ANALYZER classes which are considered the most common and important across all intrusion-detection systems. 5.2 Data model overview An overview of the data model is presented in figure 3. The main compo- nent is the ALERT class, which bears minimum required information along with the TIME and ANALYZER classes. In addition, each alert is associ- ated with zero or more TARGET, and with zero or more SOURCE. Each TARGET and SOURCE is described by a number of attributes, as described in sec- tions 5.3.3 and 5.3.4. Additional alert data can be included by subclassing the EXTENDEDALERT class. Standard extensions and examples are given in section 5.5. Debar/Huang/Donahoo [Page 18] Internet Draft IDEFDM 21 January 2000 +----------+ 1+----------+ 0..1+----------+ | ALERT |<>------| ANALYZER | +--------| HOST | | | +----------+ | +----------| | | | 0..1+----------+ | | 1+----------+ +--------| NETWORK | | |<>------| TIME | | +----------+ | | +----------+ | 0..1+----------+ | | +--------| USER | | | 0..*+----------+ | +----------+ | |<>------| TARGET |<>---+ 0..1+----------+ | | +----------+ +--------| PROCESS | | | | +----------+ | |<>-+ | 0..1+----------+ | | | +--------| SERVICE | +----------+ | +----------+ /_\ |0..*+----------+ 0..1+----------+ | +----| SOURCE |<>---+--------| HOST | | +----------+ | +----------+ +----------+ | 0..1+----------+ | EXTENDED | +--------| NETWORK | | ALERT | | +----------+ +----------| | 0..1+----------+ +--------| USER | | +----------+ | 0..1+----------+ +--------| PROCESS | +----------+ Figure 3: Data model overview It is important to note that this data model does not specify how an alert should be classified or identified. For example, a port scan may be determined as a single attack against multiple targets by one sensor where another sensor may see it as multiple attacks by a single source. The taxonomy for this analysis lies in each IDS. Once the alert type is determined this data model provides the standard structure for format- ting the alert. Also the data model implements a set of types with default values (see section 5.1.1), which must be understood by the reader beforehand. Debar/Huang/Donahoo [Page 19] Internet Draft IDEFDM 21 January 2000 5.3 The core of the data model The core of the data model is the ALERT class. Every alert is associ- ated with a single analyzer that generated it, and a single time. It is also associated with a list of 0 or more targets, and a list of 0 or more sources. This relationship is illustrated in figure 4. +--------------------+ 1..1+-------------------------+ | ALERT |<>--------------| ANALYZER | |--------------------| +-------------------------+ | INTEGER version=1 | | INTEGER analyzerID | | INTEGER alertID | | HOST anlyzerHost | | INTEGER confidence | | PROCESS analyzerProc | | INTEGER impact | +-------------------------+ | INTEGER success | | INTEGER method | 1..1+-------------------------+ | STRING name |<>--------------| TIME | | STRING signature | +-------------------------+ | STRING reaction | | STRING date | | | | STRING time | | | | INTEGER milliseconds | | | +-------------------------+ | | | | 0..*+-------------------------+ | |<>--------------| TARGET | | | +-------------------------+ | | | | 0..*+-------------------------+ | |<>--------------| SOURCE | +--------------------+ +-------------------------+ Figure 4: Data model core 5.3.1 The ALERT class The ALERT class is the central component of the data model. An IDWG- compliant intrusion-detection analyzer must generate at a minimum this set of informations. The ALERT class defines the following attributes: Debar/Huang/Donahoo [Page 20] Internet Draft IDEFDM 21 January 2000 ---------------------------------------------------------------------- Attribute Type Definition ---------------------------------------------------------------------- version INTEGER The version of the class hierarchy used. The current version is 1. ---------------------------------------------------------------------- alertID INTEGER A serial number for the alert. This number MUST be unique for every alert generated by a given analyzer. ---------------------------------------------------------------------- confidence INTEGER The confidence that the analyzer trusts that the alert properly identified an attack (or en event for which the operator requires notification). The range [0..100] is reserved by the standard. The valid range is [1..100], where 1 represents the lowest confidence and 100 represents the highest confidence. ---------------------------------------------------------------------- impact INTEGER The evaluated impact of the alert on the system. The range [0..100] is reserved for the standard. The valid range is [1..100], where 1 represents the lowest impact and 100 represents the highest impact. ---------------------------------------------------------------------- success INTEGER The evaluated probability that the action related to the alert was successful. The range [0..100] is reserved for the standard. The valid range is [1..100], where 1 represents the lowest probability of success and 100 represents the highest probability of success. ---------------------------------------------------------------------- method INTEGER The method used by the detector. The range [0..100] is reserved for the standard. 0 is the NULL value, 1 means knowledge-based, 2 means behavior-based, 3 means correlation-based, 4 means policy-based. Vendor provided values start at 101. ---------------------------------------------------------------------- name STRING The name of the attack. The name of the attack MUST be non-empty. The name of the attack SHOULD follow a well known scheme such as the bugtraq identifier or the cve identifier[4] whenever possible. The name SHOULD contain the scheme identification (bugtraqid or cveid) concatenated with the identifier of the vulnerability in the scheme. ---------------------------------------------------------------------- Debar/Huang/Donahoo [Page 21] Internet Draft IDEFDM 21 January 2000 signature STRING The signature of the attack. ---------------------------------------------------------------------- reaction STRING The countermeasure that was applied to the attack. ---------------------------------------------------------------------- 5.3.2 The ANALYZER class The ANALYZER class identifies the intrusion detection analyzer that provided the alert. At the minimum, this is a unique identifier such as a serial number (unique over the organization where the IDS system is deployed). Additional identification information is provided. ----------------------------------------------------------------------- Attribute Type Definition ----------------------------------------------------------------------- analyzerID INTEGER Analyzer identification token. This token MUST be unique. ----------------------------------------------------------------------- analyzerHost HOST Identification of the equipment on which the analyzer resides. ----------------------------------------------------------------------- analyzerProc PROCESS Process information concerning the analyzer. ----------------------------------------------------------------------- 5.3.3 The TARGET class The TARGET class contains information about the TARGET of the alert, i.e. the recipient of the malicious or anomalous activity that has been spotted by the intrusion detection system. The target itself consists of an identifier and a boolean indicating whether the target is real or spoofed. The relationship diagram for TARGET is shown in figure 5. The TARGET class defines the following attributes: --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- targetID INTEGER Target reference token. This token identifies and refers to a previously defined target. This token MUST be unique. --------------------------------------------------------------------- spoofed BOOLEAN Indicates if the data associated with the target is considered real as far as the analyzer can Debar/Huang/Donahoo [Page 22] Internet Draft IDEFDM 21 January 2000 decide (spoofed=FALSE) or a decoy (spoofed=TRUE). The default value is FALSE. --------------------------------------------------------------------- +------------------+ 0..1+---------------------+ | TARGET |<>------------------| HOST | |------------------| +---------------------+ | INTEGER targetID | | BOOL spoofed | 0..1+---------------------+ | |<>------------------| NETWORK | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| USER | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| PROCESS | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| SERVICE | +------------------+ +---------------------+ Figure 5: The Target class 5.3.4 The SOURCE class The SOURCE class contains information about the possible source or sources of the alert, i.e. the party or parties generating the anomalous data. The source itself contains a reference number (to refer to previ- ously transmitted or defined sources) and an indicator to indicate whether the source is real or spoofed. The relationship diagram for SOURCE is given in figure 6. The SOURCE class defines the following attributes: Debar/Huang/Donahoo [Page 23] Internet Draft IDEFDM 21 January 2000 --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- sourceID INTEGER Source reference token. This token MUST be unique. --------------------------------------------------------------------- spoofed BOOLEAN Indicates if the data associated with the source is considered real as far as the analyzer can decide (spoofed=FALSE) or a decoy (spoofed=TRUE). The default value is FALSE. --------------------------------------------------------------------- +------------------+ 0..1+---------------------+ | SOURCE |<>------------------| HOST | |------------------| +---------------------+ | INTEGER sourceID | | BOOL spoofed | 0..1+---------------------+ | |<>------------------| NETWORK | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| USER | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| PROCESS | +------------------+ +---------------------+ Figure 6: The Source class 5.4 The support classes The support classes represent entities in the data model that have an important role. Their relationship is described in figure 7. The follow- ing entities have been identified: hosts, processes, users and services. In addition, an address entity has been defined to enhance user and host. The relationship diagram for the support classes is shown in fig- ure 7. Debar/Huang/Donahoo [Page 24] Internet Draft IDEFDM 21 January 2000 +---------------+ | IDENT | |---------------| | INTEGER ident | +---------------+ /_\ | +-------------------------------------+ | | +-------------------+ | +-----------------+ | |PROCESS |---+---|HOST | | |-------------------+ | |-----------------+ 0..*+----------------+ |INTEGER pid | | |STRING name |<>-----|ADDRESS | |STRING name | | |STRING location | |----------------+ |STRING path | | +-----------------+ |INTEGER category| |STRING[] arguments | | |STRING data | |STRING[] environ | | +-----------------+ +----------------+ +-------------------+ +---|USER | |0..* | |-----------------+ | | |INTEGER category |<>-------------+ +-------------------+ | |STRING name | |SERVICE |---+ |INTEGER uid | |-------------------+ | |STRING group | |STRING name | | |INTEGER gid | |INTEGER dport | | |STRING serialID | |INTEGER sport | | +-----------------+ |STRING protocol | | +-------------------+ | | +-----------------+ +---|NETWORK | |-----------------| |STRING netmask | |STRING gateway | |STRING broadcast | +-----------------+ Figure 7: Support classes diagram 5.4.1 The IDENT class All support classes inherit from the IDENT class. The IDENT class pro- vides a reference to an object predefined by the analyzer and the man- ager. Instead of sending the complete description of the object, the Debar/Huang/Donahoo [Page 25] Internet Draft IDEFDM 21 January 2000 IDEFDM message can contain the reference identifier for this object. The IDENT class defines the following attributes: --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- ident INTEGER The shared reference number by which the analyzer and the manager identify the object. The value 0 is reserved to indicate that no shared reference number is available for this object. The NULL value is identical to 0. --------------------------------------------------------------------- This means that every HOST, USER, ADDRESS, PROCESS or SERVICE can be exchanged with a 64--bits integer. However, the implementor MUST NOT reuse an identification previously used for an other instance. It is explicitly forbidden to share the same identification for two instances even if they are specializations of two different subclasses (e.g. a HOST and a USER). 5.4.2 The ADDRESS class The ADDRESS support class carries address information. The address in question can be for example a network address, a hardware address or an application address. --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- category INTEGER The kind of address information. 0 or NULL indicates no value in the address string. The range [1..99] is reserved by the standard. Values 100 or above are vendor-dependent. --------------------------------------------------------------------- data BYTE[] The address information itself. The type information MUST allow transcription of the byte string into its original format. --------------------------------------------------------------------- The following values are defined for the category attribute: Debar/Huang/Donahoo [Page 26] Internet Draft IDEFDM 21 January 2000 --------------------------------------------------------------------- category type of Definition value value attribute --------------------------------------------------------------------- 10 INTEGER IP v4 address (short form). 11 STRING IP v4 address (readable 4 dot separated 3-digit sets). 12 STRING IP v6 address. 13 STRING MAC address. 14 STRING ATM network address. 15 STRING SNA network address. 20 STRING Internet e-mail address (somebody@somewhere). --------------------------------------------------------------------- 5.4.3 The USER class The USER class indicates the different ways by which a user can be identified. --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- category INTEGER The kind of USER transported. The range [0..100] is reserved by the standard. 0 or NULL indicates that the information is not provided by the analyzer. In this case, no information contained in the other attributes SHOULD be interpreted by the manager. Values >= 101 are vendor-defined and MUST be interpreted according to the identification of the analyzer. The data model specifies that 1 indicates an operating system or device user, 2 indicates an application user. --------------------------------------------------------------------- name STRING The name identifying the user. --------------------------------------------------------------------- uid INTEGER The user identification number of the user. --------------------------------------------------------------------- group STRING The group name or domain name associated with the user. --------------------------------------------------------------------- gid INTEGER The group identification number associated with the user. --------------------------------------------------------------------- Debar/Huang/Donahoo [Page 27] Internet Draft IDEFDM 21 January 2000 serialID STRING User identification as a string when the uid cannot be used. The data model defines the following values for the category attribute of the USER class: -------------------------------------------------------------------- category category Definition value string -------------------------------------------------------------------- 1 osuser Operating system or device user. This covers for example UNIX logins and NT users. -------------------------------------------------------------------- 2 appuser Application user. This covers for example web accounts, database accounts or transaction application accounts. -------------------------------------------------------------------- The USER class is associated with a list of addresses. 5.4.4 The HOST class The HOST class indicates the different ways by which a host or equip- ment on the network can be identified. ----------------------------------------------------------------- Attribute Type Definition ----------------------------------------------------------------- name STRING The machine fully qualified domain name. ----------------------------------------------------------------- location STRING The location of the equipment. ----------------------------------------------------------------- domain INTEGER The domain to which the equipment belongs, if relevant. ----------------------------------------------------------------- The data model defines the following values for the category attribute of the HOST class: Debar/Huang/Donahoo [Page 28] Internet Draft IDEFDM 21 January 2000 ------------------------------------------------ Value Key Definition ------------------------------------------------ 1 DNS Domain Name Service. ------------------------------------------------ 2 NIS Network Information Service (SUN). ------------------------------------------------ 3 NIS+ Network Information Service (SUN). ------------------------------------------------ 4 WfW Windows for Workgroups. ------------------------------------------------ 5 NT Windows NT domain. ------------------------------------------------ 6 ADS Windows 2000 ADS. ------------------------------------------------ 7 NDS Netware. ------------------------------------------------ 8 AFS Andrew File System. ------------------------------------------------ 9 Kerb Kerberos realm. ------------------------------------------------ 10 DFS Distributed file system. ------------------------------------------------ 11 CODA Distributed file system. ------------------------------------------------ 5.4.5 The PROCESS class The PROCESS class gathers information about the process that is being run. ---------------------------------------------------------------------- Attribute Type Definition ---------------------------------------------------------------------- name STRING The name of the program being run. This is a short name, e.g. sendmail or explorer. Options and path information are provided by additional attributes. ---------------------------------------------------------------------- pid INTEGER The process identifier of the process being run. ---------------------------------------------------------------------- path STRING The path of the program. ---------------------------------------------------------------------- arguments STRING[] The arguments passed to the program. ---------------------------------------------------------------------- environ STRING[] The environment strings in which the process is Debar/Huang/Donahoo [Page 29] Internet Draft IDEFDM 21 January 2000 being run. ---------------------------------------------------------------------- 5.4.6 The SERVICE class The SERVICE class identifies a network service request being carried out over the network. In particular, this class should be used to report not only open services, but also connections and connections attempts. To do so, the class provides for identification of the source port from which the connection originated. In general, a service is a resource available from the network. This SERVICE class is also related to process and user information. Process and user information are aggregated at the source or target. ------------------------------------------------------------------- Attribute Type Definition ------------------------------------------------------------------- name STRING The name of the service. This SHOULD be listed in the IANA list of well-known ports. ------------------------------------------------------------------- dport INTEGER The port to which the connection request is addressed. In many situations, this will be a well-known port. ------------------------------------------------------------------- sport INTEGER The source port from which the connection originated. In many situations, this will be a high-numbered port. ------------------------------------------------------------------- protocol STRING The protocol name. ------------------------------------------------------------------- 5.4.7 The NETWORK class The NETWORK class carries information related to an entire network or sub-network. -------------------------------------------------------------------- Attribute Type Definition -------------------------------------------------------------------- netmask STRING The pool of addresses that represent the network. -------------------------------------------------------------------- Debar/Huang/Donahoo [Page 30] Internet Draft IDEFDM 21 January 2000 gateway STRING Gateway information, if available. -------------------------------------------------------------------- broadcast STRING The broadcast address, if applicable. -------------------------------------------------------------------- 5.5 The extension mechanism It is expected that the model will have to be extended by vendors to carry additional information relevant to the alerts they need to trans- port. When an intrusion-detection vendor desires to extend the data model, he MUST do so by subclassing the EXTENDEDALERT class. All the other classes in the model cannot be subclassed unless a revision of the data model is proposed, that changes the ALERT version number. The extension MUST be referenced with a number which documents the derived classes and attributes provided by the vendor. The classes derived from the EXTENDEDALERT class are part of the stan- dard data model and MUST be understood by an IDWG-compliant manager. They are also proposed as examples of how the data model can be extended to fit new needs. +---------------------+ | ALERT | +---------------------+ /_\ | | +---------------------+ 0..*+------------------+ | EXTENDEDALERT |<>-------| ADDITIONALDATA | |---------------------| |------------------| | INTEGER extVersion | | INTEGER category | | | | INTEGER size | +---------------------+ | BYTE data | +------------------+ Figure 8: Extended alert class hierarchy 5.5.1 The EXTENDEDALERT class Debar/Huang/Donahoo [Page 31] Internet Draft IDEFDM 21 January 2000 The EXTENDEDALERT class extends the basic alert format by allowing to provide additional information, either as bulk data (aggregation to ADDITIONALDATA), or by subclassing. It defines the following attributes: ---------------------------------------------------------------------- Attribute Type Definition ---------------------------------------------------------------------- extVersion INTEGER The extension version number. This is a vendor-specific number and must be related to the specification of the analyzer in the ALERT class. ---------------------------------------------------------------------- 5.5.2 The ADDITIONALDATA class The ADDITIONALDATA class allows to pack additional elements of informa- tion that are relevant to the alert. --------------------------------------------------------------------- Attribute Type Definition --------------------------------------------------------------------- category INTEGER The kind of additional data provided. It determines the actual type and semantics of the information provided in the data attribute. Values in the range [0..999] are reserved by the standard. This MUST be provided. --------------------------------------------------------------------- size INTEGER Indicates how many elements of the category are contained in the data buffer. 1 indicates a single element, n a list of n data elements of the type indicated by the category. This MUST be provided. --------------------------------------------------------------------- data BYTE [] The additional information as an array of byte strings. This MUST be non-void. --------------------------------------------------------------------- The following values are defined for the category attribute: ----------------------------------------------------- category type of Definition value data Debar/Huang/Donahoo [Page 32] Internet Draft IDEFDM 21 January 2000 attribute ----------------------------------------------------- 0 FORBIDDEN. 1 INTEGER 16-bits integer value. 2 INTEGER 32-bits integer value. 3 INTEGER 64-bits integer value. 4 CHARACTER UTF-8 character. 5 STRING UTF-8 string. 6 BOOLEAN Boolean value. 7 BYTE 8-bits byte value. 8 REAL 64-bits real value. 10 SERVICE Service information. 11 PROCESS Host information. 12 USER User information. 13 NETWORK Network information. 14 HOST Host information. 20 ALERT Alert information. 21 TIME Time information. 22 ANALYZER IDS information. 23 TARGET Target information. 24 SOURCE Source information. 100 STRING URL. 101 STRING CGI script name. 102 STRING CGI script argument. 103 STRING HTTP Method request name. 104 INTEGER Alert identifiers. 105 STRING Command submitted to a program. 106 BYTE Overflow data. ----------------------------------------------------- 6 Examples of use of the data model 6.1 Use cases for denial of service attacks 6.1.1 The teardrop attack The teardrop attack is a classic example of a denial of service where the attacker sends anomalous fragmented packets. This teardrop attack would be represented in the following way: Alert.version = 1 Alert.alertID = 14285812 Alert.confidence = 100 Alert.impact = 5 Alert.success = 1 Debar/Huang/Donahoo [Page 33] Internet Draft IDEFDM 21 January 2000 Alert.method = 1 Alert.name = cve.GENERIC-MAP-NOMATCH Alert.signature = Teardrop Alert.reaction = none Alert.Time.date = 1999/12/02 Alert.Time.time = 10:01:25 Alert.Time.milliseconds = 93464 Alert.Analyzer.ident = 123123123 Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.231.121 Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 222.121.111.112 This is the base information that would be expected from all intrusion- detection sensors detecting this attack. Variations are possible, such as also reporting the service that is targeted by the attack (this might be considered useful in an NT networking environment, where typically one of the netbios services is the target of the attack). 6.1.2 The ping of death attack The ping-of-death attack is a classic example of a denial of service attack. By sending very large packets to a machine, one can overflow the reassembly routines and crash the IP subsystem and potentially the whole machine. The example given shows how to report in a single alert a ping-of-death attack from one source against 3 hosts. Each of the target hosts is reported in a different manner. The alert conveys the message that all three were concerned. However, the data model does not specify which host was the first, second or third target. Alert.version = 1 Alert.alertID = 113123 Alert.confidence = 100 Alert.impact = 25 Alert.success = 10 Alert.method = 1 Alert.name = cve.CVE-1999-128 Alert.signature = Oversized ICMP packet Alert.reaction = Firewall reconfigured Alert.Time.date = 1999/12/02 Alert.Time.time = 10:01:25 Alert.Time.milliseconds = 93464 Alert.Analyzer.sensorID = 3 Debar/Huang/Donahoo [Page 34] Internet Draft IDEFDM 21 January 2000 Alert.Analyzer.analyzerID = 2 Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.231.121 Alert.Target[1].Host.name = lollipop Alert.Target[2].Host.name = Cisco.router.b10 Alert.Target[2].Host.location = Cabinet B10 Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 222.121.111.112 6.1.3 The SYN-flood attack ******************************************************* * TODO * ******************************************************* 6.2 Use cases for scans 6.2.1 Connection to a denied service The simple type of scan is reported when the attacker tries to connect to an unavailable or forbidden port on a machine. Sniffers or simple wrappers (i.e. TCPWrappers[5]) can detect this type of situation. The message sent by the sensor would be: Alert.version = 1 Alert.alertID = 7395 Alert.confidence = 100 Alert.impact = 45 Alert.success = 60 Alert.name = policy.finger Alert.signature = Connection on finger port Alert.reaction = none Alert.Time.date = 1999/12/02 Alert.Time.time = 10:01:25 Alert.Time.milliseconds = 93464 Alert.Analyzer.sensorID = 3 Alert.Analyzer.analyzerID = 2 Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.231.121 Alert.Target[0].Host.name = myhost Alert.Target[0].Service.name = finger Debar/Huang/Donahoo [Page 35] Internet Draft IDEFDM 21 January 2000 Alert.Target[0].Service.dport = 79 Alert.Target[0].Service.sport = 31532 Alert.Source[0].spoofed = FALSE Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 222.121.111.112 Alert.Source[0].User.name = attacker Note that in this case, there is no exploitation of a vulnerability per se. Hence, the name of the attack follows an implementor-dependent scheme. Also, the user launching the attack on the source host could be determined and is transmitted. 6.2.2 Simple port scanning activity We define a simple port scan by connections request from one machine to another machine on a number (left as a parameter of the intrusion detec- tion sensor) of different services in a small amount of time (again, left to the configuration of the intrusion-detection sensor). Such a port scan would be reported with extended alert data. The first field of the extended alert data would be the number of ports touched, the second would be the time interval, and the remainder would identify inclusive port intervals as port number pairs. The alert represented here carries port scan information happening between 09:52:45 and 09:53:28, touching 501 ports, and intervals with ports queried include [5-25], [69-119] and [123-514]. Alert.version = 1 Alert.alertID = 79105235 Alert.confidence = 60 Alert.impact = 90 Alert.success = 10 Alert.method = 1 Alert.name = policy.portscan Alert.signature = Connection on more than 500 ports in less than 1 mn Alert.reaction = none Alert.Time.date = 1999/12/02 Alert.Time.time = 10:01:25 Alert.Time.milliseconds = 93464 Alert.Analyzer.idsID = 4275 Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.231.121 Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 222.121.111.112 ExtendedAlert.extVersion = 423 ExtendedAlert.AdditionalData[0].category = 21 Debar/Huang/Donahoo [Page 36] Internet Draft IDEFDM 21 January 2000 ExtendedAlert.AdditionalData[0].size = 2 ExtendedAlert.AdditionalData[0].data[0].date = 1999/12/02 ExtendedAlert.AdditionalData[0].data[0].time = 09:52:45 ExtendedAlert.AdditionalData[0].data[1].date = 1999/12/02 ExtendedAlert.AdditionalData[0].data[1].time = 09:53:28 ExtendedAlert.AdditionalData[1].category = 2 ExtendedAlert.AdditionalData[1].size = 1 ExtendedAlert.AdditionalData[1].data[0] = 501 ExtendedAlert.AdditionalData[2].category = 2 ExtendedAlert.AdditionalData[2].size = 2 ExtendedAlert.AdditionalData[2].data[0] = 5 ExtendedAlert.AdditionalData[2].data[1] = 25 ExtendedAlert.AdditionalData[3].category = 2 ExtendedAlert.AdditionalData[3].size = 2 ExtendedAlert.AdditionalData[3].data[0] = 69 ExtendedAlert.AdditionalData[3].data[1] = 119 ExtendedAlert.AdditionalData[4].category = 2 ExtendedAlert.AdditionalData[4].size = 2 ExtendedAlert.AdditionalData[4].data[0] = 123 ExtendedAlert.AdditionalData[4].data[1] = 514 6.3 Use cases for local attacks 6.3.1 The loadmodule attack The loadmodule attack involves invoking the loadmodule program on a SUN workstation to run another program. Since loadmodule is suid-root, the executed program runs as root. The alert reporting such activity could look like the following: Alert.version = 1 Alert.alertID = 1473 Alert.confidence = 100 Alert.impact = 100 Alert.success = 100 Alert.method = 1 Alert.name = bugtraqid.33 Alert.signature = loadmodule forking shell Alert.reaction = none Alert.Time.date = 1999/10/21 Alert.Time.time = 08:12:32 Alert.Analyzer.ident = 12345678 Alert.Target[0].Host.name = machine.domain.com Alert.Target[0].host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.345.456 Debar/Huang/Donahoo [Page 37] Internet Draft IDEFDM 21 January 2000 Alert.Source[0].User.name = joe Alert.Source[0].User.uid = 13243 Alert.Source[0].Process.name = /usr/openwin/bin/loadmodule Of course, the alert could be more precise and indicate that the target user is the root user, indicating that this is an attempt to run /bin/sh. Here the attack is successful and the impact large. In that case, the alert would look like: Alert.version = 1 Alert.alertID = 1473 Alert.confidence = 100 Alert.impact = 100 Alert.success = 100 Alert.method = 1 Alert.name = bugtraqid.33 Alert.signature = loadmodule forking shell Alert.reaction = none Alert.Time.date = 1999/10/21 Alert.Time.time = 08:12:32 Alert.Analyzer.ident = 12345678 Alert.Target[0].Host.name = machine.domain.com Alert.Target[0].host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.345.456 Alert.Target[0].User.name = root Alert.Target[0].Process.name = /bin/sh Alert.Target[0].Process.pid = 25134 Alert.Source[0].User.name = joe Alert.Source[0].User.uid = 13243 Alert.Source[0].Process.name = /usr/openwin/bin/loadmodule 6.3.2 The PHF attack The phf attack is a buffer overflow against an apache web server running the vulnerable phf script. In this case, the alert contains two addi- tional information items. The first is a set of three strings giving the url, the cgi script and the method. The second is a set of two numbers, the status code and the number of bytes returned in the reply. Alert.version = 1 Alert.alertID = 13251 Alert.confidence = 100 Alert.impact = 1 Debar/Huang/Donahoo [Page 38] Internet Draft IDEFDM 21 January 2000 Alert.success = 1 Alert.method = 1 Alert.name = bugtraqid.629 Alert.signature = /.*http[w+]bin//phf?/ Alert.reaction = none Alert.Time.date = 1999/10/21 Alert.Time.time = 08:12:32 Alert.Analyzer.ident = 12345678 Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 123.234.231.121 Alert.Target[0].Service.dport = 8080 Alert.Target[0].Service.sport = 21534 Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 222.121.111.112 ExtendedAlert.extVersion = 28 ExtendedAlert.AdditionalData[0].category = 5 ExtendedAlert.AdditionalData[0].size = 3 ExtendedAlert.AdditionalData[0].data[0] = http://www.my.net/cgi-bin/phf? /etc/group ExtendedAlert.AdditionalData[0].data[1] = /cgi-bin/phf ExtendedAlert.AdditionalData[0].data[2] = GET ExtendedAlert.AdditionalData[1].category = 3 ExtendedAlert.AdditionalData[1].size = 2 ExtendedAlert.AdditionalData[1].data[0] = 404 ExtendedAlert.AdditionalData[1].data[1] = 2048 6.4 Use cases for system policy usage System policy usage is a report by an intrusion-detection system that a particular policy has been violated. 6.4.1 Night login In this example, logging into the monitored system is restricted to business hours. The alert reports a violation of user "Louis" logging in during the night to machine003 from localhost, which in that case is a spoofed address with a good certainty. In addition, the extended alert reports the allowed times of login for this user during this day as a time interval. Alert.version = 1 Alert.alertID = 25616 Alert.confidence = 100 Alert.impact = 60 Alert.success = 100 Alert.method = 1 Debar/Huang/Donahoo [Page 39] Internet Draft IDEFDM 21 January 2000 Alert.name = policy.out-of-hours -activity Alert.signature = User activity outside of normal hours Alert.reaction = none Alert.Time.date = 1999/10/21 Alert.Time.time = 02:15:32 Alert.Analyzer.ident = 12345678 Alert.Target[0].Host.name = machine003.mydomain Alert.Target[0].Host.Address.category = 11 Alert.Target[0].Host.Address.data = 10.10.10.24 Alert.Target[0].Service.name = login Alert.Target[0].Service.dport = 23 Alert.Target[0].Service.sport = 4235 Alert.Target[0].Process.pid = 426 Alert.Target[0].User.name = Louis Alert.Target[0].User.uid = 501 Alert.Target[0].User.gid = 500 Alert.Source[0].confidence = 80 Alert.Source[0].spoofed = TRUE Alert.Source[0].Host.Address.category = 11 Alert.Source[0].Host.Address.data = 127.0.0.1 ExtendedAlert.extVersion = 2 ExtendedAlert.AdditionalData[0].category = 21 ExtendedAlert.AdditionalData[0].size = 2 ExtendedAlert.AdditionalData[0].data[0].time = 07:00:00 ExtendedAlert.AdditionalData[0].data[1].time = 19:30:00 6.4.2 Modification of a protected file ******************************************************* * TODO * ******************************************************* ******************************************************* * This section also needs examples on the correlation * * of alerts - How to send more complex alerts. * ******************************************************* 7 Security considerations Debar/Huang/Donahoo [Page 40] Internet Draft IDEFDM 21 January 2000 This memo describes a data format for security related products usage. In that respect, the transport protocol used to move this data between communicating entities has to be secure. The data format itself does not have security considerations. 8 Bibliography [1] S. Bradner, "Key words for use in RFCs to indicate requirement lev- els," Request for Comments (Best Current Practice) 2119, Internet Engi- neering Task Force, mar 1997. [2] M. Wood, "Intrusion detection exchange format requirements," inter- net draft, Internet Engineering Task Force, jul 1999. Work in progress. [3] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual Addison-Wesley, 1997. [4] S. Christey, Mann, and Hill, "Development of a common vulnerability enumeration." Workshop RAID99, September 1999. [5] W. Venema, "Tcp wrapper: Network monitoring, access control and booby traps," in Proceedings of the Third Usenix UNIX Security Symposium , (Baltimore, Md), pp. 85--92, September 1992. Debar/Huang/Donahoo [Page 41] Internet Draft IDEFDM 21 January 2000 Acknowledgments The following individuals contributed substantially to this document and should be recognized for their efforts. This document would not exist without their help: Dominique Alessandri IBM Corporation James L. Burden California Independent System Operator Dave Curry Internet Security Systems, Inc. Marc Dacier IBM Corporation Glenn Mansfield Cyber Solutions, Inc. James Riordan IBM Corporation Stephane Schitter IBM Corporation Michael J. Slifcak Internet Security Systems, Inc Michael Steiner University of Saarland Steven R. Snapp CyberSafe Corporation Maureen Stillman Nokia IP Telephony Vimal Vaidya AXENT Andreas Wespi IBM Corporation Eric D. Williams Information Brokers, Inc. S.Felix Wu North Carolina State University Editor's Address: Herve Debar IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland Tel: +41 1 724 8499 Email: deb@zurich.ibm.com Intrusion Detection Exchange Format Working Group The Intrusion Detection Exchange Format Working Group can be contacted via the working group's mailing list (idwg-public@zurich.ibm.com) or through its chairs: Stuart Staniford-Chen stuart@SiliconDefense.com Silicon Defense Mike Erlinger mike@cs.hmc.edu Harvey Mudd College Debar/Huang/Donahoo [Page 42] Internet Draft IDEFDM 21 January 2000 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or ref- erences to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed. Debar/Huang/Donahoo [Page 43]