Draft-ietf-idwg-idmef-xml-14.txt-CSDN博客

The Intrusion Detection Message Exchange Format
draft-ietf-idwg-idmef-xml-14

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,

[@more@]

Intrusion Detection Exchange H. Debar
Format France Telecom
Internet-Draft D. Curry
Expires: July 31, 2005 Guardian
B. Feinstein
TNT
January 27, 2005

The Intrusion Detection Message Exchange Format
draft-ietf-idwg-idmef-xml-14

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.

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.

This Internet-Draft will expire on July 31, 2005.

Abstract

Debar, et al. Expires July 31, 2005 [Page 1]
Internet-Draft The IDMEF January 2005

and to the management systems which may need to interact with them.

This Internet-Draft describes a data model to represent information
exported by intrusion detection systems, and explains the rationale
for using this model. An implementation of the data model in the
Extensible Markup Language (XML) is presented, an XML Document Type
Definition is developed, and examples are provided.

Table of Contents

1. Status of memo . . . . . . . . . . . . . . . . . . . . . . . 5
2. Notices and conventions Used in This Document . . . . . . . 6
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 About the IDMEF Data Model . . . . . . . . . . . . . . . . 7
3.1.1 Problems Addressed by the Data Model . . . . . . . . . 7
3.1.2 Data Model Design Goals . . . . . . . . . . . . . . . 9
3.2 About the IDMEF XML Implementation . . . . . . . . . . . . 10
3.2.1 The Extensible Markup Language . . . . . . . . . . . . 10
3.2.2 Rationale for Implementing IDMEF in XML . . . . . . . 11
4. Notational Conventions and Formatting Issues . . . . . . . . 13
4.1 IDMEF XML Documents . . . . . . . . . . . . . . . . . . . 13
4.1.1 The Document Prolog . . . . . . . . . . . . . . . . . 13
4.1.2 Character Data Processing in IDMEF . . . . . . . . . . 14
4.1.3 Languages in IDMEF . . . . . . . . . . . . . . . . . . 15
4.2 IDMEF Data Types . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 Integers . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Real Numbers . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 Characters and Strings . . . . . . . . . . . . . . . . 16
4.2.4 Bytes . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.5 Enumerated Types . . . . . . . . . . . . . . . . . . . 16
4.2.6 Date-Time Strings . . . . . . . . . . . . . . . . . . 16
4.2.7 NTP Timestamps . . . . . . . . . . . . . . . . . . . . 18
4.2.8 Port Lists . . . . . . . . . . . . . . . . . . . . . . 18
4.2.9 Unique Identifiers . . . . . . . . . . . . . . . . . . 19
5. The IDMEF Data Model and XML DTD . . . . . . . . . . . . . . 21
5.1 Data Model Overview . . . . . . . . . . . . . . . . . . . 21
5.2 The Message Classes . . . . . . . . . . . . . . . . . . . 22
5.2.1 The IDMEF-Message Class . . . . . . . . . . . . . . . 22
5.2.2 The Alert Class . . . . . . . . . . . . . . . . . . . 23
5.2.3 The Heartbeat Class . . . . . . . . . . . . . . . . . 29
5.2.4 The Core Classes . . . . . . . . . . . . . . . . . . . 31
5.2.5 The Time Classes . . . . . . . . . . . . . . . . . . . 44
5.2.6 The Assessment Classes . . . . . . . . . . . . . . . . 46
5.2.7 The Support Classes . . . . . . . . . . . . . . . . . 51
6. Extending the IDMEF . . . . . . . . . . . . . . . . . . . . 80
6.1 Extending the Data Model . . . . . . . . . . . . . . . . . 80
6.2 Extending the XML DTD or schema . . . . . . . . . . . . . 80
7. Special Considerations . . . . . . . . . . . . . . . . . . . 83

Debar, et al. Expires July 31, 2005 [Page 2]
Internet-Draft The IDMEF January 2005

7.1 XML Validity and Well-Formedness . . . . . . . . . . . . . 83
7.2 Unrecognized XML Tags . . . . . . . . . . . . . . . . . . 83
7.3 Analyzer-Manager Time Synchronization . . . . . . . . . . 84
7.4 NTP Timestamp Wrap-Around . . . . . . . . . . . . . . . . 85
7.5 Digital Signatures . . . . . . . . . . . . . . . . . . . . 86
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 87
8.1.1 The "teardrop" Attack . . . . . . . . . . . . . . . . 87
8.1.2 The "ping of death" Attack . . . . . . . . . . . . . . 88
8.2 Port Scanning Attacks . . . . . . . . . . . . . . . . . . 90
8.2.1 Connection To a Disallowed Service . . . . . . . . . . 90
8.2.2 Simple Port Scanning . . . . . . . . . . . . . . . . . 91
8.3 Local Attacks . . . . . . . . . . . . . . . . . . . . . . 92
8.3.1 The "loadmodule" Attack . . . . . . . . . . . . . . . 92
8.3.2 The "phf" Attack . . . . . . . . . . . . . . . . . . . 95
8.3.3 File Modification . . . . . . . . . . . . . . . . . . 96
8.4 System Policy Violation . . . . . . . . . . . . . . . . . 98
8.5 Correlated Alerts . . . . . . . . . . . . . . . . . . . . 99
8.6 Analyzer Assessments . . . . . . . . . . . . . . . . . . . 101
8.7 Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . 102
8.8 XML Extension . . . . . . . . . . . . . . . . . . . . . . 103
9. The IDMEF Document Type Definition (Non-normative) . . . . . 106
10. The IDMEF Schema Definition (Normative) . . . . . . . . . . 120
11. Security Considerations . . . . . . . . . . . . . . . . . . 141
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 142
12.1 Adding Values to Existing Attributes . . . . . . . . . . 142
12.1.1 Attribute Registrations . . . . . . . . . . . . . . 142
12.1.2 Registration Template . . . . . . . . . . . . . . . 156
12.2 Adding New Attributes and Classes . . . . . . . . . . . 157
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 158
13.1 Normative References . . . . . . . . . . . . . . . . . . 158
13.2 Informational References . . . . . . . . . . . . . . . . 158
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 159
A. History of Significant Changes . . . . . . . . . . . . . . . 160
A.1 Things to do before publication . . . . . . . . . . . . . 160
A.2 Response to IESG comments . . . . . . . . . . . . . . . . 160
A.2.1 Comment on Section 3.1.3 . . . . . . . . . . . . . . . 160
A.2.2 Comment on Section A.3.4 . . . . . . . . . . . . . . . 160
A.2.3 Comment on Section 3.2 . . . . . . . . . . . . . . . . 161
A.2.4 Comment on section 3.2.4 . . . . . . . . . . . . . . . 161
A.2.5 Comment on 3.2.5 Enumerated Types . . . . . . . . . . 161
A.2.6 Comment on Section 4.* . . . . . . . . . . . . . . . . 162
A.2.7 Comment on Section 5 . . . . . . . . . . . . . . . . . 163
A.2.8 Comment on Section 7.8 . . . . . . . . . . . . . . . . 163
A.3 Significant Changes Since idmef-10 . . . . . . . . . . . . 164
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 166
C. An Overview of UML and XML as Used in This Document . . . . 167
C.1 Unified Modeling Language . . . . . . . . . . . . . . . . 167

Debar, et al. Expires July 31, 2005 [Page 3]
Internet-Draft The IDMEF January 2005

C.1.1 Relationships . . . . . . . . . . . . . . . . . . . . 167
C.1.2 Occurrence Indicators . . . . . . . . . . . . . . . . 169
C.2 XML Document Type Definitions . . . . . . . . . . . . . . 170
C.2.1 Element Declarations . . . . . . . . . . . . . . . . . 170
C.2.2 Attribute Declarations . . . . . . . . . . . . . . . . 173
C.2.3 Entity Declarations . . . . . . . . . . . . . . . . . 174
C.3 XML Documents . . . . . . . . . . . . . . . . . . . . . . 175
C.3.1 The Document Prolog . . . . . . . . . . . . . . . . . 175
C.3.2 Character Data Processing in XML . . . . . . . . . . . 176
C.3.3 Languages in XML . . . . . . . . . . . . . . . . . . . 178
Intellectual Property and Copyright Statements . . . . . . . 179

Debar, et al. Expires July 31, 2005 [Page 4]
Internet-Draft The IDMEF January 2005

1. Status of memo

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.

Debar, et al. Expires July 31, 2005 [Page 5]
Internet-Draft The IDMEF January 2005

2. Notices and conventions Used in This Document

The keywords "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 [1].

An "IDMEF-compliant application" is a program or program component,
such as an analyzer or manager, 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. "IDMEF message" is another term for an "IDMEF
document."

Debar, et al. Expires July 31, 2005 [Page 6]
Internet-Draft The IDMEF January 2005

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
deem 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:

o 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;
o 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;
o 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
o 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
selecting its method of implementation.

3.1 About the IDMEF Data Model

The IDMEF data model is an object-oriented representation of the
alert data sent to intrusion detection managers by intrusion
detection analyzers.

3.1.1 Problems Addressed by the Data Model

The data model addresses several problems associated with
representing intrusion detection alert data:

Debar, et al. Expires July 31, 2005 [Page 7]
Internet-Draft The IDMEF January 2005

o Alert information is inherently heterogeneous. Some alerts are
defined with very little information, such as origin, destination,
name, and time of the event. Other alerts provide much more
information, such as ports or services, processes, user
information, and so on. The data model that represents this
information must be flexible to accommodate different needs.

An object-oriented model is naturally extensible via aggregation
and subclassing. If an implementation of the data model extends
it with new classes, either by aggregation or subclassing, an
implementation that does not understand these extensions will
still be able to understand the subset of information that is
defined by the data model. Subclassing and aggregation provide
extensibility while preserving the consistency of the model.
o Inrusion detection environments are different. Some analyzers
detect attacks by analyzing network traffic; others use operating
system logs or application audit trail information. Alerts for
the same attack, sent by analyzers with different information
sources, will not contain the same information.

The data model defines support classes that accommodate the
differences in data sources among analyzers. In particular, the
notion of source and target for the alert are represented by the
combination of Node, Process, Service, and User classes.
o Analyzer capabilities are different. Depending on the
environment, one may install a lightweight analyzer that provides
little information in its alerts, or a more complex analyzer that
will have a greater impact on the running system but provide more
detailed alert information. The data model must allow for
conversion to formats used by tools other than intrusion detection
analyzers, for the purpose of further processing the alert
information.

The data model defines extensions to the basic schema that allow
carrying both simple and complex alerts. Extensions are
accomplished through subclassing or association of new classes.
o Operating environments are different. Depending on the kind of
network or operating system used, attacks will be observed and
reported with different characteristics. The data model should
accommodate these differences.

Significant flexibility in reporting is provided by the Node and
Service support classes. If additional information must be
reported, subclasses may be defined that extend the data model
with additional attributes.
o Commercial vendor objectives are different. For various reasons,
vendors may wish to deliver more or less information about certain
types of attacks.

Debar, et al. Expires July 31, 2005 [Page 8]

The object-oriented approach allows this flexibility while the
subclassing rules preserve the integrity of the model.

3.1.2 Data Model Design Goals

The data model was designed to provide a standard representation of
alerts in an unambiguous fashion, and to permit the relationship
between simple and complex alerts to be described.

3.1.2.1 Representing Events

The goal of the data model is to provide a standard representation of
the information that an intrusion detection analyzer reports when it
detects an occurrence of some unusual event(s). These alerts may be
simple or complex, depending on the capabilities of the analyzer that
creates them.

3.1.2.2 Content-Driven

The design of the data model is content-driven. This means that new
objects are introduced to accommodate additional content, not
semantic differences between alerts. This is an important goal, as
the task of classifying and naming computer vulnerabilities is both
extremely difficult and very subjective.

The data model must be unambiguous. This means that while we allow
analyzers to be more or less precise than one another (i.e., one
analyzer may report more information about an event than another), we
do not allow them to produce contradictory information in two alerts
describing the same event (i.e., the common subset of information
reported by both analyzers must be identical and inserted in the same
placeholders within the alert data structure). Of course, it is
always possible to insert all "interesting" information about an
event in extension fields of the alert instead of in the fields where
it belongs; however, such practice reduces interoperability and
should be avoided whenever possible.

3.1.2.3 Relationship Between Alerts

Intrusion detection alerts can be transmitted at several levels.
This Internet-Draft applies to the entire range, from very simple
alerts (e.g., those alerts that are the result of a single action or
operation in the system, such as a failed login report) to very
complex ones (e.g., the aggregation of several events causing an
alert to be generated).

As such, the data model must provide a way for complex alerts that
aggregate several simple alerts to identify those simple alerts in
the complex alert's content.

Debar, et al. Expires July 31, 2005 [Page 9]
Internet-Draft The IDMEF January 2005

3.2 About the IDMEF XML Implementation

Two implementations of the IDMEF were originally proposed to the
IDWG: one using the Structure of Management Information (SMI) to
describe an SNMP MIB, and the other using a Document Type Definition
(DTD) to describe XML documents.

These proposed implementations were reviewed by the IDWG at its
September 1999 and February 2000 meetings; it was decided at the
February meeting that the XML solution was best at fulfilling the
IDWG requirements.

3.2.1 The Extensible Markup Language

The Extensible Markup Language (XML) [3] is a simplified version of
the Standard Generalized Markup Language (SGML), a syntax for
specifying text markup 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 identifiers with preset meanings that
must be "adapted" for specialized uses. Both XML and HTML use
elements (tags) (identifiers delimited by '') and attributes
(of the form "name='value'"). But where "

" 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.

NOTE: XML provides both a syntax for declaring document markup and
structure (i.e., defining elements and attributes, specifying the
order in which they appear, and so on) and a syntax for using that
markup in documents. Because markup declarations look radically
different from markup, many people are confused as to which syntax
is called XML. The answer is that they both are, because they are
actually both part of the same language.
For clarity in this document, we will use the terms "XML" and "XML
documents" when speaking in the general case, and the term "IDMEF
markup" when speaking specifically of the elements (tags) and
attributes that describe IDMEF messages.

The publication of XML was followed by the publication of a second

Debar, et al. Expires July 31, 2005 [Page 10]
Internet-Draft The IDMEF January 2005

recommendation [4] 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) [5]. When
using namespaces, each tag is identified with the namespace it comes
from, allowing tags from different namespaces with the same names to
occur in the same document. For example, a single document could
contain both "usa:football" and "europe:football" tags, each with
different meanings.

In anticipation of the widespread use of XML namespaces, this memo
includes the definition of the URI to be used to identify the IDMEF
namespace.

3.2.2 Rationale for Implementing IDMEF in XML

XML-based applications are being used or developed for a wide variety
of purposes, 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
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:

o 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).
o Software tools for processing XML documents are widely available,
in both commercial and open source forms. Numerous 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.
o XML meets IDMEF Requirement 5.1 [2], that message formats support
full internationalization and localization. The XML standard
requires support for both the UTF-8 and UTF-16 encodings of
ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set,
"UCS") and Unicode, making all XML applications (and therefore all
IDMEF-compliant applications) compatible with these common
character encodings.

Debar, et al. Expires July 31, 2005 [Page 11]
Internet-Draft The IDMEF January 2005

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.
o XML meets IDMEF Requirement 5.2 [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.
o 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.
o XML is free, with no license, no license fees, and no royalties.

Debar, et al. Expires July 31, 2005 [Page 12]
Internet-Draft The IDMEF January 2005

4. Notational Conventions and Formatting Issues

This document uses three notations: Unified Modeling Language to
describe the data model, XML to describe the markup used in IDMEF
documents, and IDMEF markup to represent the documents themselves.

Appendix A describes these notations in sufficient detail that
readers unfamiliar with them can understand the document. Note,
however, that these descriptions are not comprehensive; they only
cover the components of the notations used by the data model and
document format.

Appendix A also explains several document formatting issues that
apply to XML documents, including formats for particular data types,
special character and whitespace processing, character sets, and
languages.

4.1 IDMEF XML Documents

This section describes IDMEF XML document formatting rules. Most of
these rules are "inherited" from the rules for formatting XML
documents; see Appendix A for more detail.

4.1.1 The Document Prolog

The format of an IDMEF XML document prolog is described in the
following sections.

4.1.1.1 XML Declaration

IDMEF documents being exchanged between IDMEF-compliant applications
MUST begin with an XML declaration, and MUST specify the XML version
in use. Specification of the encoding in use is RECOMMENDED.

IDMEF-compliant 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.1.2 IDMEF DTD Formal Public Identifier

The formal public identifier (FPI) for the IDMEF Document Type
Definition described in this memo is:

"-//IETF//DTD RFC XXXX IDMEF v1.0//EN"

This FPI MUST be used in the document type declaration within an XML

Debar, et al. Expires July 31, 2005 [Page 13]
Internet-Draft The IDMEF January 2005

document referencing the IDMEF DTD defined by this memo, as shown in
the following section.

4.1.1.3 IDMEF DTD Document Type Declaration

The document type declaration for an XML document referencing the
IDMEF DTD defined by this memo will usually be specified in one of
the following ways:

br /> "-//IETF//DTD RFC XXXX IDMEF v1.0//EN">

The last component of the document type declaration is the formal
public identifier (FPI) specified in the previous section.

br /> "/some/path/to/the/idmef-message.dtd">

The last component of the document type declaration is a URI that
points to a copy of the Document Type Definition.

In order to be valid (see Section 7.1), an XML document must contain
a document type declaration. However, this represents significant
overhead to an IDMEF-compliant application, both in the bandwidth it
consumes as well as the requirements it places on the XML processor
(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 to exchange messages (the standard one as defined here,
or one with extensions), and then omit the document type declaration
from IDMEF messages. The method for negotiating this agreement is
outside the scope of this document. Note that great care must be
taken in negotiating any such agreements, as the manager may have to
accept messages from many different analyzers, each using a DTD with
a different set of extensions.

4.1.2 Character Data Processing in IDMEF

For portability reasons, IDMEF-compliant applications SHOULD NOT use,
and IDMEF messages SHOULD NOT be encoded in, character encodings
other than UTF-8 and UTF-16. Consistent with the XML standard, if no
encoding is specified for an IDMEF message, UTF-8 is assumed.

Debar, et al. Expires July 31, 2005 [Page 14]
Internet-Draft The IDMEF January 2005

NOTE: The ASCII character set is a subset of the UTF-8 encoding, and
therefore 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.1.2.1 Character Entity References

It is RECOMMENDED that IDMEF-compliant applications use the entity
reference form (see A.3.2.1) of the characters '&', ,'', '"',
and ''' (single-quote) whenever writing these characters in data, to
avoid any possibility of misinterpretation.

4.1.2.2 White Space Processing

All IDMEF elements MUST support the "xml:space" attribute.

4.1.3 Languages in IDMEF

IDMEF-compliant applications MUST 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 element and letting all other
elements "inherit" that definition.

4.2 IDMEF Data Types

Within an XML IDMEF message, all data will be expressed as "text" (as
opposed to "binary"), since XML is a text formatting language. We
provide typing information for the attributes of the classes in the
data model however, to convey to the reader the type of data the
model expects for each attribute.

Each data type in the model has specific formatting requirements in
an XML IDMEF message; these requirements are set forth in this
section.

4.2.1 Integers

Integer attributes are represented by the INTEGER data type. Integer
data MUST be encoded in Base 10 or Base 16.

Base 10 integer encoding uses the digits '0' through '9' and an
optional sign ('+' or '-'). For example, "123", "-456".

Base 16 integer encoding uses the digits '0' through '9' and 'a'
through 'f' (or their upper case equivalents), and is preceded by the

Debar, et al. Expires July 31, 2005 [Page 15]
Internet-Draft The IDMEF January 2005

characters "0x". For example, "0x1a2b".

4.2.2 Real Numbers

Real (floating-point) attributes are represented by the REAL data
type. Real data MUST be encoded in Base 10.

Real encoding is that of the POSIX 1003.1 "strtod" library function:
an optional sign ('+' or '-') followed by a non-empty string of
decimal digits, optionally containing a radix character, then an
optional exponent part. An exponent part consists of an 'e' or 'E',
followed by an optional sign, followed by one or more decimal digits.
For example, "123.45e02", "-567,89e-03".

IDMEF-compliant applications MUST support both the '.' and ',' radix
characters.

4.2.3 Characters and Strings

Single-character attributes are represented by the CHARACTER data
type. Multi-character attributes of known length are represented by
the STRING data type.

Character and string data have no special formatting requirements,
other than the need to occasionally use character references (see
Appendix C.3.2.1 and Appendix C.3.2.2) to represent special
characters.

4.2.4 Bytes

Binary data is represented by the BYTE (and BYTE[]) data type.

Binary data MUST be encoded in its entirety using base64.

4.2.5 Enumerated Types

Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values.

4.2.6 Date-Time Strings

Date-time strings are represented by the DATETIME data type. Each
date-time string identifies a particular instant in time; ranges are
not supported.

Date-time strings are formatted according to a subset of ISO
8601:2000 [6], as show below. Section references in parentheses
refer to sections of the ISO 8601:2000 standard.

Debar, et al. Expires July 31, 2005 [Page 16]
Internet-Draft The IDMEF January 2005

1. Dates MUST be formatted as follows:
YYYY-MM-DD
where YYYY is the four- digit year, MM is the two-digit month
(01-12), and DD is the two- digit day (01-31). (Section 5.2.1.1,
"Complete representation -- Extended format.")
2. Times MUST be formatted as follows:
hh:mm:ss
where hh is the two-digit hour (00-24), mm is the two-digit
minute (00-59), and ss is the two-digit second (00-60). (Section
5.3.1.1, "Complete representation -- Extended format.")

Note that midnight has two representations, 00:00:00 and
24:00:00. Both representations MUST be supported by
IDMEF-compliant applications, however, the 00:00:00
representation SHOULD be used whenever possible.

Note also that this format accounts for leap seconds. Positive
leap seconds are inserted between 23:59:59Z and 24:00:00Z and are
represented as 23:59:60Z. Negative leap seconds are achieved by
the omission of 23:59:59Z. IDMEF-compliant applications MUST
support leap seconds.
3. Times MAY be formatted to include a decimal fraction of seconds,
as follows:
hh:mm:ss.ss or
hh:mm:ss,ss
As many digits as necessary may follow the decimal sign (at least
one digit must follow the decimal sign). Decimal fractions of
hours and minutes are not supported. (Section 5.3.1.3,
"Representation of decimal fractions.")

IDMEF-compliant applications MUST support the use of both decimal
signs ('.' and ',').

Note that the number of digits in the fraction part does not
imply anything about accuracy -- i.e., "00.100000", "00,1000" and
"00.1" are all equivalent.
4. Times MUST be formatted to include (a) an indication that the
time is in Coordinated Universal Time (UTC), or (b) an indication
of the difference between the specified time and Coordinated
Universal Time.
* Times in UTC MUST be formatted by appending the letter 'Z' to
the time string as follows:
hh:mm:ssZ
hh:mm:ss.ssZ
hh:mm:ss,ssZ
(Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended
format.")

Debar, et al. Expires July 31, 2005 [Page 17]
Internet-Draft The IDMEF January 2005

* If the time is ahead of or equal to UTC, a '+' sign is
appended to the time string; if the time is behind UTC, a '-'
sign is appended. Following the sign, the number of hours and
minutes representing the different from UTC is appended, as
follows:
hh:mm:ss+hh:mm
hh:mm:ss-hh:mm
hh:mm:ss.ss+hh:mm
hh:mm:ss.ss-hh:mm
hh:mm:ss,ss+hh:mm
hh:mm:ss,ss-hh:mm
The difference from UTC MUST be specified in both hours and
minutes, even if the minutes component is 0. A "difference"
of "+00:00" is equivalent to UTC. (Section 5.3.4.2, "Local
time and the difference with Coordinated Universal Time --
Extended Format.")
5. Date-time strings are created by joining the date and time
strings with the letter 'T', as shown below:
YYYY-MM-DDThh:mm:ssZ
YYYY-MM-DDThh:mm:ss.ssZ
YYYY-MM-DDThh:mm:ss,ssZ
YYYY-MM-DDThh:mm:ss+hh:mm
YYYY-MM-DDThh:mm:ss-hh:mm
YYYY-MM-DDThh:mm:ss.ss+hh:mm
YYYY-MM-DDThh:mm:ss.ss-hh:mm
YYYY-MM-DDThh:mm:ss,ss+hh:mm
YYYY-MM-DDThh:mm:ss,ss-hh:mm
(Section 5.4.1, "Complete representation -- Extended format.")

In summary, IDMEF date-time strings MUST adhere to one of the nine
templates identified in Paragraph 5, above.

4.2.7 NTP Timestamps

NTP timestamps are represented by the NTPSTAMP data type, and are
described in detail in [7] and [8]. An NTP timestamp is a 64-bit
unsigned fixed-point number. The integer part is in the first 32
bits, and the fraction part is in the last 32 bits.

Within IDMEF messages, NTP timestamps MUST be encoded as two 32-bit
hexadecimal values, separated by a period ('.'). For example,
"0x12345678.0x87654321".

See also Section 7.4 for more information on NTP timestamps.

4.2.8 Port Lists

Port lists are represented by the PORTLIST data type, and consist of

Debar, et al. Expires July 31, 2005 [Page 18]
Internet-Draft The IDMEF January 2005

a comma-separated list of numbers (individual integers) and ranges
(N-M means ports N through M, inclusive). Any combination of numbers
and ranges may be used in a single list. For example,
"5-25,37,42,43,53,69-119,123-514".

4.2.9 Unique Identifiers

There are two types of unique identifiers used in this specification.
Both types are represented by STRING data types.

These identifiers are implemented as attributes on the relevant XML
elements, and must have unique values as follows:

1. The Analyzer class' (Section 5.2.4.1) "analyzerid" attribute, if
specified, MUST have a value that is unique across all analyzers
in the intrusion detection environment.

The "analyzerid" attribute is not required to be globally unique,
only unique within the intrusion detection environment of which
the analyzer is a member. It is permissible for two analyzers,
in different intrusion detection environments, to have the same
value for "analyzerid".

The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.
2. The Alert and Heartbeat messages (Section 5.2.2, Section 5.2.3)
must be uniquely identified by the couple (analyzerid,messageid),
if the analyzer supports the generation of message identifiers.
3. The Source, Target, Node, User, Process, Service, File, Address,
and UserId classes' (Section 5.2.4.4, Section 5.2.4.5,
Section 5.2.7.1, Section 5.2.7.2, Section 5.2.7.3,
Section 5.2.7.4, Section 5.2.7.5, Section 5.2.7.1.1, and
Section 5.2.7.2.1) "ident" attribute, if specified, MUST have a
value that is unique across all messages sent by the individual
analyzer.

The "ident" attribute value MUST be unique for each particular
combination of data identifying an object, not for each object.
Objects may have more than one "ident" value associated with
them. For example, an identification of a host by name would
have one value, while an identification of that host by address
would have another value, and an identification of that host by
both name and address would have still another value.
Furthermore, different analyzers may produce different values for
the same information.

The "ident" attribute by itself provides a unique identifier only
among all the "ident" values sent by a particular analyzer. But

Debar, et al. Expires July 31, 2005 [Page 19]
Internet-Draft The IDMEF January 2005

when combined with the "analyzerid" value for the analyzer, a
value that is unique across the intrusion detection environment
is created. Again, there is no requirement for global
uniqueness.

The default value is "0", which indicates that the analyzer
cannot generate unique identifiers.

The specification of methods for creating the unique values contained
in these attributes is outside the scope of this document.

Debar, et al. Expires July 31, 2005 [Page 20]
Internet-Draft The IDMEF January 2005

5. The IDMEF Data Model and XML DTD

In this section, the individual components of the IDMEF data model
are explained in detail. UML diagrams of the model are provided to
show how the components are related to each other, and relevant
sections of the XML DTD are presented to show how the model is
translated into XML.

5.1 Data Model Overview

The relationship between the principal components of the data model
is shown in Figure 1 (occurrence indicators and attributes are
omitted).

The top-level class for all IDMEF messages is IDMEF-Message; each
type of message is a subclass of this top-level class. There are
presently two types of messages defined; Alerts and Heartbeats.
Within each message, subclasses of the message class are used to
provide the detailed information carried in the message.

It is important to note that the data model does not specify how an
alert should be classified or identified. For example, a port scan
may be identified by one analyzer as a single attack against multiple
targets, while another analyzer might identify it as multiple attacks
from a single source. However, once an analyzer has determined the
type of alert it plans to send, the data model dictates how that
alert should be formatted.

+---------------+
| IDMEF-Message |
+---------------+
/_
|
+--------------------+-------------+
| |
+-------+ +--------------+ +-----------+ +----------------+
| Alert |<>-| Analyzer | | Heartbeat |<>-| Analyzer |
+-------+ +--------------+ +-----------+ +----------------+
| | +--------------+ | | +----------------+
| |<>-| CreateTime | | |<>-| CreateTime |
| | +--------------+ | | +----------------+
| | +--------------+ | | +----------------+
| |<>-| DetectTime | | |<>-| AdditionalData |
| | +--------------+ +-----------+ +----------------+
| | +--------------+
| |<>-| AnalyzerTime |
| | +--------------+
| | +--------+ +----------+

Debar, et al. Expires July 31, 2005 [Page 21]
Internet-Draft The IDMEF January 2005

| |<>-| Source |<>-| Node |
| | +--------+ +----------+
| | | | +----------+
| | | |<>-| User |
| | | | +----------+
| | | | +----------+
| | | |<>-| Process |
| | | | +----------+
| | | | +----------+
| | | |<>-| Service |
| | +--------+ +----------+
| | +--------+ +----------+
| |<>-| Target |<>-| Node |
| | +--------+ +----------+
| | | | +----------+
| | | |<>-| User |
| | | | +----------+
| | | | +----------+
| | | |<>-| Process |
| | | | +----------+
| | | | +----------+
| | | |<>-| Service | +----------------+
| | | | +----------+ +----| Classification |
| | | | +----------+ | +----------------+
| | | |<>-| File | | +----------------+
| | +--------+ +----------+ | +--| Assessment |
| |<>----------------------------+ | +----------------+
| |<>------------------------------+ +----------------+
| |<>---------------------------------| AdditionalData |
+-------+ +----------------+

Figure 1: Data model overview

5.2 The Message Classes

The individual classes are described in the following sections.

5.2.1 The IDMEF-Message Class

All IDMEF messages are instances of the IDMEF-Message class; it is
the top-level class of the IDMEF data model, as well as the IDMEF
DTD. There are currently two types (subclasses) of IDMEF-Message:
Alert and Heartbeat.

Debar, et al. Expires July 31, 2005 [Page 22]
Internet-Draft The IDMEF January 2005

Because DTDs do not support subclassing, the inheritance relationship
between IDMEF-Message and the Alert and Heartbeat subclasses shown in
Figure 1 has been replaced with an aggregate relationship. This is
declared in the IDMEF DTD as follows:

version CDATA #FIXED '1.0'
">
(Alert | Heartbeat)*
)>
%attlist.idmef;
>

The IDMEF-Message class has a single attribute:

version
The version of the IDMEF-Message specification (this document)
this message conforms to. Applications specifying a value for
this attribute MUST specify the value "1.0".

5.2.2 The Alert Class

Generally, every time an analyzer detects an event that it has been
configured to look for, it sends an Alert message to its manager(s).
Depending on the analyzer, an Alert message may correspond to a
single detected event, or multiple detected events. Alerts occur
asynchronously in response to outside events.

An Alert message is composed of several aggregate classes, as shown
in Figure 3. The aggregate classes themselves are described in
Section 5.2.4, Section 5.2.5, and Section 5.2.6.

+-------------------+
| Alert |
+-------------------+ +------------------+
| STRING messageid |<>----------| Analyzer |
| | +------------------+
| | +------------------+
| |<>----------| CreateTime |
| | +------------------+
| | +------------------+
| |<>----------| Classification |
| | +------------------+
| | 0..1 +------------------+
| |<>----------| DetectTime |
| | +------------------+

Debar, et al. Expires July 31, 2005 [Page 23]
Internet-Draft The IDMEF January 2005

| | 0..1 +------------------+
| |<>----------| AnalyzerTime |
| | +------------------+
| | 0..* +------------------+
| |<>----------| Source |
| | +------------------+
| | 0..* +------------------+
| |<>----------| Target |
| | +------------------+
| | 0..1 +------------------+
| |<>----------| Assessment |
| | +------------------+
| | 0..* +------------------+
| |<>----------| AdditionalData |
| | +------------------+
+-------------------+
/_
|
+----+------------+-------------+
| | |
+-------------------+ | +-------------------+
| ToolAlert | | | CorrelationAlert |
+-------------------+ | +-------------------+
|
+-------------------+
| OverflowAlert |
+-------------------+

Figure 3: The Alert Class

The aggregate classes that make up Alert are:

Analyzer
Exactly one. Identification information for the analyzer that
originated the alert.
CreateTime
Exactly one. The time the alert was created. Of the three times
that may be provided with an Alert, this is the only one that is
required.
Classification
Exactly one. The "name" of the alert, or other information
allowing the manager to determine what it is.
DetectTime
Zero or one. The time the event(s) leading up to the alert was
detected. In the case of more than one event, the time the first
event was detected. In some circumstances, this may not be the
same value as CreateTime.

Debar, et al. Expires July 31, 2005 [Page 24]
Internet-Draft The IDMEF January 2005

AnalyzerTime
Zero or one. The current time on the analyzer (see Section 7.3).
Source
Zero or more. The source(s) of the event(s) leading up to the
alert.
Target
Zero or more. The target(s) of the event(s) leading up to the
alert.
Assessment
Zero or one. Information about the impact of the event, actions
taken by the analyzer in response to it, and the analyzer's
confidence in its evaluation.
AdditionalData
Zero or more. Information included by the analyzer that does not
fit into the data model. This may be an atomic piece of data, or
a large amount of data provided through an extension to the IDMEF
(see Section 6).

Because DTDs do not support subclassing, the inheritance relationship
between Alert and the ToolAlert, CorrelationAlert, and OverflowAlert
subclasses shown in Figure 3 has been replaced with an aggregate
relationship.

Alert is represented in the XML DTD as follows:

Analyzer, CreateTime, DetectTime?, AnalyzerTime?,
Source*, Target*, Classification, Assessment?, (ToolAlert |
OverflowAlert | CorrelationAlert)?, AdditionalData*
)>
messageid CDATA '0'
>

The Alert class has one attribute:

messageid
Optional. A unique identifier for the alert, see Section 4.2.9.

5.2.2.1 The ToolAlert Class

The ToolAlert class carries additional information related to the use
of attack tools or malevolent programs such as Trojan horses, and can
be used by the analyzer when it is able to identify these tools. It
is intended to group one or more previously-sent alerts together, to
say "these alerts were all the result of someone using this tool."

The ToolAlert class is composed of three aggregate classes, as shown

Debar, et al. Expires July 31, 2005 [Page 25]
Internet-Draft The IDMEF January 2005

in Figure 5.

+------------------+
| Alert |
+------------------+
/_
|
+------------------+
| ToolAlert |
+------------------+ +-------------------+
| |<>----------| name |
| | +-------------------+
| | 0..1 +-------------------+
| |<>----------| command |
| | +-------------------+
| | 1..* +-------------------+
| |<>----------| alertident |
| | +-------------------+
| | | STRING analyzerid |
| | +-------------------+
+------------------+

Figure 5: The ToolAlert Class

The aggregate classes that make up ToolAlert are:

name
Exactly one. STRING. The reason for grouping the alerts
together, for example, the name of a particular tool.
command
Zero or one. STRING. The command or operation that the tool was
asked to perform, for example, a BackOrifice ping.
alertident
One or more. STRING. The list of alert identifiers that are
related to this alert. Because alert identifiers are only unique
across the alerts sent by a single analyzer, the optional
"analyzerid" attribute of "alertident" should be used to identify
the analyzer that a particular alert came from. If the
"analyzerid" is not provided, the alert is assumed to have come
from the same analyzer that is sending the ToolAlert.

Debar, et al. Expires July 31, 2005 [Page 26]
Internet-Draft The IDMEF January 2005

This is represented in the XML DTD as follows:

name, command?, alertident+
)>

analyzerid CDATA #IMPLIED
>

5.2.2.2 The CorrelationAlert Class

The CorrelationAlert class carries additional information related to
the correlation of alert information. It is intended to group one or
more previously-sent alerts together, to say "these alerts are all
related."

The CorrelationAlert class is composed of two aggregate classes, as
shown in Figure 7.

+------------------+
| Alert |
+------------------+
/_
|
+------------------+
| CorrelationAlert |
+------------------+ +-------------------+
| |<>----------| name |
| | +-------------------+
| | 1..* +-------------------+
| |<>----------| alertident |
| | +-------------------+
| | | STRING analyzerid |
| | +-------------------+
+------------------+

Figure 7: The CorrelationAlert Class

The aggregate classes that make up CorrelationAlert are:

name
Exactly one. STRING. The reason for grouping the alerts
together, for example, a partic

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/83980/viewspace-801757/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/83980/viewspace-801757/