Intrusion Detection Working Group D. Curry
draft-ietf-idwg-idmef-xml-00.txt ISS
Expires: September 14, 2000 March 15, 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.
This Internet-Draft expires September 14, 2000.
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.
Internet-Draft IDMEF XML DTD March 15, 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 ................. 10
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
5. IDMEF Data Types ................................................ 13
6. Structure of an IDMEF Message ................................... 14
6.1 The IDMEF-Message Root Element ............................. 15
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 ...................................... 18
6.2.2 Heartbeat ............................................ 19
6.2.3 Query ................................................ 19
6.2.4 Response ............................................. 20
6.3 Time Elements .............................................. 21
6.3.1 Time ................................................. 21
6.3.2 DetectTime ........................................... 21
6.3.3 AnalyzerTime ......................................... 22
6.4 High-Level Entity Identification Elements .................. 22
6.4.1 Analyzer ............................................. 22
6.4.2 Source ............................................... 22
6.4.3 Target ............................................... 23
6.5 Low-Level Entity Identification Elements ................... 24
6.5.1 Address .............................................. 24
6.5.2 Name ................................................. 25
6.5.3 Node ................................................. 25
6.5.4 Process .............................................. 26
6.5.5 Service .............................................. 27
Curry Expires: September 14, 2000 [Page 2]
Internet-Draft IDMEF XML DTD March 15, 2000
6.5.5.1 SNMPService .................................... 28
6.5.5.2 WebService ..................................... 28
6.5.6 User ................................................. 29
6.6 Simple Elements ............................................ 30
6.6.1 alertid .............................................. 30
6.6.2 Arguments ............................................ 30
6.6.2.1 arg ............................................ 30
6.6.3 buffer ............................................... 30
6.6.4 cgi .................................................. 30
6.6.5 command .............................................. 30
6.6.6 community ............................................ 31
6.6.7 date ................................................. 31
6.6.8 dport ................................................ 31
6.6.9 Environment .......................................... 31
6.6.9.1 env ............................................ 31
6.6.10 gid ................................................. 31
6.6.11 group ............................................... 31
6.6.12 location ............................................ 31
6.6.13 method .............................................. 32
6.6.14 name ................................................ 32
6.6.15 oid ................................................. 32
6.6.16 path ................................................ 32
6.6.17 pid ................................................. 32
6.6.18 portlist ............................................ 32
6.6.19 program ............................................. 32
6.6.20 protocol ............................................ 32
6.6.21 reaction ............................................ 33
6.6.22 serial .............................................. 33
6.6.23 signature ........................................... 33
6.6.24 size ................................................ 33
6.6.25 sport ............................................... 33
6.6.26 time ................................................ 33
6.6.27 url ................................................. 33
6.6.28 uid ................................................. 33
6.7 Providing Additional Information ........................... 34
6.7.1 AdditionalData ....................................... 34
7. Examples ........................................................ 35
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 .......................................... 43
7.6 Query and Response ......................................... 44
7.6.1 Passing Data by Reference ............................ 45
7.6.2 Manager-to-Analyzer Query ............................ 45
Curry Expires: September 14, 2000 [Page 3]
Internet-Draft IDMEF XML DTD March 15, 2000
7.6.3 Analyzer-to-Manager Response ......................... 46
7.7 Heartbeat .................................................. 46
8. Extending the IDMEF ............................................. 47
8.1 Extending an Existing Attribute ............................ 48
8.2 Adding an Attribute ........................................ 48
8.3 Adding an Element .......................................... 49
9. The IDMEF Document Type Definition .............................. 50
10. Security Considerations ........................................ 63
11. References ..................................................... 63
12. Acknowledgments ................................................ 64
13. Author's Address ............................................... 64
Curry Expires: September 14, 2000 [Page 4]
Internet-Draft IDMEF XML DTD March 15, 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: September 14, 2000 [Page 5]
Internet-Draft IDMEF XML DTD March 15, 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. 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.
XML applications that conform to the requirements set forth in this
memo and also make use of namespaces MUST NOT include other non-IDMEF
namespaces in an IDMEF document.
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
others.
XML's flexibility makes it a good choice for these applications; that
Curry Expires: September 14, 2000 [Page 6]
Internet-Draft IDMEF XML DTD March 15, 2000
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
they know; and
+ it is easy to extend, and will allow vendors to provide additional
Curry Expires: September 14, 2000 [Page 7]
Internet-Draft IDMEF XML DTD March 15, 2000
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 subtags of the tags for the
parent classes.
+ Several extensions have been made, represented by the following
elements: <Heartbeat>, <Query>, <Response>, <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" ?>
where "charset" is the name of the character set in use (see section
4.2). If no encoding is specified, UTF-8 is assumed.
Curry Expires: September 14, 2000 [Page 8]
Internet-Draft IDMEF XML DTD March 15, 2000
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
in nonsense order, elements "invented" by the author that the
processing application doesn't understand, and so forth.
Curry Expires: September 14, 2000 [Page 9]
Internet-Draft IDMEF XML DTD March 15, 2000
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 v1.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 v1.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.
4.2 Character Data Processing in XML and IDMEF
Curry Expires: September 14, 2000 [Page 10]
Internet-Draft IDMEF XML DTD March 15, 2000
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 SHOULD NOT use, and IDMEF messages SHOULD NOT be
encoded in, character sets 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
possibility of misinterpretation.
Curry Expires: September 14, 2000 [Page 11]
Internet-Draft IDMEF XML DTD March 15, 2000
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:
<tagname xml:lang="langcode">
Curry Expires: September 14, 2000 [Page 12]
Internet-Draft IDMEF XML DTD March 15, 2000
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).
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:
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
negative ('-') or positive ('+') sign. 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. For
example, the number one hundred twenty-three and forty-five
Curry Expires: September 14, 2000 [Page 13]
Internet-Draft IDMEF XML DTD March 15, 2000
one-hundredths would be encoded as "123.45".
3. Character and character string data does not require quoting, as
the IDMEF tags provide that functionality.
3. Dates MUST be encoded as a four-digit year, two-digit month, and
two-digit day, separated by forward slashes. The two-digit day
and its corresponding forward slash 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 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".
5. 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.
6. The identification strings used with the "id" attribute of the
<Address>, <Analyzer>, <Node>, <Process>, <Service>, <Source>,
<Target>, 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 string 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 strings MUST be generated.
(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 "id" attributes of the <Alert>,
<Heartbeat>, <Query>, and <Response> elements, 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.
Curry Expires: September 14, 2000 [Page 14]
Internet-Draft IDMEF XML DTD March 15, 2000
A description of the element is provided, followed by a list of the
element's attributes, and then a list of the sub-elements that the
element may contain.
For attributes, the notation "required" indicates that a value for
the attribute must be specified, while "optional" indicates that a
value is not required. All optional attributes have default values
that the manager (XML parser) will assume if no other value is
provided.
For sub-elements, the number of times the element may occur is given.
Possible values are "exactly one," "zero or one," "zero or more," and
"one or more." Except as stated otherwise, sub-elements must occur
in the order shown (XML does not require this; it is a requirement of
this specification).
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 "1.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.
<Query>
Zero or more. Query from the manager to the analyzer to provide
additional data. This is an extension element, not specified in
the data model.
<Response>
Zero or more. Response from the analyzer to the manager sent as
the result of a <Query>. This is an extension element, not
specified in the data model.
Curry Expires: September 14, 2000 [Page 15]
Internet-Draft IDMEF XML DTD March 15, 2000
6.2 The Message Type Elements
There are four types of IDMEF message: <Alert>, <Heartbeat>, <Query>,
and <Response>. All of 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:
confidence
Optional. The confidence the analyzer has in the alert.
Permitted values: 1 (low) to 100 (high) and 0 (unknown).
Default value: "0".
id
Required. A "serial number" for the alert. This string MUST be
unique for every alert generated by a given analyzer. Default
value: (none).
impact
Optional. 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 | Successful reconnaissance probe
+-----------------------+---------------------------------------
| attempted-user | Attempt to obtain user-level access
Curry Expires: September 14, 2000 [Page 16]
Internet-Draft IDMEF XML DTD March 15, 2000
+-----------------------+---------------------------------------
| successful-user | Successful compromise of user access
+-----------------------+---------------------------------------
method
Optional. The detection method used. Possible values:
+-----------------------+---------------------------------------
| unknown | Information not provided (default
| | value)
+-----------------------+---------------------------------------
| behavior | Behavior-based
+-----------------------+---------------------------------------
| correlation | Correlation of other alerts/data
+-----------------------+---------------------------------------
| knowledge | Knowledge-based
+-----------------------+---------------------------------------
| policy | Policy-based
+-----------------------+---------------------------------------
version
Optional. The version of the data model used. Messages
conforming to the format described in this memo MUST use "1.0"
as the value for this attribute.
The <Alert> element has the following sub-elements:
<Time>
Exactly one. The time the alert was generated.
<Analyzer>
Exactly one. The analyzer sending the alert.
<Name>
One or more. The name of the vulnerability (event causing the
alert).
<signature>
Zero or one. The signature used to detect the event.
<reaction>
Zero or one. The countermeasure applied to the event.
<Source>
Zero or more. The source(s) of the event/attack.
<Target>
Zero or more. The target(s) of the event/attack.
<ToolAlert>
Zero or one. Information about the tool that caused the event.
Curry Expires: September 14, 2000 [Page 17]
Internet-Draft IDMEF XML DTD March 15, 2000
<OverflowAlert>
Zero or one. Information about buffer-overflow events.
<CorrelationAlert>
Zero or one. Identifies the alerts used in the correlation.
<AdditionalData>
Zero or more. Additional information provided.
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 "id" 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 name of the program against which the overflow
was attempted.
<size>
Exactly one. The size, in bytes, of the data that was sent to
the program. This is NOT the size of the <buffer> element,
below.
<buffer>
Exactly one. Some or all of the data that was sent to the
program.
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. This may allow the analyzer to group alerts it has
already received into a single "meta-alert" for display purposes.
<ToolAlert> has two sub-elements:
<name>
Exactly one. The name of the attack tool these alerts "belong"
to.
Curry Expires: September 14, 2000 [Page 18]
Internet-Draft IDMEF XML DTD March 15, 2000
<alertid>
One or more. The alerts that have been identified as coming
from this attack tool.
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:
id
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 heartbeat "id"
with an alert "id" 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.
6.2.3 Query
The <Query> element is used by a manager to request information from
an analyzer.
By using the query/response mechanism, cooperating analyzers and
managers can communicate in a "shorthand" manner that reduces the
amount of network bandwidth needed to communicate alerts. Use of the
query/response mechanism is OPTIONAL, and must be negotiated between
each manager and analyzer. The manner in which this negotiation is
accomplished is outside the scope of this specification.
As an example, consider an analyzer that has 100 alerts to send, all
of which will contain exactly the same information in the <Source>
element and its sub-elements (this could happen, for example, in the
case where a single host is running a vulnerability scanner). When
Curry Expires: September 14, 2000 [Page 19]
Internet-Draft IDMEF XML DTD March 15, 2000
it sends the first alert, the analyzer will provide a completely
"filled-in" <Source> element, with an "id" attribute that uniquely
identifies it. This information, when received by the manager, will
be cached for later use.
When the analyzer sends the second and following alerts, it will not
send a "filled-in" <Source> element. Instead, it will send an empty
element, with the same "id" attribute as the filled-in version:
<Source id="same id as before" />
(The trailing "/" in the tag indicates that this is an empty element
in XML; it is equivalent to providing a start-tag followed
immediately by an end-tag in HTML.)
The manager, on receiving this empty element, will look up the "id"
in its cache, and obtain the data locally. When used extensively,
this method can substantially reduce the amount of network bandwidth
required to transmit alerts.
The <Query> element is used by a manager to request information from
an analyzer that the manager no longer has cached. This situation
can occur, for example, because of garbage collection on the manager,
or a manager restart that has cleared an in-memory cache.
The <Query> element has the following attribute:
id
Required. A "serial number" for the query. This string MUST be
unique for every query generated by the manager. It MUST NOT be
possible to confuse a query "id" with an alert "id" from the
same analyzer.
The <Query> element may have zero or more sub-elements of <Address>,
<Analyzer>, <Node>, <Process>, <Service>, <Source>, <Target>, or
<User>, in any order. These sub-elements are given as empty
elements, with "id" attributes equal to the ids the manager wishes to
have more information about.
6.2.4 Response
The <Response> element is used by an analyzer to respond to a <Query>
element received from a manager. See the description in Section
6.2.3, above, to understand how <Query> and <Response> are used
together.
The <Response> element has the following attribute:
id
Required. The value of this attribute MUST be the same as the
value of the "id" attribute of the <Query> that this <Response>
Curry Expires: September 14, 2000 [Page 20]
Internet-Draft IDMEF XML DTD March 15, 2000
answers.
The <Response> element may have zero or more sub-elements of
<Address>, <Analyzer>, <Node>, <Process>, <Service>, <Source>,
<Target>, or <User>, in any order. The contents of these
sub-elements is the data associated with the sub-elements whose "id"
attributes match the ones specified in the <Query>.
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. The offset, in hours, from Coordinated Universal Time
(Greenwich Mean Time). Given as a positive or negative real
number. Default value: "0".
The <Time> element has the following sub-elements:
<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.
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 two
Curry Expires: September 14, 2000 [Page 21]
Internet-Draft IDMEF XML DTD March 15, 2000
sub-elements, <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 two
sub-elements, <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:
id
Required. See Section 5 for formatting details.
The <Analyzer> element has the following sub-elements:
<Node>
Zero or one. Host/device name and address information.
<Process>
Zero or one. Process information.
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
Curry Expires: September 14, 2000 [Page 22]
Internet-Draft IDMEF XML DTD March 15, 2000
distributed denial-of-service attack).
The <Source> element has the following attributes:
id
Required. See Section 5 for formatting details.
spoofed
Optional. 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:
id
Required. See Section 5 for formatting details.
decoy
Optional. 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.
Curry Expires: September 14, 2000 [Page 23]
Internet-Draft IDMEF XML DTD March 15, 2000
+-----------------------+---------------------------------------
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 more granular information 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:
id
Required. See Section 5 for formatting details.
category
Optional. The type of address provided. Possible values:
+-----------------------+---------------------------------------
| unknown | Type not known. Default value.
+-----------------------+---------------------------------------
| 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
+-----------------------+---------------------------------------
Curry Expires: September 14, 2000 [Page 24]
Internet-Draft IDMEF XML DTD March 15, 2000
| 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)
+-----------------------+---------------------------------------
| ipv6-addr | IPv6 host address
+-----------------------+---------------------------------------
| ipv6-net | IPv6 network address
+-----------------------+---------------------------------------
The <Address> element has no sub-elements.
6.5.2 Name
The <Name> element provides the name of the event (vulnerability)
that caused this alert to be generated. Names may come from several
sources. (Note: Do not confuse this element with the <name>
element, used elsewhere.)
The <Name> 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]
+-----------------------+---------------------------------------
| policy | An organization policy (environment
| | dependent)
+-----------------------+---------------------------------------
The <Name> element has no sub-elements.
6.5.3 Node
The <Node> element provides identification of hosts and network
equipment.
Curry Expires: September 14, 2000 [Page 25]
Internet-Draft IDMEF XML DTD March 15, 2000
The <Node> element has the following attributes:
id
Required. 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
+-----------------------+---------------------------------------
| 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. 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
Curry Expires: September 14, 2000 [Page 26]
Internet-Draft IDMEF XML DTD March 15, 2000
on a node.
The <Process> element has the following attribute:
id
Required. See Section 5 for formatting details.
The <Process> element has the following sub-elements:
<pid>
Zero or one. The system process identifier (usually a small
integer).
<name>
Zero or one. The name of the process.
<path>
Zero or one. The path name of the program being run.
<Arguments>
Zero or one. The arguments to the process.
<Environment>
Zero or one. The environment variables associated with the
process.
6.5.5 Service
The <Service> element provides information about a service being
provided by a node.
The <Service> element has the following attribute:
id
Required. See Section 5 for formatting details.
The <Service> element has the following sub-elements:
<name>
Zero or one. Name of the service.
<dport>
Zero or one. Destination port number of the service (port
number on the server).
<sport>
Zero or one. Source port number of the service (port number on
the client).
<protocol>
Zero or one. Protocol implemented by the service.
Curry Expires: September 14, 2000 [Page 27]
Internet-Draft IDMEF XML DTD March 15, 2000
<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:
id
Required. 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:
id
Required. See Section 5 for formatting details.
The <WebService> element has the following sub-elements:
<url>
Zero or one. The URL in the request.
<cgi>
Zero or one. The CGI script in the request (without arguments)
Curry Expires: September 14, 2000 [Page 28]
Internet-Draft IDMEF XML DTD March 15, 2000
<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:
id
Required. See Section 5 for formatting details.
category
Optional. The type of user information provided. Possible
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. The user name.
<uid>
Zero or one. The user id (usually a small integer).
<group>
Zero or one. The name of the group the user is in.
<gid>
Zero or one. The group id (usually a small integer).
<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).
Curry Expires: September 14, 2000 [Page 29]
Internet-Draft IDMEF XML DTD March 15, 2000
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 alertid
The <alertid> element contains an alert identifier (the "id"
attribute of an <Alert> element). It is a sub-element of the
<CorrelationAlert> and <ToolAlert> elements.
6.6.2 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.2.1 arg
The <arg> element contains a single process argument string. It is a
sub-element of the <Arguments> element.
6.6.3 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.4 cgi
The <cgi> element contains the name of a CGI script. It is a
sub-element of the <WebService> element.
6.6.5 command
The <command> element contains an SNMP command. It is a sub-element
of the <SNMPService> element.
Curry Expires: September 14, 2000 [Page 30]
Internet-Draft IDMEF XML DTD March 15, 2000
6.6.6 community
The <community> element contains an SNMP community name. It is a
sub-element of the <SNMPService> element.
6.6.7 date
The <date> element contains a date string. See Section 5 for
formatting details. The <date> element is a sub-element of the
<AnalyzerTime>, <DetectTime>, and <Time> elements.
6.6.8 dport
The <dport> element contains a destination port number. It is a
sub-element of the <Service> element.
6.6.9 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.9.1 env
The <env> element contains a single process environment string. It
is a sub-element of the <Environment> element.
6.6.10 gid
The <gid> element contains a group identifier. It is a sub-element
of the <User> element.
6.6.11 group
The <group> element contains a group name. It is a sub-element of
the <User> element.
6.6.12 location
Curry Expires: September 14, 2000 [Page 31]
Internet-Draft IDMEF XML DTD March 15, 2000
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.13 method
The <method> element contains the HTTP method used to access a web
service. It is a sub-element of the <WebService> element.
6.6.14 name
The <name> element contains the name of a host, piece of network
equipment, process, service, user, or attack tool. Do not confuse it
with the <Name> element, which contains event names. The <name>
element is a sub-element of the <Node>, <Process>, <Service>,
<ToolAlert>, and <User> elements.
6.6.15 oid
The <oid> element contains an SNMP object identifier. It is a
sub-element of the <SNMPService> element.
6.6.16 path
The <path> element contains the path name of a program. It is a
sub-element of the <Process> element.
6.6.17 pid
The <pid> element contains a process identifier. It is a sub-element
of the <Process> element.
6.6.18 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.19 program
The <program> element contains the name of a program. It is a
sub-element of the <OverflowAlert> element.
6.6.20 protocol
Curry Expires: September 14, 2000 [Page 32]
Internet-Draft IDMEF XML DTD March 15, 2000
The <protocol> element contains the name of a protocol. It is a
sub-element of the <Service> element.
6.6.21 reaction
The <reaction> element contains the description of a countermeasure.
It is a sub-element of the <Alert> element.
6.6.22 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.23 signature
The <signature> element contains an intrusion detection signature.
It is a sub-element of the <Alert> element.
6.6.24 size
The <size> element contains a buffer (data) size, in bytes. It is a
sub-element of the <OverflowAlert> element.
6.6.25 sport
The <sport> element contains a source port number. It is a
sub-element of the <Service> element.
6.6.26 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.27 url
The <url> element contains a Universal Resource Locator. It is a
sub-element of the <WebService> element.
6.6.28 uid
The <uid> element contains a user identifier. It is a sub-element of
Curry Expires: September 14, 2000 [Page 33]
Internet-Draft IDMEF XML DTD March 15, 2000
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.
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
+-----------------------+---------------------------------------
| 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.
Curry Expires: September 14, 2000 [Page 34]
Internet-Draft IDMEF XML DTD March 15, 2000
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
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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="12345.123456789" confidence="100" method="knowledge"
impact="successful-dos">
<Time offset="-5">
<date>2000/03/09</date>
<time>10:01:25.93464</time>
</Time>
<Analyzer id="12345">
<Node id="12345.n01" category="dns">
<name>analyzer01.bigcompany.com</name>
<location>Headquarters DMZ Network</location>
</Node>
</Analyzer>
<Name origin="bugtraqid">124</Name>
<signature>teardrop</signature>
<reaction>source address blocked</reaction>
<Source id="12345.s7beae779">
<Node id="12345.n7beae779" category="dns">
<name>badguy.hacker.net</name>
<Address id="12345.a7beae779" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
Curry Expires: September 14, 2000 [Page 35]
Internet-Draft IDMEF XML DTD March 15, 2000
</Source>
<Target id="12345.tde796f70">
<Node id="12345.nde796f70">
<Address id="12345.ade796f70" category="ipv4-addr-hex">
de796f70
</Address>
</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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="1234567890" confidence="70" impact="attempted-dos"
method="knowledge">
<Time offset="0">
<date>2000/03/09</date>
<time>10:01:25.93464</time>
</Time>
<Analyzer id="123123123">
<Node id="123123123.1" category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Name origin="cve">CVE-1999-128</Name>
<signature>Oversized ICMP packet</signature>
<Source id="234234234" spoofed="yes">
<Node id="234234234.1">
<Address id="234234234.2" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
</Source>
<Target id="345345345">
<Node id="345345345.1">
<Address id="345345345.2" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
</Target>
<Target id="456456456">
Curry Expires: September 14, 2000 [Page 36]
Internet-Draft IDMEF XML DTD March 15, 2000
<Node id="456456456.1" category="nisplus">
<name>lollipop</name>
</Node>
</Target>
<Target id="567567567">
<Node id="567567567.1">
<name>Cisco.router.b10</name>
<location>Cabinet B10</location>
</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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="1234567890" confidence="100" impact="attempted-recon"
method="policy">
<Time offset="+2">
<date>2000/03/09</date>
<time>18:47:25</time>
</Time>
<Analyzer id="123123123">
<Node id="123123123.1" category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Name origin="policy">finger</Name>
<signature>Connection on finger port</signature>
<Source id="234234234">
<Node id="234234234.1">
<Address id="234234234.2" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
Curry Expires: September 14, 2000 [Page 37]
Internet-Draft IDMEF XML DTD March 15, 2000
</Source>
<Target id="345345345">
<Node id="345345345.1" category="nis">
<name>myhost</name>
<Address id="345345345.2" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
<Service id="345345345.3">
<name>finger</name>
<dport>79</dport>
<sport>31532</sport>
</Service>
</Target>
<Target id="456456456">
<Node id="456456456.1">
<Address id="456456456.2" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
<User id="456456456.3" 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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="12345.987654321" confidence="60" method="behavior"
impact="successful-recon">
<Time offset="-8">
<date>2000/03/09</date>
<time>15:31</time>
</Time>
<Analyzer id="12345">
<Node id="12345.n62" category="dns">
<name>analyzer62.bigcompany.com</name>
<location>Headquarters Web Server</location>
</Node>
Curry Expires: September 14, 2000 [Page 38]
Internet-Draft IDMEF XML DTD March 15, 2000
</Analyzer>
<Name origin="policy">portscan</Name>
<signature>connection to many ports in short period</signature>
<Source id="12345.sde796f70">
<Node id="12345.nde796f70">
<Address id="12345.ade796f70" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
</Source>
<Target id="12345.t7beae779">
<Node id="12345.n7beae779" category="dns">
<name>www.bigcompany.com</name>
<Address id="12345.a7beae779" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
<Service id="12345.svcset01">
<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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="345097" confidence="100" impact="attempted-admin"
method="knowledge">
<Time offset="-5">
<date>2000/03/09</date>
<time>08:12:32.3</time>
</Time>
Curry Expires: September 14, 2000 [Page 39]
Internet-Draft IDMEF XML DTD March 15, 2000
<Analyzer id="372">
<Node id="987" category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
<Process id="956">
<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>
<Name origin="bugtraqid">33</Name>
<signature>loadmodule forking shell</signature>
<Source id="5678901234">
<User id="7890123456" category="os-device">
<name>joe</name>
<uid>13243</uid>
</User>
<Process id="6789012345">
<name>loadmodule</name>
<path>/usr/openwin/bin</path>
</Process>
</Source>
<Target id="3456789012">
<Node id="4567890123" 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 v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="345097" confidence="100" impact="attempted-admin"
method="knowledge">
<Time offset="-5">
<date>2000/03/09</date>
<time>08:12:32.3</time>
</Time>
<Analyzer id="372">
<Node id="987" category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
Curry Expires: September 14, 2000 [Page 40]
Internet-Draft IDMEF XML DTD March 15, 2000
<Process id="956">
<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>
<Name origin="bugtraqid">33</Name>
<signature>loadmodule forking shell</signature>
<Source id="5678901234">
<User id="7890123456" category="os-device">
<name>joe</name>
<uid>13243</uid>
</User>
<Process id="6789012345">
<name>loadmodule</name>
<path>/usr/openwin/bin</path>
</Process>
</Source>
<Target id="3456789012">
<Node id="4567890123" category="dns">
<name>fileserver.bigcompany.com</name>
</Node>
<User id="3463252342" category="os-device">
<name>root</name>
<uid>0</uid>
</User>
<Process id="249872434">
<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"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="1234567890" confidence="100" impact="attempted-recon"
method="knowledge">
Curry Expires: September 14, 2000 [Page 41]
Internet-Draft IDMEF XML DTD March 15, 2000
<Time offset="-1">
<date>2000/03/09</date>
<time>08:12:32</time>
</Time>
<Analyzer id="123123123">
<Node id="123123123.1" category="dns">
<name>sensor.bigcompany.com</name>
</Node>
</Analyzer>
<Name origin="bugtraqid">629</Name>
<signature>/.*http[w+]bin//phf?/</signature>
<Source id="234234234">
<Node id="234234234.1">
<Address id="234234234.2" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
</Source>
<Target id="3456789012">
<Node id="3456789012.1" category="dns">
<name>www.bigcompany.com</name>
<Address id="3456789012.2" category="ipv4-addr">
123.45.67.89
</Address>
</Node>
<Service id="3456789012.3">
<dport>8080</dport>
<sport>21534</sport>
<WebService id="3456789012.4">
<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
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 v1.1//EN"
Curry Expires: September 14, 2000 [Page 42]
Internet-Draft IDMEF XML DTD March 15, 2000
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="1234567890" confidence="100" impact="attempted-user"
method="policy">
<Time offset="-5">
<date>2000/03/09</date>
<time>22:18:07</time>
</Time>
<Analyzer id="999888777.1">
<Node id="999888777.2" category="dns">
<name>dialserver.bigcompany.com</name>
</Node>
</Analyzer>
<Name origin="policy">out-of-hours activity</Name>
<signature>user activity outside of normal hours</signature>
<Source id="234234234">
<Node id="234234234.1">
<Address id="234234234.2" category="ipv4-addr">
127.0.0.1
</Address>
</Node>
</Source>
<Target id="3456789012">
<Node id="3456789012.1" category="dns">
<name>mainframe.bigcompany.com</name>
</Node>
<User id="3456789012.2" category="os-device">
<name>louis</name>
<uid>501</uid>
</User>
<Service id="3456789012.3">
<name>login</name>
<dport>23</dport>
<sport>4235</sport>
</Service>
</Target>
<AdditionalData type="time" meaning="start-time">
07:00:00
</AdditionalData>
<AdditionalData type="time" meaning="stop-time">
19:30:00
</AdditionalData>
</Alert>
</IDMEF-Message>
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.
Curry Expires: September 14, 2000 [Page 43]
Internet-Draft IDMEF XML DTD March 15, 2000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="12345.987654321" confidence="60" method="behavior"
impact="successful-recon">
<Time offset="-8">
<date>2000/03/09</date>
<time>15:31</time>
</Time>
<Analyzer id="12345">
<Node id="12345.n01" category="dns">
<name>correlator01.bigcompany.com</name>
</Node>
</Analyzer>
<Name origin="policy">portscan</Name>
<signature>connection to many ports in short period</signature>
<Source id="12345.sde796f70">
<Node id="12345.nde796f70">
<Address id="12345.ade796f70" category="ipv4-addr">
222.121.111.112
</Address>
</Node>
</Source>
<Target id="12345.t7beae779">
<Node id="12345.n7beae779" category="dns">
<name>www.bigcompany.com</name>
<Address id="12345.a7beae779" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
<Service id="12345.svcset01">
<portlist>5-25,37,42,43,53,69-119,123-514</portlist>
</Service>
</Target>
<CorrelationAlert>
<alertid>12345.3563635</alertid>
<alertid>12345.4746734</alertid>
<alertid>12345.4564363</alertid>
<alertid>12345.3635657</alertid>
<alertid>12345.4747463</alertid>
<alertid>12345.4585875</alertid>
<alertid>12345.6769574</alertid>
</CorrelationAlert>
</Alert>
</IDMEF-Message>
7.6 Query and Response
Curry Expires: September 14, 2000 [Page 44]
Internet-Draft IDMEF XML DTD March 15, 2000
The examples in this section show how the query/response mechanism
described in Section 6.2.3 is used.
7.6.1 Passing Data by Reference
Passing data by reference, to conserve bandwidth. This is what
Example 7.1.1 would look like. Note that the <Analyzer>, <Source>,
and <Target> elements have "id" attributes but no data. If the
analyzer has sent these to the manager already in other alerts, the
manager should know what they are, and be able to look them up
locally in its cache/database.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Alert id="12345.123456789" confidence="100" method="knowledge"
impact="successful-dos">
<Time offset="-5">
<date>2000/03/09</date>
<time>10:01:25.93464</time>
</Time>
<Analyzer id="12345"/>
<Name origin="bugtraqid">124</Name>
<signature>teardrop</signature>
<reaction>source address blocked</reaction>
<Source id="12345.s7beae779"/>
<Target id="12345.tde796f70"/>
</Alert>
</IDMEF-Message>
7.6.2 Manager-to-Analyzer Query
If the manager doesn't know what a pass-by-reference item is (e.g.,
if it has lost its cache since the last time the data was sent), it
can query the analyzer to find out. This query asks about the
pass-by-reference items from Example 7.6.1.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Query id="315670095">
<Analyzer id="12345"/>
<Source id="12345.s7beae779"/>
Curry Expires: September 14, 2000 [Page 45]
Internet-Draft IDMEF XML DTD March 15, 2000
<Target id="12345.tde796f70"/>
</Query>
</IDMEF-Message>
7.6.3 Analyzer-to-Manager Response
The analyzer responds to a query by sending a response whose "id"
attribute has the same value as the query's. The content of the
response is the full data for the queried elements.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v1.1//EN"
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Response id="315670095">
<Analyzer id="12345">
<Node id="12345.n01" category="dns">
<name>analyzer01.bigcompany.com</name>
<location>Headquarters DMZ Network</location>
</Node>
</Analyzer>
<Source id="12345.s7beae779">
<Node id="12345.n7beae779" category="dns">
<name>badguy.hacker.net</name>
<Address id="12345.a7beae779" category="ipv4-addr">
123.234.231.121
</Address>
</Node>
</Source>
<Target id="12345.tde796f70">
<Node id="12345.nde796f70">
<Address id="12345.ade796f70" category="ipv4-addr-hex">
de796f70
</Address>
</Node>
</Target>
</Response>
</IDMEF-Message>
7.7 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 v1.1//EN"
Curry Expires: September 14, 2000 [Page 46]
Internet-Draft IDMEF XML DTD March 15, 2000
"idmef-message.dtd">
<IDMEF-Message version="1.1">
<Heartbeat id="123456789">
<Time offset="0">
<date>2000/03/09</date>
<time>14:07:58</time>
</Time>
<Analyzer id="abcdefghij">
<Node id="abcdefghij.1" 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
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.
Curry Expires: September 14, 2000 [Page 47]
Internet-Draft IDMEF XML DTD March 15, 2000
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 v1.1//EN"
"idmef-message.dtd"
[
<!ENTITY % ext.attvals.Listname "
| x-value-1 | x-value-2
">
]>
All new attribute values defined in this manner MUST have names that
begin with "x-". They SHOULD also include the name of their creator
in the name, e.g., "x-acme-specialvalue."
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 "">
Curry Expires: September 14, 2000 [Page 48]
Internet-Draft IDMEF XML DTD March 15, 2000
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 v1.1//EN"
"idmef-message.dtd"
[
<!ENTITY % ext.attlist.Elementname "
x-attribute CDATA #IMPLIED
">
]>
All new attributes defined in this manner MUST have names that begin
with "x-". They SHOULD also include the name of their creator in the
name, e.g., "x-acme-specialattr." Required attributes (those marked
"#REQUIRED") SHOULD be avoided, as it may not be possible to cause an
analyzer to generate that attribute.
Existing IDMEF element attributes MAY NOT be redefined.
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 v1.1//EN"
"idef-message.dtd"
[
<!ELEMENT IDMEF-Message (
(Alert | Heartbeat | Query | Response | x-acme-error)*
)>
<!ELEMENT x-acme-error (#PCDATA) >
]>
Curry Expires: September 14, 2000 [Page 49]
Internet-Draft IDMEF XML DTD March 15, 2000
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 1.1, 15 March 2000 ***
*** ***
*** Use of the IDMEF DTD is described in "Intrusion Detection ***
*** Message Exchange Format - XML Document Type Definition," ***
*** David A. Curry, draft-curry-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-02.txt. ***
*******************************************************************
*************************************************************** -->
<!-- ===============================================================
===================================================================
=== SECTION 1. Attribute list declarations. The version attributes
=== are used with the IDMEF-Message top-level element;
=== the global attributes are used with all elements;
=== the id attributes are used with most entity elements
===================================================================
=============================================================== -->
<!--
| 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-curry-idmef-xml-01.txt'
xmlns:idmef CDATA #FIXED
'http://www.ietf.org/internet-drafts/draft-curry-idmef-xml-01.txt'
version CDATA #FIXED '1.1'
%ext.attlist.version;
">
<!--
Curry Expires: September 14, 2000 [Page 50]
Internet-Draft IDMEF XML DTD March 15, 2000
| 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 most "entity" elements.
-->
<!ENTITY % ext.attlist.id "">
<!ENTITY % attlist.id "
id CDATA #REQUIRED
">
<!-- ===============================================================
===================================================================
=== SECTION 2. Attribute value declarations. Enumerated values of
=== many of the element attributes.
===================================================================
=============================================================== -->
<!--
| Values for the Alert.confidence attribute.
-->
<!ENTITY % ext.attvals.confidence "">
<!ENTITY % attvals.confidence "
( 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 |
50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 |
60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 |
70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 |
80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 |
90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 |
100
%ext.attvals.confidence; )
">
<!--
| Values for the Alert.impact attribute.
-->
<!ENTITY % ext.attvals.impact "">
<!ENTITY % attvals.impact "
( unknown | bad-unknown | not-suspicious |
attempted-admin | successful-admin |
attempted-dos | successful-dos |
attempted-recon | successful-recon |
Curry Expires: September 14, 2000 [Page 51]
Internet-Draft IDMEF XML DTD March 15, 2000
attempted-user | successful-user
%ext.attvals.impact; )
">
<!--
| Values for the Alert.method attribute.
-->
<!ENTITY % ext.attvals.method "">
<!ENTITY % attvals.method "
( unknown | behavior | correlation | knowledge | policy
%ext.attvals.method; )
">
<!--
| Values for the AdditionalData.type attribute.
-->
<!ENTITY % ext.attvals.adtype "">
<!ENTITY % attvals.adtype "
( unknown | boolean | byte | character | date | integer |
real | string | time
%ext.attvals.adtype; )
">
<!--
| Values for the Name.origin attribute.
-->
<!ENTITY % ext.attvals.origin "">
<!ENTITY % attvals.origin "
( unknown | bugtraqid | cve | policy
%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.
Curry Expires: September 14, 2000 [Page 52]
Internet-Draft IDMEF XML DTD March 15, 2000
-->
<!ENTITY % ext.attvals.addrcat "">
<!ENTITY % attvals.addrcat "
( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
ipv4-addr | ipv4-addr-hex | ipv4-net |
ipv6-addr | ipv6-net
%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 | Query | Response)*
)>
<!ENTITY % ext.attlist.IDMEF-Message "">
<!ATTLIST IDMEF-Message
%attlist.version;
%attlist.global;
%ext.attlist.IDMEF-Message;
>
<!ELEMENT Alert (
Time, Analyzer, Name+, signature?, reaction?, Source*, Target*,
ToolAlert?, OverflowAlert?, CorrelationAlert?, AdditionalData*
)>
<!ENTITY % ext.attlist.Alert "">
<!ATTLIST Alert
confidence %attvals.confidence; '0'
Curry Expires: September 14, 2000 [Page 53]
Internet-Draft IDMEF XML DTD March 15, 2000
impact %attvals.impact; 'unknown'
method %attvals.method; 'unknown'
version CDATA #FIXED '1.0'
%attlist.id;
%attlist.global;
%ext.attlist.Alert;
>
<!ELEMENT Heartbeat (
Time, Analyzer, AdditionalData*
)>
<!ENTITY % ext.attlist.Heartbeat "">
<!ATTLIST Heartbeat
%attlist.id;
%attlist.global;
%ext.attlist.Heartbeat;
>
<!ELEMENT Query (
(Address | Analyzer | Node | Process | Service | Source |
Target | User )*
)>
<!ENTITY % ext.attlist.Query "">
<!ATTLIST Query
%attlist.id;
%attlist.global;
%ext.attlist.Query;
>
<!ELEMENT Response (
(Address | Analyzer | Node | Process | Service | Source |
Target | User )*
)>
<!ENTITY % ext.attlist.Response "">
<!ATTLIST Response
%attlist.id;
%attlist.global;
%ext.attlist.Response;
>
<!-- ===============================================================
===================================================================
=== 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'
Curry Expires: September 14, 2000 [Page 54]
Internet-Draft IDMEF XML DTD March 15, 2000
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, alertid+
)>
<!ENTITY % ext.attlist.ToolAlert "">
<!ATTLIST ToolAlert
%attlist.global;
%ext.attlist.ToolAlert;
>
<!-- ===============================================================
===================================================================
=== SECTION 5. Elements related to time. The base time is the time
=== the alert was generated.
===================================================================
=============================================================== -->
<!ELEMENT Time (
date, time, DetectTime?, AnalyzerTime?
)>
<!ENTITY % ext.attlist.Time "">
<!ATTLIST Time
offset CDATA '0'
%attlist.global;
%ext.attlist.Time;
>
<!ELEMENT DetectTime (
date, time
)>
Curry Expires: September 14, 2000 [Page 55]
Internet-Draft IDMEF XML DTD March 15, 2000
<!ENTITY % ext.attlist.DetectTime "">
<!ATTLIST DetectTime
offset CDATA '0'
%attlist.global;
%ext.attlist.DetectTime;
>
<!ELEMENT AnalyzerTime (
date, time
)>
<!ENTITY % ext.attlist.AnalyzerTime "">
<!ATTLIST AnalyzerTime
offset CDATA '0'
%attlist.global;
%ext.attlist.AnalyzerTime;
>
<!-- ===============================================================
===================================================================
=== SECTION 6. Elements related to identifying entities - analyzers
=== (the senders of these messages), sources (of
=== attacks), and targets (of attacks).
===================================================================
=============================================================== -->
<!ELEMENT Analyzer (
Node?, Process?
)>
<!ENTITY % ext.attlist.Analyzer "">
<!ATTLIST Analyzer
%attlist.id;
%attlist.global;
%ext.attlist.Analyzer;
>
<!ELEMENT Source (
Node?, User?, Process?
)>
<!ENTITY % ext.attlist.Source "">
<!ATTLIST Source
spoofed %attvals.spoofed; 'unknown'
%attlist.id;
%attlist.global;
%ext.attlist.Source;
>
<!ELEMENT Target (
Node?, User?, Process?, Service?
)>
<!ENTITY % ext.attlist.Target "">
<!ATTLIST Target
decoy %attvals.decoy; 'unknown'
Curry Expires: September 14, 2000 [Page 56]
Internet-Draft IDMEF XML DTD March 15, 2000
%attlist.id;
%attlist.global;
%ext.attlist.Target;
>
<!-- ===============================================================
===================================================================
=== SECTION 7. Lower-level elements used for providing detailed
=== information about entities - addresses, names, etc.
===================================================================
=============================================================== -->
<!ELEMENT Address (#PCDATA) >
<!ENTITY % ext.attlist.Address "">
<!ATTLIST Address
category %attvals.addrcat; 'unknown'
%attlist.id;
%attlist.global;
%ext.attlist.Address;
>
<!ELEMENT Name (#PCDATA) >
<!ENTITY % ext.attlist.Name "">
<!ATTLIST Name
origin %attvals.origin; 'unknown'
%attlist.global;
%ext.attlist.Name;
>
<!ELEMENT Node (
name?, location?, Address*
)>
<!ENTITY % ext.attlist.Node "">
<!ATTLIST Node
category %attvals.nodecat; 'unknown'
%attlist.id;
%attlist.global;
%ext.attlist.Node;
>
<!ELEMENT Process (
pid?, name?, path?, Arguments?, Environment?
)>
<!ENTITY % ext.attlist.Process "">
<!ATTLIST Process
%attlist.id;
%attlist.global;
%ext.attlist.Process;
>
<!ELEMENT Service (
name?, dport?, sport?, protocol?, portlist?, SNMPService?,
Curry Expires: September 14, 2000 [Page 57]
Internet-Draft IDMEF XML DTD March 15, 2000
WebService?
)>
<!ENTITY % ext.attlist.Service "">
<!ATTLIST Service
%attlist.id;
%attlist.global;
%ext.attlist.Service;
>
<!ELEMENT User (
name?, uid?, group?, gid?, serial?, Address*
)>
<!ENTITY % ext.attlist.User "">
<!ATTLIST User
category %attvals.usercat; 'unknown'
%attlist.id;
%attlist.global;
%ext.attlist.User;
>
<!ELEMENT SNMPService (
oid?, community?, command?
)>
<!ENTITY % ext.attlist.SNMPService "">
<!ATTLIST SNMPService
%attlist.id;
%attlist.global;
%ext.attlist.SNMPService;
>
<!ELEMENT WebService (
url?, cgi?, method?, Arguments?
)>
<!ENTITY % ext.attlist.WebService "">
<!ATTLIST WebService
%attlist.id;
%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
Curry Expires: September 14, 2000 [Page 58]
Internet-Draft IDMEF XML DTD March 15, 2000
%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 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;
Curry Expires: September 14, 2000 [Page 59]
Internet-Draft IDMEF XML DTD March 15, 2000
%ext.attlist.command;
>
<!ELEMENT community (#PCDATA) >
<!ENTITY % ext.attlist.community "">
<!ATTLIST community
%attlist.global;
%ext.attlist.community;
>
<!ELEMENT date (#PCDATA) >
<!ENTITY % ext.attlist.date "">
<!ATTLIST date
%attlist.global;
%ext.attlist.date;
>
<!ELEMENT dport (#PCDATA) >
<!ENTITY % ext.attlist.dport "">
<!ATTLIST dport
%attlist.global;
%ext.attlist.dport;
>
<!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;
>
Curry Expires: September 14, 2000 [Page 60]
Internet-Draft IDMEF XML DTD March 15, 2000
<!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 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
Curry Expires: September 14, 2000 [Page 61]
Internet-Draft IDMEF XML DTD March 15, 2000
%attlist.global;
%ext.attlist.protocol;
>
<!ELEMENT reaction (#PCDATA) >
<!ENTITY % ext.attlist.reaction "">
<!ATTLIST reaction
%attlist.global;
%ext.attlist.reaction;
>
<!ELEMENT serial (#PCDATA) >
<!ENTITY % ext.attlist.serial "">
<!ATTLIST serial
%attlist.global;
%ext.attlist.serial;
>
<!ELEMENT signature (#PCDATA) >
<!ENTITY % ext.attlist.signature "">
<!ATTLIST signature
%attlist.global;
%ext.attlist.signature;
>
<!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;
>
Curry Expires: September 14, 2000 [Page 62]
Internet-Draft IDMEF XML DTD March 15, 2000
<!ELEMENT uid (#PCDATA) >
<!ENTITY % ext.attlist.uid "">
<!ATTLIST uid
%attlist.global;
%ext.attlist.uid;
>
<!-- ***************************************************************
*******************************************************************
*** END OF DTD ***
*******************************************************************
*************************************************************** -->
10. Security Considerations
This Internet-Draft describes a data format for the exchange of
security-related data between security product implementations.
There are no security considerations directly applicable to the
format of this data. There may, however, be security considerations
associated 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 21, 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-02.txt,
March 7, 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.
Curry Expires: September 14, 2000 [Page 63]
Internet-Draft IDMEF XML DTD March 15, 2000
[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/.
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.
148 Madison Avenue, 11th Floor
New York, NY 10016
Phone: +1 212 592-5525
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
Curry Expires: September 14, 2000 [Page 64]
Internet-Draft IDMEF XML DTD March 15, 2000
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE 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: September 14, 2000 [Page 65]
