draft-ietf-idwg-idmef-xml-02.txt
From: http://www.semper.org/idwg-public/0247.html
Subject: draft-ietf-idwg-idmef-xml-02.txt
From: Hervé Debar (herve.debar@francetelecom.fr)
Date: Tue Dec 05 2000 - 15:08:52 CET
Title : IDMEF Data Model and XML DTD
Author(s) : D. Curry, H. Debar, M. Huang
Filename : draft-ietf-idwg-idmef-xml-02.txt
Pages : 86
Date : 05-Dec-00
This is (under version -02 of the XML draft) an attempt to merge the
data model and the XML representation, to avoid divergences between the
two.
Abstract
The purpose of the Intrusion Detection Message Exchange Format
(IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems,
and to the management systems that may need to interact with them.
The goals and requirements of the IDMEF are described in [2].
This Internet-Draft describes a proposed data model to represent the
information exported by the intrusion-detection systems, including
the rationale for this model, and a proposed implementation of this
data model, using the Extensible Markup Language (XML) [3]. The
rationale for choosing XML is explained, a Document Type Definition
(DTD) is developed, and examples are provided.
An earlier version of this implementation was reviewed, along with
other proposed implementations, by the IDWG at its September 1999 and
February 2000 meetings. At the February meeting, it was decided that
the XML solution was best at fulfilling the IDWG requirements. The
rationale for this decision is presented in [4].
Intrusion Detection Working Group D. Curry
Internet Draft ISS
Document: draft-ietf-idwg-idmef-xml-02.txt December 2000
Category: Informational
Intrusion Detection Message Exchange Format
IDMEF Data Model
Extensible Markup Language (XML) Document Type Definition
David A. Curry
Internet Security Systems, Inc.
davy@iss.net
Herve Debar
France Telecom R&D
herve.debar@francetelecom.fr
Ming-Yuh Huang
The Boeing Company
Ming-Yuh.Huang@boeing.com
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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
material 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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Curry Informational - Expires June 2001 [Page 1]
Internet Draft IDMEF Data Model and XML DTD December 2000
Abstract
The purpose of the Intrusion Detection Message Exchange Format
(IDMEF) is to define data formats and exchange procedures for sharing
information of interest to intrusion detection and response systems,
and to the management systems that may need to interact with them.
The goals and requirements of the IDMEF are described in [2].
This Internet-Draft describes a proposed data model to represent the
information exported by the intrusion-detection systems, including
the rationale for this model, and a proposed implementation of this
data model, using the Extensible Markup Language (XML) [3]. The
rationale for choosing XML is explained, a Document Type Definition
(DTD) is developed, and examples are provided.
An earlier version of this implementation was reviewed, along with
other proposed implementations, by the IDWG at its September 1999 and
February 2000 meetings. At the February meeting, it was decided that
the XML solution was best at fulfilling the IDWG requirements. The
rationale for this decision is presented in [4].
Curry Informational - Expires June 2001 [Page 2]
Internet Draft IDMEF Data Model and XML DTD December 2000
Table of Contents
1. Introduction...................................................6
2. Conventions used in this document..............................6
3. Rationale for the IDMEF Data Model.............................7
3.1. Problems addressed by the data model.........................7
3.2. Design goals.................................................8
3.2.1. Representing events........................................8
3.2.2. Content driven.............................................8
3.2.3. Relationship between alerts................................9
3.3. UML Overview.................................................9
3.3.1. Relationships..............................................9
3.3.1.1. Inheritance Relationship.................................9
3.3.1.2. Aggregation Relationship................................10
3.3.1.3. Multiplicity Indicator..................................10
3.3.2. Types and default values..................................11
4. The Data Model................................................12
4.1. Data model overview.........................................12
4.2. The core of the data model..................................13
4.2.1. The ALERT class...........................................15
4.2.2. The TOOLALERT class.......................................16
4.2.3. The CORRELATIONALERT class................................16
4.2.4. The OVERFLOWALERT class...................................16
4.2.5. The ANALYZER class........................................17
4.2.6. The CLASSIFICATION class..................................17
4.2.7. The ADDITIONALDATA class..................................18
4.2.8. The TARGET class..........................................19
4.2.9. The SOURCE class..........................................20
4.2.10. The support classes......................................20
4.2.10.1. The IDENT class........................................21
4.2.10.2. The ADDRESS class......................................22
4.2.10.3. The USER class.........................................23
4.2.10.4. The NODE class.........................................25
4.2.10.5. The PROCESS class......................................26
4.2.11. The SERVICE class........................................27
4.2.11.1. The WEBSERVICE class...................................27
4.2.11.2. The SNMPSERVICE class..................................28
4.3. Extension of the data model.................................28
4.3.1. Extension by aggregation..................................29
4.3.2. Extension by subclassing..................................29
5. Arguments for the realization of the class hierarchy in XML...30
5.1. The Extensible Markup Language..............................30
5.2. Rationale for Implementing IDMEF in XML.....................30
5.3. Relationship to the IDMEF Class Hierarchy...................31
6. Use of XML in the IDMEF.......................................33
6.1. The IDMEF Document Prolog...................................33
6.1.1. XML Declaration...........................................33
6.1.2. XML Document Type Definition (DTD)........................33
6.1.3. IDMEF DTD Formal Public Identifier........................34
6.1.4. IDMEF DTD Document Type Declaration.......................34
6.2. Character Data Processing in XML and IDMEF..................35
6.2.1. Character Entity References...............................36
Curry Informational - Expires June 2001 [Page 3]
Internet Draft IDMEF Data Model and XML DTD December 2000
6.2.2. Character Code References.................................36
6.2.3. White Space Processing....................................36
6.3. Languages in XML and IDMEF..................................37
6.4. Unrecognized Tags in IDMEF Messages.........................37
6.5. Digital Signatures..........................................38
7. IDMEF Data Types..............................................39
8. Structure of an IDMEF Message.................................41
8.1. The IDMEF-Message Root Element..............................41
8.2. The Message Type Elements...................................41
8.2.1. Alert.....................................................42
8.2.1.1. CorrelationAlert........................................43
8.2.1.2. OverflowAlert...........................................43
8.2.1.3. ToolAlert...............................................43
8.2.2. Heartbeat.................................................44
8.3. Time Elements...............................................44
8.3.1. Time......................................................44
8.3.2. DetectTime................................................45
8.3.3. AnalyzerTime..............................................46
8.4. High-Level Entity Identification Elements...................46
8.4.1. Analyzer..................................................46
8.4.2. Target....................................................46
8.4.3. Source....................................................47
8.5. Low-Level Entity Identification Elements....................48
8.5.1. Address...................................................48
8.5.2. Classification............................................48
8.5.3. Node......................................................49
8.5.4. Process...................................................49
8.5.5. Service...................................................50
8.5.5.1. SNMPService.............................................51
8.5.5.2. WebService..............................................51
8.5.6. User......................................................52
8.6. Simple Elements.............................................52
8.6.1. address...................................................52
8.6.2. alertid...................................................53
8.6.3. Arguments.................................................53
8.6.3.1. arg.....................................................53
8.6.4. buffer....................................................53
8.6.5. cgi.......................................................53
8.6.6. command...................................................53
8.6.7. community.................................................53
8.6.8. date......................................................54
8.6.9. dport.....................................................54
8.6.10. Environment..............................................54
8.6.10.1. env....................................................54
8.6.11. gid......................................................54
8.6.12. group....................................................54
8.6.13. location.................................................54
8.6.14. method...................................................55
8.6.15. name.....................................................55
8.6.16. netmask..................................................55
8.6.17. ntpstamp.................................................55
8.6.18. oid......................................................55
Curry Informational - Expires June 2001 [Page 4]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.6.19. path.....................................................55
8.6.20. pid......................................................55
8.6.21. portlist.................................................55
8.6.22. program..................................................56
8.6.23. protocol.................................................56
8.6.24. serial...................................................56
8.6.25. size.....................................................56
8.6.26. sport....................................................56
8.6.27. time.....................................................56
8.6.28. url......................................................56
8.6.29. uid......................................................56
8.7. Providing Additional Information............................57
8.7.1. AdditionalData............................................57
9. Examples......................................................57
9.1. Denial of Service Attacks...................................57
9.1.1. The "teardrop" Attack.....................................57
9.1.2. The "ping of death" Attack................................58
9.2. Port Scanning Attacks.......................................59
9.2.1. Connection to a Disallowed Service........................60
9.2.2. Simple Port Scanning......................................61
9.3. Local Attacks...............................................62
9.3.1. The "loadmodule" Attack...................................62
9.3.2. The "phf" Attack..........................................64
9.4. System Policy Violation.....................................65
9.5. Correlated Alerts...........................................66
9.6. Heartbeat...................................................68
10. Extending the IDMEF..........................................68
10.1. Extending an Existing Attribute............................69
10.2. Adding an Attribute........................................70
10.3. Adding an Element..........................................70
11. The IDMEF Document Type Definition...........................71
12. Security Considerations......................................83
13. References...................................................84
14. Acknowledgments..............................................85
15. Author's Addresses...........................................85
Curry Informational - Expires June 2001 [Page 5]
Internet Draft IDMEF Data Model and XML DTD December 2000
1. Introduction
The Intrusion Detection Message Exchange Format (IDMEF) [2] is
intended to be a standard data format that automated intrusion
detection systems can use to report alerts about events that they
have deemed suspicious. The development of this standard format will
enable interoperability among commercial, open source, and research
systems, allowing users to mix-and-match the deployment of these
systems according to their strong and weak points to obtain an
optimal implementation.
The most obvious place to implement the IDMEF is in the data channel
between an intrusion-detection "analyzer" (or "sensor") and the
"manager" (or "console") to which it sends alarms. But there are
other places where the IDMEF can be useful:
+ A single database system that could store the results from a
variety of intrusion detection products would make it possible for
data analysis and reporting activities to be performed on "the
whole picture" instead of just a part of it;
+ An event correlation system that could accept alerts from a
variety of intrusion detection products would be capable of
performing more sophisticated cross-correlation and cross-
confirmation calculations than one that is limited to a single
product;
+ A graphical user interface that could display alerts from a
variety of intrusion detection products would enable the user to
monitor all of the products from a single screen, and require him
or her to learn only one interface, instead of several; and
+ A common data exchange format would make it easier for different
organizations (users, vendors, response teams, law enforcement) to
not only exchange data, but also communicate about it.
2. Conventions used in this document
The keywords "MUST", "MUST NOT", "SHALL, "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED, and "MAY in this document are to be
interpreted as described in RFC-2119 [5].
Curry Informational - Expires June 2001 [Page 6]
Internet Draft IDMEF Data Model and XML DTD December 2000
3. Rationale for the IDMEF Data Model
3.1. Problems addressed by the data model
The reasons for proposing an object-oriented model as the data
representation format of the IDWG are:
+ Alert information is inherently heterogeneous. Certain alerts are
defined with very little information, such as origin, destination,
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.
An object-oriented model has a natural extensibility via
subclassing. 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.
+ Tool environments are different. Some tools detect attacks by
analyzing network traffic while others use operating system logs,
or application audit information. The same attack reported by
tools with different information sources will not contain the same
information.
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.
+ Tool capabilities are different. Depending on the environment, one
may install a lightweight tool providing little information. 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.
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.
Curry Informational - Expires June 2001 [Page 7]
Internet Draft IDMEF Data Model and XML DTD December 2000
+ 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.
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.
+ 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.
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.2. Design goals
3.2.1. Representing events
The goal of the data model is to provide a standard representation of
the information that an intrusion-detection analyzer detected an
occurrence of some unusual activity. These alerts may be simple or
complex, depending on the capabilities of the analyzer that created
them.
3.2.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 report
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 reported 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 interoperability and MUST be avoided as
much as possible.
Curry Informational - Expires June 2001 [Page 8]
Internet Draft IDMEF Data Model and XML DTD December 2000
3.2.3. Relationship between alerts
Intrusion detection alerts can be transmitted at several levels. This
draft applies to both very simple alerts (those alerts that are the
result of a single action or operation in the system, such as a
failed login report) and to more complex alerts (the aggregation of
several actions in the system to generate the alert, or the
aggregation of several simple alerts).
As such, the data model must provide a way to describe the
relationship between low level and high-level alerts.
3.3. UML Overview
The data model is described using the Universal Modeling Language
(UML)[6]. 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 | -> Class name (in uppercase)
+---------------------+
| Attribute | -> Name of attribute 1
| ... |
| Attribute | -> Name of attribute N
+---------------------+
Please note that attributes for a class do not appear in all diagrams
that use the class.
3.3.1. Relationships
This data model currently uses only two relationships, the
inheritance relationship and the aggregation relationship.
3.3.1.1. Inheritance Relationship
Inheritance denotes a superclass, subclass type of 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
Curry Informational - Expires June 2001 [Page 9]
Internet Draft IDMEF Data Model and XML DTD December 2000
ALERT. It contains all the attributes of Alert as well as any
attributes contained in the extended alert class. (Note: EXTENDED
ALERT does not have any particular role elsewhere in this document).
+---------------------+
| ALERT |
+---------------------+
/_\
|
|
+---------------------+
| EXTENDED_ALERT |
+---------------------+
3.3.1.2. Aggregation Relationship
Aggregation is a form of association in which the whole is related to
its parts. This type of relationship is also referred to as a "part-
of" relationship. In this case the aggregate class contains all of
its own attributes and as many of the attributes associated with its
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.
+---------------------+ 1 +---------------------+
| ALERT |<>----------| ANALYZER |
+---------------------+ +---------------------+
| |
| | 1 +---------------------+
| |<>----------| NAME |
| | +---------------------+
| |
| | 0..*+---------------------+
| |<>----------| TARGET |
| | +---------------------+
| |
| | 0..*+---------------------+
| |<>----------| SOURCE |
| | +---------------------+
| |
| | 0..*+---------------------+
| |<>----------| ADDITIONALDATA |
+---------------------+ +---------------------+
3.3.1.3. Multiplicity Indicator
Multiplicity defines the number of objects within a class that are
linked to one another by an aggregation relationship (Section
3.3.1.2). Typically multiplicity indicators are placed at each end of
the association line. In this document if a multiplicity number is
Curry Informational - Expires June 2001 [Page 10]
Internet Draft IDMEF Data Model and XML DTD December 2000
left off it is assumed to be 1 (one). Standard symbols, 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 its own
class and the attributes of exactly one Analyzer and the attributes
of 1 Name. I may contain the attributes of zero or more target(s),
zero or more source(s), and zero or more items of additional data.
3.3.2. 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 rather intended to convey to the reader what kind of data the
data model is expecting for this attribute. The exact representation
is left to the XML DTD starting in Section 7. For example, the
INTEGER type indicates that the data model views this attribute as an
integer. It might actually 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 or UTF-16 character
STRING An ordered sequence of characters of known length
BYTE Byte (8-bits, no parity)
TIME A structure or schema carrying time representation. This
is defined in the XML representation in Section 7 and is
understood as a generic time representation for the data
model.
ENUM An enumerated type consisting of an ordered list of
acceptable values. When an attribute is specified as ENUM,
a table describing the acceptable values for the ENUM
follows the attribute definition table. Each value has a
rank (number) and a representing keyword.
The default values are specified per class for each attribute. Only
mandatory attributes have default values.
Curry Informational - Expires June 2001 [Page 11]
Internet Draft IDMEF Data Model and XML DTD December 2000
4. The Data Model
4.1. Data model overview
An overview of the data model is presented in Figure 1. The main
component 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 describes the subject of the alert, i.e. the
reason for sending it; at least one of them MUST be provided in the
alert.
+-------+ 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+---------+
| | 0..*+----------------+ +------| PROCESS |
| |<>------| ADDITIONALDATA | +---------+
+-------+ +----------------+
Figure 1: Data Model Overview
In addition, each alert is associated with zero or more TARGETs, and
with zero or more SOURCEs. Each TARGET and SOURCE is described by a
number of attributes, as described in sections 4.2.8 and 4.2.9.
Provision of additional alert data is done by subclassing any of the
model classes. Standard extensions and examples are given in section
4.3.
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 formatting the alert.
Curry Informational - Expires June 2001 [Page 12]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2. 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
2.
+--------------------+ 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..*+----------------------+
| |<>---------| ADDITIONALDATA |
| | +----------------------+
| | | STRING meaning |
| | | ENUM type |
| | | BYTE[] data |
| | +----------------------+
| | 0..*+----------------------+
| |<>---------| TARGET |
| | +----------------------+
| | 0..*+----------------------+
| |<>---------| SOURCE |
+--------------------+ +----------------------+
/_\
+------------+----------+
| | |
+------------------+ | +-----------------+
| TOOLALERT | | | OVERFLOWALERT |
|------------------| | |-----------------|
|STRING name | | | INTEGER size |
|STRING command | | | BYTE buffer |
|INTEGER[] alertIDs| | | STRING program |
+------------------+ | +-----------------+
+--------------------+
| CORRELATIONALERT |
+--------------------+
| INTEGER[] alertIDs |
+--------------------+
Figure 2: Data model core
Curry Informational - Expires June 2001 [Page 13]
Internet Draft IDMEF Data Model and XML DTD December 2000
Figure 2 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.
Curry Informational - Expires June 2001 [Page 14]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.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 format used is defined
in Section 7. This attribute is MANDATORY and does
not have a default value.
impact ENUM The evaluated impact of the alert on the system.
The range of acceptable values is ["unknown",
"bad-unknown", "not-suspicious", "attempted-
admin", "successful-admin", "attempted-dos",
"successful-dos", "attempted-recon", "successful-
recon-limited", "successful-recon-largescale",
"attempted-user", "successful-user"], further
defined in Section 8.2.1. This attribute is
MANDATORY. The default value is "unknown"
The definition of the acceptable values for the impact attribute is
as follows:
# keyword Definition
0 unknown Event's impact not known to analyzer
1 bad-unknown Event is unpleasant in an unknown way
2 not-suspicious Event is not suspicious in any way
3 attempted-admin Attempt to obtain administrator access
4 successful-admin Successful compromise of admin access
5 attempted-dos Attempted denial-of-service
6 successful-dos Successful denial-of-service
7 attempted-recon Attempted reconnaissance probe
8 successful-recon-limited Successful reconnaissance probe of
limited scope (e.g., one machine)
9 successful-recon- Successful reconnaissance probe of
largescale large scale
10 attempted-user Attempt to obtain user-level access
11 successful-user Successful compromise of user access
Curry Informational - Expires June 2001 [Page 15]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.2. The TOOLALERT class
The TOOLALERT class carries additional information related to the use
of attack tools or Trojan horses.
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.
4.2.3. The CORRELATIONALERT class
The CORRELATIONALERT class carries additional information related to
the correlation of alert information.
Attribute Type Definition
name STRING The reason for grouping the alerts, for example
a correlation method. This attribute is
MANDATORY. This attribute does not have a
default value.
alerts INTEGER[] The list of alert identifiers that are related
to the name. This attribute is OPTIONAL. The
default value is the empty list.
4.2.4. The OVERFLOWALERT class
The OVERFLOWALERT class carries additional information related to
overflow 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
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.
Curry Informational - Expires June 2001 [Page 16]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.5. The ANALYZER class
The ANALYZER class identifies the intrusion detection analyzer that
provided the alert. At the minimum, this is a unique identifier such
as a serial number (unique over the organization where the IDS system
is deployed). Additional identification information is provided.
Attribute Type Definition
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.
4.2.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
origin ENUM The origin of the name. The range of acceptable
values is ["unknown", "bugtraqid", "cve", "vendor
specific"]. This attribute is MANDATORY. The
default value is "unknown".
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 definition of the acceptable values for the origin attribute is
as follows:
# keyword Definition
0 unknown No origin known.
1 bugtraqid The Bugtraq ID naming scheme [7]
2 cve The Common Vulnerability Enumeration naming
scheme [8]
3 vendor-specific A vendor-specific name.
Curry Informational - Expires June 2001 [Page 17]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.7. The ADDITIONALDATA class
The ADDITIONALDATA class provides a way to carry vendor-specific or
implementation specific information.
Attribute Type Definition
meaning STRING Optional. A string that describes the meaning of
the data in this element. These strings will be
implementation-dependent
type ENUM The type of the data in this element. The range of
acceptable values is ["byte", "boolean",
"character", "date", "integer", "ntpstamp", "real",
"string", "time"]. This attribute is MANDATORY.
This attribute does not have a default value.
data BYTE[] The data.
The definition of the acceptable values for the type attribute is as
follows:
# keyword Definition
0 unknown MUST NOT be used. Reserved for future use.
1 byte A single byte
2 character A single character
3 boolean True/false or yes/no
4 integer An integer
5 real A floating-point number
6 date A date string formatted as per Section 7.
7 ntpstamp An NTP timestamp as per Section 7.
8 time A time string formatted as per Section 7
9 string A string of characters
Curry Informational - Expires June 2001 [Page 18]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.8. 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 an ENUM indicating whether the target
is real or target information is unreliable. The relationship diagram
for TARGET is shown in Figure 3.
+------------------+ 0..1+---------------------+
| TARGET |<>------------------| NODE |
|------------------| +---------------------+
| INTEGER targetID |
| ENUM decoy | 0..1+---------------------+
| |<>------------------| USER |
| | +---------------------+
| |
| | 0..1+---------------------+
| |<>------------------| PROCESS |
| | +---------------------+
| |
| | 0..1+---------------------+
| |<>------------------| SERVICE |
+------------------+ +---------------------+
Figure 3: The Target class
The TARGET class defines the following attributes:
Attribute Type Definition
decoy ENUM Indicates if the data associated with the target
is considered real as far as the analyzer can
decide, a decoy, or undetermined. The range of
acceptable values is ["unknown", "yes", "no"].
This attribute is MANDATORY. The default value is
"unknown".
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 definition of the acceptable values for the decoy attribute is as
follows:
# keyword Definition
0 unknown No information
1 yes This is not the true target
2 no This is the true target.
Curry Informational - Expires June 2001 [Page 19]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.9. 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 previously 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 4.
+------------------+ 0..1+---------------------+
| SOURCE |<>------------------| NODE |
|------------------| +---------------------+
| INTEGER sourceID |
| ENUM spoofed | 0..1+---------------------+
| |<>------------------| USER |
| | +---------------------+
| |
| | 0..1+---------------------+
| |<>------------------| PROCESS |
+------------------+ +---------------------+
Figure 4: 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. The range
of acceptable values is ["unknown", "yes", "no"].
This attribute is MANDATORY. The default value is
"unknown".
sourceID INTEGER Source reference token. This attribute is
OPTIONAL. The default value is 0, meaning that
this facility is not supported by the analyzer.
The definition of the acceptable values for the decoy attribute is as
follows:
# keyword Definition
0 unknown No information
1 yes This is the true source
2 no This is not the true source
4.2.10. The support classes
The support classes represent entities in the data model that have an
important role. Their relationship is described in Figure 5. The
following entities have been identified: nodes, processes, users and
Curry Informational - Expires June 2001 [Page 20]
Internet Draft IDMEF Data Model and XML DTD December 2000
services. In addition, an address entity has been defined to enhance
user and node.
+---------------+
| IDENT |
|---------------|
| INTEGER ident |
+---------------+
/_\
|
+------------------------------------+
| |
+------------------+ | +----------------+ |
|PROCESS |---+---|NODE | |
|------------------+ | |----------------+ 0..*+---------------+
|INTEGER pid | | |STRING name |<>-----|ADDRESS |
|STRING name | | |STRING location| |---------------+
|STRING path | | |INTEGER domain | |ENUM category|
|STRING[] arguments| | +----------------+ 0..*|STRING address |
|STRING[] environ | | +----|STRING netmask |
+------------------+ | | +---------------+
| |
+------------------+ | +----------------+ |
|SERVICE |---+---| USER |<>+
|------------------+ +----------------+
|STRING name | | ENUM category |
|INTEGER dport | | | 1..*+---------------+
|INTEGER sport | | |<>-----| USERID |
|STRING protocol | | | +---------------+
+------------------+ +----------------+ | ENUM type |
/_\ | STRING name |
| | INTEGER id |
+-------------------+ +---------------+
| |
+---------------+ +-------------------+
| WEBSERVICE | | SNMPSERVICE |
|---------------| +-------------------+
| STRING url | | STRING Oid |
| STRING cgi | | STRING Community |
| STRING method | | STRING Command |
| STRING args | +-------------------+
+---------------+
Figure 5: Support classes diagram
4.2.10.1. The IDENT class
All support classes inherit from the IDENT class. The IDENT class
provides a reference to an object predefined by the analyzer and the
manager. Instead of sending the complete description of the object,
the IDMEF message MAY contain the reference identifier for this
object.
Curry Informational - Expires June 2001 [Page 21]
Internet Draft IDMEF Data Model and XML DTD December 2000
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
information can serve as a correlation tool. When two intrusion-
detection systems 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 particularly useful for target objects, which are
likely to be well identified by the organization deploying the
intrusion-detection system. This mechanism 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).
4.2.10.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 ENUM The kind of address information. The range of
acceptable values is ["unknown", "atm", "e-mail",
"lotus-notes", "mac", "sna", "vm", "ipv4-addr",
"ipv4-addr-hex", "ipv4-net", "ipv4-net-mask",
"ipv6-addr", "ipv6-net", "ipv6 network address",
"ipv6-net-mask"]. 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 netmask information, if appropriate (depends on
the category attribute). This attribute is
OPTIONAL. The default value is the empty array.
Curry Informational - Expires June 2001 [Page 22]
Internet Draft IDMEF Data Model and XML DTD December 2000
The definition of the acceptable values for the category attribute is
as follows:
# keyword Definition
0 unknown Type not known [SHOULD be avoided]
1 atm Asynchronous Transfer Mode network address
2 e-mail Internet electronic mail address (RFC 822)
3 lotus-notes Lotus Notes address
4 mac Media Access Control (MAC) address
5 sna IBM Shared Network Architecture (SNA) address
6 vm IBM "VM" (PROFS) electronic mail address
7 ipv4-addr IPv4 host address in dotted-decimal notation
(aaa.bbb.ccc.ddd
8 ipv4-addr-hex IPv4 host address in hexadecimal
9 ipv4-net IPv4 network address in dotted-decimal notation,
slash, significant bits (aaa.bbb.ccc.ddd/nn)
10 ipv4-net-mask IPv4 network address and associated network mask.
11 ipv6-addr IPv6 host (equipment) address
12 ipv6-net IPv6 network address
13 ipv6-net-mask IPv6 network address and associated network mask.
4.2.10.3. The USER class
The USER class indicates the different ways by which a user can be
identified. It contains information about which kind of user it is,
and then one or multiple USERID objects which contain the actual user
information.
+---------------+ 1..n+--------------+
| USER |<>------| USERID |
+---------------+ +--------------+
| ENUM category | | ENUM type |
| | | STRING name |
+---------------+ | INTEGER id |
+--------------+
Attribute Type Definition
Category ENUM The category of the user, representing the scope of
user information. The range of acceptable values is
["unknown", "application", "os-device"]. The default
value is "unknown".
The definition of the acceptable values for the category attribute is
as follows:
Curry Informational - Expires June 2001 [Page 23]
Internet Draft IDMEF Data Model and XML DTD December 2000
# keyword Definition
0 unknown User category unknown. SHOULD be avoided.
1 application User identity at the application level. This is for
example an HTTP authentication or an Exchange user
name.
2 os-device This is a login on a distributed network of
workstations or equipment.
The USERID class defines the following attributes:
Attribute Type Definition
type ENUM The type of user information carried by the USERID
object. The range of acceptable values is
["original-user", "current-user", "target-user",
"user-privs", "current-group", "group-privs"]. The
default value is "original-user".
name STRING A string representing the user by name.
number INTEGER A numerical representation of the user, such as a
UNIX id.
Note that there are constraints on the type of USERID associated with
the USER. Only one of each "original-user", "current-user", "target-
user" or "current-group" may be specified with a given USER. Multiple
USERIDs of type "user-privs" and "group-privs" are allowed.
The definition of the acceptable values for the category attribute is
as follows:
Curry Informational - Expires June 2001 [Page 24]
Internet Draft IDMEF Data Model and XML DTD December 2000
# keyword Definition
0 unknown MUST NOT be used, reserved for future use.
1 original-user The actual identity of the user or process being
reported on. On those systems that (a) do some
type of auditing and (b) support extracting a user
id from the "audit id" token, that value should be
used. On those systems that do not support this,
and where the user has logged into the system, the
"login id" should be used.
2 current-user The current user id being used by the user or
process. On Unix systems, this would be the "real"
user id, in general.
3 target-user The user id the user or process is attempting to
become. This would apply, for example, when the
user attempts to use "su," "rlogin," "telnet," etc.
4 current-group The current group id (if applicable) being used by
the user or process. On Unix systems, this would be
the "real" group id, in general.
5 user-privs Other user ids the user or process has the ability
to use. On Unix systems, this would be the
"effective" user id. A list is allowed, for
operating systems/applications that allow more than
one
6 group-privs Other group ids (if applicable) the user or process
has the ability to use. On Unix systems, this would
be the "effective" group id. On BSD-derived Unix
systems, it would also include all the group ids on
the "group list."
4.2.10.4. The NODE class
The NODE class indicates the different ways by which a host or
equipment on the network can be identified.
Attribute 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 ENUM The domain to which the equipment belongs, if
relevant. This attribute is OPTIONAL. Acceptable
values for the enumerated type are [unknown, ads,
afs, coda, dfs, dns, kerberos, nds, nis, nisplus,
nt, wfw]. The default value is unknown
The definition of the acceptable values for the domain attribute is
as follows:
Curry Informational - Expires June 2001 [Page 25]
Internet Draft IDMEF Data Model and XML DTD December 2000
# keyword Definition
0 unknown No relevant domain
1 ads Windows 2000 ADS
2 afs Andrew File System
3 coda CODA distributed file system
4 dfs DFS distributed file system
5 dns Domain Name System
6 kerberos Kerberos realm
7 nds Novell Netware
8 nis Network Information Service (Yellow Page)
9 nisplus Network Information Services Plus
10 nt Windows NT domain
11 wfw Windows for Workgroups
4.2.10.5. The PROCESS class
The PROCESS class gathers information about the process that is being
run.
Attribute Type Definition
name STRING The name of the program being run. This is a
short name, e.g. sendmail or explorer. Options
and path information are provided by additional
attributes. 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
OPTIONAL. The default value is the empty STRING.
Provision of the most meaningful path information
is left to the appreciation of the implementer in
this version of the data model. One could
nevertheless imagine that it SHOULD include the
server name in a Windows NT environment, or MAY
include the mount point in a Unix environment.
arguments STRING[] The arguments passed to the program or the system
call, in the order in which they appear on the
command line. This attribute is OPTIONAL. The
default value is the empty array. This version of
the data model does not differentiate between
command line flags (e.g. -x) and their associated
values.
environ STRING[] The environment strings with which the process is
being run. This argument is optional. The default
value is the empty array. For example, the string
"PATH=/bin:/usr/bin" is an acceptable value.
Curry Informational - Expires June 2001 [Page 26]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.2.11. 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. The name of the service
is independent of the destination port (dport
attribute). A combination of "name=http" and
"dport=8080" is perfectly valid. Implementers MUST
use the name listed in the IANA list of well-known
ports if applicable.
dport INTEGER The port to which the connection request is
addressed. In many situations, this will be a
well-known port in the IANA list, associated with
a name.
sport INTEGER The source port from which the connection
originated. In many situations, this will be a
high-numbered port.
protocol STRING The name of the protocol used.
There should be more information concerning the protocol. The service
name does not necessarily matches the application level protocol used
to interpret the event, one may connect using TELNET to an HTTP port;
there may be protocol encapsulation. The original meaning of the
protocol was tcp/udp, now we need to create a class with a hierarchy
of levels, IP/ICMP/ARP/EGP/OSPF/...; TCP/UDP/?; other on top, same
thing as name ?/is there something on top of application-layer
protocols ?
4.2.11.1. 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, 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).
Curry Informational - Expires June 2001 [Page 27]
Internet Draft IDMEF Data Model and XML DTD December 2000
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.
4.2.11.2. 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.
Attribute 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 sent to the SNMP daemon (e.g. GET, SET,
...). This attribute is OPTIONAL. The default value
is the empty STRING.
Note that even though it is possible to generate an alert of class
SNMPSERVICE with only default values, analyzers MUST NOT do that.
4.3. 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
transport. When a manager receives information from an analyzer that
it cannot understand, the unknown information MUST be ignored until
the manager has been enriched with the appropriate data definition
and semantic. When the vendor extensions mature, they can be
incorporated in the data model.
Depending on the kind of extension needed, two mechanisms can be
used. Note that these mechanisms extend the data model only, and that
additional mechanisms are provided in the XML DTD to transport
additional information which does not fit in the current data model,
see section 8.7.
Curry Informational - Expires June 2001 [Page 28]
Internet Draft IDMEF Data Model and XML DTD December 2000
4.3.1. Extension by aggregation
Extension by aggregation consists of aggregating a new class to one
of the existing classes of the data model. This is the mechanism used
for example to associate the NAME class with the ALERT class. This
type of extension allows propagation of the additional information to
all alerts sent by the analyzer that uses the extension.
Two methods for realizing this type of extension for the XML DTD are
described in Sections 10.2 and 10.3.
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
appropriate time information. The model would then look like Figure
6.
+----------+ 1+--------------+
| ALERT |<>------| ANALYZER |
| | +--------------+
| |
| | 1..*+--------------+
| |<>------|CLASSIFICATION|
| | +--------------+
| |
| | 1..*+--------------+
| |<>------| EXTRATIME |
| | +--------------+
| |
| | 0..*+--------------+
| |<>------| TARGET |
| | +--------------+
| |
| | 0..*+--------------+
| |<>------| SOURCE |
+----------+ +--------------+
Figure 6: Insertion of the EXTRATIME class
4.3.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).
Curry Informational - Expires June 2001 [Page 29]
Internet Draft IDMEF Data Model and XML DTD December 2000
5. Arguments for the realization of the class hierarchy in XML
5.1. The Extensible Markup Language
The Extensible Markup Language (XML) [3] is a simplified version of
the Standard Generalized Markup Language (SGML), a text markup syntax
defined by the ISO 8879 standard. XML is gaining widespread attention
as a language for representing and exchanging documents and data on
the Internet, and as the solution to most of the problems inherent in
HyperText Markup Language (HTML). XML was published as a
recommendation by the World Wide Web Consortium (W3C) on February 10,
1998.
XML is a metalanguage -- a language for describing other languages --
that enables an application to define its own markup. XML allows the
definition of customized markup languages for different types of
documents and different applications. This differs from HTML, in
which there is a fixed set of tags with preset meanings that must be
"adapted" for specialized uses. Both XML and HTML use tags
(identifiers delimited by '<' and '>') and attributes (of the form
"name='value'"). But where "<p>" always means "paragraph" in HTML, it
may mean "paragraph," "person," "price," or "platypus" in XML, or it
might have no meaning at all, depending on the particular
application.
The publication of XML was followed by the publication of a second
recommendation [9] by the World Wide Web Consortium, defining the use
of namespaces in XML documents. An XML namespace is a collection of
names, identified by a Universal Resource Identifier (URI). It allows
documents of different types, that use tags with the same names, to
be merged with no confusion. When using namespaces, each tag is
identified with the namespace it comes from, allowing tags from
different namespaces with the same names to occur in the same
document. For example, a single document could contain both
"usa:football" and "europe:football" tags, each with different
meanings.
In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.
5.2. Rationale for Implementing IDMEF in XML
XML-based applications are being used or developed for a wide variety
of uses, including electronic data interchange in a variety of
fields, financial data interchange, electronic business cards,
calendar and scheduling, enterprise software distribution, web "push"
technology, and markup languages for chemistry, mathematics, music,
molecular dynamics, astronomy, book and periodical publishing, web
publishing, weather observations, real estate transactions, and many
others.
Curry Informational - Expires June 2001 [Page 30]
Internet Draft IDMEF Data Model and XML DTD December 2000
XML's flexibility makes it a good choice for these applications; that
same flexibility makes it a good choice for implementing the IDMEF as
well. Other, more specific reasons for choosing XML to implement the
IDMEF are:
+ XML allows a custom language to be developed specifically for the
purpose of describing intrusion detection alerts. It also defines
a standard way to extend this language, either for later revisions
of this document ("standard" extensions), or for vendor-specific
use ("non-standard" extensions).
+ Software tools for processing XML documents are widely available,
in both commercial and open source forms. A variety of tools and
APIs for parsing and/or validating XML are available in a variety
of languages, including Java, C, C++, Tcl, Perl, Python, and GNU
Emacs Lisp. Widespread access to tools will make adoption of the
IDMEF by product developers easier, and hopefully, faster.
+ XML meets IDMEF Requirement 5.1, that message formats support full
internationalization and localization. The XML standard specifies
support for both the UTF-8 and UTF-16 encodings of ISO 10646
(Unicode), making IDMEF compatible with both one- and two-byte
character sets. XML also provides support for specifying, on a
per-element basis, the language in which the element's content is
written, making IDMEF easy to adapt to "Natural Language Support"
versions of a product.
+ XML meets IDMEF Requirement 5.2, that message formats must support
filtering and aggregation. XML's integration with XSL, a style
language, allows messages to be combined, discarded, and
rearranged.
+ Ongoing XML development projects, in the W3C and elsewhere, will
provide object-oriented extensions, database support, and other
useful features. If implemented in XML, the IDMEF immediately
gains these features as well.
+ XML is free, with no license, no license fees, and no royalties.
5.3. Relationship to the IDMEF Class Hierarchy
This implementation follows the model described in Section 4 almost
exactly, with the following exceptions and restrictions:
+ XML tags have the names given to the various classes in the model,
with a few minor exceptions where changes were made to deal with
XML scoping rules or to increase consistency with the rest of the
implementation.
+ XML does not support "inheritance;" tags may only be used at the
level at which they are declared. Subclasses are implemented by
Curry Informational - Expires June 2001 [Page 31]
Internet Draft IDMEF Data Model and XML DTD December 2000
making the tags for those classes child tags of the tags for the
parent classes.
+ Some extensions have been made, represented by the following
elements: <Heartbeat>, <AdditionalData>, <DetectTime>,
<AnalyzerTime>, and <portlist>.
These changes make little difference in the overall usefulness of the
model, or XML as an implementation language.
Curry Informational - Expires June 2001 [Page 32]
Internet Draft IDMEF Data Model and XML DTD December 2000
6. Use of XML in the IDMEF
This section describes how some of XML's features and requirements
will impact the IDMEF.
6.1. The IDMEF Document Prolog
The "prolog" of an IDMEF document, that part that precedes anything
else, consists of the XML declaration and the document type
declaration.
6.1.1. XML Declaration
Every XML document (and therefore every IDMEF document) starts with
an XML declaration. The XML declaration specifies the version of XML
being used; it may also specify the character set being used.
The XML declaration looks like:
<?xml version="1.0" ?>
If a character encoding is specified, the declaration looks like:
<?xml version="1.0" encoding="charset" ?>
where "charset" is the name of the character encoding in use (see
section 6.2). If no encoding is specified, UTF-8 is assumed.
IDMEF documents being exchanged between IDMEF applications MUST begin
with an XML declaration, and MUST specify the XML version in use.
Specification of the encoding in use is RECOMMENDED.
IDMEF applications MAY choose to omit the XML declaration internally
to conserve space, adding it only when the message is sent to another
destination (e.g., a web browser). This practice is NOT RECOMMENDED
unless it can be accomplished without loss of each message's version
and encoding information.
6.1.2. XML Document Type Definition (DTD)
The Document Type Definition (DTD) specifies the exact syntax of an
XML document. It defines the various tags that may be used in the
document, how the tags are related to each other, which tags are
mandatory and which are optional, and so forth.
The IDMEF Document Type Definition is listed in its entirety in
Section 11.
It is expected that IDMEF applications will not normally include the
IDMEF DTD itself in their communications. Instead, the DTD will be
Curry Informational - Expires June 2001 [Page 33]
Internet Draft IDMEF Data Model and XML DTD December 2000
referenced in the document type declaration in the document entity
(see below). Such IDMEF documents will be well-formed and valid as
defined in [3].
Other IDMEF documents will be specified that do not include the
document prolog (e.g., entries in an IDMEF-format database). Such
IDMEF documents will be well-formed but not valid.
Generally, well-formedness implies that a document has a single
element that contains everything else (e.g., "<book>"), and that all
the other elements nest nicely within each other without any
overlapping (e.g., a "chapter" does not start in the middle of
another "chapter").
Validity further implies that not only is the document well-formed,
but it also follows specific rules (contained in the Document Type
Definition) about which elements are "legal" in the document, how
those elements nest within other elements, and so on (e.g., a
"chapter" does not begin in the middle of a "title"). A document
CANNOT be valid unless it references a DTD (see Section 6.1.4).
XML processors are required to be able to parse any well-formed
document, valid or not. The purpose of validation is to make the
processing of that document (what's done with the data after it's
parsed) easier. Without validation, a document may contain elements
in nonsense order, elements "invented" by the author that the
processing application doesn't understand, and so forth.
IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid
whenever both possible and practical.
6.1.3. IDMEF DTD Formal Public Identifier
The formal public identifier (FPI) for the Document Type Definition
described in this memo is:
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN"
NOTE: The "RFCxxxx" text in the FPI value will be replaced
with the actual RFC number, if this memo is published
as an RFC.
This FPI MUST be used in the document type declaration within an XML
document referencing the DTD defined by this memo, as shown in the
following section.
6.1.4. IDMEF DTD Document Type Declaration
Curry Informational - Expires June 2001 [Page 34]
Internet Draft IDMEF Data Model and XML DTD December 2000
The document type declaration for an XML document referencing the DTD
defined by this memo will usually be specified in one of the
following ways:
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.1//EN">
The last component of the document type declaration is the formal
public identifier (FPI) specified in the previous section.
<!DOCTYPE IDMEF-Message SYSTEM "/some/path/to/the/idmef-message.dtd">
The last component of the document type declaration is a URL that
points to a copy of the Document Type Definition.
To be valid (see above), an XML document must contain a document type
declaration. However, this represents significant overhead to an
IDMEF application, both in the bandwidth it consumes as well as the
requirements it places on the XML parser (not only to parse the
declaration itself, but also to parse the DTD it references).
Implementers MAY decide, therefore, to have analyzers and managers
agree out-of-band on the particular document type definition they
will be using (the standard one as defined here, or one with
extensions), and then omit the document type declaration from IDMEF
messages. Great care must be taken in doing this however, as the
manager may have to accept messages from analyzers using DTDs with
different sets of extensions.
6.2. Character Data Processing in XML and IDMEF
The XML standard requires that XML processors support the UTF-8 and
UTF-16 encodings of ISO 10646 (Unicode), making XML compatible with
both one- and two-byte character sets. While many XML processing
applications may support other character sets, only UTF-8 and UTF-16
can be relied upon from a portability viewpoint.
A document's XML declaration (see section 6.1.1) specifies the
character encoding to be used in the document, as follows:
<?xml version="1.0" encoding="charset" ?>
where "charset" is the name of the character set, as registered with
the Internet Assigned Numbers Authority (IANA), see [10].
Consistent with the XML standard, if no encoding is specified for an
IDMEF message, UTF-8 SHALL be assumed.
IDMEF applications MUST NOT use, and IDMEF messages MUST NOT be
encoded in, character encodings other than UTF-8 and UTF-16. Note
that since ASCII is a subset of UTF-8, it MAY be used to encode IDMEF
messages.
Curry Informational - Expires June 2001 [Page 35]
Internet Draft IDMEF Data Model and XML DTD December 2000
Per the XML standard, IDMEF documents encoded in UTF-16 MUST begin
with the Byte Order Mark described by ISO/IEC 10646 Annex E and
Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character,
#xFEFF).
6.2.1. Character Entity References
Within XML documents, certain characters have special meanings in
some contexts. To include the actual character itself in one of these
contexts, a special escape sequence, called an entity reference, must
be used.
The characters that sometimes need to be escaped, and their entity
references, are:
Character Entity Reference
---------------------------------
& &
< <
> >
" "
' '
It is RECOMMENDED that IDMEF applications use the entity reference
form whenever writing these characters in data, to avoid any
possibility of misinterpretation.
6.2.2. Character Code References
Any character defined by the ISO/IEC 10646 standard may be included
in an XML document by the use of a character reference. A character
reference is started with the characters '&' and '#', and ended with
the character ';'. Between these characters, the character code for
the character inserted.
If the character code is preceded by an 'x' it is interpreted in
hexadecimal (base 16), otherwise, it is interpreted in decimal (base
10). For instance, the ampersand (&) is encoded as & or &
and the less-than sign (<) is encoded as < or <.
Any one- or two-byte character specified in the Unicode standard can
be included in a document using this technique.
6.2.3. White Space Processing
XML preserves white space by default. The XML processor passes all
white space characters to the application unchanged. This is much
different from HTML (and SGML), in which, although the space/no space
Curry Informational - Expires June 2001 [Page 36]
Internet Draft IDMEF Data Model and XML DTD December 2000
distinction is meaningful, the one space/many spaces distinction is
not.
XML allows tags to identify the importance of white space in their
content by using the "xml:space" attribute:
<tagname xml:space="action">
where "action" is either "default" or "preserve."
If "action" is "preserve," the application MUST treat all white space
in the tag's content as significant. If "action" is "default," the
application is free to do whatever it normally would with white space
in the tag's content.
The intent declared with the "xml:space" attribute is considered to
apply to all attributes and content of the element where it is
specified, unless overridden with an instance of "xml:space" on
another element within that content.
All IDMEF tags support the "xml:space" attribute.
6.3. Languages in XML and IDMEF
XML allows tags to identify the language their content is written in
by using the "xml:lang" attribute:
<tagname xml:lang="langcode">
where "langcode" is a language tag as described in RFC 1766 [11].
The intent declared with the "xml:lang" attribute is considered to
apply to all attributes and content of the element where it is
specified, unless overridden with an instance of "xml:lang" on
another element within that content.
IDMEF applications SHOULD specify the language in which their
contents are encoded; in general this can be done by specifying the
"xml:lang" attribute for the top-level <IDMEF-Message> tag.
If no language is specified for an IDMEF message, English SHALL be
assumed.
All IDMEF tags support the "xml:lang" attribute.
6.4. Unrecognized Tags in IDMEF Messages
On occasion, an IDMEF application may receive a well-formed, or even
well-formed and valid, IDMEF message containing tags that it does not
understand. The tags may be either:
Curry Informational - Expires June 2001 [Page 37]
Internet Draft IDMEF Data Model and XML DTD December 2000
+ Recognized as "legitimate" (a valid document), but the application
does not know the semantic meaning of the tag's content; or
+ Not recognized at all.
IDMEF applications MUST continue to process IDMEF messages that
contain unknown tags, provided that such messages meet the well-
formedness requirement of Section 6.1.2. It is up to the individual
application to decide how to process any content from the unknown
tag(s).
6.5. Digital Signatures
The joint IETF/W3C XML Signature Working Group is currently working
to specify XML digital signature processing rules and syntax [12].
XML Signatures provide integrity, message authentication, and/or
signer authentication services for data of any type, whether located
within the XML that includes the signature or elsewhere.
The IDMEF requirements document assigns responsibility for message
integrity and authentication to the communications protocol, not the
message format. However, in situations where IDMEF messages are
exchanged over other, less secure protocols, or in cases where the
digital signatures must be archived for later use, the inclusion of
digital signatures within an IDMEF message itself may be desirable.
Specifications for the use of digital signatures within IDMEF
messages are outside the scope of this document. However, use of the
XML Signature standard is RECOMMENDED if such functionality is
needed.
Curry Informational - Expires June 2001 [Page 38]
Internet Draft IDMEF Data Model and XML DTD December 2000
7. IDMEF Data Types
XML is a typeless language; everything is simply a stream of bytes,
and it is left to the application to extract meaning from them.
That being said, this specification makes the following rules to
allow interoperability in interpreting IDMEF documents:
1. Integer data MUST be encoded in either Base 10 or Base 16. Base 10
encoding uses the digits '0' through '9' and an optional sign ('+'
or '-'). Base 16 encoding uses the digits '0' through '9' and 'a'
through 'f' (or their upper case equivalents), and is preceded by
the characters "0x". For example, the number one hundred twenty-
three would be encoded as "123" in Base 10, or "0x7b" in Base 16.
2. Floating-point (real) data MUST be encoded in Base 10. The
encoding is that of the POSIX strtod() function: an optional sign
('+' or '-') followed by a non-empty sequence of digits optionally
containing a radix character, then an optional exponent part. An
exponent part consists of an 'e' or 'E', followed by an optional
sign, followed by one or more decimal digits.
3. Character and character string data does not require quoting, as
the IDMEF tags provide that functionality.
4. Dates, as used in the <date> element, MUST be encoded as a four-
digit year, two-digit month, and two-digit day, separated by
dashes. The two-digit day and its corresponding dash MAY be
omitted to represent an entire month. For example, March 13, 2000
would be encoded as "2000-03-13", and December, 1999 would be
encoded as "1999-12".
5. Time of day, as used in the <time> element, MUST be encoded as a
two-digit hour, two-digit minutes, and two-digit seconds,
separated by colons. The two-digit seconds and corresponding colon
MAY be omitted to represent times with less precision. The seconds
field MAY be followed by a decimal point and fractional number of
seconds, if more precision is needed. All times MUST be specified
on a 24-hour clock. For example, 6:00 P.M. would be encoded as
"18:00", 3:15:27 A.M. would be encoded as "03:15:27", and two-
tenths of a second past midnight would be encoded as "00:00:00.2".
6. NTP timestamps, as used in the <ntpstamp> element, are described
in detail in [13]. NTP timestamps are represented as a 64-bit
unsigned fixed-point number containing seconds relative to 0h on 1
January 1900. The integer part is in the first 32 bits and the
fraction part in the last 32 bits. Within IDMEF messages, these
timestamps MUST be encoded as two 32-bit hexadecimal values,
separated by a period ("."), for example, "0x123.0x456".
7. Port lists, as used in the <portlist> element, are encoded as a
comma-separated list of numbers (individual integers) and ranges
Curry Informational - Expires June 2001 [Page 39]
Internet Draft IDMEF Data Model and XML DTD December 2000
(N-M means ports N through M, inclusive). Any combination of
numbers and ranges may be used in a single list. For example: 5-
25,37,42,43,53,69-119,123-514.
8. The identification numbers used with the "sourceid" attribute of
the <Source> element, the "targetid" attribute of the <Target>
element, and the "ident" attribute of the <Address>, <Node>,
<Process>, <Service> and <User> elements MUST be unique for each
particular combination of elements and sub-elements. Each time the
same entity is identified in the same way, this number SHOULD be
the same. Note, though, that if the same entity is identified in
two different ways (e.g., once by host name and once by IP
address), two different id numbers MUST be generated. A value of 0
indicates that the analyzer is not capable of identifying these
entities uniquely.
- An easy, albeit overly complex, way to accomplish this would be
to compute the cryptographic checksum of the element and its
sub-elements.)
- The above does not apply to the "alertid" attribute of the
<Alert> element, the "heartbeatid" attribute of the <Heartbeat>
element, or the "ident" attribute of the <Analyzer> attribute,
which have different rules.
Curry Informational - Expires June 2001 [Page 40]
Internet Draft IDMEF Data Model and XML DTD December 2000
8. Structure of an IDMEF Message
This section describes the individual elements and attributes that
make up an IDMEF message. It is organized in a somewhat "top down"
manner, in that the more significant elements are described first,
followed by the less significant ones.
A description of the element is provided, followed by a list of the
element's attributes, and then a list of the sub-elements that the
element may contain.
For attributes, the notation "required" indicates that a value for
the attribute must be specified, while "optional" indicates that a
value is not required. All optional attributes have default values
that the manager (XML parser) will assume if no other value is
provided.
For sub-elements, the number of times the element may occur is given.
Possible values are "exactly one," "zero or one," "zero or more," and
"one or more." Except as stated otherwise, sub-elements must occur in
the order shown.
8.1. The IDMEF-Message Root Element
An IDMEF message (document) contains one or more alerts and other
message types (see below). The <IDMEF-Message> element represents
this; all other elements are sub-elements of <IDMEF-Message>. Put
another way, <IDMEF-Message> is the root element of an IDMEF
document.
The <IDMEF-Message> element has one attribute:
version
- Optional. The version of the IDMEF message specification this
message conforms to; messages conforming to the format described
in this memo MUST use "0.1" as the value for this attribute.
The <IDMEF-Message> element may contain the following sub-elements,
in any order:
<Alert>
- Zero or more. Description of an intrusion detection alert. The
data model specifies the contents of this element type.
<Heartbeat>
- Zero or more. Data about the "health" of the analyzer. This is an
extension element, not specified in the data model.
8.2. The Message Type Elements
Curry Informational - Expires June 2001 [Page 41]
Internet Draft IDMEF Data Model and XML DTD December 2000
There are two types of IDMEF message: <Alert>, and <Heartbeat>. These
elements are sub-elements of the <IDMEF-Message> element.
8.2.1. Alert
The <Alert> element implements the ALERT class described in Section
4.2.1. It is used to describe an alert. It contains the name of the
analyzer that generated the alert, the event that caused the alert to
be generated, and information about the source(s) and target(s) of
the event.
The <Alert> element has the following attributes:
alertid
Required. A serial number for the alert. This number MUST be
unique for every alert generated by a given analyzer. The default
value is 0, which indicates that the analyzer cannot provide this
information reliably.
impact
Required. The evaluated impact of the event on the system. The
list of acceptable values is [unknown, bad-unknown, not-
suspicious, attempted-admin, successful-admin, attempted-dos,
successful-dos, attempted-recon, successful-recon-limited,
successful-recon-largescale, attempted-user, successful-user],
refer to Section 4.2.1 for the significance of the keywords.
version
Required. The version of the class hierarchy used. Messages
conforming to the format described in this memo MUST use "1" as
the value for this attribute.
The <Alert> element has the following sub-elements:
<Time>
Exactly one. The time the alert was generated.
<Analyzer>
Exactly one. The analyzer sending the alert.
<Classification>
One or more. The name of the vulnerability (event causing the
alert).
<Source>
Zero or more. The source(s) of the event/attack.
<Target>
Zero or more. The target(s) of the event/attack.
<ToolAlert>
Zero or one. Information about the tool that caused the event.
Curry Informational - Expires June 2001 [Page 42]
Internet Draft IDMEF Data Model and XML DTD December 2000
<OverflowAlert>
Zero or one. Information about buffer-overflow events.
<CorrelationAlert>
Zero or one. Identifies the alerts used in the correlation.
<AdditionalData>
Zero or more. Additional information provided.
8.2.1.1. CorrelationAlert
The <CorrelationAlert> sub-element of <Alert> is used to provide
additional information about alert correlation activities. It has one
sub-element:
<alertid>
One or more. The "alertid" strings of the alerts that were used by
the correlation engine to generate this alert.
8.2.1.2. OverflowAlert
The <OverflowAlert> sub-element of <Alert> is used to provide
additional information when the alert is the result of a buffer
overflow attack. It has three sub-elements:
<program>
Exactly one. The program that the overflow attempted to run.
<size>
Exactly one. The size, in bytes, of the overflowing buffer.
<buffer>
Zero or one. Some or all of the data that was sent to the program.
8.2.1.3. ToolAlert
The <ToolAlert> sub-element of <Alert> is used to provide additional
information when the analyzer recognizes the use of a particular
attack tool or Trojan horse. This may allow the analyzer to group
alerts it has already received into a single "meta-alert" for display
purposes. <ToolAlert> has three sub-elements:
<name>
Exactly one. The reason for grouping the alerts, e.g., the name of
an attack tool.
<command>
Curry Informational - Expires June 2001 [Page 43]
Internet Draft IDMEF Data Model and XML DTD December 2000
Zero or one. The command or operation the tool was asked to
perform.
<alertid>
Zero or more. The alerts that have been identified as being
related to the name.
8.2.2. Heartbeat
The <Heartbeat> element is used by an analyzer to provide status to a
manager. In its simplest form, the heartbeat simply indicates to the
manager that the analyzer is still up and running. In more complex
forms, it can be used to communicate information such as restarts,
ruleset reloads, disk and/or memory consumption statistics, and so
on.
The <Heartbeat> element has the following attribute:
heartbeatid
Required. A serial number for the heartbeat. This string SHOULD be
unique for every heartbeat generated by a given analyzer. It MUST
NOT be possible to confuse a "heartbeatid" with an "alertid" from
the same analyzer.
The <Heartbeat> element has the following sub-elements:
<Time>
Exactly one. The time the heartbeat was generated.
<Analyzer>
Exactly one. The analyzer sending the heartbeat.
<AdditionalData>
Zero or more. Additional information provided. See Examples 9.4
and 9.6 for suggested usage.
8.3. Time Elements
The IDMEF data model provides for one piece of time data, the alert
generation time. This specification extends that, adding the event
detection time (which, especially in the case of correlation, may be
quite different from the alert generation time), and current analyzer
time.
8.3.1. Time
The <Time> element provides the time at which the alert or heartbeat
was sent by the analyzer.
Curry Informational - Expires June 2001 [Page 44]
Internet Draft IDMEF Data Model and XML DTD December 2000
The <Time> element has the following attribute:
offset
Optional. Specifies the offset from Coordinated Universal
Time(UTC, formerly referred to as "Greenwich Mean Time") that the
<date> and <time> elements represent. A "+" or "-" indicates
whether the <time> is ahead of (i.e., east of) or behind (i.e.,
west of) Universal Time. The first two digits indicate the number
of hours difference from Universal Time, and the last two digits
indicate the number of minutes difference from Universal Time.
(Hence, "+hhmm" means +(hh * 60 + mm) minutes, and "-hhmm" means -
(hh * 60 + mm) minutes). The form "+0000" SHOULD be used to
indicate a time zone at Universal Time. Though "-0000" also
indicates Universal Time, it is used to indicate that the time was
generated on a system that may be in a local time zone other than
Universal Time and therefore indicates that the <date>/<time>
contains no information about the local time zone. Default value:
"+0000".
The <Time> element has the following sub-elements:
<ntpstamp>
Exactly one. The NTP timestamp. See Section 7 for formatting
details.
<date>
Exactly one. The date. See Section 7 for formatting details.
<time>
Exactly one. The time. See Section 7 for formatting details.
<DetectTime>
Zero or one. The time the event was detected.
<AnalyzerTime>
Zero or one. The current date and time on the analyzer.
In the event of a discrepancy between the time contained in the
<ntpstamp> element and the time contained in the <date> and <time>
elements, the time in the <ntpstamp> element shall prevail.
8.3.2. DetectTime
The <DetectTime> element provides the time the event that generated
this alert was detected. This may be quite different from the time
the alert was generated.
The <DetectTime> element has one attribute, "offset," and three sub-
elements, <ntpstamp>, <date>, and <time>, as described in Section
8.3.1, above.
Curry Informational - Expires June 2001 [Page 45]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.3.3. AnalyzerTime
The <AnalyzerTime> element provides the current date and time on the
analyzer. By comparing this to its own date and time, a manager can
compute an "adjustment" to the other times in this element,
compensating for unsynchronized clocks.
The <AnalyzerTime> element has one attribute, "offset," and three
sub-elements, <ntpstamp>, <date>, and <time>, as described in Section
8.3.1, above.
8.4. High-Level Entity Identification Elements
There are three "high-level" entities in the IDMEF model: analyzers,
sources, and targets. The elements described in this section are
used to contain the identification of those entities.
8.4.1. Analyzer
The <Analyzer> element contains all the information that describes
the analyzer sending the current message. Only one analyzer may be
encoded for each alert. The data model does not provide a way to
record a "stream" of analyzers (as would occur in a hierarchical
intrusion detection system, where alerts get relayed up the tree).
The data model does not prevent this architecture, but it doesn't
provide any way to keep track of the relays along the path from the
analyzer to the manager that ultimately receives the alert.
The <Analyzer> element has the following attribute:
ident
Required. Analyzer identification token. This token MUST be unique
within the communicating analyzers and managers.
The <Analyzer> element has the following sub-elements:
<Node>
Zero or one. Identification of the equipment on which the analyzer
resides.
<Process>
Zero or one. Process information concerning the analyzer.
8.4.2. Target
The <Target> element implements the TARGET class defined in Section
0. It contains all the information about the target of an event. An
event may have multiple targets (e.g., in the case of a port sweep).
Curry Informational - Expires June 2001 [Page 46]
Internet Draft IDMEF Data Model and XML DTD December 2000
The <Target> element has the following attributes:
targetid
Optional. See Section 7 for formatting details.
decoy
Required. An indication of whether the analyzer believes this to
be the true target of the event. The list of acceptable values is
[unknown, yes, no], refer to Section 0 for the significance of the
keywords.
The <Target> element has the following sub-elements:
<Node>
Zero or one. Host/device name and address information.
<User>
Zero or one. User information.
<Process>
Zero or one. Process information.
<Service>
Zero or one. Service information.
8.4.3. Source
The <Source> element implements the SOURCE class defined in Section
4.2.9. It contains all the information about the source of an event.
An event may have multiple sources (e.g., in the case of a
distributed denial-of-service attack).
The <Source> element has the following attributes:
sourceid
Optional. See Section 7 for formatting details.
spoofed
Required. An indication of whether the analyzer believes this to
be the true source of the event. The list of acceptable values is
[unknown, yes, no], refer to Section 4.2.9 for the significance of
the keywords.
The <Source> element has the following sub-elements:
<Node>
Zero or one. Host/device name and address information.
<User>
Zero or one. User information.
Curry Informational - Expires June 2001 [Page 47]
Internet Draft IDMEF Data Model and XML DTD December 2000
<Process>
Zero or one. Process information.
8.5. Low-Level Entity Identification Elements
Several elements are used to provide additional details used to
identify entities. These elements are all sub-elements of the
<Alert>, <Analyzer>, <Source>, and <Target> elements.
8.5.1. Address
The <Address> element implements the ADDRESS class described in
Section 4.2.10.2. It provides addressing information for hosts,
networks, and users.
The <Address> element has the following attributes:
ident
Optional. See Section 7 for formatting details.
category
Required. The type of address provided. The list of acceptable
values is [unknown, atm, e-mail, lotus-notes, mac, sna, vm, ipv4-
addr, ipv4-addr-hex, ipv4-net, ipv4-net-mask, ipv6-addr, ipv6-net,
ipv6-net-mask], refer to Section 4.2.10.2 for the significance of
the keywords.
The <Address> element has two sub-elements:
<address>
Required. The address information.
<netmask>
Optional. The network mask, if appropriate (depending on the value
of the "category" attribute).
8.5.2. Classification
The <Classification> element implements the CLASSIFICATION class
defined in Section 4.2.6. It provides the name of the event
(vulnerability) that caused this alert to be generated. Names may
come from several sources.
The <Classification> element has the following attribute:
origin
Optional. The origin of the name. The list of acceptable values is
[unknown, bugtraqid, cve, vendor specific], refer to Section 4.2.6
for the significance of the keywords. Possible values:
Curry Informational - Expires June 2001 [Page 48]
Internet Draft IDMEF Data Model and XML DTD December 2000
The <Name> element has two sub-elements:
<name>
Required. The name of the vulnerability.
<url>
Required. The URL at which the manager can find more information
about the vulnerability and/or the alert.
8.5.3. Node
The <Node> element implements the NODE class defined in section
4.2.10.4. It provides identification of hosts and network equipment.
The <Node> element has the following attributes:
ident
Optional. See Section 7 for formatting details.
category
Optional. The domain to which the provided information belongs, if
relevant. The list of acceptable values is [unknown, ads, afs,
coda, dfs, dns, kerberos, nds, nis, nisplus, nt, wfw], refer to
Section 4.2.10.4 for the significance of the keywords.
The <Node> element has the following sub-elements:
<name>
Zero or one if <Address> information is provided; exactly one
otherwise. The equipment's fully qualified domain name.
<location>
Zero or one. The equipment's physical location.
<Address>
Zero or more. The equipment's network address(es).
8.5.4. Process
The <Process> element implements the PROCESS class defined in Section
4.2.10.5. It provides information about a process being run
on a node.
The <Process> element has the following attribute:
ident
Optional. See Section 7 for formatting details.
The <Process> element has the following sub-elements:
Curry Informational - Expires June 2001 [Page 49]
Internet Draft IDMEF Data Model and XML DTD December 2000
<name>
Exactly one. The name of the process.
<pid>
Zero or one. The system process identifier.
<path>
Zero or one. The path name of the program being run.
<Arguments>
Zero or one. The arguments to the process.
<Environment>
Zero or one. The environment variables associated with the
process.
8.5.5. Service
The <Service> element implements the SERVICE class defined in Section
4.2.11. It provides information about a service being provided by a
node, and also to provide information about connections and
connection attempts.
The <Service> element has the following attribute:
ident
Required. See Section 7 for formatting details.
The <Service> element has the following sub-elements:
<name>
Zero or one. Name of the service. This SHOULD be listed in the
IANA list of well-known ports.
<dport>
Zero or one. Destination port number of the service (port number
to which the connection is addressed).
<sport>
Zero or one. Source port number of the service (port number from
which the connection originates).
<protocol>
Zero or one. Protocol implemented by the service.
<portlist>
Zero or one. List of ports (identifies multiple services). See
Section 7 for formatting details.
<SNMPService>
Zero or one. Additional information about SNMP services.
Curry Informational - Expires June 2001 [Page 50]
Internet Draft IDMEF Data Model and XML DTD December 2000
<WebService>
Zero or one. Additional information about web-based services.
8.5.5.1. SNMPService
The <SNMPService> element provides additional information about SNMP
services.
The <SNMPService> element has the following attribute:
ident
Optional. See Section 7 for formatting details.
The <SNMPService> element has the following sub-elements:
<oid>
Zero or one. The object identifier used in a request.
<community>
Zero or one. The object's community.
<command>
Zero or one. The command.
8.5.5.2. WebService
The <WebService> element provides additional information about web-
based services.
The <WebService> element has the following attribute:
ident
Optional. See Section 7 for formatting details.
The <WebService> element has the following sub-elements:
<url>
Exactly one. The URL in the request.
<cgi>
Zero or one. The CGI script in the request (without arguments)
<method>
Zero or one. The method used for the request.
<Arguments>
Zero or one. The arguments passed to the CGI script.
Curry Informational - Expires June 2001 [Page 51]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.5.6. User
The <User> element implements the USER class defined in Section
4.2.10.3. It identifies users of nodes.
The <User> element has the following attributes:
ident
Optional. See Section 7 for formatting details.
category
Required. The type of user information provided. The list of
acceptable values is [unknown, application, os-device], refer to
Section 4.2.10.3 for the significance of the keywords.
The <User> element has the following sub-elements:
<name>
Zero or one if <uid> information is provided; exactly one
otherwise. The user name.
<uid>
Zero or one if <name> information is provided; exactly one
otherwise. The user id.
<group>
Zero or one. The name of the group or domain the user is in.
<gid>
Zero or one. The group id.
<serial>
Zero or one. The user's serial number or other unique identifier.
<Address>
Zero or more. Addresses associated with the user (e.g., an e-mail
address).
8.6. Simple Elements
The elements described in this section are "simple" elements -- they
have no special attributes associated with them, and they have no
sub-elements. These elements are the lowest level of an IDMEF
document; they contain the actual alert data.
8.6.1. address
The <address> element contains a network address. It is a sub-element
of the <Address> element.
Curry Informational - Expires June 2001 [Page 52]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.6.2. alertid
The <alertid> element contains an alert identifier (the "alertid"
attribute of an <Alert> element). It is a sub-element of the
<CorrelationAlert> and <ToolAlert> elements.
8.6.3. Arguments
The <Arguments> element contains a list of process arguments.
The <Arguments> element has one sub-element:
<arg>
One or more. An argument.
The <Arguments> element is a sub-element of the <Process> and
<WebService> elements.
8.6.3.1. arg
The <arg> element contains a single process argument string. It is a
sub-element of the <Arguments> element.
8.6.4. buffer
The <buffer> element contains some or all of the data that was sent
to a program during a buffer-overflow attack. It is a sub-element of
the <OverflowAlert> element.
8.6.5. cgi
The <cgi> element contains the name of a CGI script. It is a sub-
element of the <WebService> element.
8.6.6. command
The <command> element contains a program name or an SNMP command. It
is a sub-element of the <ToolAlert> and <SNMPService> elements.
8.6.7. community
The <community> element contains an SNMP community name. It is a sub-
element of the <SNMPService> element.
Curry Informational - Expires June 2001 [Page 53]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.6.8. date
The <date> element contains a date string. See Section 7 for
formatting details. The <date> element is a sub-element of the
<AnalyzerTime>, <DetectTime>, and <Time> elements.
8.6.9. dport
The <dport> element contains a destination port number. It is a sub-
element of the <Service> element.
8.6.10. Environment
The <Environment> element contains a list of process environment
variables.
The <Environment> element has one sub-element:
<env>
One or more. An environment variable.
The <Environment> element is a sub-element of the <Process> element.
8.6.10.1. env
The <env> element contains a single process environment string. It is
a sub-element of the <Environment> element.
8.6.11. gid
The <gid> element contains a group identifier. It is a sub-element of
the <User> element.
8.6.12. group
The <group> element contains a group name. It is a sub-element of the
<User> element.
8.6.13. location
The <location> element contains the physical location of a host or
piece of network equipment. It is a sub-element of the <Node>
element.
Curry Informational - Expires June 2001 [Page 54]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.6.14. method
The <method> element contains the HTTP method used to access a web
service. It is a sub-element of the <WebService> element.
8.6.15. name
The <name> element contains the name of a host, piece of network
equipment, process, service, user, or attack tool. The <name>
element is a sub-element of the <Classification>, <Node>, <Process>,
<Service>, <ToolAlert>, and <User> elements.
8.6.16. netmask
The <netmask> element contains a network mask. It is a sub-element
of the <Address> element.
8.6.17. ntpstamp
An NTP timestamp. See Section 7 for formatting details. It is a sub-
element of the <Time>, <AnalyzerTime>, and <DetectTime> elements.
8.6.18. oid
The <oid> element contains an SNMP object identifier. It is a sub-
element of the <SNMPService> element.
8.6.19. path
The <path> element contains the path name of a program. It is a sub-
element of the <Process> element.
8.6.20. pid
The <pid> element contains a process identifier. It is a sub-element
of the <Process> element.
8.6.21. portlist
The <portlist> element contains a list of port numbers. See Section 7
for formatting details. The <portlist> element is a sub-element of
the <Service> element.
Curry Informational - Expires June 2001 [Page 55]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.6.22. program
The <program> element contains the name of a program. It is a sub-
element of the <OverflowAlert> element.
8.6.23. protocol
The <protocol> element contains the name of a protocol. It is a sub-
element of the <Service> element.
8.6.24. serial
The <serial> element contains a person's serial number or other
unique identifying information. It is a sub-element of the <User>
element.
8.6.25. size
The <size> element contains a buffer (data) size, in bytes. It is a
sub-element of the <OverflowAlert> element.
8.6.26. sport
The <sport> element contains a source port number. It is a sub-
element of the <Service> element.
8.6.27. time
The <time> element contains a time string. See Section 7 for
formatting details. The <time> element is a sub-element of the
<AnalyzerTime>, <DetectTime>, and <Time> elements.
8.6.28. url
The <url> element contains a Universal Resource Locator. It is a
sub-element of the <Classification> and <WebService> elements.
8.6.29. uid
The <uid> element implements the USERID class defined in Section
4.2.10.3. It contains a user identifier. It is a sub-element of the
<User> element.
Curry Informational - Expires June 2001 [Page 56]
Internet Draft IDMEF Data Model and XML DTD December 2000
8.7. Providing Additional Information
This specification allows vendors to provide arbitrary information in
an alert (or heartbeat) without having to modify the DTD. This is
done by using the <AdditionalData> element.
8.7.1. AdditionalData
The <AdditionalData> implements the ADDITIONALDATA class defined in
Section 4.2.7. This element is used to provide arbitrary information
in an alert or heartbeat that does not "fit" anywhere else in the
message.
The <AdditionalData> element has two attributes:
meaning
Optional. A string that describes the meaning of the data in this
element. These strings will be implementation-dependent.
type
Optional. The type of the data in this element. Possible values:
["byte", "boolean", "character", "date", "integer", "ntpstamp",
"real", "string", "time"], refer to Section 4.2.7 for the
significance of the keywords.
The <AdditionalData> element has no sub-elements. It is a sub-
element of the <Alert> and <Heartbeat> elements.
9. Examples
The examples shown in this section demonstrate how the IDMEF is used
to encode alert data. The first eight examples are taken from [4],
and show how the IDMEF format relates to the Debar/Huang/Donahoo
class hierarchy.
These examples are for demonstration purposes only. They do not
necessarily represent the only (or even the "best") way to encode a
particular alert, and should not be construed as guidelines on how
particular alerts should be classified.
9.1. Denial of Service Attacks
The following examples show how some common denial of service attacks
could be represented in the IDMEF.
9.1.1. The "teardrop" Attack
Curry Informational - Expires June 2001 [Page 57]
Internet Draft IDMEF Data Model and XML DTD December 2000
Network-based detection of the "teardrop" attack. This shows the
basic format of an alert.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="12345.123456789" impact="successful-dos">
<Time offset="-0500">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>10:01:25.93464</time>
</Time>
<Analyzer ident="12345">
<Node category="dns">
<location>Headquarters DMZ Network</location>
<name>analyzer01.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="bugtraqid">
<name>124</name>
<url>http://www.securityfocus.com</url>
</Classification>
<Source>
<Node ident="12345.s7beae779" category="dns">
<name>badguy.hacker.net</name>
<Address category="ipv4-addr">
<address>123.234.231.121</address>
<netmask>255.255.255.255</netmask>
</Address>
</Node>
</Source>
<Target>
<Node ident="12345.tde796f70" category="dns">
<Address category="ipv4-addr-hex">
<address>de796f70</address>
</Address>
</Node>
</Target>
</Alert>
</IDMEF-Message>
9.1.2. The "ping of death" Attack
Network-based detection of the "ping of death" attack. Note the
identification of multiple targets, and the identification of the
source as a spoofed address.
<?xml version="1.0" encoding="UTF-8"?>
Curry Informational - Expires June 2001 [Page 58]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF
v0.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="1234567890" impact="attempted-dos">
<Time offset="+0000">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>10:01:25.93464</time>
</Time>
<Analyzer ident="123123123">
<Node category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="cve">
<name>CVE-1999-128</name>
<url>http://www.cve.mitre.org/</url>
</Classification>
<Source spoofed="yes">
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
</Source>
<Target>
<Node>
<Address category="ipv4-addr">
<address>123.234.231.121</address>
</Address>
</Node>
</Target>
<Target>
<Node category="nisplus">
<name>lollipop</name>
</Node>
</Target>
<Target>
<Node>
<location>Cabinet B10</location>
<name>Cisco.router.b10</name>
</Node>
</Target>
</Alert>
</IDMEF-Message>
9.2. Port Scanning Attacks
Curry Informational - Expires June 2001 [Page 59]
Internet Draft IDMEF Data Model and XML DTD December 2000
The following examples show how some common port scanning attacks
could be represented in the IDMEF.
9.2.1. Connection to a Disallowed Service
Host-based detection of a policy violation (attempt to obtain
information via "finger"). Note the identification of the target
service, as well as the originating user (obtained, e.g., via RFC
1413).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF
v0.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="1234567890" impact="attempted-recon">
<Time offset="+0200">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>18:47:25</time>
</Time>
<Analyzer ident="123123123">
<Node category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="vendor-specific">
<name>finger</name>
<url>http://www.vendor.com/finger</url>
</Classification>
<Source>
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
</Source>
<Target>
<Node category="nis">
<name>myhost</name>
<Address category="ipv4-addr">
<address>123.234.231.121</address>
</Address>
</Node>
<Service>
<name>finger</name>
<dport>79</dport>
<sport>31532</sport>
</Service>
Curry Informational - Expires June 2001 [Page 60]
Internet Draft IDMEF Data Model and XML DTD December 2000
</Target>
<Target>
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
<User category="os-device">
<name>badguy</name>
</User>
</Target>
</Alert>
</IDMEF-Message>
9.2.2. Simple Port Scanning
Network-based detection of a port scan. This shows detection by a
single analyzer; see Example 7.5 for the same attack as detected by a
correlation engine. Note the use of the <portlist> element to show
the ports that were scanned.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="12345.987654321"
impact="successful-recon-limited">
<Time offset="-0800">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>15:31</time>
</Time>
<Analyzer ident="12345">
<Node category="dns">
<location>Headquarters Web Server</location>
<name>analyzer62.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="vendor-specific">
<name>portscan</name>
<url>http://www.vendor.com/portscan</url>
</Classification>
<Source>
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
</Source>
Curry Informational - Expires June 2001 [Page 61]
Internet Draft IDMEF Data Model and XML DTD December 2000
<Target>
<Node category="dns">
<name>www.bigcompany.com</name>
<Address category="ipv4-addr">
<address>123.234.231.121</address>
</Address>
</Node>
<Service>
<portlist>5-25,37,42,43,53,69-119,123-514</portlist>
</Service>
</Target>
</Alert>
</IDMEF-Message>
9.3. Local Attacks
The following examples show how some common local host attacks could
be represented in the IDMEF.
9.3.1. The "loadmodule" Attack
Host-based detection of the "loadmodule" exploit. This attack
involves tricking the "loadmodule" program to run another program;
since "loadmodule" is set-user-id "root," the executed program runs
with super-user privileges. Note the use of the <User> and <Process>
elements to identify the user attempting the exploit and how he's
doing it.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="345097" impact="attempted-admin">
<Time offset="-0500">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>08:12:32.3</time>
</Time>
<Analyzer ident="372">
<Node category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
<Process>
<name>monitor</name>
<pid>8956</pid>
<Arguments>
<arg>monitor</arg><arg>-d</arg>
<arg>-m</arg><arg>idmanager.bigcompany.com</arg>
Curry Informational - Expires June 2001 [Page 62]
Internet Draft IDMEF Data Model and XML DTD December 2000
<arg>-l</arg><arg>/var/logs/idlog</arg>
</Arguments>
</Process>
</Analyzer>
<Classification origin="bugtraqid">
<name>33</name>
<url>http://www.securityfocus.com</url>
</Classification>
<Source>
<User category="os-device">
<name>joe</name>
<uid>13243</uid>
</User>
<Process>
<name>loadmodule</name>
<path>/usr/openwin/bin</path>
</Process>
</Source>
<Target>
<Node category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
</Target>
</Alert>
</IDMEF-Message>
The IDS could also indicate that the target user is the "root" user;
the alert might then look like:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="345097" impact="attempted-admin">
<Time offset="-0500">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>08:12:32.3</time>
</Time>
<Analyzer ident="372">
<Node category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
<Process>
<name>monitor</name>
<pid>8956</pid>
<Arguments>
<arg>monitor</arg><arg>-d</arg>
<arg>-m</arg><arg>idmanager.bigcompany.com</arg>
<arg>-l</arg><arg>/var/logs/idlog</arg>
Curry Informational - Expires June 2001 [Page 63]
Internet Draft IDMEF Data Model and XML DTD December 2000
</Arguments>
</Process>
</Analyzer>
<Classification origin="bugtraqid">
<name>33</name>
<url>http://www.securityfocus.com</url>
</Classification>
<Source>
<User category="os-device">
<name>joe</name>
<uid>13243</uid>
</User>
<Process>
<name>loadmodule</name>
<path>/usr/openwin/bin</path>
</Process>
</Source>
<Target>
<Node category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
<User category="os-device">
<name>root</name>
<uid>0</uid>
</User>
<Process>
<name>sh</name>
<pid>25134</pid>
<path>/bin/sh</path>
</Process>
</Target>
</Alert>
</IDMEF-Message>
9.3.2. The "phf" Attack
Network-based detection of the "phf" attack. Note the use of the
<WebService> element to provide more details about this particular
attempt.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="1234567890" impact="attempted-recon">
<Time offset="-0100">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>08:12:32</time>
Curry Informational - Expires June 2001 [Page 64]
Internet Draft IDMEF Data Model and XML DTD December 2000
</Time>
<Analyzer ident="123123123">
<Node category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="bugtraqid">
<name>629</name>
<url>http://www.securityfocus.com</url>
</Classification>
<Source>
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
</Source>
<Target>
<Node category="dns">
<name>www.bigcompany.com</name>
<Address category="ipv4-addr">
<address>123.45.67.89</address>
</Address>
</Node>
<Service>
<dport>8080</dport>
<sport>21534</sport>
<WebService>
<url>
http://www.bigcompany.com/cgi-bin/phf?/etc/group</url>
<cgi>/cgi-bin/phf</cgi>
<method>GET</method>
</WebService>
</Service>
</Target>
</Alert>
</IDMEF-Message>
9.4. System Policy Violation
In this example, logins are restricted to daytime hours. The alert
reports a violation of this policy that occurs when a user logs in a
little after 10:00pm. Example of a policy violation. Note the use
of <AdditionalData> elements to provide information about the policy
being violated.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
Curry Informational - Expires June 2001 [Page 65]
Internet Draft IDMEF Data Model and XML DTD December 2000
<IDMEF-Message version="0.1">
<Alert alertid="1234567890" impact="attempted-user">
<Time offset="-0500">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>22:18:07</time>
</Time>
<Analyzer ident="999888777.1">
<Node category="dns">
<name>dialserver.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="vendor-specific">
<name>out-of-hours activity</name>
<url>http://my.company.com/policies</url>
</Classification>
<Source>
<Node>
<Address category="ipv4-addr">
<address>127.0.0.1</address>
</Address>
</Node>
</Source>
<Target>
<Node category="dns">
<name>mainframe.bigcompany.com</name>
</Node>
<User category="os-device">
<name>louis</name>
<uid>501</uid>
</User>
<Service>
<name>login</name>
<dport>23</dport>
<sport>4235</sport>
</Service>
</Target>
<AdditionalData type="time" meaning="start-time">
07:00:00
</AdditionalData>
<AdditionalData type="time" meaning="stop-time">
19:30:00
</AdditionalData>
</Alert>
</IDMEF-Message>
9.5. Correlated Alerts
Curry Informational - Expires June 2001 [Page 66]
Internet Draft IDMEF Data Model and XML DTD December 2000
The following example shows how the port scan alert (see Section
9.2.2) would be represented if it had been sent by a correlation
engine, instead of an analyzer.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Alert alertid="12345.987654321"
impact="successful-recon-largescale">
<Time offset="-0800">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>15:31</time>
</Time>
<Analyzer ident="12345">
<Node category="dns">
<name>correlator01.bigcompany.com</name>
</Node>
</Analyzer>
<Classification origin="vendor-specific">
<name>portscan</name>
<url>http://www.vendor.com/portscan</url>
</Classification>
<Source>
<Node>
<Address category="ipv4-addr">
<address>222.121.111.112</address>
</Address>
</Node>
</Source>
<Target>
<Node category="dns">
<name>www.bigcompany.com</name>
<Address category="ipv4-addr">
<address>123.234.231.121</address>
</Address>
</Node>
<Service>
<portlist>5-25,37,42,43,53,69-119,123-514</portlist>
</Service>
</Target>
<CorrelationAlert>
<alertid>12345.3563635</alertid>
<alertid>12345.4746734</alertid>
<alertid>12345.4564363</alertid>
<alertid>12345.3635657</alertid>
<alertid>12345.4747463</alertid>
<alertid>12345.4585875</alertid>
<alertid>12345.6769574</alertid>
Curry Informational - Expires June 2001 [Page 67]
Internet Draft IDMEF Data Model and XML DTD December 2000
</CorrelationAlert>
</Alert>
</IDMEF-Message>
9.6. Heartbeat
Use of the <Hearbeat> element to provide "I'm alive and working"
information to the manager. Note the use of <AdditionalData>
elements, with "meaning" attributes, to provide further info.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd">
<IDMEF-Message version="0.1">
<Heartbeat heartbeatid="123456789">
<Time offset="+0000">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>14:07:58</time>
</Time>
<Analyzer ident="abcdefghij">
<Node category="dns">
<name>analyzer01.bigcompany.com</name>
</Node>
</Analyzer>
<AdditionalData type="real" meaning="%memused">
62.5
</AdditionalData>
<AdditionalData type="real" meaning="%diskused">
87.1
</AdditionalData>
</Heartbeat>
</IDMEF-Message>
10. Extending the IDMEF
There are four ways to extend the IDMEF:
1. The <AdditionalData> element (see Section 8.7.1) can be used to
include arbitrary data in an <Alert> or <Heartbeat>. This
approach SHOULD be used whenever possible.
2. The IDMEF DTD will allow additional values to be added to certain
attributes by redefining the "ext.attvals.Listname" parameterized
entity reference (see below). This approach MAY be used, with the
caveat that extensions may not be understood by all analyzers or
managers.
Curry Informational - Expires June 2001 [Page 68]
Internet Draft IDMEF Data Model and XML DTD December 2000
3. The IDMEF DTD will allow additional attributes to be added to any
element by redefining the "ext.attlist.Elementname" parameterized
entity reference (see below). This approach MAY be used, with the
caveat that extensions may not be understood by all analyzers or
managers.
4. XML will allow the DTD to be extended by declaring additional
elements, entities, and attributes in the document type
declaration. This approach SHOULD NOT be used unless the
alternatives above are unworkable.
This section briefly describes how to extend the IDMEF using methods
(2), (3), and (4) above.
10.1. Extending an Existing Attribute
Many attributes in the IDMEF DTD have a pre-defined list of values
that the attributes may take on. The "category" attributes of the
<Address>, <Node>, and <User> elements are examples of this.
The IDMEF DTD provides a standard way to extend the list of allowed
values for these attributes by redefining the already-defined
"ext.attvals.Listname" parameterized entity (where "Listname" is the
name of the attribute value list -- see the DTD for the actual
names). Initially, this entity is defined as the empty string:
<!ENTITY % ext.attvals.Listname "">
To add two new attribute values called "x-value-1" and "x-value-2" to
the "Listname" list of values, this would be redefined as follows:
<!ENTITY % ext.attvals.Listname "
| x-value-1 | x-value-2
">
This redefinition is made at the time the document type is declared,
through the document type declaration (see Section 6.1.4):
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd"
[
<!ENTITY % ext.attvals.Listname "
| x-value-1 | x-value-2
">
]>
All new attribute values defined in this manner MUST have names that
begin with "x-". They SHOULD also include the name of their creator
in the name, e.g., "x-acme-specialvalue."
Curry Informational - Expires June 2001 [Page 69]
Internet Draft IDMEF Data Model and XML DTD December 2000
10.2. Adding an Attribute
Every element in the IDMEF DTD has an attribute list associated with
it. At a minimum, this list contains the "xml:lang" and "xml:space"
attributes. Many elements also have particular attributes associated
with them, as described in Section 8.
The IDMEF DTD provides a standard way to extend the attribute list
for a particular element by redefining the already-defined
"ext.attlist.Elementname" parameterized entity (where "Elementname"
is the name of the element to which the attribute is to be added).
Initially, this entity is defined as the empty string:
<!ENTITY % ext.attlist.Elementname "">
To add a new attribute called "x-attribute" to the "Elementname"
element, this would be redefined as follows:
<!ENTITY % ext.attlist.Elementname "
x-attribute CDATA #IMPLIED
">
This declares the attribute as an optional attribute that may have
any value (other possibilities, such as required attributes, a
default value, or a fixed set of values, are also possible -- see a
text on XML for details).
This redefinition is made at the time the document type is declared,
through the document type declaration (see Section 6.1.4):
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd"
[
<!ENTITY % ext.attlist.Elementname"
x-attribute CDATA #IMPLIED
">
]>
All new attributes defined in this manner MUST have names that begin
with "x-". They SHOULD also include the name of their creator in the
name, e.g., "x-acme-specialattr." Required attributes (those marked
"#REQUIRED") SHOULD be avoided, as it may not be possible to cause an
analyzer to generate that attribute.
Existing IDMEF element attributes MAY NOT be redefined.
10.3. Adding an Element
To add a new element, the new element is defined inside the document
type declaration, as above. However, the definitions of one or more
Curry Informational - Expires June 2001 [Page 70]
Internet Draft IDMEF Data Model and XML DTD December 2000
existing elements must also be modified, to "plug in" the new element
in the right places.
The example below shows how to add a new element. In this case, a
new IDMEF message type, "x-acme-error," is added:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC
"-//IETF//DTD RFCxxxx IDMEF v0.1//EN""idmef-message.dtd"
[
<!ELEMENT IDMEF-Message (
(Alert | Heartbeat | x-acme-error)*
)>
<!ELEMENT x-acme-error (#PCDATA) >
]>
All new elements defined in this manner MUST have names that begin
with "x-". They SHOULD also include the name of their creator in the
name, e.g., "x-acme-specialelem."
Any additions made in this manner MUST NOT change the existing IDMEF
document structure as defined in this specification (i.e., elements
may not be deleted or resequenced).
11. The IDMEF Document Type Definition
<?xml version="1.0" encoding="UTF-8"?>
<!-- ***************************************************************
*******************************************************************
*** Intrusion Detection Message Exchange Format (IDMEF) XML DTD ***
*** Version 0.2, 06 July 2000 ***
*** ***
*** Use of the IDMEF DTD is described in "Intrusion Detection ***
*** Message Exchange Format - XML Document Type Definition," ***
*** David A. Curry, draft-ietf-idwg-idmef-xml-01.txt ***
*** ***
*** The IDMEF data model is described in "Intrusion Detection ***
*** Exchange Format Data Model," Herve Debar, Ming-Yuh Huang, ***
*** and David Donahoo, draft-ietf-idwg-data-model-03.txt. ***
*******************************************************************
*************************************************************** -->
<!-- ===============================================================
===================================================================
=== SECTION 1. Attribute list declarations. The version attributes
=== are used with the IDMEF-Message top-level element;
=== the global attributes are used with all elements;
=== the id attributes are used with most entity elements
===================================================================
Curry Informational - Expires June 2001 [Page 71]
Internet Draft IDMEF Data Model and XML DTD December 2000
=============================================================== -->
<!--
| Attributes that change with the version of the DTD.
-->
<!ENTITY % ext.attlist.version "">
<!ENTITY % attlist.version "
xmlns CDATA #FIXED
'http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-
01.txt'
xmlns:idmef CDATA #FIXED
'http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-
01.txt'
version CDATA #FIXED '0.1'
%ext.attlist.version;
">
<!--
| Standard attributes that should be present on all elements.
-->
<!ENTITY % ext.attlist.global "">
<!ENTITY % attlist.global "
xml:space (default | preserve) 'default'
xml:lang NMTOKEN #IMPLIED
%ext.attlist.global;
">
<!--
| Attribute that should be present on all support class elements
| (Address, Node, Process, Service, User, WebService, SNMPService).
-->
<!ENTITY % ext.attlist.ident "">
<!ENTITY % attlist.ident "
ident CDATA '0'
">
<!-- ===============================================================
===================================================================
=== SECTION 2. Attribute value declarations. Enumerated values of
=== many of the element attributes.
===================================================================
=============================================================== -->
<!--
| Values for the Alert.impact attribute.
-->
<!ENTITY % ext.attvals.impact "">
<!ENTITY % attvals.impact "
( unknown | bad-unknown | not-suspicious | attempted-admin |
successful-admin | attempted-dos | successful-dos |
attempted-recon | successful-recon-largescale |
successful-recon-limited | attempted-user |
Curry Informational - Expires June 2001 [Page 72]
Internet Draft IDMEF Data Model and XML DTD December 2000
successful-user
%ext.attvals.impact; )
">
<!--
| Values for the AdditionalData.type attribute.
-->
<!ENTITY % ext.attvals.adtype "">
<!ENTITY % attvals.adtype "
( unknown | boolean | byte | character | date | integer |
ntpstamp | real | string | time
%ext.attvals.adtype; )
">
<!--
| Values for the Classification.origin attribute.
-->
<!ENTITY % ext.attvals.origin "">
<!ENTITY % attvals.origin "
( unknown | bugtraqid | cve | vendor-specific
%ext.attvals.origin; )
">
<!--
| Values for the Source.spoofed attribute.
-->
<!ENTITY % ext.attvals.spoofed "">
<!ENTITY % attvals.spoofed "
( unknown | no | yes
%ext.attvals.spoofed; )
">
<!--
| Values for the Target.decoy attribute.
-->
<!ENTITY % ext.attvals.decoy "">
<!ENTITY % attvals.decoy "
( unknown | no | yes
%ext.attvals.decoy; )
">
<!--
| Values for the Address.category attribute.
-->
<!ENTITY % ext.attvals.addrcat "">
<!ENTITY % attvals.addrcat "
( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
ipv6-addr | ipv6-net | ipv6-net-mask
%ext.attvals.addrcat; )
">
Curry Informational - Expires June 2001 [Page 73]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!--
| Values for the Node.category attribute.
-->
<!ENTITY % ext.attvals.nodecat "">
<!ENTITY % attvals.nodecat "
( unknown | ads | afs | coda | dfs | dns | kerberos | nds |
nis | nisplus | nt | wfw
%ext.attvals.nodecat; )
">
<!--
| Values for the User.category attribute.
-->
<!ENTITY % ext.attvals.usercat "">
<!ENTITY % attvals.usercat "
( unknown | application | os-device
%ext.attvals.usercat; )
">
<!-- ===============================================================
===================================================================
=== SECTION 3. The top-level elements. This includes IDMEF-Message
=== and the various types of message it can include.
===================================================================
=============================================================== -->
<!ELEMENT IDMEF-Message (
(Alert | Heartbeat)*
)>
<!ENTITY % ext.attlist.IDMEF-Message "">
<!ATTLIST IDMEF-Message
%attlist.version;
%attlist.global;
%ext.attlist.IDMEF-Message;
>
<!ELEMENT Alert (
Time, Analyzer, Classification+, Source*, Target*, ToolAlert?,
OverflowAlert?, CorrelationAlert?, AdditionalData*
)>
<!ENTITY % ext.attlist.Alert "">
<!ATTLIST Alert
version CDATA #FIXED '1'
alertid CDATA #REQUIRED
impact %attvals.impact; 'unknown'
%attlist.global;
%ext.attlist.Alert;
>
<!ELEMENT Heartbeat (
Time, Analyzer, AdditionalData*
)>
Curry Informational - Expires June 2001 [Page 74]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!ENTITY % ext.attlist.Heartbeat "">
<!ATTLIST Heartbeat
heartbeatid CDATA #REQUIRED
%attlist.global;
%ext.attlist.Heartbeat;
>
<!-- ===============================================================
===================================================================
=== SECTION 4. Elements related to Alert that provide more data:
=== AdditionalData, CorrelationAlert, OverflowAlert,
=== and ToolAlert.
===================================================================
=============================================================== -->
<!ELEMENT AdditionalData (#PCDATA) >
<!ENTITY % ext.attlist.AdditionalData "">
<!ATTLIST AdditionalData
type %attvals.adtype; 'unknown'
meaning CDATA #IMPLIED
%attlist.global;
%ext.attlist.AdditionalData;
>
<!ELEMENT CorrelationAlert (
alertid+
)>
<!ENTITY % ext.attlist.CorrelationAlert "">
<!ATTLIST CorrelationAlert
%attlist.global;
%ext.attlist.CorrelationAlert;
>
<!ELEMENT OverflowAlert (
program, size, buffer?
)>
<!ENTITY % ext.attlist.OverflowAlert "">
<!ATTLIST OverflowAlert
%attlist.global;
%ext.attlist.OverflowAlert;
>
<!ELEMENT ToolAlert (
name, command?, alertid*
)>
<!ENTITY % ext.attlist.ToolAlert "">
<!ATTLIST ToolAlert
%attlist.global;
%ext.attlist.ToolAlert;
>
<!-- ===============================================================
Curry Informational - Expires June 2001 [Page 75]
Internet Draft IDMEF Data Model and XML DTD December 2000
===================================================================
=== SECTION 5. Elements related to time. The base time is the time
=== the alert was generated.
===================================================================
=============================================================== -->
<!ELEMENT Time (
ntpstamp, date, time, DetectTime?, AnalyzerTime?
)>
<!ENTITY % ext.attlist.Time "">
<!ATTLIST Time
offset CDATA '+0000'
%attlist.global;
%ext.attlist.Time;
>
<!ELEMENT DetectTime (
ntpstamp, date, time
)>
<!ENTITY % ext.attlist.DetectTime "">
<!ATTLIST DetectTime
offset CDATA '+0000'
%attlist.global;
%ext.attlist.DetectTime;
>
<!ELEMENT AnalyzerTime (
ntpstamp, date, time
)>
<!ENTITY % ext.attlist.AnalyzerTime "">
<!ATTLIST AnalyzerTime
offset CDATA '+0000'
%attlist.global;
%ext.attlist.AnalyzerTime;
>
<!-- ===============================================================
===================================================================
=== SECTION 6. Elements related to identifying entities - analyzers
=== (the senders of these messages), sources (of
=== attacks), and targets (of attacks).
===================================================================
=============================================================== -->
<!ELEMENT Analyzer (
Node?, Process?
)>
<!ENTITY % ext.attlist.Analyzer "">
<!ATTLIST Analyzer
ident CDATA #REQUIRED
%attlist.global;
%ext.attlist.Analyzer;
Curry Informational - Expires June 2001 [Page 76]
Internet Draft IDMEF Data Model and XML DTD December 2000
>
<!ELEMENT Source (
Node?, User?, Process?
)>
<!ENTITY % ext.attlist.Source "">
<!ATTLIST Source
spoofed %attvals.spoofed; 'unknown'
sourceid CDATA '0'
%attlist.global;
%ext.attlist.Source;
>
<!ELEMENT Target (
Node?, User?, Process?, Service?
)>
<!ENTITY % ext.attlist.Target "">
<!ATTLIST Target
decoy %attvals.decoy; 'unknown'
targetid CDATA '0'
%attlist.global;
%ext.attlist.Target;
>
<!-- ===============================================================
===================================================================
=== SECTION 7. Lower-level elements used for providing detailed
=== information about entities - addresses, names, etc.
===================================================================
=============================================================== -->
<!ELEMENT Address (
address, netmask?
)>
<!ENTITY % ext.attlist.Address "">
<!ATTLIST Address
category %attvals.addrcat; 'unknown'
%attlist.ident;
%attlist.global;
%ext.attlist.Address;
>
<!ELEMENT Classification (
name, url
)>
<!ENTITY % ext.attlist.Classification "">
<!ATTLIST Classification
origin %attvals.origin; 'unknown'
%attlist.global;
%ext.attlist.Classification;
>
Curry Informational - Expires June 2001 [Page 77]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!ELEMENT Node (
location?, (name | Address), Address*
)>
<!ENTITY % ext.attlist.Node "">
<!ATTLIST Node
category %attvals.nodecat; 'unknown'
%attlist.ident;
%attlist.global;
%ext.attlist.Node;
>
<!ELEMENT Process (
name, pid?, path?, Arguments?, Environment?
)>
<!ENTITY % ext.attlist.Process "">
<!ATTLIST Process
%attlist.ident;
%attlist.global;
%ext.attlist.Process;
>
<!ELEMENT Service (
name?, dport?, sport?, protocol?, portlist?, SNMPService?,
WebService?
)>
<!ENTITY % ext.attlist.Service "">
<!ATTLIST Service
%attlist.ident;
%attlist.global;
%ext.attlist.Service;
>
<!ELEMENT User (
(name | uid | (name, uid)), group?, gid?, serial?, Address*
)>
<!ENTITY % ext.attlist.User "">
<!ATTLIST User
category %attvals.usercat; 'unknown'
%attlist.ident;
%attlist.global;
%ext.attlist.User;
>
<!ELEMENT SNMPService (
oid?, community?, command?
)>
<!ENTITY % ext.attlist.SNMPService "">
<!ATTLIST SNMPService
%attlist.ident;
%attlist.global;
%ext.attlist.SNMPService;
>
Curry Informational - Expires June 2001 [Page 78]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!ELEMENT WebService (
url, cgi?, method?, Arguments?
)>
<!ENTITY % ext.attlist.WebService "">
<!ATTLIST WebService
%attlist.ident;
%attlist.global;
%ext.attlist.WebService;
>
<!-- ===============================================================
===================================================================
=== SECTION 8. Simple elements with sub-elements or attributes of a
=== special nature.
===================================================================
=============================================================== -->
<!ELEMENT Arguments (
arg+
)>
<!ENTITY % ext.attlist.Arguments "">
<!ATTLIST Arguments
%attlist.global;
%ext.attlist.Arguments;
>
<!ELEMENT Environment (
env+
)>
<!ENTITY % ext.attlist.Environment "">
<!ATTLIST Environment
%attlist.global;
%ext.attlist.Environment;
>
<!-- ===============================================================
===================================================================
=== SECTION 9. Simple elements with no sub-elements and no special
=== attributes.
===================================================================
=============================================================== -->
<!ELEMENT address (#PCDATA) >
<!ENTITY % ext.attlist.address "">
<!ATTLIST address
%attlist.global;
%ext.attlist.address;
>
<!ELEMENT alertid (#PCDATA) >
<!ENTITY % ext.attlist.alertid "">
Curry Informational - Expires June 2001 [Page 79]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!ATTLIST alertid
%attlist.global;
%ext.attlist.alertid;
>
<!ELEMENT arg (#PCDATA) >
<!ENTITY % ext.attlist.arg "">
<!ATTLIST arg
%attlist.global;
%ext.attlist.arg;
>
<!ELEMENT buffer (#PCDATA) >
<!ENTITY % ext.attlist.buffer "">
<!ATTLIST buffer
%attlist.global;
%ext.attlist.buffer;
>
<!ELEMENT cgi (#PCDATA) >
<!ENTITY % ext.attlist.cgi "">
<!ATTLIST cgi
%attlist.global;
%ext.attlist.cgi;
>
<!ELEMENT command (#PCDATA) >
<!ENTITY % ext.attlist.command "">
<!ATTLIST command
%attlist.global;
%ext.attlist.command;
>
<!ELEMENT community (#PCDATA) >
<!ENTITY % ext.attlist.community "">
<!ATTLIST community
%attlist.global;
%ext.attlist.community;
>
<!ELEMENT date (#PCDATA) >
<!ENTITY % ext.attlist.date "">
<!ATTLIST date
%attlist.global;
%ext.attlist.date;
>
<!ELEMENT dport (#PCDATA) >
<!ENTITY % ext.attlist.dport "">
<!ATTLIST dport
%attlist.global;
%ext.attlist.dport;
Curry Informational - Expires June 2001 [Page 80]
Internet Draft IDMEF Data Model and XML DTD December 2000
>
<!ELEMENT env (#PCDATA) >
<!ENTITY % ext.attlist.env "">
<!ATTLIST env
%attlist.global;
%ext.attlist.env;
>
<!ELEMENT gid (#PCDATA) >
<!ENTITY % ext.attlist.gid "">
<!ATTLIST gid
%attlist.global;
%ext.attlist.gid;
>
<!ELEMENT group (#PCDATA) >
<!ENTITY % ext.attlist.group "">
<!ATTLIST group
%attlist.global;
%ext.attlist.group;
>
<!ELEMENT location (#PCDATA) >
<!ENTITY % ext.attlist.location "">
<!ATTLIST location
%attlist.global;
%ext.attlist.location;
>
<!ELEMENT method (#PCDATA) >
<!ENTITY % ext.attlist.method "">
<!ATTLIST method
%attlist.global;
%ext.attlist.method;
>
<!ELEMENT name (#PCDATA) >
<!ENTITY % ext.attlist.name "">
<!ATTLIST name
%attlist.global;
%ext.attlist.name;
>
<!ELEMENT netmask (#PCDATA) >
<!ENTITY % ext.attlist.netmask "">
<!ATTLIST netmask
%attlist.global;
%ext.attlist.netmask;
>
<!ELEMENT ntpstamp (#PCDATA) >
Curry Informational - Expires June 2001 [Page 81]
Internet Draft IDMEF Data Model and XML DTD December 2000
<!ENTITY % ext.attlist.ntpstamp "">
<!ATTLIST ntpstamp
%attlist.global;
%ext.attlist.ntpstamp;
>
<!ELEMENT oid (#PCDATA) >
<!ENTITY % ext.attlist.oid "">
<!ATTLIST oid
%attlist.global;
%ext.attlist.oid;
>
<!ELEMENT path (#PCDATA) >
<!ENTITY % ext.attlist.path "">
<!ATTLIST path
%attlist.global;
%ext.attlist.path;
>
<!ELEMENT pid (#PCDATA) >
<!ENTITY % ext.attlist.pid "">
<!ATTLIST pid
%attlist.global;
%ext.attlist.pid;
>
<!ELEMENT portlist (#PCDATA) >
<!ENTITY % ext.attlist.portlist "">
<!ATTLIST portlist
%attlist.global;
%ext.attlist.portlist;
>
<!ELEMENT program (#PCDATA) >
<!ENTITY % ext.attlist.program "">
<!ATTLIST program
%attlist.global;
%ext.attlist.program;
>
<!ELEMENT protocol (#PCDATA) >
<!ENTITY % ext.attlist.protocol "">
<!ATTLIST protocol
%attlist.global;
%ext.attlist.protocol;
>
<!ELEMENT serial (#PCDATA) >
<!ENTITY % ext.attlist.serial "">
<!ATTLIST serial
%attlist.global;
Curry Informational - Expires June 2001 [Page 82]
Internet Draft IDMEF Data Model and XML DTD December 2000
%ext.attlist.serial;
>
<!ELEMENT size (#PCDATA) >
<!ENTITY % ext.attlist.size "">
<!ATTLIST size
%attlist.global;
%ext.attlist.size;
>
<!ELEMENT sport (#PCDATA) >
<!ENTITY % ext.attlist.sport "">
<!ATTLIST sport
%attlist.global;
%ext.attlist.sport;
>
<!ELEMENT time (#PCDATA) >
<!ENTITY % ext.attlist.time "">
<!ATTLIST time
%attlist.global;
%ext.attlist.time;
>
<!ELEMENT url (#PCDATA) >
<!ENTITY % ext.attlist.url "">
<!ATTLIST url
%attlist.global;
%ext.attlist.url;
>
<!ELEMENT uid (#PCDATA) >
<!ENTITY % ext.attlist.uid "">
<!ATTLIST uid
%attlist.global;
%ext.attlist.uid;
>
<!-- ***************************************************************
*******************************************************************
*** END OF DTD ***
*******************************************************************
*************************************************************** -->
12. Security Considerations
This Internet-Draft describes a data format for the exchange of
security-related data between security product implementations. There
are no security considerations directly applicable to the format of
this data. There may, however, be security considerations associated
Curry Informational - Expires June 2001 [Page 83]
Internet Draft IDMEF Data Model and XML DTD December 2000
with the transport protocol chosen to move this data between
communicating entities.
13. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Wood, M., "Intrusion Detection Message Exchange Requirements,"
draft-ietf-idwg-requirements-02.txt, October 26, 1999, work in
progress.
3 World Wide Web Consortium (W3C), "Extensible Markup Language
(XML)," W3C Recommendation, February 1998,
http://www.w3.org/TR/1998/REC-xml-19980210
4 Mansfield, G. and D. A. Curry, "Intrusion Detection Message
Exchange Format: Comparison of SMI and XML Implementations,"
draft-ietf-idwg-xmlsmi-00.txt, July 6, 2000, work in progress.
5 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
6 Rumbaugh, J., I. Jacobson and G. Booch, "Unified Modeling Language
Reference Manual," Addison-Wesley, 1997.
7 The Bugtraq reference number for the securityfocus vulnerability
database, http://www.securityfocus.com/
8 Christey, S., D. W. Baker, W. H. Hill, and D. E. Mann, "The
Development of a Common Vulnerabilities and Exposures List,"
Second International Workshop on Recent Advances in Intrusion
Detection, West Lafayette, Indiana, September 1999,
http://www.cve.mitre.org/.
9 World Wide Web Consortium (W3C), "Namespaces in XML," W3C
Recommendation, January 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114.
10 Freed, N., "IANA Charset Registration Procedures," BCP 19, RFC
2278, January 1998.
11 Alvestrand, H., "Tags for the Identification of Languages," RFC
1766, March 1995.
12 Eastlake, D., J. Reagle, and D. Solo, "XML-Signature Syntax and
Processing," draft-ietf-xmldsig-core-07.txt, June 1, 2000, work in
progress.
Curry Informational - Expires June 2001 [Page 84]
Internet Draft IDMEF Data Model and XML DTD December 2000
13 Mills, D. L., "Network Time Protocol (Version 3) Specification,
Implementation, and Analysis," RFC 1305, March 1992.
14. 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
Marc Dacier, IBM Corporation
David J. Donahoo, AFIWC
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
15. Author's Addresses
David A. Curry
Internet Security Systems, Inc.
345 Route 17 South
Upper Saddle River, NJ 07458
Phone: +1 201 934-4207
Email: davy@iss.net
Herve Debar
France Telecom R & D
42 rue des coutures
Phone: +33.2.31.75.92.61
Email: herve.debar@france.telecom.fr
Full Copyright Statement
"Copyright (C) The Internet Society (2000). 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
Curry Informational - Expires June 2001 [Page 85]
Internet Draft IDMEF Data Model and XML DTD December 2000
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references 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, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Debar Informational - Expires June 2001 [Page 86]
Prepared by Robin Cover for The XML Cover Pages archive. See: "Intrusion Detection Message Exchange Format."
