One document matched: draft-ietf-idwg-data-model-03.txt
Differences from draft-ietf-idwg-data-model-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 11:07:25 |