Internet Engineering Task Force IDWG Internet Draft Debar/Huang/Donahoo draft-ietf-idwg-data-model-03.txt IBM Corp./The Boeing Company/AFIWC 15 June 2000 Expires: December 15th, 2000 Intrusion Detection Exchange Format Data Model draft-ietf-idwg-data-model-03.txt Herve Debar IBM Corporation deb@zurich.ibm.com Ming-Yuh Huang The Boeing Company Ming-Yuh.Huang@boeing.com David J. Donahoo AFIWC ddonahoo@cmet.af.mil STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. This Internet Draft expires December 15th, 2000. Debar/Huang/Donahoo [Page 1] Internet Draft IDEFDM 15 June 2000 Table of Contents 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Conventions used in this document . . . . . . . . . . . . 4 3 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Problems addressed by the data model . . . . . . . . . . 4 3.2 How the data model answers these questions . . . . . . . 5 3.3 Design goals . . . . . . . . . . . . . . . . . . . . . . 6 3.3.1 Representing events . . . . . . . . . . . . . . . . . . . 6 3.3.2 Content driven . . . . . . . . . . . . . . . . . . . . . 6 3.3.3 Relationship between alerts . . . . . . . . . . . . . . . 6 4 Data analysis . . . . . . . . . . . . . . . . . . . . . . 7 4.1 Network-based Intrusion Detection Data . . . . . . . . . 7 4.1.1 Network-based IDS Common (Shared) Data Elements . . . . . 7 4.1.2 Network-based System Unique Date Elements . . . . . . . . 12 4.2 Host-based Intrusion Detection Data . . . . . . . . . . . 15 4.2.1 Host-based IDS Common (Shared) Data Elements . . . . . . 16 4.2.2 Host-based System Unique Date Elements . . . . . . . . . 18 4.3 Anomaly-based Intrusion Detection Data . . . . . . . . . 19 4.4 Examples of network-based IDSes alert data . . . . . . . 20 4.4.1 Port scan attack . . . . . . . . . . . . . . . . . . . . 20 4.4.2 IP spoofing . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.3 SYN Flood Attack . . . . . . . . . . . . . . . . . . . . 22 4.4.4 Buffer overflow . . . . . . . . . . . . . . . . . . . . . 22 4.4.5 PHF attack . . . . . . . . . . . . . . . . . . . . . . . 23 4.5 Analysis summary . . . . . . . . . . . . . . . . . . . . 23 5 The data model . . . . . . . . . . . . . . . . . . . . . 24 5.1 Principles . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1 Relationships . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Data model overview . . . . . . . . . . . . . . . . . . . 27 5.3 The core of the data model . . . . . . . . . . . . . . . 29 5.3.1 The ALERT class . . . . . . . . . . . . . . . . . . . . . 29 5.3.2 The TOOLALERT class . . . . . . . . . . . . . . . . . . . 31 5.3.3 The CORRELATIONALERT class . . . . . . . . . . . . . . . 32 5.3.4 The OVERFLOWALERT class . . . . . . . . . . . . . . . . . 32 5.3.5 The ANALYZER class . . . . . . . . . . . . . . . . . . . 33 5.3.6 The CLASSIFICATION class . . . . . . . . . . . . . . . . 33 5.3.7 The TARGET class . . . . . . . . . . . . . . . . . . . . 34 5.3.8 The SOURCE class . . . . . . . . . . . . . . . . . . . . 36 5.4 The support classes . . . . . . . . . . . . . . . . . . . 37 5.4.1 The IDENT class . . . . . . . . . . . . . . . . . . . . . 38 5.4.2 The ADDRESS class . . . . . . . . . . . . . . . . . . . . 39 5.4.3 The USER class . . . . . . . . . . . . . . . . . . . . . 41 5.4.4 The NODE class . . . . . . . . . . . . . . . . . . . . . 42 5.4.5 The PROCESS class . . . . . . . . . . . . . . . . . . . . 43 5.4.6 The SERVICE class . . . . . . . . . . . . . . . . . . . . 44 5.4.7 The WEBSERVICE class . . . . . . . . . . . . . . . . . . 44 Debar/Huang/Donahoo [Page 2] Internet Draft IDEFDM 15 June 2000 5.4.8 The SNMPSERVICE class . . . . . . . . . . . . . . . . . . 45 5.5 Extension of the data model . . . . . . . . . . . . . . . 46 5.5.1 Extension by aggregation . . . . . . . . . . . . . . . . 46 5.5.2 Extension by subclassing . . . . . . . . . . . . . . . . 46 6 Examples of use of the data model . . . . . . . . . . . . 46 6.1 Use cases for denial of service attacks . . . . . . . . . 46 6.1.1 The teardrop attack . . . . . . . . . . . . . . . . . . . 46 6.1.2 The ping of death attack . . . . . . . . . . . . . . . . 48 6.1.3 The SYN-flood attack . . . . . . . . . . . . . . . . . . 48 6.2 Use cases for scans . . . . . . . . . . . . . . . . . . . 48 6.2.1 Connection to a denied service . . . . . . . . . . . . . 48 6.2.2 Simple port scanning activity . . . . . . . . . . . . . . 49 6.3 Use cases for local attacks . . . . . . . . . . . . . . . 50 6.3.1 The loadmodule attack . . . . . . . . . . . . . . . . . . 50 6.3.2 The PHF attack . . . . . . . . . . . . . . . . . . . . . 51 6.4 Use cases for system policy usage . . . . . . . . . . . . 51 6.4.1 Night login . . . . . . . . . . . . . . . . . . . . . . . 51 6.4.2 Modification of a protected file . . . . . . . . . . . . 52 7 Security considerations . . . . . . . . . . . . . . . . . 53 8 Bibliography . . . . . . . . . . . . . . . . . . . . . . 53 Debar/Huang/Donahoo [Page 3] Internet Draft IDEFDM 15 June 2000 1 Abstract The purpose of the Intrusion Detection Exchange Format is to define data formats and exchange procedures for sharing information of interest with intrusion detection and response systems, and with the management sys- tems that may need to interact with them. This Internet-Draft describes a proposed data model to represent the information exported by the intrusion-detection systems, including the rationale for this model. This information is herein refered to as "Alert", in accordance with the definition given in the IDWG requirements draft [1]. Examples are given to illustrate the use of the model. 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[2]. 3 Introduction This document defines a proposed data model for the Intrusion Detection Exchange Format (IDEF), which is the intended work product of the Intru- sion Detection Exchange Format Working Group (IDWG). IDEF is planned to be a standard format that automated Intrusion Detection Systems can use for reporting alerts that they have deemed to be suspicious. This docu- ment does not address the need for a common exchange format for intru- sion-detection alarms. This need is detailed in the requirement document of the IDWG working group, currently an Internet draft[1]. The terminol- ogy used in this document is defined in the aforementioned requirement document. 3.1 Problems addressed by the data model The reasons for proposing an object-oriented model as the data represen- tation format of the IDWG are: 1. Alert information is inherently heterogeneous. Certain alerts are defined with very little information, such as origin, des- tination, name and time of the event. Other alerts provide much more context, such as ports or services, processes, user information, and others. Therefore, it is important that the data representation proposed is flexible enough to accommodate different needs. 2. Tool environments are different. Some tools detect attacks by analyzing network traffic while others use operating system Debar/Huang/Donahoo [Page 4] Internet Draft IDEFDM 15 June 2000 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 allow for conversion to formats used by tools other than intrusion detection sensors, for the purpose of further processing the alert information. 4. Operating environments are different. Depending on the kind of network, or operating system used, attacks will be observed and reported with different characteristics. The data model should accommodate these differences. 5. Commercial vendor objectives are different. Depending on the constraints set forth for the development of the tool, or on the operating environment, vendors may wish to deliver more or less information about certain attacks. 3.2 How the data model answers these questions Each point in this section constitutes an answer to the corresponding question raised in the previous section. 1. An object-oriented model has a natural extensibility via sub- classing. If an implementation of the data model extends it with new classes, either by aggregation or subclassing, an implementation that does not understand these extensions will still be able to understand the subset of information that is defined by the data model. Subclassing and aggregation provide extensibility while preserving the consistency of the model. 2. The data model defines support classes that accommodate the differences in data sources among tools. In particular, the notion of target and source for the alert are represented by the combination of NODE, USER, PROCESS and SERVICE classes. Debar/Huang/Donahoo [Page 5] Internet Draft IDEFDM 15 June 2000 3. The data model defines extensions to the basic schema that allow carrying both simple and complex alerts. Extensions are either done through subclassing or association of new classes. 4. The reporting flexibility is brought by the definition of the NODE and SERVICE support classes. If additional information must be reported, subclasses should be defined that extend the data model with the additional attributes. 5. Vendors may want to provide more information about alerts. Again, the object-oriented approach allows this flexibility while specifying how the subclassing mechanism must be used. 3.3 Design goals 3.3.1 Representing events The goal of the data model is to provide a standard data model to repre- sent that an occurrence of unusual activity was detected by a(n) intru- sion detection analyzer/sensor. These alerts may be simple or complex, depending on the capability of the analyzer/sensor that created them. 3.3.2 Content driven The design of the data model is content-driven. This means that new objects are introduced to accommodate additional content, not semantic differences between the alerts. This is an important goal as the task of classifying and naming computer vulnerabilities is extremely difficult and subjective. The data model must be unambiguous. This means that we allow tools to be more or less precise than one another, e.g. one tool may reports more information about an event than another. However, we do not allow them to produce contradictory information in two alerts describing the same event; e.g. in the previous case, the common set of information rap- ported by the two tools MUST be identical and inserted in the same placeholder of the data structure. Of course, it is always possible to insert all interesting information about an event in the extensions to an alert instead of using pre-defined fields; doing this reduces inter- operability and MUST be avoided as much as possible. 3.3.3 Relationship between alerts Intrusion detection alerts can be transmitted at several levels. This draft applies to both very simple alerts (those alerts that are the Debar/Huang/Donahoo [Page 6] Internet Draft IDEFDM 15 June 2000 result of a single action or operation in the system, such as a failed login report) and to more complex alerts (the aggregation of several actions in the system to generate the alert, or the aggregation of sev- eral simple alerts). As such, the data model must provide a way to describe the relationship between low level and high level alerts. 4 Data analysis This section contains a comparison of data collected by various IDSs while actively monitoring a protected system. This study was limited in scope by the degree of active participation of IDS vendors. In the course of collecting this data, five Network-based, three Host- based and one Anomaly-based vendors provided the requested data. While the information obtained from this analysis is valuable, greater participa- tion would enchance the results. 4.1 Network-based Intrusion Detection Data In the first part (starting at para 4.1.1), this analysis is simply a listing of tables containing the data identified by five vendors as the data they collect in an IDS. This part is listed in short tables to identify like data elements (elements shared between various IDSs). Following that (starting at para 4.1.2) is a set of tables showing seem- ingly unique data elements listed by IDSs. The second part of this section (starting at para 4.2) provides a list- ing of simular data collected by three Host-Based Intrusion Detection vendors. The third part of this section (starting at para 4.3) provides a listing of the date elements collected by an Anomaly-based IDS. Section 4.4 illustrates the data analysis with examples of reported alerts. For the purposes of this analysis, IDSs are identified generically. For example, a Network-based IDS would carry a designator NB_IDS_(n) where the (n) would be replaced with a single number. A Host-based system would carry a designator HB_IDS_(n). 4.1.1 Network-based IDS Common (Shared) Data Elements This part of the document presents the data elements of the various Net- work-based ID systems which appear to match up with data elements of other ID systems' data elements. This part is broken down into separate tables to represent various major data types. Debar/Huang/Donahoo [Page 7] Internet Draft IDEFDM 15 June 2000 Source IP Address The source IP address is represented in the following way: ---------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ====================================================================== NB_IDS_1 |Source IP |String | |Address | | ---------------------------------------------------------------------- NB_IDS_2 |attackinghostip |String | IP address from which the | | | attack was conducted ---------------------------------------------------------------------- NB_IDS_2 |actualhostip |String | IP address of the actual host | | | in Man-in-middle ---------------------------------------------------------------------- NB_IDS_3 |Source IP |String | ---------------------------------------------------------------------- NB_IDS_4 |Initiating Host |Integer | Source IP Address ---------------------------------------------------------------------- NB_IDS_5 |SourceIP_A |Integer | 1st octet of source IP ---------------------------------------------------------------------- NB_IDS_5 |SourceIP_B |Integer | 2nd octet of source IP ---------------------------------------------------------------------- NB_IDS_5 |SourceIP_C |Integer | 3rd octet of source IP ---------------------------------------------------------------------- NB_IDS_5 |SourceIP_D |Integer | 4th octet of source IP ---------------------------------------------------------------------- Destination IP Address ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Destination IP |String | |Address | | ----------------------------------------------------------------------- NB_IDS_2 |attackedhostip |String | IP address of the host that was | | | attacked ----------------------------------------------------------------------- NB_IDS_3 |Dest IP |String | ----------------------------------------------------------------------- NB_IDS_4 |Destination Host |Integer | Destination IP Address ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 8] Internet Draft IDEFDM 15 June 2000 NB_IDS_5 |destIP_A |Integer | 1st octet of dest IP ----------------------------------------------------------------------- NB_IDS_5 |destIP_B |Integer | 2nd octet of dest IP ----------------------------------------------------------------------- NB_IDS_5 |destIP_C |Integer | 3rd octet of dest IP ----------------------------------------------------------------------- NB_IDS_5 |destIP_D |Integer | 4th octet of dest IP ----------------------------------------------------------------------- Source Port Number ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Source Port |Integer | |Number | | ----------------------------------------------------------------------- NB_IDS_3 |Source Port |Integer | ----------------------------------------------------------------------- NB_IDS_5 |SourcePort |Integer | ----------------------------------------------------------------------- Destination Port Number ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Destination Port |Integer | |Number | | ----------------------------------------------------------------------- NB_IDS_2 |clientport |Integer | Client port for time of day | | | acess check ----------------------------------------------------------------------- NB_IDS_3 |Dest Port |Integer | ----------------------------------------------------------------------- NB_IDS_5 |dest Port |Integer | ----------------------------------------------------------------------- Protocol Debar/Huang/Donahoo [Page 9] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Protocol ID |Integer | IANA protocol ID ----------------------------------------------------------------------- NB_IDS_2 |protocoltype |String | ----------------------------------------------------------------------- NB_IDS_3 |Protocol |String | ----------------------------------------------------------------------- NB_IDS_4 |Service |String | ----------------------------------------------------------------------- NB_IDS_5 |Protocol |String | Protocol used (TCP, UDP) ----------------------------------------------------------------------- Severity/Priority ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Priority |ULONG | Priority level (user assigned) ----------------------------------------------------------------------- NB_IDS_2 |***trappriority |Integer | Level of severity of alarm ----------------------------------------------------------------------- NB_IDS_3 |Warning Level |Integer | Degree of confidence of valid | | | attack ----------------------------------------------------------------------- NB_IDS_4 |Warning Level |Integer | Internal algorithm--gives a | | | warning level based on | | | threat/vulnerability ----------------------------------------------------------------------- Time ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Time of Event |Integer | Timeticks ----------------------------------------------------------------------- NB_IDS_2 |+++dctime |Integer | Timeticks--Value of the time | | | stamp when the data collector | | | made the alarm ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 10] Internet Draft IDEFDM 15 June 2000 NB_IDS_2 |sessionduration |Integer | Duration of the session ----------------------------------------------------------------------- NB_IDS_2 |idleduration |Integer | Duration when session was idle ----------------------------------------------------------------------- NB_IDS_3 |Time | | ----------------------------------------------------------------------- NB_IDS_4 |Timestamp | | ----------------------------------------------------------------------- NB_IDS_4 |Start Time | | Time event record started ----------------------------------------------------------------------- NB_IDS_4 |End Time | | Time event record ended ----------------------------------------------------------------------- NB_IDS_5 |starime |Date | Time a connection started ----------------------------------------------------------------------- NB_IDS_5 |msecs |Integer | Number of microseconds when | | | network layer stamps 1st | | | detected packet ----------------------------------------------------------------------- NB_IDS_5 |duration |Integer | Duration os connection in | | | seconds ----------------------------------------------------------------------- Packet Data ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_2 |packetsize |Integer | Size of captured packets ----------------------------------------------------------------------- NB_IDS_5 |packetsSent |Integer | Number of packets sent over a | | | connection ----------------------------------------------------------------------- NB_IDS_5 |packetsReceived |Integer | Number of packets received over | | | a connection ----------------------------------------------------------------------- NB_IDS_5 |bytesSent |Integer | Ammount of data sent ----------------------------------------------------------------------- NB_IDS_5 |bytesReceived |Integer | Ammount of data received ----------------------------------------------------------------------- String/Pattern Debar/Huang/Donahoo [Page 11] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_2 |attackpattern |String | Attack pattern string ----------------------------------------------------------------------- NB_IDS_4 |Words matched |String | |Initiating Host | | ----------------------------------------------------------------------- NB_IDS_4 |Words matched |String | |Destination Host | | ----------------------------------------------------------------------- NB_IDS_5 |String |String | The string that matched ----------------------------------------------------------------------- Sensor/Analyzer Identification ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_2 |***dcname |String | User defined name for data | | | collector or appliance | | | generating the alarm ----------------------------------------------------------------------- NB_IDS_3 |Community |String | ----------------------------------------------------------------------- NB_IDS_5 |assignedHostID |String | Unique ID assigned to | | | analyzer/manager in an IDS | | | network ----------------------------------------------------------------------- 4.1.2 Network-based System Unique Date Elements This part of the document presents the data elements of various systems which didn't appear to match up with any other systems' data elements. This is not to say that these are truely unique. It merely means that when reviewing the data it appeared these were unique. This could be as a result of a lack of data type definations or it could represent data which the various IDS's use for internal processing of event information to enchance their functionality. System Unique Data Elements for NB_IDS_1 Debar/Huang/Donahoo [Page 12] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_1 |Action Mask |Integer | Masks of actions taken by | | | analyzer/manager ----------------------------------------------------------------------- NB_IDS_1 |Info Type |String | Null-terminating field ----------------------------------------------------------------------- NB_IDS_1 |Info Value |String | Null-terminating field ----------------------------------------------------------------------- NB_IDS_1 |Info Type |String | Null-terminating field ----------------------------------------------------------------------- System Unique Data Elements for NB_IDS_2 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_2 |Application |String | Name of application for the | | | attack ----------------------------------------------------------------------- NB_IDS_2 |doscount |Integer | Number of denial of service | | | attacks ----------------------------------------------------------------------- NB_IDS_2 |poscount |integer | Number of port scan attacks ----------------------------------------------------------------------- NB_IDS_2 |halfopen |Integer | Number of half open connections |conncount | | for a syn flood attack ----------------------------------------------------------------------- NB_IDS_2 |terminated |integer | Number of connections |conncount | | terminated ----------------------------------------------------------------------- NB_IDS_2 |capture |String | Name of file to which the ASD |filename | | attack was captured ----------------------------------------------------------------------- NB_IDS_2 |actiontaken |String | Action taken when attack was | | | detected ----------------------------------------------------------------------- NB_IDS_2 |attacktemplate |String | Name of attack template ----------------------------------------------------------------------- NB_IDS_2 |inconsistent |String | Name of file that was found to |filename | | be inconsistent ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 13] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- NB_IDS_2 |printresults |String | Results of printing attack | | | details ----------------------------------------------------------------------- NB_IDS_2 |***trapheader |String | Objects specifying information | | | about the attack ----------------------------------------------------------------------- NB_IDS_2 |***trapmessage |String | Actual alarm string ----------------------------------------------------------------------- System Unique Data Elements for NB_IDS_3 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_3 |Info |String | Data collected on attack; could | | | be port list or general | | | comments. ----------------------------------------------------------------------- NB_IDS_3 |Query |String | ----------------------------------------------------------------------- NB_IDS_3 |UserName |String | ----------------------------------------------------------------------- NB_IDS_3 |Password |String | ----------------------------------------------------------------------- NB_IDS_3 |Request |String | ----------------------------------------------------------------------- NB_IDS_3 |Source Ident | | ----------------------------------------------------------------------- NB_IDS_3 |Arguments |String | ----------------------------------------------------------------------- NB_IDS_3 |Client UserName |String | ----------------------------------------------------------------------- NB_IDS_3 |Server UserName |String | ----------------------------------------------------------------------- NB_IDS_3 |Command |String | ----------------------------------------------------------------------- NB_IDS_3 |Sender |String | ----------------------------------------------------------------------- NB_IDS_3 |Recipient |String | ----------------------------------------------------------------------- NB_IDS_3 |Error Status |String | ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 14] Internet Draft IDEFDM 15 June 2000 NB_IDS_3 |Error Index |String | ----------------------------------------------------------------------- NB_IDS_3 |PDU |String | ----------------------------------------------------------------------- NB_IDS_3 |TCP Flags |String | ----------------------------------------------------------------------- NB_IDS_3 |Virtual Host |String | ----------------------------------------------------------------------- NB_IDS_3 |Bad Host |String | ----------------------------------------------------------------------- System Unique Data Elements for NB_IDS_4 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_4 |Source Name |String | UserName of the host ----------------------------------------------------------------------- NB_IDS_4 |Destination |String | UserName of the dest host |Name | | ----------------------------------------------------------------------- System Unique Data Elements for NB_IDS_5 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_5 |Status |String | Data detected order. Used for | | | updating the latest data in the | | | database ----------------------------------------------------------------------- NB_IDS_5 |eventDesc |String | Detailed description of an | | | event describing what it was | | | and why it was important ----------------------------------------------------------------------- 4.2 Host-based Intrusion Detection Data This part (starting at para 4.2.1), provides a listing of tables con- taining the data identified by three vendors as the data they collect in a Host-based IDS. This part is listed in short tables to identify like data elements (elements shared between various IDSs). Following that (starting at para 4.2.2) is a set of tables showing seemingly unique Debar/Huang/Donahoo [Page 15] Internet Draft IDEFDM 15 June 2000 data elements listed by IDSs. For the purposes of this analysis, IDSs are identified generically. For example, Host-based IDS would carry a designator HB_IDS_(n) where the (n) would be replaced with a single number. 4.2.1 Host-based IDS Common (Shared) Data Elements This part of the document presents the data elements of the various Host-based ID systems which appear to match up with data elements of other ID systems' data elements. This part is broken down into separate tables to represent each major data type. Time ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_6 |time_t Time | | Time that the collector parsed | | | the event, not the time from a | | | log ----------------------------------------------------------------------- NB_IDS_7 |Date |Date | Date and time ----------------------------------------------------------------------- NB_IDS_8 |Time of Event |Integer | Timeticks ----------------------------------------------------------------------- Attack Source ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_6 |user_name |String | User who caused the event ----------------------------------------------------------------------- NB_IDS_7 |User Name |String | User name or source IP ----------------------------------------------------------------------- NB_IDS_8 |Source Port |Integer | |Number | | ----------------------------------------------------------------------- NB_IDS_8 |Source IP |Integer | |Address | | ----------------------------------------------------------------------- NB_IDS_8 |Source Port |Integer | |Name | | Debar/Huang/Donahoo [Page 16] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- NB_IDS_8 |Source MAC |Integer | |Address | | ----------------------------------------------------------------------- Destination ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_6 |system_name |String | Agent name where the event | | | occured ----------------------------------------------------------------------- NB_IDS_7 |Target System |String | User name or destination IP | | | Addresses ----------------------------------------------------------------------- NB_IDS_8 |Destination |Integer | |Port Number | | ----------------------------------------------------------------------- NB_IDS_8 |Destination |Integer | |IP Address | | ----------------------------------------------------------------------- NB_IDS_8 |Destination |Integer | |Port Name | | ----------------------------------------------------------------------- NB_IDS_8 |Destination |Integer | |MAC Address | | ----------------------------------------------------------------------- Event/Activity Naming ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_6 |event_type | | Type of event ----------------------------------------------------------------------- NB_IDS_6 |type_txt |String | Text for type of event ----------------------------------------------------------------------- NB_IDS_7 |Activity Name |String | ----------------------------------------------------------------------- NB_IDS_8 |Event Name |String | ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 17] Internet Draft IDEFDM 15 June 2000 4.2.2 Host-based System Unique Date Elements This part of the document presents the data elements of various systems which didn't appear to match up with any other systems' data elements. This is not to say that these are truely unique. It merely means that when reviewing the data it appeared these were unique. This could be as a result of a lack of data type definations. As with network-based intrusion-detection systems, the common identifi- cation of the tool that sent the alert, the timestamp, what the alert name/signature is, and the source/target are included. Then, additional information is very much dependant on the technique and data source used by the intrusion-detection system. HB_IDS_6 Unique Data Elements ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_6 |match_clause |Integer | Clause type to match ----------------------------------------------------------------------- NB_IDS_6 |*Policy | | Policy that applies to the | | | event ----------------------------------------------------------------------- NB_IDS_6 |*rule_s | | Rule which matched event ----------------------------------------------------------------------- NB_IDS_6 |*clause_s | | Action clause to execute ----------------------------------------------------------------------- NB_IDS_6 |*system_softid |Char | System software ID ----------------------------------------------------------------------- NB_IDS_6 |process_id |Int 32 | Process Identification # ----------------------------------------------------------------------- NB_IDS_6 |session_id |Int 32 | Session Identification # ----------------------------------------------------------------------- NB_IDS_6 |*text |Char | Text of the event ----------------------------------------------------------------------- NB_IDS_6 |*action_text |Char | Text of event for action ----------------------------------------------------------------------- NB_IDS_6 |Text_size | | Size of event text ----------------------------------------------------------------------- HB_IDS_7 Unique Data Elements Debar/Huang/Donahoo [Page 18] Internet Draft IDEFDM 15 June 2000 ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_7 |Priority | | Priority Level (high, med, low) ----------------------------------------------------------------------- NB_IDS_7 |Details | | Details specific to event ----------------------------------------------------------------------- HB_IDS_8 Unique Data Elements ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_8 |Priority |ULONG | Priority assigned by user ----------------------------------------------------------------------- NB_IDS_8 |Sequence Number |ULONG | ----------------------------------------------------------------------- NB_IDS_8 |ICMP Type |String | ----------------------------------------------------------------------- NB_IDS_8 |ICMP Code |String | ----------------------------------------------------------------------- NB_IDS_8 |Protocol |INT | IANA protocol ID ----------------------------------------------------------------------- NB_IDS_8 |Action Maks |INT | Mask the action madde by the | | | analyzer ----------------------------------------------------------------------- 4.3 Anomaly-based Intrusion Detection Data Only one source reported Anomaly-based data therefore there is currently no comparative data. ----------------------------------------------------------------------- SYSTEM |DATA NAME |DATA TYPE| COMMENTS ======================================================================= NB_IDS_9 |sa | | Source IP address ----------------------------------------------------------------------- NB_IDS_9 |sp | | Source IP port ----------------------------------------------------------------------- NB_IDS_9 |da | | Destination IP address ----------------------------------------------------------------------- NB_IDS_9 |dp | | Destination IP Port ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 19] Internet Draft IDEFDM 15 June 2000 NB_IDS_9 |start/end |UNIXEpoch| Time of attack ----------------------------------------------------------------------- NB_IDS_9 |prt | | Protocol ----------------------------------------------------------------------- NB_IDS_9 |as | | Attack signature code ----------------------------------------------------------------------- NB_IDS_9 |ac | | Attack certainty ----------------------------------------------------------------------- NB_IDS_9 |cnt | | Count of events ----------------------------------------------------------------------- NB_IDS_9 |ob | | Observer (server name) ----------------------------------------------------------------------- 4.4 Examples of network-based IDSes alert data This section shows the information reported by three different intrusion detection systems when faced with five attacks. The data shown here is not a reflection of the data names listed in the above tables. For sim- plification comments/definations have been used. For example in the case of the Source IP. From the data tables above, you can see that Source IP addresses can be stated as: Source IP Address| String attackinghostip actualhostip Source IP Initiating Host Source IP Address SourceIP_A, SourceIP_B, SourceIP_C, SourceIP_D For the purposes of this section we simply use the term Source IP. If there is no entry in a column it indicates that IDS does not record the data. 4.4.1 Port scan attack A port scan is a preliminary attack aimed at recognizing the services offered by a given host, along with possibly additional information such as banners or version numbers. -------------------------------------------------------------------- IDS-A | IDS-B | IDS-C ==================================================================== Sensor Name | | Sensor Name -------------------------------------------------------------------- Date/Time | Date/Time | Date/Time -------------------------------------------------------------------- Actual Alarm String | | -------------------------------------------------------------------- Severity Level | | -------------------------------------------------------------------- Debar/Huang/Donahoo [Page 20] Internet Draft IDEFDM 15 June 2000 Source IP | Source IP | Source IP -------------------------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------------------------- Port Count | | -------------------------------------------------------------------- Application Name | | -------------------------------------------------------------------- | Protocol | -------------------------------------------------------------------- | List of Ports | -------------------------------------------------------------------- | | Port Scan Range -------------------------------------------------------------------- 4.4.2 IP spoofing IP spoofing is an attack that masquerades the originator's IP address. ---------------------------------------------------------------------- IDS-A | IDS-B | IDS-C ====================================================================== Sensor Name | | Sensor Name ---------------------------------------------------------------------- Date/Time | Date/Time | Date/Time ---------------------------------------------------------------------- Actual Alarm String | | ---------------------------------------------------------------------- Source port | | ---------------------------------------------------------------------- Destination port | List of port intervals | ---------------------------------------------------------------------- Severity Level | | Severity Level ---------------------------------------------------------------------- Source IP | | Source IP ---------------------------------------------------------------------- MAC Address | | ---------------------------------------------------------------------- | | Protocol ---------------------------------------------------------------------- | | Begin Time ---------------------------------------------------------------------- | | End Time ---------------------------------------------------------------------- Debar/Huang/Donahoo [Page 21] Internet Draft IDEFDM 15 June 2000 4.4.3 SYN Flood Attack The SYN flood attack is a denial of service attack that aims at prevent- ing a host from answering connection requests by exhausting system resources. ---------------------------------------------------------------------- IDS-A | IDS-B | IDS-C ====================================================================== Sensor Name | (not documented) | (not documented) ---------------------------------------------------------------------- Date/Time | | ---------------------------------------------------------------------- Actual Alarm | | ---------------------------------------------------------------------- Severity Level | | ---------------------------------------------------------------------- Source IP | | ---------------------------------------------------------------------- Destination IP | | ---------------------------------------------------------------------- Half Open Connections | | ---------------------------------------------------------------------- Terminated Connections | | ---------------------------------------------------------------------- 4.4.4 Buffer overflow The buffer overflow attack is aimed against a program that does not properly check size boundaries for incoming data. -------------------------------------------------------------------- IDS-A | IDS-B | IDS-C ==================================================================== Date/Time | Date/Time | Date/Time -------------------------------------------------------------------- Source IP | Source IP | Source IP -------------------------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------------------------- | Protocol | Protocol -------------------------------------------------------------------- | Attack Data | Program Text -------------------------------------------------------------------- Debar/Huang/Donahoo [Page 22] Internet Draft IDEFDM 15 June 2000 | | Program Name -------------------------------------------------------------------- | | Begin Time -------------------------------------------------------------------- | | End Time -------------------------------------------------------------------- | | Severity -------------------------------------------------------------------- 4.4.5 PHF attack The PHF attack is aimed at exploiting the vulnerable PHF script avail- able in early versions of the apache web server. -------------------------------------------------------------------- IDS-A | IDS-B | IDS-C ==================================================================== Date/Time | Date/Time | Date/Time -------------------------------------------------------------------- Source IP | Source IP | Source IP -------------------------------------------------------------------- Destination IP | Destination IP | Destination IP -------------------------------------------------------------------- Source port | Source port | Source port -------------------------------------------------------------------- Destination port | Destination port | Destination port -------------------------------------------------------------------- URL | URL | URL -------------------------------------------------------------------- Script | | Script -------------------------------------------------------------------- | | Method -------------------------------------------------------------------- 4.5 Analysis summary Some techniques for intrusion detection have not been surveyed in this very short analysis. For example, we expect intrusion-detection systems based on application data (spanning multiple hosts) or on alert data (correlation) to appear shortly, either as prototypes or commercial products. The data model MUST take these emerging technologies into account. The information reported by different intrusion-detection systems con- cerning the same attack can be fairly different. This means that the Debar/Huang/Donahoo [Page 23] Internet Draft IDEFDM 15 June 2000 proposed data model has to strike a sensible balance between information that is commonly regarded as important for describing the alert, and additional information (enhancements) proposed by the intrusion detec- tion vendor. Intrusion-detection sensors report the same kind of information under different names and formats, depending on their capabilities. For exam- ple, a network-based intrusion-detection system is more likely to pro- vide network addresses, and a host-based system more likely to provide host names and user names. The data model needs to these different ways to convey the same information, and this is achieved in the data model through the use of support classes. These support classes also allow the IDS to create the relation between these multiple views of the same object. Many of the intrusion-detection systems surveyed do not include reaction information with the alert, but encode it in a separate message. The data model therefore MUST be able to support transmission of counter- measure information either as an attribute of the alert, or as a sepa- rate standalone alert. 5 The data model 5.1 Principles The data model is described using the Universal Modeling Language (UML) [3]. UML provides a simple framework to represent entities and their relationships. UML define entities as classes. In this document we have identified the classes with the associated attributes. The symbols used in this document to represent class and attributes are: +---------------------+ | CLASS | +---------------------+ | Attribute | | Attribute | | Attribute | | ... | +---------------------+ Please note that attributes for a class do not appear in all diagrams which use the class. 5.1.1 Relationships Debar/Huang/Donahoo [Page 24] Internet Draft IDEFDM 15 June 2000 This data model currently uses only two relationships, the inheritance relationship and the aggregation relationship. Inheritance Relationship Inheritance denotes a superclass, subclass type of a relationship where the subclass inherits all the attributes, operations and relationships of the superclass. This type of relationship is also referred to as an "is-a" or a "kind-of" relationship. The subclasses have additional attributes or operations which apply only to the subclass and not to the superclass In this document, inheritance is represented by the /_\ symbol. In the example below we are stating that an Extended Alert is a kind of alert. It contains all the attributes of Alert as well as any attributes con- tained in the extended alert class. (Note: purpose of Extended_Alert will be discussed latter in this document). +---------------------+ | ALERT | +---------------------+ /_\ | | +---------------------+ | EXTENDED_ALERT | +---------------------+ Figure 1: Inheritance relationship example Aggregation Relationship Aggregation is a form of association in which the whole is related to its parts. This type of relationship is also referred to as a "part-of" relationship. In this case the aggregate class contains all of it own attributes and as many of the attributes associated to it parts as required and specified in the multiplicity indicators (discussed in the next paragraph). In this document the symbol <> is used to indicate aggregation. It is placed at the end of the association line closest to the aggregate (whole) class. Debar/Huang/Donahoo [Page 25] Internet Draft IDEFDM 15 June 2000 +---------------------+ 1 +---------------------+ | ALERT |<>----------| ANALYZER | +---------------------+ +---------------------+ | | | | 1 +---------------------+ | |<>----------| NAME | | | +---------------------+ | | | | 0..*+---------------------+ | |<>----------| TARGET | | | +---------------------+ | | | | 0..*+---------------------+ | |<>----------| SOURCE | +---------------------+ +---------------------+ Figure 2: Aggregation relationship example Multiplicity Indicator Multiplicity defines the number of objects within a class that are linked to one another. Typically multiplicity indicators are placed at each end of the association line. In this document if a multiplicity number is left off it is assumed to be 1 (one). Standard symbol, as used in this document, are: 1 = Exactly One 0..* = Zero or More 1..* = One or More 0..1 = Zero or One 5..8 = Specific Range (5,6,7, & 8) In the example above an Alert contains all the attributes of it's own class and the attributes of exactly one Analyzer and the attributes of 1 time. I may contain the attributes of zero or more target(s) and the attributes of zero or more source(s). Types and default values Attributes of the classes defined by the data model are typed. This type information is not an exact requirement on the implementation; it is Debar/Huang/Donahoo [Page 26] Internet Draft IDEFDM 15 June 2000 rather intended to convey to the reader what kind of data the data model is expecting for this attribute. The exact representation is left for the representation documents. For example, the INTEGER type indicates that the data model views this attribute as an integer. It might actu- ally be encoded as a binary 32 bit integer, a binary 64 bit integer, or a string in an XML representation. -------------------------------------------------------------------- Name Definition -------------------------------------------------------------------- BOOLEAN Boolean = TRUE,FALSE. -------------------------------------------------------------------- INTEGER The value provided MUST be an integer. -------------------------------------------------------------------- CHARACTER UTF-8 encoded character. -------------------------------------------------------------------- STRING UTF-8 encoded string. -------------------------------------------------------------------- BYTE Byte (8-bits, no parity). -------------------------------------------------------------------- TIME A structure or schema carrying time representation. This is defined by the implementation draft and MUST comply with the requirements draft [1]. -------------------------------------------------------------------- ENUM An INTEGER-based enumerated type. Wherever this type is used to describe an attribute, the definition of the value set will be given afterwards. -------------------------------------------------------------------- The default values are precised per class for each attribute. Only mandatory attributes have default values. 5.2 Data model overview An overview of the data model is presented in figure 3. The main compo- nent is the ALERT class, which bears minimum required information along with the ANALYZER and CLASSIFICATION classes. The ANALYZER class describes the sender of the alert, i.e. the analyzer; every alert must be associated with one and only one analyzer. The CLASSIFICATION class describe the subject of the alert, i.e. the reason for sending it; at least one of them MUST be provided in the alert. In addition, each alert is associated with zero or more TARGET, and with zero or more SOURCE. Each TARGET and SOURCE is described by a number of attributes, as described in sections 5.3.7 and 5.3.8. Debar/Huang/Donahoo [Page 27] Internet Draft IDEFDM 15 June 2000 Additional alert data can be included by subclassing any of the model classes. Standard extensions and examples are given in section 5.5. +-------+ 1+----------------+ | ALERT |<>------| ANALYZER | | | +----------------+ 0..1+---------+ | | +------| USER | | | 1..*+----------------+ | +---------+ | |<>------| CLASSIFICATION | | 0..1+---------+ | | +----------------+ +------| PROCESS | | | | +---------+ | | 0..*+----------+ 0..1+----------+ | 0..1+---------+ | |<>------| TARGET |<>------| NODE |<>-+------| SERVICE | | | +----------+ +----------+ +---------+ | | | | 0..*+----------+ 0..1+----------+ 0..1+---------+ | |<>------| SOURCE |<>------| NODE |<>-+------| USER | +-------+ +----------+ +----------+ | +---------+ | 0..1+---------+ +------| PROCESS | +---------+ Figure 3: Data model overview It is important to note that this data model does not specify how an alert should be classified or identified. For example, a port scan may be determined as a single attack against multiple targets by one sensor where another sensor may see it as multiple attacks by a single source. The taxonomy for this analysis lies in each IDS. Once the alert type is determined this data model provides the standard structure for format- ting the alert. Also the data model implements a set of types with default values (see section 5.1.1), which must be understood by the reader beforehand. Debar/Huang/Donahoo [Page 28] Internet Draft IDEFDM 15 June 2000 5.3 The core of the data model The core of the data model is the ALERT class. Every alert is associated with a single analyzer that generated it, and a single time. It is also associated with a list of 0 or more targets, and a list of 0 or more sources. This relationship is illustrated in figure 4. Figure 4 contains three classes that extend the ALERT class. These three classes have been included here because the information they carry appears frequently during the operation of intrusion-detection systems. the TOOLALERT class extends the ALERT 5.3.1 The ALERT class The ALERT class is the central component of the data model. An IDWG- compliant intrusion-detection analyzer must generate at a minimum this set of information. The ALERT class defines the following attributes: -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== version |INTEGER | The version of the class hierarchy used. The current version is 1. This attribute is MANDATORY. The default value is 1. -------------------------------------------------------------------------- alertID |INTEGER | A serial number for the alert. This number MUST be unique for every alert generated by a given analyzer. This attribute is MANDATORY. The default value is 0 and indicates that the analyzer cannot generate this information reliably. -------------------------------------------------------------------------- time TIME The time of the alert. The implementation document MUST define the time format used. This attribute is MANDATORY and does not have a default value. -------------------------------------------------------------------------- impact |ENUM | The evaluated impact of the alert on the system. See the definition thereafter. This attribute is MANDATORY. The default value is 0. -------------------------------------------------------------------------- The impact attribute takes the following values: Debar/Huang/Donahoo [Page 29] Internet Draft IDEFDM 15 June 2000 +--------------------+ 1..1+----------------------+ | ALERT |<>---------| ANALYZER | |--------------------| +----------------------+ | INTEGER version=1 | | INTEGER ident | | INTEGER alertID | | NODE host | | ENUM impact | | PROCESS process | | TIME time | +----------------------+ | | | | 1..*+----------------------+ | |<>---------| CLASSIFICATION | | | +----------------------+ | | | ENUM origin | | | | STRING name | | | | STRING url | | | +----------------------+ | | | | 0..*+----------------------+ | |<>---------| TARGET | | | +----------------------+ | | | | 0..*+----------------------+ | |<>---------| SOURCE | +--------------------+ +----------------------+ /_\ | +------------+----------+ | | | +------------------+ | +-----------------+ | TOOLALERT | | | OVERFLOWALERT | |------------------| | |-----------------| |STRING name | | | INTEGER size | |STRING command | | | BYTE buffer | |INTEGER[] alertIDs| | | STRING program | +------------------+ | +-----------------+ | +--------------------+ | CORRELATIONALERT | +--------------------+ | INTEGER[] alertIDs | +--------------------+ Figure 4: Data model core Debar/Huang/Donahoo [Page 30] Internet Draft IDEFDM 15 June 2000 ---------------------------------------------------------------- Value Definition ---------------------------------------------------------------- 0 The impact of the event is not known to the analyzer. ---------------------------------------------------------------- 1 Event is not known to be suspicious in any way. ---------------------------------------------------------------- 2 Event is believed unpleasant in an unknown way. ---------------------------------------------------------------- 3 Event is believed to be an attempted reconnaissance probe. ---------------------------------------------------------------- 4 Event is believed to be a reconnaissance probe which provided useful information, but of limited scope (e.g. a single machine was scanned for a small number of ports (< 10)). ---------------------------------------------------------------- 5 Event is believed to be a large scale reconnaissance probe which provided useful information (e.g. a DNS sweep over a complete subnetwork). ---------------------------------------------------------------- 6 event appears intended to lead to denial of service. ---------------------------------------------------------------- 7 event is believed to have successfully denied service ---------------------------------------------------------------- 8 event is believed to be an attempt to gain user level access. ---------------------------------------------------------------- 9 event appears to be a successful compromise of user level access. ---------------------------------------------------------------- 10 event is believed to be an attempt to gain administrator level access. ---------------------------------------------------------------- 11 event appears to be a successful compromise of administrator level access. ---------------------------------------------------------------- 5.3.2 The TOOLALERT class The TOOLALERT class carries additional information related to the use of attack tools or trojan horses. Debar/Huang/Donahoo [Page 31] Internet Draft IDEFDM 15 June 2000 -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== name |STRING | The reason for grouping the alerts, for example an attack tool name (trinoo). This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- command |STRING | The command or operation that the tool was asked to perform, for example a BackOrifice ping. This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- alerts INTEGER[] The list of alert identifiers that are related to the name. This attribute is OPTIONAL. The default value is the empty list. -------------------------------------------------------------------------- 5.3.3 The CORRELATIONALERT class The CORRELATIONALERT class carries additional information related to the correlation of alert information. --------------------------------------------------------------------------- Attribute |Type | Definition =========================================================================== alerts INTEGER [] The list of alert identifiers that are related to the name. This attribute is MANDATORY. This attribute does not have a default value. --------------------------------------------------------------------------- 5.3.4 The OVERFLOWALERT class The OVERFLOWALERT class carries additional information related to over- flow attacks. These include but are not limited to the infamous buffer overflow attacks when an attacker can overflow a fixed size buffer and have code run under higher privileges than his own. -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== size |INTEGER | The size of the overflowing buffer. This attribute is MANDATORY. This attribute does not have a Debar/Huang/Donahoo [Page 32] Internet Draft IDEFDM 15 June 2000 default value. -------------------------------------------------------------------------- program |STRING | The program that the overflow attempted to run. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- buffer BYTE [] A buffer containing the overflowing data partially or entirely. This attribute is OPTIONAL. The default value is the empty array. -------------------------------------------------------------------------- 5.3.5 The ANALYZER class The ANALYZER class identifies the intrusion detection analyzer that pro- vided the alert. At the minimum, this is a unique identifier such as a serial number (unique over the organization where the IDS system is deployed). Additional identification information is provided. -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== ident |INTEGER | Analyzer identification token. This attribute is MANDATORY. This attribute does not have a default value. This token MUST be unique within the communicating analyzers and managers. -------------------------------------------------------------------------- host NODE Identification of the equipment on which the analyzer resides. This attribute is OPTIONAL. The default value is EMPTY. -------------------------------------------------------------------------- process PROCESS Process information concerning the analyzer. This attribute is OPTIONAL. The default value is EMPTY. -------------------------------------------------------------------------- 5.3.6 The CLASSIFICATION class The CLASSIFICATION class names the vulnerability associated with the alert. One name MUST be provided, and additional, equivalent names MAY be added. -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== Debar/Huang/Donahoo [Page 33] Internet Draft IDEFDM 15 June 2000 origin |ENUM | The origin of the name, refer to the definition afterwards. This attribute is MANDATORY. The default value is 1. -------------------------------------------------------------------------- name |STRING | The associated name. This attribute is MANDATORY. The default value is the empty STRING. -------------------------------------------------------------------------- url |STRING | The URL at which the manager can find more information about the alert. This information can consist of a signature pattern, a description of the attack, appropriate countermeasures, or any other information deemed relevant by the vendor. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- The origin attribute takes the following values: ------------------------------ Value Definition ------------------------------ 1 vendor-specific name. ------------------------------ 2 bugtraq identifier. ------------------------------ 3 CVE identifier. ------------------------------ 5.3.7 The TARGET class The TARGET class contains information about the TARGET of the alert, i.e. the recipient of the malicious or anomalous activity that has been spotted by the intrusion detection system. The target itself consists of an identifier and a boolean indicating whether the target is real or spoofed. The relationship diagram for TARGET is shown in figure 5. The TARGET class defines the following attributes: -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== decoy |ENUM | Indicates if the data associated with the target Debar/Huang/Donahoo [Page 34] Internet Draft IDEFDM 15 June 2000 +------------------+ 0..1+---------------------+ | TARGET |<>------------------| NODE | |------------------| +---------------------+ | INTEGER targetID | | ENUM decoy | 0..1+---------------------+ | |<>------------------| USER | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| PROCESS | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| SERVICE | +------------------+ +---------------------+ Figure 5: The Target class is considered real as far as the analyzer can decide, a decoy, or undetermined. This attribute is MANDATORY. The default value is 0. -------------------------------------------------------------------------- targetID |INTEGER | Target reference token. This token identifies and refers to a previously defined target. This attribute is OPTIONAL. The default value is 0 and indicates that the analyzer does not support this facility. -------------------------------------------------------------------------- The decoy attribute of the TARGET class takes the following values: ---------------------------------------------------------------- Value Definition ---------------------------------------------------------------- -1 The target is a decoy. The attack is aimed at another target (decoy=YES). ---------------------------------------------------------------- 0 The appropriateness of the target information cannot be evaluated by the analyzer (decoy=DON'T KNOW). ---------------------------------------------------------------- 1 The target information is considered valid by the Debar/Huang/Donahoo [Page 35] Internet Draft IDEFDM 15 June 2000 analyzer with a good confidence (decoy=NO). ---------------------------------------------------------------- 5.3.8 The SOURCE class The SOURCE class contains information about the possible source or sources of the alert, i.e. the party or parties generating the anomalous data. The source itself contains a reference number (to refer to previ- ously transmitted or defined sources) and an indicator to indicate whether the source is real or spoofed. The relationship diagram for SOURCE is given in figure 6. +------------------+ 0..1+---------------------+ | SOURCE |<>------------------| NODE | |------------------| +---------------------+ | INTEGER sourceID | | BOOL spoofed | 0..1+---------------------+ | |<>------------------| USER | | | +---------------------+ | | | | 0..1+---------------------+ | |<>------------------| PROCESS | +------------------+ +---------------------+ Figure 6: The Source class The SOURCE class defines the following attributes: ------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================= spoofed |ENUM | Indicates if the data associated with the source is considered real as far as the analyzer can decide, a decoy, or impossible to tell. This attribute is MANDATORY. The default value is 0. ------------------------------------------------------------------------- sourceID |INTEGER | Source reference token. This attribute is OPTIONAL. The default value is 0, meaning that this facility is not supported by the analyzer. ------------------------------------------------------------------------- Debar/Huang/Donahoo [Page 36] Internet Draft IDEFDM 15 June 2000 The spoofed attribute of the SOURCE class takes the following values: ---------------------------------------------------------------- Value Definition ---------------------------------------------------------------- -1 The source is a decoy. The attack comes from another source than the one provided by the analyzer (spoofed=YES). ---------------------------------------------------------------- 0 The appropriateness of the soiurce information cannot be evaluated by the analyzer (spoofed=DON'T KNOW). ---------------------------------------------------------------- 1 The source information is considered valid by the analyzer with a good confidence (spoofed=NO). ---------------------------------------------------------------- 5.4 The support classes The support classes represent entities in the data model that have an important role. Their relationship is described in figure 7. The follow- ing entities have been identified: nodes, processes, users and services. In addition, an address entity has been defined to enhance user and node. The relationship diagram for the support classes is shown in fig- ure 7. Debar/Huang/Donahoo [Page 37] Internet Draft IDEFDM 15 June 2000 +---------------+ | IDENT | |---------------| | INTEGER ident | +---------------+ /_\ | +------------------------------------+ | | +------------------+ | +----------------+ | |PROCESS |---+---|NODE | | |------------------+ | |----------------+ 0..*+----------------+ |INTEGER pid | | |STRING name |<>-----|ADDRESS | |STRING name | | |STRING location| |----------------+ |STRING path | | |INTEGER domain | 0..*|INTEGER category| |STRING[] arguments| | +----------------+ 0..*|STRING address | |STRING[] environ | | +---|STRING netmask | +------------------+ | +----------------+ | +----------------+ +---|USER | | +------------------+ | |----------------+ | |SERVICE |---+ |INTEGER category|<>-+ |------------------+ |STRING name | |STRING name | |INTEGER uid | |INTEGER dport | |STRING group | |INTEGER sport | |INTEGER gid | |STRING protocol | |STRING serialID| +------------------+ +----------------+ /_\ +-------------------+ | | +---------------+ +-------------------+ | WEBSERVICE | | SNMPSERVICE | |---------------| +-------------------+ | STRING url | | STRING Oid | | STRING cgi | | STRING Community | | STRING method | | STRING Command | | STRING args | +-------------------+ +---------------+ Figure 7: Support classes diagram 5.4.1 The IDENT class Debar/Huang/Donahoo [Page 38] Internet Draft IDEFDM 15 June 2000 All support classes inherit from the IDENT class. The IDENT class pro- vides a reference to an object predefined by the analyzer and the man- ager. Instead of sending the complete description of the object, the IDEFDM message MAY contain the reference identifier for this object. The IDENT class defines the following attributes: -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== ident |INTEGER | The shared reference number by which the analyzer and the manager identify the object. This attribute is OPTIONAL. The default value is 0 and indicates that the analyzer does not support this facility. -------------------------------------------------------------------------- The justification for having an ident is twofold. First, this informa- tion can serve as a correlation tool. When two intrusion-detection sys- tems have different views of objects (e.g. network based associated with IP addresses and host-based associated with names), providing them with a single identifier will help the manager receiving the alerts understand that they are related to the same object. This is particu- larly useful for target objects, which are likely to be well identified by the organization deploying the intrusion-detection system. This mech- anism is also useful when the same object has multiple interfaces. This also means that every NODE, USER, ADDRESS, PROCESS or SERVICE information can be exchanged with an integer. However, the implementor MUST NOT reuse an identification previously used for an other instance. It is explicitly forbidden to share the same identification for two instances even if they are specializations of two different subclasses (e.g. a NODE and a USER). 5.4.2 The ADDRESS class The ADDRESS support class carries address information. The address in question can be for example a network address, a hardware address or an application address. -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== category |INTEGER | The kind of address information. Refer to the Debar/Huang/Donahoo [Page 39] Internet Draft IDEFDM 15 June 2000 following table for defined values. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- address BYTE [] The address information itself. The type information MUST allow transcription of the byte string into its original format. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- netmask BYTE [] The netmwsk information, if appropriate (depends on the category attribute). This attribute is OPTIONAL. The default value is the empty array. The category attribute of the ADDRESS class can take the following val- ues: ----------------------------------------------------------------------- value Definition ----------------------------------------------------------------------- 1 IP v4 address (short hexadecimal form). ----------------------------------------------------------------------- 2 IP v4 address (readable 4 dot separated 3-digit sets). ----------------------------------------------------------------------- 3 IP v4 network definition (readable 4 dot separated 3-digit set with scope). ----------------------------------------------------------------------- 4 IP v4 network definition with associated netmask. ----------------------------------------------------------------------- 5 IP v6 address. ----------------------------------------------------------------------- 6 IP v6 network. ----------------------------------------------------------------------- 7 IP v6 network with netmask. ----------------------------------------------------------------------- 8 MAC address. ----------------------------------------------------------------------- 9 ATM network address. ----------------------------------------------------------------------- 10 SNA network address. ----------------------------------------------------------------------- 20 Internet e-mail address (somebody@somewhere). ----------------------------------------------------------------------- 21 Lotus Notes address. ----------------------------------------------------------------------- Debar/Huang/Donahoo [Page 40] Internet Draft IDEFDM 15 June 2000 22 VM address. ----------------------------------------------------------------------- 100 and above Vendor-defined. ----------------------------------------------------------------------- 5.4.3 The USER class The USER class indicates the different ways by which a user can be iden- tified. -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== category |INTEGER | The kind of USER transported. Refer to the following table for defined values. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- name |STRING | The name identifying the user. This attribute is OPTIONAL if the uid attribute is provided, otherwise it is MANDATORY. The default value is the empty STRING. -------------------------------------------------------------------------- uid |INTEGER | The user identification number of the user. This attribute is OPTIONAL if the name attribute is provided, otherwise it is MANDATORY. The default value is 0. -------------------------------------------------------------------------- group |STRING | The group name or domain name associated with the user. This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- gid |INTEGER | The group identification number associated with the user. This attribute is OPTIONAL. The default value is 0. -------------------------------------------------------------------------- serialID |STRING | User identification as a string when the uid cannot be used. This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- The category attribute of the USER class can take the following values: Debar/Huang/Donahoo [Page 41] Internet Draft IDEFDM 15 June 2000 ------------------------------------------------------------------------ value Definition ------------------------------------------------------------------------ 1 Operating system or device user. This covers for example UNIX logins and NT users. ------------------------------------------------------------------------ 2 Application user. This covers for example web accounts, database accounts or transaction application accounts. ------------------------------------------------------------------------ 100 and above Vendor defined. ------------------------------------------------------------------------ The USER class is associated with a list of addresses. 5.4.4 The NODE class The NODE class indicates the different ways by which a host or equipment on the network can be identified. ------------------------------------------------------------------------- AttributeX Type | Definition ------------------------------------------------------------------------- name |STRING |The machine fully qualified domain name. This attribute is MANDATORY unless associated ADDRESS information is provided. The default value is the empty STRING. ------------------------------------------------------------------------- location |STRING |The location of the equipment. This attribute is optional. The default value is the empty STRING. ------------------------------------------------------------------------- domain |INTEGER |The domain to which the equipment belongs, if relevant. This attribute is OPTIONAL. The default value is 0. ------------------------------------------------------------------------- The data model defines the following values for the domain attribute of the NODE class: -------------------------------------------------- Value Definition -------------------------------------------------- 0 Information not avaliable. -------------------------------------------------- Debar/Huang/Donahoo [Page 42] Internet Draft IDEFDM 15 June 2000 1 DNS - Domain Name Service. -------------------------------------------------- 2 NIS - Network Information Service (SUN). -------------------------------------------------- 3 NIS+ - Network Information Service (SUN). -------------------------------------------------- 4 WfW - Windows for Workgroups. -------------------------------------------------- 5 NT - Windows NT domain. -------------------------------------------------- 6 ADS - Windows 2000 ADS. -------------------------------------------------- 7 NDS - Netware. -------------------------------------------------- 8 AFS - Andrew File System. -------------------------------------------------- 9 Kerb - Kerberos realm. -------------------------------------------------- 10 DFS - Distributed file system. -------------------------------------------------- 11 CODA - Distributed file system. -------------------------------------------------- 12 Other. -------------------------------------------------- 5.4.5 The PROCESS class The PROCESS class gathers information about the process that is being run. ------------------------------------------------------------------------- AttributeX Type | Definition ------------------------------------------------------------------------- name |STRING |The name of the program being run. This is a short name, e.g. sendmail or explorer. Options and path information are provided by additional attributes. This attribute is MANDATORY. This attribute does not have a default value. ------------------------------------------------------------------------- pid |INTEGER |The process identifier of the process being run. This attribute is OPTIONAL. The default value is 0. ------------------------------------------------------------------------- path |STRING |The path of the program. This attribute is Debar/Huang/Donahoo [Page 43] Internet Draft IDEFDM 15 June 2000 OPTIONAL. The default value is the empty STRING. ------------------------------------------------------------------------- arguments STRING[] The arguments passed to the program. This attribute is OPTIONAL. The default value is the empty array. ------------------------------------------------------------------------- environ STRING[] The environment strings in which the process is being run. This argument is optional. The default value is the empty array. ------------------------------------------------------------------------- 5.4.6 The SERVICE class The SERVICE class identifies a network service request being carried out over the network. In particular, this class should be used to report not only open services, but also connections and connections attempts. To do so, the class provides for identification of the source port from which the connection originated. In general, a service is a resource available from the network. This SERVICE class is also related to process and user information. Process and user information are aggregated at the source or target. ------------------------------------------------------------------------ Attribute |Type | Definition ======================================================================== name |STRING | The name of the service. This SHOULD be listed in the IANA list of well-known ports. ------------------------------------------------------------------------ dport |INTEGER | The port to which the connection request is addressed. In many situations, this will be a well-known port. ------------------------------------------------------------------------ sport |INTEGER | The source port from which the connection originated. In many situations, this will be a high-numbered port. ------------------------------------------------------------------------ protocol |STRING | The protocol name. ------------------------------------------------------------------------ 5.4.7 The WEBSERVICE class The WEBSERVICE class carries additional information related to web traffic. Note that the data model does not enforce coherence between the usage of this class and the information contained in the Service class, Debar/Huang/Donahoo [Page 44] Internet Draft IDEFDM 15 June 2000 because the two can be unrelated (examples of ports used for web traffic include but are not limited to 80, 443, 8080, 8484 and 8888). -------------------------------------------------------------------------- Attribute |Type | Definition ========================================================================== url |STRING | The URL in the request. This attribute is MANDATORY. This attribute does not have a default value. -------------------------------------------------------------------------- cgi |STRING | The CGI script in the request (without arguments). This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- args |STRING | The arguments passed to the cgi script. This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- method |STRING | The method used for the request. This attribute is OPTIONAL. The default value is the empty STRING. -------------------------------------------------------------------------- 5.4.8 The SNMPSERVICE class The SNMPSERVICE class carries additional information related to SNMP traffic. Note that the data model does not enforce coherence between the usage of this class and the information contained in the Service class, because the two can be unrelated. ------------------------------------------------------------------------ AttributeX Type | Definition ------------------------------------------------------------------------ oid |STRING |The object identifier used for the request. This attribute is OPTIONAL. The default value is the empty STRING. ------------------------------------------------------------------------ community |STRING |The object's community string. This attribute is OPTIONAL. The default value is the empty STRING. ------------------------------------------------------------------------ command |STRING |The command. This attribute is OPTIONAL. The default value is the empty STRING. ------------------------------------------------------------------------ Debar/Huang/Donahoo [Page 45] Internet Draft IDEFDM 15 June 2000 Note that even though it is possible to generate an alert of class SNMPSERVICE with only default values, analyzers SHOULD NOT do that. 5.5 Extension of the data model It is expected that the model will have to be extended by vendors to carry additional information relevant to the alerts they need to trans- port. When a manager receives from an analyzer information that it can- not understand, the unknown information MUST be ignored until the man- ager has been enriched with the appropriate data definition and seman- tic. When the vendor extensions mature, they can be incorporated in the dat model. Depending on the kind of extension needed, two mechanisms can be used. 5.5.1 Extension by aggregation Extension by aggregation consist of aggregating a new class to one of the existing classes of the dat model. This is the mechanism used for example to associate the NAME class with the ALERT class. This type of extension allows to propagate the additional information to all alerts sent by the analyzer that uses the extension. For example, if an analyzer decides to send the time of the analyzer in addition to the time already stored in the alert, the IDS vendor defines a new class aggregated with the ALERT class, that carries the appropri- ate time information. The model would then look like shown in figure 8. 5.5.2 Extension by subclassing The other extension possibility consists of specializing one of the classes defined by the model. This is the mechanism used for example to specialise the SERVICE class into the WEBSERVICE class, or the ALERT class into the TOOLALERT class. This is the preferred mode of extension because it not only preserves the data structure, it also preserves the operations executed on them (i.e. the methods). 6 Examples of use of the data model 6.1 Use cases for denial of service attacks 6.1.1 The teardrop attack The teardrop attack is a classic example of a denial of service where the attacker sends anomalous fragmented packets. This teardrop attack would be represented in the following way: Debar/Huang/Donahoo [Page 46] Internet Draft IDEFDM 15 June 2000 +----------+ 1+--------------+ | ALERT |<>------| ANALYZER | | | +--------------+ | | | | 1..*+--------------+ | |<>------|CLASSIFICATION| | | +--------------+ | | | | 1..*+--------------+ | |<>------| EXTRATIME | | | +--------------+ | | | | 0..*+--------------+ | |<>------| TARGET | | | +--------------+ | | | | 0..*+--------------+ | |<>------| SOURCE | +----------+ +--------------+ Figure 8: Insertion of the EXTRATIME class Alert.version = 1 Alert.alertID = 14285812 Alert.impact = 6 Alert.time = 1999/12/02 10:01:25.34125 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 3 Alert.Classification[0].name = GENERIC-MAP-NOMATCH Alert.Classification[0].url = iap://my.ids.vendor/doc/teardrop Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112 This is the base information that would be expected from all intrusion- detection sensors detecting this attack. Variations are possible, such as also reporting the service that is targeted by the attack (this might be considered useful in an NT networking environment, where typically one of the netbios services is the target of the attack). Debar/Huang/Donahoo [Page 47] Internet Draft IDEFDM 15 June 2000 6.1.2 The ping of death attack The ping-of-death attack is a classic example of a denial of service attack. By sending very large packets to a machine, one can overflow the reassembly routines and crash the IP subsystem and potentially the whole machine. The example given shows how to report in a single alert a ping-of-death attack from one source against 3 hosts. Each of the target hosts is reported in a different manner. The alert conveys the message that all three were concerned. However, the data model does not specify which host was the first, second or third target. Alert.version = 1 Alert.alertID = 113123 Alert.impact = 6 Alert.time = 1999/12/02 10:01:25.93464 UTC-4 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 3 Alert.Classification[0].name = CVE-1999-128 Alert.Classification[0].url = iap://my.ids.vendor/doc/pod Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Target[1].Node.name = lollipop Alert.Target[2].Node.name = Cisco.router.b10 Alert.Target[2].Node.location = Cabinet B10 Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112 6.1.3 The SYN-flood attack ******************************************************* * TODO * ******************************************************* 6.2 Use cases for scans 6.2.1 Connection to a denied service The simple type of scan is reported when the attacker tries to connect to an unavailable or forbidden port on a machine. Sniffers or simple wrappers (i.e. TCPWrappers[4]) can detect this type of situation. The message sent by the sensor would be: Debar/Huang/Donahoo [Page 48] Internet Draft IDEFDM 15 June 2000 Alert.version = 1 Alert.alertID = 7395 Alert.impact = 3 Alert.time = 1999/12/02 10:01:25.93464 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 1 Alert.Classification[0].name = finger request Alert.Classification[0].url = iap://my.ids.vendor/doc/finger Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Target[0].Node.name = myhost Alert.Target[0].Service.name = finger Alert.Target[0].Service.dport = 79 Alert.Target[0].Service.sport = 31532 Alert.Source[0].spoofed = FALSE Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112 Alert.Source[0].User.name = attacker Note that in this case, there is no exploitation of a vulnerability per se. Hence, the name of the attack follows an implementor-dependent scheme. Also, the user launching the attack on the source host could be determined and is transmitted. 6.2.2 Simple port scanning activity We define a simple port scan by connections request from one machine to another machine on a number (left as a parameter of the intrusion detec- tion sensor) of different services in a small amount of time (again, left to the configuration of the intrusion-detection sensor). Such a port scan would be reported with extended alert data. The first field of the extended alert data would be the number of ports touched, the second would be the time interval, and the remainder would identify inclusive port intervals as port number pairs. The alert represented here carries port scan information happening between 09:52:45 and 09:53:28, touching 501 ports, and intervals with ports queried include [5-25], [69-119] and [123-514]. Alert.version = 1 Alert.alertID = 79105235 Alert.impact = 5 Alert.time = 1999/12/02 10:01:25.93464 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 1 Alert.Classification[0].name = portscan Debar/Huang/Donahoo [Page 49] Internet Draft IDEFDM 15 June 2000 Alert.Classification[0].url = iap://my.ids.vendor/doc/portscan Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112 6.3 Use cases for local attacks 6.3.1 The loadmodule attack The loadmodule attack involves invoking the loadmodule program on a SUN workstation to run another program. Since loadmodule is suid-root, the executed program runs as root. The alert reporting such activity could look like the following: Alert.version = 1 Alert.alertID = 1473 Alert.impact = 10 Alert.time = 1999/10/21 08:12:32 UTC Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 2 Alert.Classification[0].name = 33 Alert.Classification[0].url = iap://my.ids.vendor/doc/loadmodule Alert.Target[0].Node.name = machine.domain.com Alert.Target[0].node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.345.456 Alert.Source[0].User.name = joe Alert.Source[0].User.uid = 13243 Alert.Source[0].Process.name = /usr/openwin/bin/loadmodule Of course, the alert could be more precise and indicate that the target user is the root user, indicating that this is an attempt to run /bin/sh. Here the attack is successful and the impact large. In that case, the alert would look like: Alert.version = 1 Alert.alertID = 1473 Alert.impact = 10 Alert.time = 1999/10/21 08:12:32 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 2 Alert.Classification[0].name = 33 Alert.Classification[0].url = iap://my.ids.vendor/doc/loadmodule Debar/Huang/Donahoo [Page 50] Internet Draft IDEFDM 15 June 2000 Alert.Target[0].Node.name = machine.domain.com Alert.Target[0].node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.345.456 Alert.Target[0].User.name = root Alert.Target[0].Process.name = /bin/sh Alert.Target[0].Process.pid = 25134 Alert.Source[0].User.name = joe Alert.Source[0].User.uid = 13243 Alert.Source[0].Process.name = /usr/openwin/bin/loadmodule 6.3.2 The PHF attack The phf attack is a buffer overflow against an apache web server running the vulnerable phf script. In this case, the alert contains two addi- tional information items. The first is a set of three strings giving the url, the cgi script and the method. The second is a set of two numbers, the status code and the number of bytes returned in the reply. Alert.version = 1 Alert.alertID = 13251 Alert.impact = 9 Alert.time = 1999/10/21 08:12:32 UTC+2 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 2 Alert.Classification[0].name = 629 Alert.Classification[0].url = iap://my.ids.vendor/doc/phf Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 123.234.231.121 Alert.Target[0].Service.dport = 8080 Alert.Target[0].Service.sport = 21534 Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 222.121.111.112 WebAlert.url = http://www.my.net/cgi-bin/phf?/etc/group WebAlert.cgi = /cgi-bin/phf WebAlert.method = GET 6.4 Use cases for system policy usage System policy usage is a report by an intrusion-detection system that a particular policy has been violated. 6.4.1 Night login In this example, logging into the monitored system is restricted to business hours. The alert reports a violation of user "Louis" logging in Debar/Huang/Donahoo [Page 51] Internet Draft IDEFDM 15 June 2000 during the night to machine003 from localhost, which in that case is a spoofed address with a good certainty. In addition, the extended alert reports the allowed times of login for this user during this day as a time interval. Alert.version = 1 Alert.alertID = 25616 Alert.impact = 9 Alert.time = 1999/10/21 02:15:32 UTC+3 Alert.Analyzer.ident = 123123123 Alert.Classification[0].origin = 1 Alert.Classification[0].name = out of hours login Alert.Classification[0].url = iap://my.ids.vendor/doc/policy-login Alert.Target[0].Node.name = machine003.mydomain.mycom Alert.Target[0].Node.Address.category = 2 Alert.Target[0].Node.Address.data = 10.10.10.24 Alert.Target[0].Service.name = login Alert.Target[0].Service.dport = 23 Alert.Target[0].Service.sport = 4235 Alert.Target[0].Process.pid = 426 Alert.Target[0].User.name = Louis Alert.Target[0].User.uid = 501 Alert.Target[0].User.gid = 500 Alert.Source[0].confidence = 80 Alert.Source[0].spoofed = TRUE Alert.Source[0].Node.Address.category = 2 Alert.Source[0].Node.Address.data = 127.0.0.1 6.4.2 Modification of a protected file ******************************************************* * TODO * ******************************************************* ******************************************************* * This section also needs examples on the correlation * * of alerts - How to send more complex alerts. * ******************************************************* Debar/Huang/Donahoo [Page 52] Internet Draft IDEFDM 15 June 2000 7 Security considerations This memo describes a data model 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 model itself does not have security considerations. 8 Bibliography [1] M. Wood, "Intrusion detection exchange format requirements," inter- net draft, Internet Engineering Task Force, jul 1999. Work in progress. [2] 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. [3] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual Addison-Wesley, 1997. [4] 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 53] Internet Draft IDEFDM 15 June 2000 Acknowledgments The following individuals contributed substantially to this document and should be recognized for their efforts. This document would not exist without their help: Dominique Alessandri IBM Corporation James L. Burden California Independent System Operator Dave Curry Internet Security Systems, Inc. Marc Dacier IBM Corporation Glenn Mansfield Cyber Solutions, Inc. James Riordan IBM Corporation Stephane Schitter IBM Corporation Michael J. Slifcak Internet Security Systems, Inc Michael Steiner University of Saarland Steven R. Snapp CyberSafe Corporation Stuart Staniford-Chen Silicon Defense Maureen Stillman Nokia IP Telephony Vimal Vaidya AXENT Andreas Wespi IBM Corporation Eric D. Williams Information Brokers, Inc. S.Felix Wu North Carolina State University Editor's Address: Herve Debar IBM Zurich Research Laboratory Saeumerstrasse 4 8803 Rueschlikon Switzerland Tel: +41 1 724 8499 Email: deb@zurich.ibm.com Intrusion Detection Exchange Format Working Group The Intrusion Detection Exchange Format Working Group can be contacted via the working group's mailing list (idwg-public@zurich.ibm.com) or through its chairs: Stuart Staniford-Chen stuart@SiliconDefense.com Silicon Defense Mike Erlinger mike@cs.hmc.edu Harvey Mudd College Debar/Huang/Donahoo [Page 54] Internet Draft IDEFDM 15 June 2000 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or ref- erences to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed. Debar/Huang/Donahoo [Page 55]