Intrusion Detection Working Group D. Curry
draft-ietf-idwg-idmef-xml-01.txt ISS
Expires: January 5, 2001 July 6, 2000
Intrusion Detection Message Exchange Format
Extensible Markup Language (XML) Document Type Definition
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [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.
Distribution of this memo is unlimited.
1. 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 which may need to interact with them.
The goals and requirements of the IDMEF are described in [2].
This Internet-Draft describes a proposed implementation of the data
format component of the IDMEF, using the Extensible Markup Language
(XML) [3] to represent the class hierarchy defined by Debar, Huang
and Donahoo [4]. 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 [10].
Internet-Draft IDMEF XML DTD July 6, 2000
TABLE OF CONTENTS
1. Abstract ........................................................ 1
2. Conventions used in this document ............................... 5
3. Introduction .................................................... 5
3.1 The Extensible Markup Language ............................. 6
3.2 Rationale for Implementing IDMEF in XML .................... 6
3.3 The Debar/Huang/Donahoo IDMEF Class Hierarchy .............. 7
4. Use of XML in the IDMEF ......................................... 8
4.1 The IDMEF Document Prolog .................................. 8
4.1.1 XML Declaration ...................................... 8
4.1.2 XML Document Type Definition (DTD) ................... 9
4.1.3 IDMEF DTD Formal Public Identifier ................... 10
4.1.4 IDMEF DTD Document Type Declaration .................. 10
4.2 Character Data Processing in XML and IDMEF ................. 11
4.2.1 Character Entity References .......................... 11
4.2.2 Character Code References ............................ 12
4.2.3 White Space Processing ............................... 12
4.3 Languages in XML and IDMEF ................................. 12
4.4 Unrecognized Tags in IDMEF Messages ........................ 13
4.5 Digital Signatures ......................................... 13
5. IDMEF Data Types ................................................ 14
6. Structure of an IDMEF Message ................................... 15
6.1 The IDMEF-Message Root Element ............................. 16
6.2 The Message Type Elements .................................. 16
6.2.1 Alert ................................................ 16
6.2.1.1 CorrelationAlert ............................... 18
6.2.1.2 OverflowAlert .................................. 18
6.2.1.3 ToolAlert ...................................... 19
6.2.2 Heartbeat ............................................ 19
6.3 Time Elements .............................................. 20
6.3.1 Time ................................................. 20
6.3.2 DetectTime ........................................... 21
6.3.3 AnalyzerTime ......................................... 21
6.4 High-Level Entity Identification Elements .................. 21
6.4.1 Analyzer ............................................. 21
6.4.2 Source ............................................... 22
6.4.3 Target ............................................... 22
6.5 Low-Level Entity Identification Elements ................... 23
6.5.1 Address .............................................. 23
6.5.2 Classification ....................................... 24
6.5.3 Node ................................................. 25
6.5.4 Process .............................................. 26
6.5.5 Service .............................................. 27
6.5.5.1 SNMPService .................................... 27
Curry Expires: January 5, 2001 [Page 2]
Internet-Draft IDMEF XML DTD July 6, 2000
6.5.5.2 WebService ..................................... 28
6.5.6 User ................................................. 28
6.6 Simple Elements ............................................ 29
6.6.1 address .............................................. 29
6.6.2 alertid .............................................. 29
6.6.3 Arguments ............................................ 30
6.6.3.1 arg ............................................ 30
6.6.4 buffer ............................................... 30
6.6.5 cgi .................................................. 30
6.6.6 command .............................................. 30
6.6.7 community ............................................ 30
6.6.8 date ................................................. 30
6.6.9 dport ................................................ 31
6.6.10 Environment ......................................... 31
6.6.10.1 env ........................................... 31
6.6.11 gid ................................................. 31
6.6.12 group ............................................... 31
6.6.13 location ............................................ 31
6.6.14 method .............................................. 31
6.6.15 name ................................................ 32
6.6.16 netmask ............................................. 32
6.6.17 ntpstamp ............................................ 32
6.6.18 oid ................................................. 32
6.6.19 path ................................................ 32
6.6.20 pid ................................................. 32
6.6.21 portlist ............................................ 32
6.6.22 program ............................................. 32
6.6.23 protocol ............................................ 33
6.6.24 serial .............................................. 33
6.6.25 size ................................................ 33
6.6.26 sport ............................................... 33
6.6.27 time ................................................ 33
6.6.28 url ................................................. 33
6.6.29 uid ................................................. 33
6.7 Providing Additional Information ........................... 33
6.7.1 AdditionalData ....................................... 34
7. Examples ........................................................ 34
7.1 Denial of Service Attacks .................................. 35
7.1.1 The "teardrop" Attack ................................ 35
7.1.2 The "ping of death" Attack ........................... 36
7.2 Port Scanning Attacks ...................................... 37
7.2.1 Connection to a Disallowed Service ................... 37
7.2.2 Simple Port Scanning ................................. 38
7.3 Local Attacks .............................................. 39
7.3.1 The "loadmodule" Attack .............................. 39
7.3.2 The "phf" Attack ..................................... 41
7.4 System Policy Violation .................................... 42
7.5 Correlated Alerts .......................................... 44
7.6 Heartbeat .................................................. 45
8. Extending the IDMEF ............................................. 45
Curry Expires: January 5, 2001 [Page 3]
Internet-Draft IDMEF XML DTD July 6, 2000
8.1 Extending an Existing Attribute ............................ 46
8.2 Adding an Attribute ........................................ 47
8.3 Adding an Element .......................................... 48
9. The IDMEF Document Type Definition .............................. 48
10. Security Considerations ........................................ 60
11. References ..................................................... 61
12. Acknowledgments ................................................ 62
13. Author's Address ............................................... 62
Curry Expires: January 5, 2001 [Page 4]
Internet-Draft IDMEF XML DTD July 6, 2000
2. Conventions used in this document
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
An "IDMEF application" is a program or program component that reads
and/or writes messages in the format specified by this memo.
An "IDMEF document" is a message that adheres to the requirements
specified by this memo, and that is exchanged by two or more IDMEF
applications. An "IDMEF message" is another term for an "IDMEF
document."
3. 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.
The diversity of uses for the IDMEF needs to be considered when
Curry Expires: January 5, 2001 [Page 5]
Internet-Draft IDMEF XML DTD July 6, 2000
selecting its method of implementation.
3.1 The Extensible Markup Language
The Extensible Markup Language (XML) [4] 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 [6] 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.
3.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
Curry Expires: January 5, 2001 [Page 6]
Internet-Draft IDMEF XML DTD July 6, 2000
others.
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.
3.3 The Debar/Huang/Donahoo IDMEF Class Hierarchy
Debar, Huang and Donahoo [4] have proposed that intrusion detection
alerts in the IDMEF be represented by a class hierarchy. This
representation has several advantages:
+ it is flexible, and capable of describing alerts to arbitrary
levels of complexity;
+ it is compact, and allows applications to specify only the data
Curry Expires: January 5, 2001 [Page 7]
Internet-Draft IDMEF XML DTD July 6, 2000
they know; and
+ it is easy to extend, and will allow vendors to provide additional
information about particular alerts.
This implementation follows the Debar/Huang/Donahoo model 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
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
Debar/Huang/Donahoo model, or XML as an implementation language.
4. Use of XML in the IDMEF
This section describes how some of XML's features and requirements
will impact the IDMEF.
4.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.
4.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" ?>
Curry Expires: January 5, 2001 [Page 8]
Internet-Draft IDMEF XML DTD July 6, 2000
where "charset" is the name of the character encoding in use (see
section 4.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.
4.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 9.
It is expected that IDMEF applications will not normally include the
IDMEF DTD itself in their communications. Instead, the DTD will be
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 4.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
Curry Expires: January 5, 2001 [Page 9]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
4.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.
4.1.4 IDMEF DTD Document Type Declaration
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 idef-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 idef-message SYSTEM "/some/path/to/the/idef-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).
Implementors 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.
Curry Expires: January 5, 2001 [Page 10]
Internet-Draft IDMEF XML DTD July 6, 2000
4.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 4.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 [7].
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.
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).
4.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
Curry Expires: January 5, 2001 [Page 11]
Internet-Draft IDMEF XML DTD July 6, 2000
possibility of misinterpretation.
4.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.
4.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
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.
4.3 Languages in XML and IDMEF
XML allows tags to identify the language their content is written in
by using the "xml:lang" attribute:
Curry Expires: January 5, 2001 [Page 12]
Internet-Draft IDMEF XML DTD July 6, 2000
<tagname xml:lang="langcode">
where "langcode" is a language tag as described in RFC 1766 [8].
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 <idef-message> tag.
If no language is specified for an IDMEF message, English SHALL be
assumed.
All IDMEF tags support the "xml:lang" attribute.
4.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:
+ 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 4.1.2. It is up to the
individual application to decide how to process any content from the
unknown tag(s).
4.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.
Curry Expires: January 5, 2001 [Page 13]
Internet-Draft IDMEF XML DTD July 6, 2000
Specifications for the use of digital signatures within IDMEF
messages is outside the scope of this document. However, use of the
XML Signature standard is RECOMMENDED if such functionality is
needed.
5. 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 interoperabity 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.
3. 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".
4. 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".
Curry Expires: January 5, 2001 [Page 14]
Internet-Draft IDMEF XML DTD July 6, 2000
5. NTP timestamps, as used in the <ntpstamp> element, are described
in detail in [11]. 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".
6. Port lists, as used in the <portlist> element, are encoded as a
comma-separated list of numbers (individual integers) and ranges
(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.
7. 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.
6. 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.
Curry Expires: January 5, 2001 [Page 15]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
6.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.
6.2 The Message Type Elements
There are two types of IDMEF message: <Alert>, and <Heartbeat>.
These elements are sub-elements of the <IDMEF-Message> element.
6.2.1 Alert
The <Alert> element 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
Curry Expires: January 5, 2001 [Page 16]
Internet-Draft IDMEF XML DTD July 6, 2000
provide this information reliably.
impact
Required. The evaluated impact of the event on the system.
Permitted values:
+-----------------------------+---------------------------------
| unknown | Event's impact not known to
| | analyzer (default value)
+-----------------------------+---------------------------------
| bad-unknown | Event is unpleasant in an
| | unknown way
+-----------------------------+---------------------------------
| not-suspicious | Event is not suspicious in any
| | way
+-----------------------------+---------------------------------
| attempted-admin | Attempt to obtain administrator
| | access
+-----------------------------+---------------------------------
| successful-admin | Successful compromise of admin
| | access
+-----------------------------+---------------------------------
| attempted-dos | Attempted denial-of-service
+-----------------------------+---------------------------------
| successful-dos | Successful denial-of-service
+-----------------------------+---------------------------------
| attempted-recon | Attempted reconnaissance probe
+-----------------------------+---------------------------------
| successful-recon-limited | Successful reconnaissance probe
| | of limited scope (e.g., one
| | machine)
+-----------------------------+---------------------------------
| successful-recon-largescale | Successful reconnaissance probe
| | of large scale
+-----------------------------+---------------------------------
| attempted-user | Attempt to obtain user-level
| | access
+-----------------------------+---------------------------------
| successful-user | Successful compromise of user
| | access
+-----------------------------+---------------------------------
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.
Curry Expires: January 5, 2001 [Page 17]
Internet-Draft IDMEF XML DTD July 6, 2000
<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.
<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.
6.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.
6.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.
Curry Expires: January 5, 2001 [Page 18]
Internet-Draft IDMEF XML DTD July 6, 2000
6.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>
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.
6.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
7.4 and 7.7 for suggested usage.
Curry Expires: January 5, 2001 [Page 19]
Internet-Draft IDMEF XML DTD July 6, 2000
6.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.
6.3.1 Time
The <Time> element provides the time the alert or heartbeat was sent
by the analyzer.
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 5 for formatting
details.
<date>
Exactly one. The date. See Section 5 for formatting details.
<time>
Exactly one. The time. See Section 5 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.
Curry Expires: January 5, 2001 [Page 20]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
6.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
6.3.1, above.
6.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
6.3.1, above.
6.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.
6.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.
Curry Expires: January 5, 2001 [Page 21]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
6.4.2 Source
The <Source> element 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 5 for formatting details.
spoofed
Required. An indication of whether the analyzer believes this
to be the true source of the event. Possible values:
+-----------------------+---------------------------------------
| unknown | No information. Default value.
+-----------------------+---------------------------------------
| yes | This is not the true source.
+-----------------------+---------------------------------------
| no | This is the true source.
+-----------------------+---------------------------------------
The <Source> 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.
6.4.3 Target
The <Target> element 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).
The <Target> element has the following attributes:
Curry Expires: January 5, 2001 [Page 22]
Internet-Draft IDMEF XML DTD July 6, 2000
targetid
Optional. See Section 5 for formatting details.
decoy
Required. An indication of whether the analyzer believes this
to be the true target of the event. Possible values:
+-----------------------+---------------------------------------
| unknown | No information. Default value.
+-----------------------+---------------------------------------
| yes | This is not the true target.
+-----------------------+---------------------------------------
| no | This is the true target.
+-----------------------+---------------------------------------
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.
6.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.
6.5.1 Address
The <Address> element provides addressing information for hosts,
networks, and users.
The <Address> element has the following attributes:
ident
Optional. See Section 5 for formatting details.
category
Required. The type of address provided. Possible values:
+-----------------------+---------------------------------------
| unknown | Type not known. Default value.
Curry Expires: January 5, 2001 [Page 23]
Internet-Draft IDMEF XML DTD July 6, 2000
+-----------------------+---------------------------------------
| atm | Asynchronous Transfer Mode network
| | address
+-----------------------+---------------------------------------
| e-mail | Internet electronic mail address
| | (RFC822)
+-----------------------+---------------------------------------
| lotus-notes | Lotus Notes address
+-----------------------+---------------------------------------
| mac | Media Access Control (MAC) address
+-----------------------+---------------------------------------
| sna | IBM Shared Network Architecture (SNA)
| | address
+-----------------------+---------------------------------------
| vm | IBM "VM" (PROFS) electronic mail
| | address
+-----------------------+---------------------------------------
| ipv4-addr | IPv4 host address in dotted-decimal
| | notation (aaa.bbb.ccc.ddd)
+-----------------------+---------------------------------------
| ipv4-addr-hex | IPv4 host address in hexadecimal
+-----------------------+---------------------------------------
| ipv4-net | IPv4 network address in dotted-decimal
| | notation, slash, significant bits
| | (aaa.bbb.ccc.ddd/nn)
+-----------------------+---------------------------------------
| ipv4-net-mask | IPv4 network address and associated
| | network mask.
+-----------------------+---------------------------------------
| ipv6-addr | IPv6 host address
+-----------------------+---------------------------------------
| ipv6-net | IPv6 network address
+-----------------------+---------------------------------------
| ipv6-net-mask | IPv6 network address and associated
| | network mask.
+-----------------------+---------------------------------------
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).
6.5.2 Classification
The <Classification> element provides the name of the event
(vulnerability) that caused this alert to be generated. Names may
come from several sources.
Curry Expires: January 5, 2001 [Page 24]
Internet-Draft IDMEF XML DTD July 6, 2000
The <Classification> element has the following attribute:
origin
Optional. The origin of the name. Possible values:
+-----------------------+---------------------------------------
| unknown | No origin known. Default value.
+-----------------------+---------------------------------------
| bugtraqid | The Bugtraq ID naming scheme
| | (www.securityfocus.com)
+-----------------------+---------------------------------------
| cve | The Common Vulnerability Enumeration
| | naming scheme [9]
+-----------------------+---------------------------------------
| vendor-specific | A vendor-specific name.
+-----------------------+---------------------------------------
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.
6.5.3 Node
The <Node> element provides identification of hosts and network
equipment.
The <Node> element has the following attributes:
ident
Optional. See Section 5 for formatting details.
category
Optional. The domain to which the provided information
belongs, if relevant. Possible values:
+-----------------------+---------------------------------------
| unknown | No relevant domain. Default value.
+-----------------------+---------------------------------------
| ads | Windows 2000 ADS
+-----------------------+---------------------------------------
| afs | Andrew File System
+-----------------------+---------------------------------------
| coda | CODA distributed file system
+-----------------------+---------------------------------------
| dfs | DFS distributed file system
Curry Expires: January 5, 2001 [Page 25]
Internet-Draft IDMEF XML DTD July 6, 2000
+-----------------------+---------------------------------------
| dns | Domain Name System
+-----------------------+---------------------------------------
| kerberos | Kerberos realm
+-----------------------+---------------------------------------
| nds | Novell Netware
+-----------------------+---------------------------------------
| nis | Network Information Service (Yellow
| | Pages)
+-----------------------+---------------------------------------
| nisplus | Network Information Services Plus
+-----------------------+---------------------------------------
| nt | Windows NT domain
+-----------------------+---------------------------------------
| wfw | Windows for Workgroups
+-----------------------+---------------------------------------
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).
6.5.4 Process
The <Process> element provides information about a process being run
on a node.
The <Process> element has the following attribute:
ident
Optional. See Section 5 for formatting details.
The <Process> element has the following sub-elements:
<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>
Curry Expires: January 5, 2001 [Page 26]
Internet-Draft IDMEF XML DTD July 6, 2000
Zero or one. The arguments to the process.
<Environment>
Zero or one. The environment variables associated with the
process.
6.5.5 Service
The <Service> element 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 5 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 5 for formatting details.
<SNMPService>
Zero or one. Additional information about SNMP services.
<WebService>
Zero or one. Additional information about web-based services.
6.5.5.1 SNMPService
The <SNMPService> element provides additional information about SNMP
services.
The <SNMPService> element has the following attribute:
Curry Expires: January 5, 2001 [Page 27]
Internet-Draft IDMEF XML DTD July 6, 2000
ident
Optional. See Section 5 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.
6.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 5 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.
6.5.6 User
The <User> element identifies users of nodes.
The <User> element has the following attributes:
ident
Optional. See Section 5 for formatting details.
category
Required. The type of user information provided. Possible
Curry Expires: January 5, 2001 [Page 28]
Internet-Draft IDMEF XML DTD July 6, 2000
values:
+-----------------------+---------------------------------------
| unknown | No information provided. Default
| | value.
+-----------------------+---------------------------------------
| application | An application user.
+-----------------------+---------------------------------------
| os-device | A operating system or device user.
+-----------------------+---------------------------------------
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).
6.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.
6.6.1 address
The <address> element contains a network address. It is a
sub-element of the <Address> element.
6.6.2 alertid
Curry Expires: January 5, 2001 [Page 29]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
6.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.
6.6.3.1 arg
The <arg> element contains a single process argument string. It is a
sub-element of the <Arguments> element.
6.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.
6.6.5 cgi
The <cgi> element contains the name of a CGI script. It is a
sub-element of the <WebService> element.
6.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.
6.6.7 community
The <community> element contains an SNMP community name. It is a
sub-element of the <SNMPService> element.
6.6.8 date
The <date> element contains a date string. See Section 5 for
Curry Expires: January 5, 2001 [Page 30]
Internet-Draft IDMEF XML DTD July 6, 2000
formatting details. The <date> element is a sub-element of the
<AnalyzerTime>, <DetectTime>, and <Time> elements.
6.6.9 dport
The <dport> element contains a destination port number. It is a
sub-element of the <Service> element.
6.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.
6.6.10.1 env
The <env> element contains a single process environment string. It
is a sub-element of the <Environment> element.
6.6.11 gid
The <gid> element contains a group identifier. It is a sub-element
of the <User> element.
6.6.12 group
The <group> element contains a group name. It is a sub-element of
the <User> element.
6.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.
6.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.
Curry Expires: January 5, 2001 [Page 31]
Internet-Draft IDMEF XML DTD July 6, 2000
6.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.
6.6.16 netmask
The <netmask> element contains a network mask. It is a sub-element
of the <Address> element.
6.6.17 ntpstamp
An NTP timestamp. See Section 5 for formatting details. It is a
sub-element of the <Time>, <AnalyzerTime>, and <DetectTime> elements.
6.6.18 oid
The <oid> element contains an SNMP object identifier. It is a
sub-element of the <SNMPService> element.
6.6.19 path
The <path> element contains the path name of a program. It is a
sub-element of the <Process> element.
6.6.20 pid
The <pid> element contains a process identifier. It is a sub-element
of the <Process> element.
6.6.21 portlist
The <portlist> element contains a list of port numbers. See Section
5 for formatting details. The <portlist> element is a sub-element of
the <Service> element.
6.6.22 program
The <program> element contains the name of a program. It is a
sub-element of the <OverflowAlert> element.
Curry Expires: January 5, 2001 [Page 32]
Internet-Draft IDMEF XML DTD July 6, 2000
6.6.23 protocol
The <protocol> element contains the name of a protocol. It is a
sub-element of the <Service> element.
6.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.
6.6.25 size
The <size> element contains a buffer (data) size, in bytes. It is a
sub-element of the <OverflowAlert> element.
6.6.26 sport
The <sport> element contains a source port number. It is a
sub-element of the <Service> element.
6.6.27 time
The <time> element contains a time string. See Section 5 for
formatting details. The <time> element is a sub-element of the
<AnalyzerTime>, <DetectTime>, and <Time> elements.
6.6.28 url
The <url> element contains a Universal Resource Locator. It is a
sub-element of the <Classification> and <WebService> elements.
6.6.29 uid
The <uid> element contains a user identifier. It is a sub-element of
the <User> element.
6.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.
Curry Expires: January 5, 2001 [Page 33]
Internet-Draft IDMEF XML DTD July 6, 2000
6.7.1 AdditionalData
The <AdditionalData> 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:
+-----------------------+---------------------------------------
| unknown | No type given. Default value.
+-----------------------+---------------------------------------
| boolean | True/false or yes/no
+-----------------------+---------------------------------------
| byte | A single byte
+-----------------------+---------------------------------------
| character | A single character
+-----------------------+---------------------------------------
| date | A date string formatted as per
| | Section 5
+-----------------------+---------------------------------------
| integer | An integer
+-----------------------+---------------------------------------
| ntpstamp | An NTP timestamp as per Section 5
+-----------------------+---------------------------------------
| real | A floating-point number
+-----------------------+---------------------------------------
| string | A string of characters
+-----------------------+---------------------------------------
| time | A time string formatted as per
| | Section 5
+-----------------------+---------------------------------------
The <AdditionalData> element has no sub-elements. It is a
sub-element of the <Alert> and <Heartbeat> elements.
7. 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
Curry Expires: January 5, 2001 [Page 34]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
7.1 Denial of Service Attacks
The following examples show how some common denial of service attacks
could be represented in the IDMEF.
7.1.1 The "teardrop" Attack
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>
Curry Expires: January 5, 2001 [Page 35]
Internet-Draft IDMEF XML DTD July 6, 2000
</Node>
</Target>
</Alert>
</IDMEF-Message>
7.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"?>
<!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>
Curry Expires: January 5, 2001 [Page 36]
Internet-Draft IDMEF XML DTD July 6, 2000
<Target>
<Node>
<location>Cabinet B10</location>
<name>Cisco.router.b10</name>
</Node>
</Target>
</Alert>
</IDMEF-Message>
7.2 Port Scanning Attacks
The following examples show how some common port scanning attacks
could be represented in the IDMEF.
7.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>
Curry Expires: January 5, 2001 [Page 37]
Internet-Draft IDMEF XML DTD July 6, 2000
<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>
</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>
7.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">
Curry Expires: January 5, 2001 [Page 38]
Internet-Draft IDMEF XML DTD July 6, 2000
<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>
</Alert>
</IDMEF-Message>
7.3 Local Attacks
The following examples show how some common local host attacks could
be represented in the IDMEF.
7.3.1 The "loadmodule" Attack
Host-based detection of the "loadmodule" exploit. This attack
involves tricking the "loadmodule" program to run another program;
since "loadmodlue" 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>
Curry Expires: January 5, 2001 [Page 39]
Internet-Draft IDMEF XML DTD July 6, 2000
<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>
</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">
Curry Expires: January 5, 2001 [Page 40]
Internet-Draft IDMEF XML DTD July 6, 2000
<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>
</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>
7.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"?>
Curry Expires: January 5, 2001 [Page 41]
Internet-Draft IDMEF XML DTD July 6, 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-recon">
<Time offset="-0100">
<ntpstamp>0x12345.0x67890</ntpstamp>
<date>2000/03/09</date>
<time>08:12:32</time>
</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>
7.4 System Policy Violation
Curry Expires: January 5, 2001 [Page 42]
Internet-Draft IDMEF XML DTD July 6, 2000
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">
<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">
Curry Expires: January 5, 2001 [Page 43]
Internet-Draft IDMEF XML DTD July 6, 2000
19:30:00
</AdditionalData>
</Alert>
</IDMEF-Message>
7.5 Correlated Alerts
The following example shows how the port scan alert (see Section
7.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>
Curry Expires: January 5, 2001 [Page 44]
Internet-Draft IDMEF XML DTD July 6, 2000
<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>
</CorrelationAlert>
</Alert>
</IDMEF-Message>
7.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>
8. Extending the IDMEF
There are four ways to extend the IDMEF:
1. The <AdditionalData> element (see Section 6.7.1) can be used to
include arbitrary data in an <Alert> or <Heartbeat>. This
Curry Expires: January 5, 2001 [Page 45]
Internet-Draft IDMEF XML DTD July 6, 2000
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.
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.
8.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 4.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
Curry Expires: January 5, 2001 [Page 46]
Internet-Draft IDMEF XML DTD July 6, 2000
">
]>
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."
8.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 6.
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 4.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.
Curry Expires: January 5, 2001 [Page 47]
Internet-Draft IDMEF XML DTD July 6, 2000
Existing IDMEF element attributes MAY NOT be redefined.
8.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
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 idef-message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.1//EN"
"idef-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).
9. 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. ***
*******************************************************************
*************************************************************** -->
Curry Expires: January 5, 2001 [Page 48]
Internet-Draft IDMEF XML DTD July 6, 2000
<!-- ===============================================================
===================================================================
=== 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
===================================================================
=============================================================== -->
<!--
| 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 "">
Curry Expires: January 5, 2001 [Page 49]
Internet-Draft IDMEF XML DTD July 6, 2000
<!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 |
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 |
Curry Expires: January 5, 2001 [Page 50]
Internet-Draft IDMEF XML DTD July 6, 2000
ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
ipv6-addr | ipv6-net | ipv6-net-mask
%ext.attvals.addrcat; )
">
<!--
| 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;
Curry Expires: January 5, 2001 [Page 51]
Internet-Draft IDMEF XML DTD July 6, 2000
>
<!ELEMENT Heartbeat (
Time, Analyzer, AdditionalData*
)>
<!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
Curry Expires: January 5, 2001 [Page 52]
Internet-Draft IDMEF XML DTD July 6, 2000
%attlist.global;
%ext.attlist.ToolAlert;
>
<!-- ===============================================================
===================================================================
=== 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?
)>
Curry Expires: January 5, 2001 [Page 53]
Internet-Draft IDMEF XML DTD July 6, 2000
<!ENTITY % ext.attlist.Analyzer "">
<!ATTLIST Analyzer
ident CDATA #REQUIRED
%attlist.global;
%ext.attlist.Analyzer;
>
<!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
Curry Expires: January 5, 2001 [Page 54]
Internet-Draft IDMEF XML DTD July 6, 2000
origin %attvals.origin; 'unknown'
%attlist.global;
%ext.attlist.Classification;
>
<!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 "">
Curry Expires: January 5, 2001 [Page 55]
Internet-Draft IDMEF XML DTD July 6, 2000
<!ATTLIST SNMPService
%attlist.ident;
%attlist.global;
%ext.attlist.SNMPService;
>
<!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;
Curry Expires: January 5, 2001 [Page 56]
Internet-Draft IDMEF XML DTD July 6, 2000
%ext.attlist.address;
>
<!ELEMENT alertid (#PCDATA) >
<!ENTITY % ext.attlist.alertid "">
<!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;
>
Curry Expires: January 5, 2001 [Page 57]
Internet-Draft IDMEF XML DTD July 6, 2000
<!ELEMENT dport (#PCDATA) >
<!ENTITY % ext.attlist.dport "">
<!ATTLIST dport
%attlist.global;
%ext.attlist.dport;
>
<!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
Curry Expires: January 5, 2001 [Page 58]
Internet-Draft IDMEF XML DTD July 6, 2000
%attlist.global;
%ext.attlist.netmask;
>
<!ELEMENT ntpstamp (#PCDATA) >
<!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;
>
Curry Expires: January 5, 2001 [Page 59]
Internet-Draft IDMEF XML DTD July 6, 2000
<!ELEMENT serial (#PCDATA) >
<!ENTITY % ext.attlist.serial "">
<!ATTLIST serial
%attlist.global;
%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 ***
*******************************************************************
*************************************************************** -->
10. Security Considerations
Curry Expires: January 5, 2001 [Page 60]
Internet-Draft IDMEF XML DTD July 6, 2000
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 with the transport protocol chosen to move this data
between communicating entities.
11. 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] Debar, H., M. Huang, and D. Donahoo, "Intrusion Detection
Exchange Format Data Model," draft-ietf-idwg-data-model-03.txt,
June 15, 2000, work in progress.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14, RFC 2119, March 1997.
[6] World Wide Web Consortium (W3C), "Namespaces in XML," W3C
Recommendation, January, 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114.
[7] Freed, N., "IANA Charset Registration Procedures," BCP 19, RFC
2278, January, 1998.
[8] Alvestrand, H., "Tags for the Identification of Languages," RFC
1766, March, 1995.
[9] Christey, S., David W. Baker, William H. Hill, and David 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/.
[10] Mansfield, Glenn and David 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.
[11] Mills, David L., "Network Time Protocol (Version 3)
Specification, Implementation, and Analysis," RFC 1305, March,
1992.
Curry Expires: January 5, 2001 [Page 61]
Internet-Draft IDMEF XML DTD July 6, 2000
[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.
12. Acknowledgments
The following individuals deserve the credit for the data model
described here; this document simply proposes an XML-based
implementation of their work.
Herve Debar, IBM Corporation
Ming-Yuh Huang, The Boeing Company
David J. Donahoo, AFIWC
Dominique Alessandri, IBM Corporation
James L. Burden, California Independent System Operator
Marc Dacier, IBM Corporation
Glenn Mansfield, Cyber Solutions, Inc.
James Riordan, IBM Corporation
Stephane Schitter, IBM Corporation
Michael J. Slifcak, Internet Security Systems, Inc.
Michael Steiner, University of Saarland
Steven R. Snapp, CyberSafe Corporation
Stuart Staniford-Chen, Silicon Defense
Maureen Stillman, Nokia IP Telephony
Vimal Vaidya, AXENT
Andreas Wespi, IBM Corporation
Eric D. Williams, Information Brokers, Inc.
S. Felix Wu, North Carolina State University
13. Author's Address
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
Full Copyright Statement
"Copyright (C) 2000 The Internet Society. All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and 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
Curry Expires: January 5, 2001 [Page 62]
Internet-Draft IDMEF XML DTD July 6, 2000
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 DISCLAIM 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
MERCHANTIBILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Curry Expires: January 5, 2001 [Page 63]