Internet Engineering Task Force IDWG Internet Draft Debar/Huang/Donahoo draft-ietf-idwg-data-model-00.txt IBM Corp./The Boeing Company/AFIWC 15 October 1999 Expires: March 18th, 2000 Intrusion Detection Exchange Format Data Model draft-ietf-idwg-data-model-00.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@csc.com 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 March 18th, 2000. Debar/Huang/Donahoo [Page 1] Internet Draft IDEFDM 15 October 1999 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 a class hierarchy answers these questions . . . . . . 5 3.3 Design goals . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1 Represent events . . . . . . . . . . . . . . . . . . . . 7 3.3.2 Content driven . . . . . . . . . . . . . . . . . . . . . 7 3.3.3 Transport issues . . . . . . . . . . . . . . . . . . . . 7 3.3.4 Segmentation . . . . . . . . . . . . . . . . . . . . . . 8 3.3.5 Relationship between alerts . . . . . . . . . . . . . . . 8 4 Data analysis . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Analysis of network-based IDSes alert data . . . . . . . 9 4.1.1 Port scan attack . . . . . . . . . . . . . . . . . . . . 9 4.1.2 IP spoofing . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3 SYN Flood Attack . . . . . . . . . . . . . . . . . . . . 10 4.1.4 Buffer overflow . . . . . . . . . . . . . . . . . . . . . 10 4.2 Analysis of Host-based IDSes alert data . . . . . . . . . 11 4.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 5 Basic types . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 Simple types . . . . . . . . . . . . . . . . . . . . . . 12 5.2 The RANGE ([]) construct . . . . . . . . . . . . . . . . 13 5.3 Complex types . . . . . . . . . . . . . . . . . . . . . . 13 5.3.1 The STRBUFFER type . . . . . . . . . . . . . . . . . . . 14 5.3.2 The FILLER type . . . . . . . . . . . . . . . . . . . . 15 5.3.3 The USERID type . . . . . . . . . . . . . . . . . . . . 15 5.3.4 the USERINFO type . . . . . . . . . . . . . . . . . . . 16 5.3.5 The ADDRESSID type . . . . . . . . . . . . . . . . . . . 17 5.3.6 The FILEID type . . . . . . . . . . . . . . . . . . . . 17 5.3.7 The HOSTID type . . . . . . . . . . . . . . . . . . . . 18 5.3.8 The PROCESSID type . . . . . . . . . . . . . . . . . . . 19 5.3.9 The SERVICEID type . . . . . . . . . . . . . . . . . . . 19 5.3.10 The TIME type . . . . . . . . . . . . . . . . . . . . . 20 5.3.11 The IDSID type . . . . . . . . . . . . . . . . . . . . . 21 6 The alert classes . . . . . . . . . . . . . . . . . . . . 22 6.1 Class diagram . . . . . . . . . . . . . . . . . . . . . . 22 6.2 Classes definition . . . . . . . . . . . . . . . . . . . 24 6.2.1 Class ALERT . . . . . . . . . . . . . . . . . . . . . . . 24 6.2.2 Class A_WEIRD . . . . . . . . . . . . . . . . . . . . . . 26 6.2.3 Class A_MULTIPLEHOSTS . . . . . . . . . . . . . . . . . . 27 6.2.4 Class AM_RANGEID . . . . . . . . . . . . . . . . . . . . 27 6.2.5 Class A_SINGLEHOST . . . . . . . . . . . . . . . . . . . 28 6.2.6 Class AS_SPOOFEDORIGIN . . . . . . . . . . . . . . . . . 29 6.2.7 Class ASS_SINGLESERVICE . . . . . . . . . . . . . . . . . 30 Debar/Huang/Donahoo [Page 2] Internet Draft IDEFDM 15 October 1999 6.2.9 Class ESSM_SERVICERANGE . . . . . . . . . . . . . . . . . 31 6.2.10 Class AS_APPLICATION . . . . . . . . . . . . . . . . . . 31 6.2.11 Class ASA_MULTIPLEUSERS . . . . . . . . . . . . . . . . . 32 6.2.12 Class ASA_USER . . . . . . . . . . . . . . . . . . . . . 33 6.2.13 Class ASAU_TARGETUSER . . . . . . . . . . . . . . . . . . 33 6.2.14 Class ASAU_TARGETFILE . . . . . . . . . . . . . . . . . . 34 6.2.15 Class AS_REALORIGIN . . . . . . . . . . . . . . . . . . . 34 6.2.16 Class ASR_TOOL . . . . . . . . . . . . . . . . . . . . . 35 6.2.17 Class ASR_CRASHPACKET . . . . . . . . . . . . . . . . . . 35 6.2.18 Class ASR_ICMP . . . . . . . . . . . . . . . . . . . . . 36 6.2.19 Class ASR_MULTIPLESERVICES . . . . . . . . . . . . . . . 37 6.2.20 Class ASRM_SERVICERANGE . . . . . . . . . . . . . . . . . 37 6.2.21 Class ASR_SINGLESERVICE . . . . . . . . . . . . . . . . . 38 6.2.22 Class ASRS_EMAIL . . . . . . . . . . . . . . . . . . . . 39 6.2.23 Class ASRS_USER . . . . . . . . . . . . . . . . . . . . . 39 6.2.24 Class ASRS_DNSCMD . . . . . . . . . . . . . . . . . . . . 40 6.2.25 Class ASRS_SNMP . . . . . . . . . . . . . . . . . . . . . 40 6.2.26 Class ASRSS_ACTIVITY . . . . . . . . . . . . . . . . . . 41 6.2.27 Class ASRS_PASSDECODE . . . . . . . . . . . . . . . . . . 42 6.2.28 Class ASRS_CMDDECODE . . . . . . . . . . . . . . . . . . 42 6.2.29 Class ASRSC_USERINFO . . . . . . . . . . . . . . . . . . 43 6.2.30 Class ASRS_THIRDHOST . . . . . . . . . . . . . . . . . . 43 6.2.31 Class ASRST_USERINFO . . . . . . . . . . . . . . . . . . 44 6.2.32 Class ASRS_FILEACCESS . . . . . . . . . . . . . . . . . . 44 6.2.33 Class ASRS_RIP . . . . . . . . . . . . . . . . . . . . . 45 6.2.34 Class ASRS_DISTANTCNT . . . . . . . . . . . . . . . . . . 45 6.2.35 Class ASRS_STRINGMATCH . . . . . . . . . . . . . . . . . 46 6.2.36 Class ASRS_TROJAN . . . . . . . . . . . . . . . . . . . . 47 6.2.37 Class ASRS_WEBSERVER . . . . . . . . . . . . . . . . . . 47 6.2.38 class ASRSW_PRIVILEGEDCMD . . . . . . . . . . . . . . . . 48 6.2.39 Class ASRSW_INSECURECGI . . . . . . . . . . . . . . . . . 49 7 Examples of use of the class hierarchy . . . . . . . . . 49 7.1 Conventions for the examples . . . . . . . . . . . . . . 49 7.2 Use cases for denial of service attacks . . . . . . . . . 49 7.2.1 The teardrop attack . . . . . . . . . . . . . . . . . . . 49 7.2.2 The ping of death attack . . . . . . . . . . . . . . . . 50 7.3 Use cases for scans . . . . . . . . . . . . . . . . . . . 51 7.3.1 Connection to a denied service . . . . . . . . . . . . . 51 7.3.2 Simple Portscanning activity . . . . . . . . . . . . . . 52 7.4 Use cases for network decode information . . . . . . . . 53 7.4.1 Protocol decode for FTP GET command . . . . . . . . . . . 53 7.5 Use cases for local attacks . . . . . . . . . . . . . . . 54 7.5.1 The loadmodule attack . . . . . . . . . . . . . . . . . . 54 7.6 Use cases for system policy usage . . . . . . . . . . . . 55 7.6.1 Night logging . . . . . . . . . . . . . . . . . . . . . . 56 8 Implementation considerations . . . . . . . . . . . . . . 56 9 Security considerations . . . . . . . . . . . . . . . . . 56 10 Bibliography . . . . . . . . . . . . . . . . . . . . . . 57 Debar/Huang/Donahoo [Page 3] Internet Draft IDEFDM 15 October 1999 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]. The key words "REQUIRED" and "OPTIONAL" are further defined in section 5.3, but this definition should also be understood within the context of RFC-2112[1]. In addi- tion, the key words "CONSTANT" and "EITHERONE" are also defined in sec- tion 5.3 The data structure is represented as a hierarchy of classes. The graphic representation is inspired from the Universal Modeling Language (UML)[2]. The graphic representation of the class diagram following the UML standard is available as a separate PDF file. 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[3]. The reasons for proposing a class hierarchy as the data representation format of the IDWG are: 1. Alert information describing attacks is inherently heteroge- neous. Certain attacks are defined with very little informa- tion, such as origin, destination, name and time of the attack. Other attacks provide much more context, such as ports Debar/Huang/Donahoo [Page 4] Internet Draft IDEFDM 15 October 1999 or services, processes, user information, and others. There- fore, 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 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 be able to transport information provided other tools than intrusion detection sensors, provided that an adapter level realizes the adaptation between the tool format (e.g. syslog) and the idwg format. In that case, it is expected that the adapter will fill in fields of the classes in place of the tool to preserve the uniformity of the format. 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 repre- sentation format 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 a class hierarchy answers these questions Each point in this section constitutes an answer to the corresponding question raised in the previous section. 1. The class hierarchy allows one to subclass alert information to any level of the hierarchy. Very simple alerts will be sub- classed from classes higher in the inheritance tree, while complex alerts will be subclassed from classes that are leaves of the inheritance tree. Debar/Huang/Donahoo [Page 5] Internet Draft IDEFDM 15 October 1999 2. The data model defines complex types that accommodate the dif- ferences in data sources among tools. In particular, the notion of source and destination for the attack are repre- sented by the combination of HOSTID and SERVICEID types. The HOSTID type represents computing equipment in the general sense (i.e. a host). The SERVICEID type represents both net- work type information (ports, service names) and host-type information (user, process). 3. This distinction between lightweight clients and complex clients is addressed by the inheritance mechanism of the class diagram. Some subtrees (i.e. MULTIPLEHOSTS) of the class hier- archy are aimed at complex clients, while others are designed for lightweight clients. 4. The reporting flexibility is brought by the definition of the HOSTID and SERVICEID complex types. 5. Vendors may want to provide more information about alerts. To do so, they may subclass the leaf classes of the tree. This provides additional flexibility to the vendors, while ensuring that a common subset of information about the attack is avail- able. At the same time, this class hierarchy will force ven- dors to update the information they provide about an alarm to make sure that they have not omitted important elements. The idea of using a class hierarchy brings the following benefits: Alerts follow an object-oriented paradigm, allowing all notions of object orientation to be preserved. Moreover, many programming languages today are "object-oriented", which should ease implementation of the data format. The class hierarchy allows different formats in a consistent way. In particular, subclassing is the natural way to extend the class hierarchy as new characteristics of Alerts are discovered (which could be related to new attacks). We need a mechanism to update the standard when needed to reflect advances in technology, in the same way that SNMP MIBs are updated. Extension by subclassing of non-leaf classes should always be considered carefully and reserved to events introducing new characteris- tics. Subclassing of leaf classes is the natural way to provide more information about a known event. There are a number of approaches that have been followed to make class information persistent or to transmit it over the network. The format Debar/Huang/Donahoo [Page 6] Internet Draft IDEFDM 15 October 1999 can benefit from the use of these approaches to fulfill these require- ments. 3.3 Design goals 3.3.1 Represent events The goal of the data model is to carry alerts generated by intrusion- detection sensors. These alerts may or may not describe an attack. They may be simple or complex, depending on the capability of the intrusion- detection sensor that creates them. Alerts are not bound to attacks. Alerts provide a facility to describe the kind of technology used in the discovery or generation of the alert, but alert generation technology (host versus network based, knowledge versus behavior based) does not influence the definition of classes and fields. 3.3.2 Content driven The design of the class hierarchy is content-driven. This means that subclassing has been introduced mainly to accommodate additional con- tent, not semantic differences between the alarms. This is an important goal as the task of classifying and naming computer vulnerabilities is extremely difficult and subjective. The class hierarchy must be unambiguous. When reported by two different tools, alarms that concern the same attack must be on the same inheri- tance path. This means that we allow tools to be more or less precise than one another, but we do not allow them to produce divergent informa- tion about an alarm. Two tools must not report the same alarm with classes located on two different inheritance paths. 3.3.3 Transport issues The design of the class hierarchy must facilitate transport and process- ing. To this aim, the use of EITHERONE or OPTIONAL fields (see section 5) is limited to well-understood types. The class hierarchy mandates the provision of information by the intru- sion detection sensors by making all fields REQUIRED. The flexibility in the kind of data submitted by the sensor is provided by variable fields in the complex types. Complex types have mandatory and optional fields. A simple mechanism should be provided to indicate to the transport mechanism, which of the optional fields are filled, so that only the content of these optional fields has to be transmitted. Debar/Huang/Donahoo [Page 7] Internet Draft IDEFDM 15 October 1999 3.3.4 Segmentation The segmentation of classes is the following: the first level of segmen- tation concerns the target of the alert. Differences highlighted at this level focus on the number of targets: no target, one target or multiple targets. The target segmentation was put first because it is believed that operators of intrusion detection systems are very concerned about which equipment is impacted by outside actions. The second level of segmentation deals with the source of the alert. At this level, we differentiate between a real origin and a fake one, both being network equipments. An additional origin is the local user, to describe alerts happening in a local only context (i.e. the source can- not be traced to a remote equipment). There is currently no provision for multiple origins into the attack. The third level identifies the number of network services involved: no network service (attack at the IP level for example), one service, or multiple services. In the last case, this typically represents portscan alerts. More sophisticated alerts with additional context information would be reported by multiple alerts of the SINGLESERVICE class. The fourth level identifies more information about the service involved in the alert. Certain services have well-known characteristics and the data model highlights them. The included services are also well-known targets and alert generators. Levels bellow the fourth are refinements of the particular services. The data model provides few of these. 3.3.5 Relationship between alerts Intrusion detection alerts can be transmitted at several levels. This draft applies to very simple alerts, alerts that are the result of a single action or operation in the system, such as a failed login report. It also applies to more complex alerts. An example of more complex alert is generally the aggregation of several actions in the system to gener- ate the alert, or the aggregation of several 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 8] Internet Draft IDEFDM 15 October 1999 4.1 Analysis 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 -------------------------------------------------------- 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 -------------------------------------------------------- 4.1.2 IP spoofing -------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------- Sensor Name | | Sensor Name -------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------- Actual Alarm String | | -------------------------------------------------- Debar/Huang/Donahoo [Page 9] Internet Draft IDEFDM 15 October 1999 Severity Level | | Severity Level -------------------------------------------------- Source IP | | Source IP -------------------------------------------------- MAC Address | | -------------------------------------------------- | | Protocol -------------------------------------------------- | | Begin Time -------------------------------------------------- | | End Time -------------------------------------------------- 4.1.3 SYN Flood Attack ---------------------------------------- IDS-A | IDS-B | IDS-C ---------------------------------------- Sensor Name | | ---------------------------------------- Date/Time | | ---------------------------------------- Actual Alarm String | | ---------------------------------------- Severity Level | | ---------------------------------------- Source IP | | ---------------------------------------- Destination IP | | ---------------------------------------- Half Open Connections | | ---------------------------------------- Terminated Connections | | ---------------------------------------- 4.1.4 Buffer overflow -------------------------------------------------- IDS-A | IDS-B | IDS-C -------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------- Debar/Huang/Donahoo [Page 10] Internet Draft IDEFDM 15 October 1999 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 -------------------------------------------------- 4.2 Analysis of Host-based IDSes alert data IDS-E | IDS-F | IDS-G ------------------------------------------------------------ Name | Event Type | ------------------------------------------------------------ Date/Time | Date/Time | ------------------------------------------------------------ User Name/Source IP | User Name/Source IP | ------------------------------------------------------------ Target System (IP/Name) | System Name | ------------------------------------------------------------ Priority | | ------------------------------------------------------------ Details | | ------------------------------------------------------------ | Sys Software | ------------------------------------------------------------ | Process ID# | ------------------------------------------------------------ | Session ID# | ------------------------------------------------------------ | Action Text | ------------------------------------------------------------ | Text Size | ------------------------------------------------------------ | Misc Pointer | ------------------------------------------------------------ Debar/Huang/Donahoo [Page 11] Internet Draft IDEFDM 15 October 1999 | Recursion Counter | ------------------------------------------------------------ | Match Clause | ------------------------------------------------------------ | Event Policy | ------------------------------------------------------------ | Rule Matched | ------------------------------------------------------------ | Action Clause (response) | ------------------------------------------------------------ 4.3 Analysis First, the information reported by different intrusion-detection systems concerning the same attack can be fairly different. This means that the proposed class hierarchy has to strike a sensible balance between infor- mation that is commonly regarded as important for describing the alert, and additional information (enhancements) proposed by the intrusion- detection vendor. The former must be part of the core class design, whereas the later can be accomodated through subclassing the core classes. Then, intrusion-detection sensors report the same kind of information under different names and formats, depending on their capabilities. For example, a network-based intrusion-detection system is more likely to provide network addresses, and a host-based system more likely to pro- vide host names and user names. The data format needs to accomodate these different ways to convey the same information, and this is achieved in the data model through the use of complex types. These com- plex types also allow to create the relation between these multiple views of the same object. 5 Basic types In order to define the data format, we need to define a number of basic types. These types are fairly straightforward and are categorized in two parts: simple and complex. The latter already represent objects. These types have been created to be compatible with the types described in the SNMP RFCs. 5.1 Simple types processing Debar/Huang/Donahoo [Page 12] Internet Draft IDEFDM 15 October 1999 -------------------------------------------------------------------- BOOLEAN The Boolean. -------------------------------------------------------------------- INTEGER The simple 16 bits integer, analogous to the Counter type in SNMP. -------------------------------------------------------------------- INT32 The simple 32 bits integer, analogous to the Counter32 type in SNMP. -------------------------------------------------------------------- INT64 The simple 64 bits integer. -------------------------------------------------------------------- REAL The real number over 64 bits. -------------------------------------------------------------------- CHARACTER The character type, 7-bits ANSI. -------------------------------------------------------------------- STRING A string of characters. This should be understood as []CHARACTER in the UML notation. The string contains a length and does not rely on termination characters. It can not contain characters outside the 7-bit ANSI; therefore we need an encoding for control characters. The STRING type should not be used to transport potentially overflowing data or data containing "strange" characters; the STRBUFFER type should be used instead (see section 5.3.1). -------------------------------------------------------------------- BYTE The usual byte (8-bits, no parity). -------------------------------------------------------------------- 5.2 The RANGE ([]) construct An additional construct used is the RANGE construct, denoted []. This construct denotes a complex structure based on the type, defining ordered lists of this type (i.e. arrays), intervals (i.e. `a-c' means all characters between 'a' and 'c' inclusive), or lists of RANGE. Inter- val bounds describe an ordered set. Characters and numbers are ordered according to the natural order. Well-known port names are ordered according to the IANA document. A possible realization of the RANGE construct is three lists. Two lists contain the lower and upper bounds of the intervals and have to be of equal length. The third list contains individual occurrences. 5.3 Complex types Complex types are classes, defined by a name and a list of associated fields. Fields have associated types and categories. Complex types may be implemented as classes. The name "complex type" is used instead of Debar/Huang/Donahoo [Page 13] Internet Draft IDEFDM 15 October 1999 "class" to differenciate between the basic building blocs and the alert class hierarchy. The category of the field takes one of the values {CON- STANT|REQUIRED|EITHERONE|OPTIONAL}. A CONSTANT field is a class value shared by all instances of the class. The intrusion detection sensor must fill a REQUIRED field. There must be either no or at least two EITHERONE fields in the classes. The EITHERONE keyword means that at least one of the EITHERONE fields in the structure must contain a value. The intrusion-detection sensor to provide additional information may fill an OPTIONAL field. Fields in the class descriptions and type descriptions must be ordered with CONSTANT fields first, then REQUIRED then EITHERONE, and finally OPTIONAL fields. These keywords are used with the same meaning in the class definitions. 5.3.1 The STRBUFFER type The STRBUFFER complex type is a container for string data that can potentially overflow. In that case, the container indicates whether the whole data was transmitted or not and what portion of it is covered by the content. ------------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------------- Mask FILLER CONSTANT 0x3F ------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ------------------------------------------------------------------- String STRING REQUIRED The part of the string which is transmitted. ------------------------------------------------------------------- Complete BOOLEAN REQUIRED Indicates whether the string is complete or not. ------------------------------------------------------------------- Encoding STRING OPTIONAL Indicates which kind of encoding is used for the transmitted string, if any. ------------------------------------------------------------------- FullSize INT64 OPTIONAL Indicates what the full size of the buffer was. ------------------------------------------------------------------- Start INT64 OPTIONAL Indicates the position of the first character of the transmitted string in the complete buffer. 1 indicates that Debar/Huang/Donahoo [Page 14] Internet Draft IDEFDM 15 October 1999 the transmitted string begins at the beginning of the complete buffer. ------------------------------------------------------------------- End INT64 OPTIONAL Indicates the position of the last character of the transmitted string in the complete buffer. End=FullSize indicates that the transmitted string is the end of the complete buffer. ------------------------------------------------------------------- 5.3.2 The FILLER type The FILLER complex type defines a BYTE indicating which of the follow- ing structure elements are filled. This type is used when describing the complex types in the following subsection. When a field of a complex type is categorized as EITHERONE or OPTIONAL, then the filler bit cor- responding to the entry should be set to 0 if the entry is empty, other- wise it should be set to one. The correspondence between the FILLER bit number and the number of the field in the complex type is the following: the first EITHERONE or OPTIONAL entry (if there are no EITHERONE entries) is represented by the least significant bit in the filler. Associated with the filler is a mask that indicates the effective range for the filler. An XOR operation of the filler and the mask with all bits set to 0 is an error if there are EITHERONE fields, because it means that none of the OPTIONAL fields relevant for this structure con- tains a value. 5.3.3 The USERID type The USERID type indicates the different ways by which a user can be identified. This should be applicable to all platforms. -------------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------------- Mask FILLER CONSTANT 0x1F -------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). -------------------------------------------------------------------- Type INTEGER REQUIRED The type of USERID transported. This type can indicate a normal UNIX user, an NT user, a mainframe user, an Debar/Huang/Donahoo [Page 15] Internet Draft IDEFDM 15 October 1999 application user, an email address, ... -------------------------------------------------------------------- UserName STRING EITHERONE The user name running the service or application. -------------------------------------------------------------------- UserID INT32 EITHERONE The user identification number of the user running the application or service. -------------------------------------------------------------------- GroupName STRING OPTIONAL The group name running the service or application. -------------------------------------------------------------------- GroupID INT32 OPTIONAL The group identification number of the group running the application or service. -------------------------------------------------------------------- 5.3.4 the USERINFO type The USERINFO complex type is an association between a user source and a user destination. The words source and destination are analogous to the hosts source and destination provided by certain attacks. This means that the source user in the USERINFO structure gives information about the user running on the source host, and the destination user gives information about the user running on the destination host. This notion is less ambiguous than the notion of originating user, or user creating the attack, or victim user. The context of the alarm should make clear which of the source or destination user is the attacker and victim. ------------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------------- Mask FILLER CONSTANT 0x1F ------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ------------------------------------------------------------------- UserSrc USERID EITHERONE The user associated with the action on the source host. ------------------------------------------------------------------- UserDst USERID EITHERONE The user associated with the action on the destination host. ------------------------------------------------------------------- PasswdSrc STRING OPTIONAL The password of the source user (if Debar/Huang/Donahoo [Page 16] Internet Draft IDEFDM 15 October 1999 relevant). ------------------------------------------------------------------- PasswdDst STRING OPTIONAL The password of the destination user (if relevant). ------------------------------------------------------------------- 5.3.5 The ADDRESSID type The ADDRESSID complex types carries address information. The address in question can be a network address, a hardware address or an application address. In the case of a network address, the type may be for example one of IPV4, IPV6, SNA or ATM. In the case of a hardware address, the type may be for example one of MAC or TR. In the case of an application address, the type maybe for example NOTES, ORACLE, AFS or SAP. ------------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------------ Mask FILLER CONSTANT 0x1F ------------------------------------------------------------------ Filler FILLER REQUIRED (see section 5.3.2). ------------------------------------------------------------------ Type STRING REQUIRED The type of address information. This encompasses network addresses, hardware addresses, or application addresses. ------------------------------------------------------------------ Address STRING REQUIRED The address information itself. The type information should allow transcription of the string into its original format. ------------------------------------------------------------------ Info STRING OPTIONAL Additional information provided along with the address. This can be the transcoding scheme if necessary. ------------------------------------------------------------------ 5.3.6 The FILEID type The FILEID complex type represents a file in the system. It is extended to any physical or logical device that can be accessed by the system. Network devices (for example eth0) are also covered in the FILEID type. Debar/Huang/Donahoo [Page 17] Internet Draft IDEFDM 15 October 1999 ------------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------------- Mask FILLER CONSTANT 0xF ------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ------------------------------------------------------------------- File STRING EITHERONE The name of the file. This field does not contain path information. ------------------------------------------------------------------- Path STRING EITHERONE The associated path. ------------------------------------------------------------------- Inode INT64 EITHERONE The associated inode or other hardware-related location method. ------------------------------------------------------------------- Device STRING EITHERONE The associated physical or virtual device, i.e. network device, mounted disk, or other. ------------------------------------------------------------------- 5.3.7 The HOSTID type The HOSTID type indicates the different ways by which a host or equip- ment on the network can be identified. ---------------------------------------------------------------------- Field Name Type Category Comment ---------------------------------------------------------------------- Mask FILLER CONSTANT 0x3F ---------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ---------------------------------------------------------------------- Identity STRING EITHERONE An equipment identifier that does not correspond to one of the following categories. This could be, for example, an inventory serial number. ---------------------------------------------------------------------- Name STRING EITHERONE The machine fully qualified domain name. ---------------------------------------------------------------------- Location STRING EITHERONE The location of the equipment. ---------------------------------------------------------------------- NetAddress ADDRESSID EITHERONE This can be an IPv4, an IPv6 address, an ATM address, and SNA address. ---------------------------------------------------------------------- Debar/Huang/Donahoo [Page 18] Internet Draft IDEFDM 15 October 1999 HWAddress ADDRESSID EITHERONE This is typically a MAC address, an interface name, ... ---------------------------------------------------------------------- AppAddress ADDRESSID EITHERONE This is typically the address seen at the application level, such as transaction monitors, collaborative software, databases, or other. ---------------------------------------------------------------------- 5.3.8 The PROCESSID type The PROCESSID type gathers information about the process that is being run. -------------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------------- Mask FILLER CONSTANT 0xF -------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). -------------------------------------------------------------------- Name STRING EITHERONE 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 fields. -------------------------------------------------------------------- Ident INTEGER EITHERONE The process identifier of the process being run. -------------------------------------------------------------------- Path STRING OPTIONAL The path of the program. -------------------------------------------------------------------- Environ STRING OPTIONAL The environment string in which the process is being run. This includes options, environment variables, and in general all parameters passed to the program by the runtime environment. -------------------------------------------------------------------- There is no information about users there. This information is included in the SERVICEID complex type. 5.3.9 The SERVICEID type The SERVICEID complex type identifies a network service request being carried out over the network. In particular, this type should be used to Debar/Huang/Donahoo [Page 19] Internet Draft IDEFDM 15 October 1999 report not only open services, but also connections and connections attempts. To do so, the type provides for identification of the source port from which the connection originated. In general, a service is a resource available either locally or remotely. This SERVICEID type should also be able to accommodate process informa- tion when using a host-based intrusion-detection paradigm. By extension, a service is any application that a local user is able to execute. Information in the Process and User fields should be consistent. ---------------------------------------------------------------------- Field Name Type Category Comment ---------------------------------------------------------------------- Mask FILLER CONSTANT 0x3F ---------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ---------------------------------------------------------------------- Name STRING EITHERONE The name of the service. This must be listed in the IANA list of well-known ports. ---------------------------------------------------------------------- Destport INTEGER EITHERONE The port to which the connection request is addressed. In many situations, this will be a well-known port. ---------------------------------------------------------------------- Sourceport INTEGER OPTIONAL The source port from which the connection originated. In many situations, this will be a high-numbered port. ---------------------------------------------------------------------- Protocol STRING OPTIONAL The protocol name. ---------------------------------------------------------------------- Process PROCESSID OPTIONAL Identification of the process related to the execution of the service or application. ---------------------------------------------------------------------- User USERID OPTIONAL Identification of the user under which the service or application is being run. ---------------------------------------------------------------------- 5.3.10 The TIME type The TIME complex type carries time information about the alert. Debar/Huang/Donahoo [Page 20] Internet Draft IDEFDM 15 October 1999 ------------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------------ Mask FILLER CONSTANT 0x1F ------------------------------------------------------------------ Filler FILLER REQUIRED (see section 5.3.2). ------------------------------------------------------------------ Unix INT64 EITHERONE The time as understood in the UNIX world (i.e. seconds since January 1970). ------------------------------------------------------------------ Time STRING EITHERONE The time in hh:mm:ss format (by default), or according to the Format field. ------------------------------------------------------------------ Date STRING EITHERONE The date in yyyy/mm/dd format (by default), or according to the Format field. Please note the four digits year! ------------------------------------------------------------------ Zone STRING OPTIONAL The timezone for the corresponding date. ------------------------------------------------------------------ Format STRING OPTIONAL The format for the date and time information, if provided. The same format is relevant to both fields. ------------------------------------------------------------------ 5.3.11 The IDSID type The IDSID complex type identifies the intrusion detection sensor that provided the alert. At the minimum, this is a 32-bits identifier unique over the organisation where the IDS system is deployed. Additional identification information is provided. This identification must uniquely identify an IDS sensor that is generating the alert. ---------------------------------------------------------------------- Field Name Type Category Comment ---------------------------------------------------------------------- Mask FILLER CONSTANT 0x7F ---------------------------------------------------------------------- Filler FILLER REQUIRED (see section 5.3.2). ---------------------------------------------------------------------- ID INT64 EITHERONE Some global identification number for the intrusion-detection sensor, Debar/Huang/Donahoo [Page 21] Internet Draft IDEFDM 15 October 1999 similar to a serial number. ---------------------------------------------------------------------- Sensor STRING EITHERONE Sensor identification. This identification is in the context of IDS installation in one organisation. The sensor information can be related to the console information, or global to the organisation. ---------------------------------------------------------------------- Console STRING EITHERONE Console identification. This identification is in the context of IDS installation in one organisation (company, department). It is required if the sensor identification is linked to the console. ---------------------------------------------------------------------- SensorID HOSTID EITHERONE Identification of the sensor by the machine it is running on. This is an alternate way of specifying the sensor, but does not satisfy completely the uniqueness of the identification (several IDS sensors can run on one machine) and therefore should be used with caution. ---------------------------------------------------------------------- ConsoleID HOSTID EITHERONE Identification of the console by the machine it is running on. ---------------------------------------------------------------------- SensorPID PROCESSID OPTIONAL Process information concerning the sensor. ---------------------------------------------------------------------- ConsolePID PROCESSID OPTIONAL Process information concerning the console. ---------------------------------------------------------------------- 6 The alert classes There is no method information provided by this diagram. 6.1 Class diagram This is a simple ASCII representation of the class diagram. The full class diagram is available in the postscript version of the RFC, or is available as an associated PDF. This is automatically generated from the complete class description in section 6.2, which should be considered the reference material. Debar/Huang/Donahoo [Page 22] Internet Draft IDEFDM 15 October 1999 ALERT +------A_WEIRD +------A_MULTIPLEHOSTS | +------AM_RANGEID +------A_SINGLEHOST +------AS_SPOOFEDORIGIN | +------ASS_SINGLESERVICE | +------ASS_MULTIPLESERVICES | +------ESSM_SERVICERANGE +------AS_APPLICATION | +------ASA_MULTIPLEUSERS | +------ASA_USER | +------ASAU_TARGETUSER | +------ASAU_TARGETFILE +------AS_REALORIGIN +------ASR_TOOL +------ASR_CRASHPACKET +------ASR_ICMP +------ASR_MULTIPLESERVICES | +------ASRM_SERVICERANGE +------ASR_SINGLESERVICE +------ASRS_EMAIL +------ASRS_USER +------ASRS_DNSCMD +------ASRS_SNMP | +------ASRSS_ACTIVITY +------ASRS_PASSDECODE +------ASRS_CMDDECODE | +------ASRSC_USERINFO +------ASRS_THIRDHOST | +------ASRST_USERINFO +------ASRS_FILEACCESS +------ASRS_RIP +------ASRS_DISTANTCNT +------ASRS_STRINGMATCH +------ASRS_TROJAN +------ASRS_WEBSERVER +------ASRSW_INSECURECGI +------ASRSW_PRIVILEGEDCMD Debar/Huang/Donahoo [Page 23] Internet Draft IDEFDM 15 October 1999 6.2 Classes definition Each class is described following the same template. The template iden- tifies the following elements: Is-a-kind-of: indicates the superclass of the class Comment: explains the use of the class Defines: is a table containing each field of the class along with its type, its category (one of REQUIRED or OPTIONAL), and additional comments about the use of the field. Subclasses: gives the list of derived classes Each of these template elements is present in all class definitions. When they are not relevant to the definition of the class, they are left blank. 6.2.1 Class ALERT Is-a-kind-of: . Comment: This is the top level of the hierarchy. As such, it does not have a superclass, but we might provide one in the case of bindings to OIDs in the SNMP world. The alert class defines the bare minimum information that every intrusion-detection system must provide for every alert to be IDWG-compliant. However, intrusion-detection systems should use subclasses to report alert information. Subclassing or using the alert class is only acceptable in two cases, when the intrusion--detection system wishes to report some internal condition which has no destination or source involved (e.g. out of memory, out of disk, dump core, ...), or when an entirely new class of intrusion-detection systems appear. Since it is extremely likely that alerts should contain a tar- get, the later case should not happen before the standard is revised. The alert class does not carry information about the success of the alert, i.e. if the compromise attempt was successful or not. The rational is for not including this information is Debar/Huang/Donahoo [Page 24] Internet Draft IDEFDM 15 October 1999 that it is not relevant to all alerts. However, alerts can indicate a measure of success by a combination of Severity and Priority. Defines: ------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------- Priority INTEGER REQUIRED The priority with which the alert should be processed by the receiving end. ------------------------------------------------------------- Date TIME REQUIRED The date/time information associated with the alert. The class hierarchy expects that all alerts will have a timestamp identifying their date and time of creation. If other time information has to be included in the alert, it should be defined in another field. ------------------------------------------------------------- Severity REAL REQUIRED The sensitivity level associated with the alert. Most products provide integer values. However, when combining complex alarms, the combination formula might result in a real value. We need a range of acceptable values, with a definition of which value is the most critical. ------------------------------------------------------------- Idsid IDSID REQUIRED The IDS component that sent the alert. ------------------------------------------------------------- Signature STRING REQUIRED The signature that triggered the creation of the alert. By signature, we understand much more than a simple pattern matching. It can also be a policy rule that was violated, a profile that was modified, or other, depending on the IDS technology used. ------------------------------------------------------------- Debar/Huang/Donahoo [Page 25] Internet Draft IDEFDM 15 October 1999 Trust REAL REQUIRED The trust that can be put in the deduction. This value indicates whether the sensor considers that its result is good, or not. We need a range of acceptable values, with a definition of which value is the most critical. ------------------------------------------------------------- Method INTEGER REQUIRED An indication of the detection method. We currently mean behavior or knowledge. We should/might want a list of recognized detection method classes. ------------------------------------------------------------- Name STRING REQUIRED The name of the vulnerability. This should be understood as a free-form STRING provided by the vendor. An empty string is also acceptable. The naming scheme should follow the CVE[4] recommendations to provide a uniform naming space. ------------------------------------------------------------- Subclasses: A_WEIRD, A_MULTIPLEHOSTS, A_SINGLEHOST 6.2.2 Class A_WEIRD Is-a-kind-of: ALERT Comment: This class is a container for alerts that would be reported as strange by an intrusion detection sensor, but would not have any qualification of source and destination. This refers to the comment that internal IDS conditions should be reported as members of the Alert class. Therefore, this A_Weird class definition is purely semantic. Debar/Huang/Donahoo [Page 26] Internet Draft IDEFDM 15 October 1999 Defines: . Subclasses: . 6.2.3 Class A_MULTIPLEHOSTS Is-a-kind-of: ALERT Comment: This class is intended to carry more complex alerts that concern several targets in a single domain. An example of such an alert would be a wide scan, where one source tries to con- nect to the same service on different target equipment. Since very simple counters would just count but not keep trace of the source and destination, this class only provides counter information. Destination identifications are provided by sub- classing. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Number INTEGER REQUIRED The number of pieces of destination equipment that are concerned by the alert. ------------------------------------------------------------ Subclasses: AM_RANGEID 6.2.4 Class AM_RANGEID Is-a-kind-of: A_MULTIPLEHOSTS Comment: This class covers with ranges of network devices that are given inside an alert. All network devices involved in the alert are identified by a HOSTID. Debar/Huang/Donahoo [Page 27] Internet Draft IDEFDM 15 October 1999 Defines: -------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------- Dst []HOSTID REQUIRED The list contains lists of both single HOSTID and intervals of HOSTID. Intervals have to be on a measure that makes sense (i.e. network/netmask, or domain). -------------------------------------------------------------- Src HOSTID REQUIRED The identified source of the alert, as far as the intrusion detection sensor can determine. The confidence that can be put in the content of this field is a function of the intrusion detection sensor. -------------------------------------------------------------- Subclasses: . 6.2.5 Class A_SINGLEHOST Is-a-kind-of: ALERT Comment: Most simple alerts coming from intrusion detection sensors are expected to be in this hierarchy. The first component being highlighted in the alert is the destination/target of the alert. The destination of the attack is either the recipi- ent of the action in the case of a remote attack (e.g. desti- nation of the IP packet, host name to which the attacker logs in), or the host on which the action is carried out in the case of a local attack. Remote attacks for which the intru- sion-detection system has no information concerning the remote host should be reported at this level or using the AS_APPLICA- TION subclass hierarchy. Defines: Debar/Huang/Donahoo [Page 28] Internet Draft IDEFDM 15 October 1999 ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- Dst HOSTID REQUIRED The destination of the alert. This is the equipment to which the request (e.g. network packet) is destinated, or the equipment on which the request is executed (e.g. running a program). ----------------------------------------------------------- Subclasses: AS_SPOOFEDORIGIN, AS_APPLICATION, AS_REALORIGIN 6.2.6 Class AS_SPOOFEDORIGIN Is-a-kind-of: A_SINGLEHOST Comment: Some attacks require spoofing the origin of the packet. This set of subclasses contains alerts for which we are cer- tain that the source address is not the origin of the alert. A typical example of this class of alerts is the Land attack, when source and destination addresses are the same. When it is not possible to determine if the address is false, then the AS_REALORIGIN subclass hierarchy is used (even though the address may still be wrong). Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- SpoofSrc HOSTID REQUIRED This is the spoofed source address given by the intrusion detection sensor. ----------------------------------------------------------- Subclasses: ASS_MULTIPLESERVICES, Debar/Huang/Donahoo [Page 29] Internet Draft IDEFDM 15 October 1999 ASS_SINGLESERVICE 6.2.7 Class ASS_SINGLESERVICE Is-a-kind-of: AS_SPOOFEDORIGIN Comment: This class additionally describes the service being attacked from the spoofed address. Defines: --------------------------------------------------------- Field Name Type Category Comment --------------------------------------------------------- Service SERVICEID REQUIRED Description of the target service. --------------------------------------------------------- Subclasses: . 6.2.8 Class ASS_MULTIPLESERVICES Is-a-kind-of: AS_SPOOFEDORIGIN Comments: This class covers alerts indicating that multiple ser- vices have been attacked from the spoofed address. The minimal information to report there is the number of services that have been probed or involved. The lists and ranges of elements that have been probed or involved are reported in a subclass. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Number INTEGER REQUIRED The number of destination services that are concerned by the alert. ------------------------------------------------------------ Debar/Huang/Donahoo [Page 30] Internet Draft IDEFDM 15 October 1999 Subclasses: ESSM_SERVICERANGE 6.2.9 Class ESSM_SERVICERANGE Is-a-kind-of: ASS_MULTIPLESERVICES Comments: When a range is specified, the Number field associated with the parent class must contain the size of the range, i.e. the number of services comprised between the low and high ser- vices. When ranges are specified, they should indicate that all services in the range have been affected by the alert. Defines: ----------------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------------- Services []SERVICEID REQUIRED This is the list of services which are involved in the alert. Each element of the list is either an individual service or a service interval (see definition of the range construct [] in section 5.2). This list can have one lement if this element is a service interval, otherwist it has at least two elements. ----------------------------------------------------------------- Subclasses: . 6.2.10 Class AS_APPLICATION Is-a-kind-of:] A_SINGLEHOST Comments: This class represents alerts that are happening on the local machine. In most cases, this means that the attack is being run locally. Examples of such alerts include reading passwords on a Windows 95 box, the SUN loadmodule, certain symlink vulnerabilities. An alert of this class means that the Debar/Huang/Donahoo [Page 31] Internet Draft IDEFDM 15 October 1999 attack/anomaly is carried out locally. It does not mean that the attacker/perpetrator is local to the device. For example, the loadmodule attack would be reported by the same alert, irrespectively of the fact that the user is logged in on the console (physical presence) or remotely connected via telnet. To report the second case completely, two such alerts have to be generated, one for the connection and one for the local action. Most intrusion-detection systems should provide alerts in this part of the class hierarchy, which is the most detailed. Defines: --------------------------------------------------------- Field Name Type Category Comment --------------------------------------------------------- Service SERVICEID REQUIRED Description of the target application. --------------------------------------------------------- Subclasses: ASA_MULTIPLEUSERS, ASA_USER, ASAU_TARGETUSER, ASAU_TARGETFILE 6.2.11 Class ASA_MULTIPLEUSERS Is-a-kind-of: AS_APPLICATION Comments: This class covers alerts providing information when several users are triggering the alert. Defines: -------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------- Users []USERID REQUIRED Description of the target users as a list of users. -------------------------------------------------------------- Debar/Huang/Donahoo [Page 32] Internet Draft IDEFDM 15 October 1999 Subclasses: . 6.2.12 Class ASA_USER Is-a-kind-of: AS_APPLICATION Comments: In addition to the host and service information, this class contains information about the user triggering the cre- ation of the alert (i.e. the malicious user). Defines: ---------------------------------------------------- Field Name Type Category Comment ---------------------------------------------------- User USERID REQUIRED Description of the user triggering the alert. ---------------------------------------------------- Subclasses: . 6.2.13 Class ASAU_TARGETUSER Is-a-kind-of: ASA_USER Comments: In addition to the host, service and trigger user, this class contains information about the user that is the target of the attack. This class describes for example masquerading alerts, or "SU" alerts. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ TargetUser USERID REQUIRED Description of the target user, i.e. the identity that the malicious ("trigger") user Debar/Huang/Donahoo [Page 33] Internet Draft IDEFDM 15 October 1999 wants to assume. ------------------------------------------------------------ Subclasses: . 6.2.14 Class ASAU_TARGETFILE Is-a-kind-of: ASA_USER Comments: In addition to the host, service and trigger user, this class contains information about the file that is the target of the alert. This class describes for example file modifica- tion alerts. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ TargetFile FILEID REQUIRED Description of the target file. ------------------------------------------------------------ Subclasses: . 6.2.15 Class AS_REALORIGIN Is-a-kind-of: A_SINGLEHOST Comments: This class contains alerts for that there is no way to differentiate between a spoofed origin and the real source of the alert. This does not mean that the intrusion-detection sensor makes any guaranty that the source given in the alert is the one that actually carried out the alert. Defines: Debar/Huang/Donahoo [Page 34] Internet Draft IDEFDM 15 October 1999 -------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------- Source HOSTID REQUIRED The presumed source of the attack according to the intrusion detection sensor. -------------------------------------------------------- Subclasses: ASR_TOOL, ASR_CRASHPACKET, ASR_ICMP, ASR_MULTIPLESERVICES, ASR_SINGLESERVICE 6.2.16 Class ASR_TOOL Is-a-kind-of: AS_REALORIGIN Comment: This class groups information concerning the detection of tool activity, such as SATAN, ISS, or others. Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- Tool STRING REQUIRED The name of the tool. We might need a set of standard names, such as ISSvX.X, COPS, Tiger, Satan, ATP, Nessus, Nmap, ... ----------------------------------------------------------- Subclasses: . 6.2.17 Class ASR_CRASHPACKET Is-a-kind-of: AS_REALORIGIN Debar/Huang/Donahoo [Page 35] Internet Draft IDEFDM 15 October 1999 Comment: This class covers alerts related to anomalies in network traffic, for example packets not conformant to the protocol specifications (i.e. fragment overlaps, strange flags). Exam- ples of such alerts include denial of services alerts such as ping-of-death or teardrop-fragment. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Protocol STRING REQUIRED The name of the targeted protocol. We might need a set of standard names, such as ip, tcp, udp, ... ------------------------------------------------------------ Subclasses: . 6.2.18 Class ASR_ICMP Is-a-kind-of: AS_REALORIGIN Comment: This class groups attacks related to ICMP traffic. The typical attacks covered by this class are ping floods (or other kinds of ICMP floods), but also BGP, EGP and other low- level protocols. ARP/RARP is also a candidate here. Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- Code INTEGER REQUIRED The ICMP code provided by the sensor. ----------------------------------------------------------- Type INTEGER REQUIRED The ICMP type provided by the sensor. ----------------------------------------------------------- Debar/Huang/Donahoo [Page 36] Internet Draft IDEFDM 15 October 1999 Subclasses: . 6.2.19 Class ASR_MULTIPLESERVICES Is-a-kind-of: AS_REALORIGIN Comment: This class covers attacks that involve two machines, but span over a list of services or applications. The total number of services or applications involved must be reported. When using ranges, this means the size of the interval. Defines: ------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------- Number INTEGER REQUIRED The number of services involved in the alert. This is the total number, as far as the intrusion detection sensor can determine. ------------------------------------------------------------- Subclasses: ASRM_SERVICERANGE 6.2.20 Class ASRM_SERVICERANGE Is-a-kind-of: ASR_MULTIPLESERVICES Comment: This class contains both lists of services that have been touched by the attack and lists of service ranges (i.e. intervals, most likely by service port, but also possibly by service name). Defines: ----------------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------------- Services []SERVICEID REQUIRED The list of services that are Debar/Huang/Donahoo [Page 37] Internet Draft IDEFDM 15 October 1999 involved in the alert. Each element of the list is either a single SERVICEID or a SERVICEID interval (see definition of the range construct in section 5.2). The list can contain one element if and only if this element is a service interval, otherwise it has at least two elements. If intervals are used, the "Number" field contains the aggregated size of the intervals. Intervals must make sense (e.g. intervals of port numbers). ----------------------------------------------------------------- Subclasses: . 6.2.21 Class ASR_SINGLESERVICE Is-a-kind-of: AS_REALORIGIN Comment: This class covers all intrusion-detection alerts that con- tain the triplet (destination, source, service). As such, most intrusion detection alerts will be mapped onto subclasses of this class. Defines: --------------------------------------------------------------- Field Name Type Category Comment --------------------------------------------------------------- Service SERVICEID REQUIRED The description of the service involved in the alert. This is usually the service or application target of the alert. --------------------------------------------------------------- Debar/Huang/Donahoo [Page 38] Internet Draft IDEFDM 15 October 1999 Subclasses: ASRS_EMAIL, ASRS_USER, ASRS_DNSCMD, ASRS_SNMP, ASRS_PASSDECODE, ASRS_CMDDECODE, ASRS_THIRDADDRESS, ASRS_FILEACCESS, ASRS_RIP, ASRS_DISTANTCNT, ASRS_TROJAN, ASRS_STRINGMATCH, ASRS_WEBSERVER 6.2.22 Class ASRS_EMAIL Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers email-related alerts. For example, this class covers alerts targeted at the sendmail or SMTP environ- ments. Defines: ------------------------------------------------------------- Field Name Type Category Comment ------------------------------------------------------------- Address ADDRESSID REQUIRED The email address involved in the alert. ------------------------------------------------------------- Subclasses: . 6.2.23 Class ASRS_USER Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers user-related alerts. Examples of such alerts include logins (telnet, ftp, login, ssh) or r-services. Debar/Huang/Donahoo [Page 39] Internet Draft IDEFDM 15 October 1999 Defines: -------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------- User USERINFO REQUIRED The user field contains information about the source and destination users. The destination user has to be in. The source user is only filled when this information is available (see definition 5.3.4). -------------------------------------------------------------- Subclasses: . 6.2.24 Class ASRS_DNSCMD Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers DNS-related alerts. The number of DNS- related alerts generated by intrusion-detection sensors has prompted the creation of this class. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Domain STRING REQUIRED This is the DNS fully qualified domain name. This information may be related to an organization. ------------------------------------------------------------ Subclasses: . 6.2.25 Class ASRS_SNMP Debar/Huang/Donahoo [Page 40] Internet Draft IDEFDM 15 October 1999 Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers SNMP-related alerts [5]. The number of SNMP-related alerts generated by intrusion-detection sensors has prompted the creation of this class. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Community STRING REQUIRED The SNMP community string provided with the SNMP request. ------------------------------------------------------------ OID STRING REQUIRED The SNMP object identifier provided by the SNMP request. This can be implicit (numbers) or explicit (names). ------------------------------------------------------------ Subclasses: ASRSS_ACTIVITY 6.2.26 Class ASRSS_ACTIVITY Is-a-kind-of: ASRS_SNMP Comment: This class covers SNMP-related alerts when the intrusion detection sensor provides the entire PDU in addition to the Community and object requested. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Pdu STRING REQUIRED The protocol data unit covering the entire SNMP request. ------------------------------------------------------------ Debar/Huang/Donahoo [Page 41] Internet Draft IDEFDM 15 October 1999 Subclasses: . 6.2.27 Class ASRS_PASSDECODE Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers alerts reporting passwords, only when they cannot be attached to the associated account or user information directly. The service in this case is expected to be an authenticated service, such as telnet or ftp. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Password STRING REQUIRED The password associated with the service. ------------------------------------------------------------ Subclasses: . 6.2.28 Class ASRS_CMDDECODE Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers alerts describing commands that are passed by users and are related to suspicious activity. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Cmdline STRING REQUIRED The command line associated with the alert. ------------------------------------------------------------ Debar/Huang/Donahoo [Page 42] Internet Draft IDEFDM 15 October 1999 Subclasses: ASRSC_USERINFO 6.2.29 Class ASRSC_USERINFO Is-a-kind-of: ASRS_CMDDECODE Comment: The suspicious command is associated with a user and pass- word. Defines: -------------------------------------------------------------- Field Name Type Category Comment -------------------------------------------------------------- User USERINFO REQUIRED The user information related to the command submitted, which generated the alert. -------------------------------------------------------------- Password STRING REQUIRED The password information associated with the user. The password field can be an empty string if transmission of password information is prohibited. -------------------------------------------------------------- Subclasses: . 6.2.30 Class ASRS_THIRDHOST Is-a-kind-of: ASR_SINGLESERVICE Comment: Certain alerts report attacks that involve three hosts. An example of such attack is ftp bounce. This class reports the identity of the machine used in the bounce. Defines: Debar/Huang/Donahoo [Page 43] Internet Draft IDEFDM 15 October 1999 --------------------------------------------------------------- Field Name Type Category Comment --------------------------------------------------------------- THost HOSTID REQUIRED The third host involved with the alert. --------------------------------------------------------------- TService SERVICEID REQUIRED The related service information on this third host. --------------------------------------------------------------- Subclasses: ASRST_USERINFO 6.2.31 Class ASRST_USERINFO Is-a-kind-of: ASRS_THIRDHOST Comment: In addition to the third host involved, the user trigger- ing the alert is reported. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ TUser USERID REQUIRED The user involved in the bounce on the third host. ------------------------------------------------------------ TPassword STRING REQUIRED The associated password. This may be a blank string if password information is not available or should not betransmitted. ------------------------------------------------------------ Subclasses: . 6.2.32 Class ASRS_FILEACCESS Is-a-kind-of: ASR_SINGLESERVICE Debar/Huang/Donahoo [Page 44] Internet Draft IDEFDM 15 October 1999 Comment: This class covers alerts related to file accesses. Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- File FILEID REQUIRED The file accessed via the service. ----------------------------------------------------------- User USERID REQUIRED The user accessing the file. This is potentially the user identification under which the service runs. ----------------------------------------------------------- Subclasses: . 6.2.33 Class ASRS_RIP Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers routing related alerts[6]. Defines: ----------------------------------------- Field Name Type Category Comment ----------------------------------------- Route STRING REQUIRED The route. ----------------------------------------- Metric INTEGER REQUIRED The metric. ----------------------------------------- Subclasses: . 6.2.34 Class ASRS_DISTANTCNT Debar/Huang/Donahoo [Page 45] Internet Draft IDEFDM 15 October 1999 Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers alerts related to remote connections between two machines at the server level. An example of such traffic is NetBIOS. Defines: ----------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------- Client HOSTID REQUIRED The client accessing the service. ----------------------------------------------------- Server HOSTID REQUIRED The server providing the service. ----------------------------------------------------- Subclasses: . 6.2.35 Class ASRS_STRINGMATCH Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers alerts produced by an intrusion detec- tion sensor matching a given pattern with an input stream (described in the service). One example of this is the decod- ing of text protocols by certain intrusion detection sensors, which then generate an alert when a given string matches in the flow. Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- Content STRBUFFER REQUIRED The part of the stream that matches the pattern. The STRBUFFER type allows for variation in the amount of Debar/Huang/Donahoo [Page 46] Internet Draft IDEFDM 15 October 1999 information reported (see section 5.3.1). ----------------------------------------------------------- Pattern STRING REQUIRED The matching pattern. ----------------------------------------------------------- Subclasses: . 6.2.36 Class ASRS_TROJAN Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers Trojan detection alerts. Alerts such as detection of Back Orifice, NetBus and other well-known trojans are expected to go there. Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Command STRING REQUIRED The command that is sent to the Trojan. This can be an empty string if not applicable. ------------------------------------------------------------ Name STRING REQUIRED The name under which the Trojan tool is recognized. ------------------------------------------------------------ Subclasses: . 6.2.37 Class ASRS_WEBSERVER Is-a-kind-of: ASR_SINGLESERVICE Comment: This class covers alerts related to the web service. This includes all web-related traffic, most of the html documenta- tion servers in UNIX environments running on port 8888 or port Debar/Huang/Donahoo [Page 47] Internet Draft IDEFDM 15 October 1999 8080. There are many alerts generated by this service, there- fore it has been specialized in the class hierarchy. Defines: ----------------------------------------------------------- Field Name Type Category Comment ----------------------------------------------------------- Url STRING REQUIRED The URL as submitted by the requesting web browser. This means that method information (GET, POST) is included in the URL if relevant. ----------------------------------------------------------- Subclasses: ASRSW_INSECURECGI, ASRSW_PRIVILEGEDCMD 6.2.38 class ASRSW_PRIVILEGEDCMD Is-a-kind-of: ASRS_WEBSERVER Comment: This class covers alerts reporting attempted or successful shell or interpreter accesses through the web server (i.e. bat, sh, csh, perl). Defines: ------------------------------------------------------------ Field Name Type Category Comment ------------------------------------------------------------ Command STRING REQUIRED The command or interpreter that was accessed/subject of the access attempt. ------------------------------------------------------------ Subclasses: . Debar/Huang/Donahoo [Page 48] Internet Draft IDEFDM 15 October 1999 6.2.39 Class ASRSW_INSECURECGI Is-a-kind-of: ASRS_WEBSERVER Comment: This class covers alerts reporting attempts to use to well- known vulnerable cgi programs. For example, the requests for well- known php and asp vulnerabilities are reported by alerts of this class. Defines: ---------------------------------------------------------- Field Name Type Category Comment ---------------------------------------------------------- Cgi STRING REQUIRED The cgi script invoked by the http request. ---------------------------------------------------------- Subclasses: . 7 Examples of use of the class hierarchy 7.1 Conventions for the examples The name of the class carrying the alert is given in the artificial field "Class". The Method field contains either 1 (meaning knowledge-based intrusion- detection sensor) or 2 (meaning behavior-based intrusion-detection sen- sor) or 3 (meaning policy-based intrusion-detection sensor). The actual standard values for these fields may be different in the future. The convention for the priority, severity and trust is that 1 means very high and 5 means very low. 7.2 Use cases for denial of service attacks 7.2.1 The teardrop attack The teardrop attack is a classic example of a denial of service where the attacker sends anomalous fragmented packets. This attack is typi- cally reported at the service level, because most intrusion- detection sensors will find service information when analyzing packets related to Debar/Huang/Donahoo [Page 49] Internet Draft IDEFDM 15 October 1999 the teardrop attack. It can also be reported at the REALORIGIN level, because the service information in this case is not relevant (the target being the IP stack itself). This teardrop attack would be represented in the following way: Class = AS_REALORIGIN Priority = 1 Severity = 1.0 Signature = Teardrop Trustlevel = 1.0 Method = 1 Name = Denial of service/Net/Teardrop Date.Filler = 0x1 Date.Unix = 922826764 Idsid.Filler = 0x1 Idsid.ID = 123123123 Destination.Filler = 0x8 Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 123.234.231.121 Source.Filler = 0x8 Source.NetAddress.Filler = 0x3 Source NetAddress.Type = ipv4 Source.NetAddress.Address = 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). 7.2.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. Class = AS_REALORIGIN Priority = 1 Severity = 1.0 Signature = PingOfDeath Trustlevel = 1.0 Debar/Huang/Donahoo [Page 50] Internet Draft IDEFDM 15 October 1999 Method = 1 Name = Denial of service/Net/Ping of death Date.Filler = 0x1 Date.Unix = 922826764 Idsid.Filler = 0x1 Idsid.ID = 123123123 Destination.Filler = 0x7 Destination.Identity = oasd01s0 Destination.Name = Service workstation Destination.Location = Computer room B005 Source.Filler = 0x8 Source.NetAddress.Filler = 0x3 Souce.NetAddress.Type = ipv4 Source.NetAddress.Address = 222.121.111.122 7.3 Use cases for scans 7.3.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[7]) can detect this type of situation. The message sent by the sensor would be: Class = ASR_SIMPLESERVICE Priority = 3 Severity = 1.0 Signature = Connection to forbidden service Trustlevel = 4.0 Method = 3 Name = policy/forbidden service Date.Filler = 0x6 Date.Time = 08:32:43 Date.Date = 1999/04/23 Idsid.Filler = 0x6 Idsid.Console = myconsole04 Idsid.Sensor = mysensor02@miconsole04 Destination.Filler = 0xA Destination.Name = machine003.mydomain.mycom Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 10.10.10.24 Source.Filler = 0xA Source.Name = all.attacks.done Source.NetAddress.Filler = 0x3 Debar/Huang/Donahoo [Page 51] Internet Draft IDEFDM 15 October 1999 Source.NetAddress.Type = ipv4 Source.NetAddress.Addres = 127.0.0.1 Service.Filler = 0x7 Service.Name = finger Service.Sourceport = 4235 Service.Destport = 79 7.3.2 Simple Portscanning activity We define a simple portscan 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 portscan would be reported like: Class = ASR_MULTIPLESERVICES Priority = 5 Severity = 1.0 Signature = Simple portscan Trustlevel = 1.0 Method = 1 Name = Map/Net/TCP scan Date.Filler = 0x1 Date.Unix = 922826764 Idsid.Filler = 0x1 Idsid.ID = 123123123 Destination.Filler = 0x8 Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 123.234.231.121 Source.Filler = 0x8 Source.NetAddress.Filler = 0x3 Source.NetAddress.Type = ipv4 Source.NetAddress.Address = 222.121.111.112 Number = 501 If the intrusion-detection sensor were able to record the ports that have been touched, the alert would be reported in the following way: Class = ASRM_SERVICERANGE Priority = 5 Severity = 1.0 Signature = Simple portscan Debar/Huang/Donahoo [Page 52] Internet Draft IDEFDM 15 October 1999 Trustlevel = 1.0 Method = 1 Name = Map/Net/TCP scan Date.Filler = 0x1 Date.Unix = 922826764 Idsid.Filler = 0x1 Idsid.ID = 123123123 Destination.Filler = 0x8 Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 123.234.231.121 Source.Filler = 0x8 Source.NetAddress.Filler = 0x3 Source.NetAddress.Type = ipv4 Source.NetAddress.Address = 222.121.111.112 Number = 396 Services = [finger, 53, 119..512, nntp, ftp] Please not that in this last example, the Services field is filled in approximately by only the service number or name, without the appropri- ate structure information such as the Filler field. Therefore, this is not an exact representation. Also, the data model expects that the information included in the Number field and in the Services field are coherent with one-another. 7.4 Use cases for network decode information Network decodes are protocol elements that certain intrusion-detection sensors are able to monitor, usually at the request of the operator. These protocol elements do not necessarily represent known attacks, but alerts that should be monitored by an organization according to its security policy. 7.4.1 Protocol decode for FTP GET command Class = ASR_USERDECODE Priority = 10 Severity = 5.0 Signature = GET /etc/passwd Trustlevel = 1.0 Method = 3 Name = Decode/Net/FTP GET Date.Filler = 0x6 Date.Time = 08:32:43 Date.Date = 1999/04/23 Debar/Huang/Donahoo [Page 53] Internet Draft IDEFDM 15 October 1999 Idsid.Filler = 0x6 Idsid.Console = console02 Idsid.Sensor = sensor05 Destination.Filler = Destination.Name = machine003.mydomain.mycom Destination.NetAddress.Filler = Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 10.10.10.24 Source.Filler = Source.Name = all.attacks.done Source.NetAddress.Filler = Source.NetAddress.Type = ipv4 Source.NetAddress.Address = 127.0.0.1 Service.Filler = 0x7 Service.Name = ftp Service.Sourceport = 4235 Service.Destport = 20 User.Filler = 0x1 User.Name = Joe In this example, the signature field is used to provide additional information about the alert being captured, such as the file requested for download. This information could also have been delivered by a sub- classing mechanism. Other information, such as the size of the file, the file name in a more precise setting, the environment, the fact that the command succeeded or not, can also be provided by defining additional fields. 7.5 Use cases for local attacks 7.5.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: Class = ASA_USER Priority = 1 Severity = 1.0 Signature = loadmodule forking shell TrustLevel = 1.0 Method = 1 Name = privileges/bad parameter/loadmodule Time.Filler = 0x1 Debar/Huang/Donahoo [Page 54] Internet Draft IDEFDM 15 October 1999 Time.Unix = 3245234563 Idsid.Filler = 0x1 Idsid.ID = 12345678 Destination.Filler = Destination.Name = machine.domain.com Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 123.234.345.456 Service.Filler = Service.Process = /usr/openwin/bin/loadmodule User.Filler = User.Name = joe User.Userid = 13243 Of course, the alert could be more precise and indicate that the target user is the root user. In that case, the alert would look like: Class = ASA_TARGETUSER Priority = 1 Severity = 1.0 Signature = loadmodule forking shell TrustLevel = 1.0 Method = 1 Name = privileges/bad parameter/loadmodule Time.Filler = 0x1 Time.Unix = 3245234563 Idsid.Filler = 0x1 Idsid.ID = 12345678 Destination.Filler = Destination.Name = machine.domain.com Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 123.234.345.456 Service.Filler = Service.Process = /usr/openwin/bin/loadmodule User.Filler = User.Name = joe User.Userid = 13243 TargetUser.Filler = TargetUser.Name = root 7.6 Use cases for system policy usage System policy usage is a report by an intrusion-detection system that a particular policy has been violated. Debar/Huang/Donahoo [Page 55] Internet Draft IDEFDM 15 October 1999 7.6.1 Night logging In this example, logging into the monitored system is restricted to business hours. The alert reports a violation of a user logging in dur- ing the night. Class = ASR_USERDECODE Priority = 1 Severity = 1.0 Signature = Night login Trustlevel = 4.0 Method = 3 Name = Policy violation Date.Filler = 0x6 Date.Time = 08:32:43 Date.Date = 1999/04/23 Idsid.Filler = 0x6 Idsid.Console = console02 Idsid.Sensor = sensor05 Destination.Filler = 0x6 Destination.Name = machine003.mydomain.mycom Destination.NetAddress.Filler = 0x3 Destination.NetAddress.Type = ipv4 Destination.NetAddress.Address = 10.10.10.24 Source.Filler = 0x8 Source.NetAddress.Filler = 0x3 Source.NetAddress.Type = ipv4 Source.NetAddress.Address = 127.0.0.1 Service.Filler = 0x7 Service.Name = login Service.Sourceport = 4235 Service.Destport = 23 User.Filler = 0x1 User.Name = Joe 8 Implementation considerations This section should be very much improved after discussions in the WG. This is very much experimental. Maybe it should not exist at all. 9 Security considerations 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. Debar/Huang/Donahoo [Page 56] Internet Draft IDEFDM 15 October 1999 10 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] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual Addison-Wesley, 1997. [3] M. Wood, "Intrusion detection exchange format requirements," inter- net draft, Internet Engineering Task Force, jul 1999. Work in progress. [4] S. Christey, Mann, and Hill, "Development of a common vulnerability enumeration." Workshop RAID99, September 1999. [5] J. Case, R. Mundy, D. Partain, and B. Stewart, "Introduction to ver- sion 3 of the internet-standard network management framework," Request for Comments (Informational) 2570, Internet Engineering Task Force, April 1999. [6] G. Malkin, "Rip version 2," Request for Comments (Standards track) 2453, Internet Engineering Task Force, November 1998. [7] 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 57] Internet Draft IDEFDM 15 October 1999 Acknowledgements 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 Marc Dacier IBM Corporation James Riordan IBM Corporation Stephane Schitter IBM Corporation Michael Steiner University of Saarland Steven R. Snapp CyberSafe Corporation Maureen Stillman Nokia IP Telephony Vimal Vaidya AXENT Andreas Wespi IBM Corporation 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 58] Internet Draft IDEFDM 15 October 1999 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 implmentation may be prepared, copied, published and distributed, 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 refer- ences 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 59]