| TOC |
|
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.
Copyright (C) The Internet Society (2005).
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.
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.
1.
Status of memo
2.
Notices and conventions Used in This Document
3.
Introduction
3.1
About the IDMEF Data Model
3.1.1
Problems Addressed by the Data Model
3.1.2
Data Model Design Goals
3.2
About the IDMEF XML Implementation
3.2.1
The Extensible Markup Language
3.2.2
Rationale for Implementing IDMEF in XML
4.
Notational Conventions and Formatting Issues
4.1
IDMEF XML Documents
4.1.1
The Document Prolog
4.1.2
Character Data Processing in IDMEF
4.1.3
Languages in IDMEF
4.2
IDMEF Data Types
4.2.1
Integers
4.2.2
Real Numbers
4.2.3
Characters and Strings
4.2.4
Bytes
4.2.5
Enumerated Types
4.2.6
Date-Time Strings
4.2.7
NTP Timestamps
4.2.8
Port Lists
4.2.9
Unique Identifiers
5.
The IDMEF Data Model and XML DTD
5.1
Data Model Overview
5.2
The Message Classes
5.2.1
The IDMEF-Message Class
5.2.2
The Alert Class
5.2.3
The Heartbeat Class
5.2.4
The Core Classes
5.2.5
The Time Classes
5.2.6
The Assessment Classes
5.2.7
The Support Classes
6.
Extending the IDMEF
6.1
Extending the Data Model
6.2
Extending the XML DTD or schema
7.
Special Considerations
7.1
XML Validity and Well-Formedness
7.2
Unrecognized XML Tags
7.3
Analyzer-Manager Time Synchronization
7.4
NTP Timestamp Wrap-Around
7.5
Digital Signatures
8.
Examples
8.1
Denial of Service Attacks
8.1.1
The "teardrop" Attack
8.1.2
The "ping of death" Attack
8.2
Port Scanning Attacks
8.2.1
Connection To a Disallowed Service
8.2.2
Simple Port Scanning
8.3
Local Attacks
8.3.1
The "loadmodule" Attack
8.3.2
The "phf" Attack
8.3.3
File Modification
8.4
System Policy Violation
8.5
Correlated Alerts
8.6
Analyzer Assessments
8.7
Heartbeat
8.8
XML Extension
9.
The IDMEF Document Type Definition (Non-normative)
10.
The IDMEF Schema Definition (Normative)
11.
Security Considerations
12.
IANA Considerations
12.1
Adding Values to Existing Attributes
12.1.1
Attribute Registrations
12.1.2
Registration Template
12.2
Adding New Attributes and Classes
13.
References
13.1
Normative References
13.2
Informational References
§
Authors' Addresses
A.
History of Significant Changes
A.1
Things to do before publication
A.2
Response to IESG comments
A.2.1
Comment on Section 3.1.3
A.2.2
Comment on Section A.3.4
A.2.3
Comment on Section 3.2
A.2.4
Comment on section 3.2.4
A.2.5
Comment on 3.2.5 Enumerated Types
A.2.6
Comment on Section 4.*
A.2.7
Comment on Section 5
A.2.8
Comment on Section 7.8
A.3
Significant Changes Since idmef-10
B.
Acknowledgements
C.
An Overview of UML and XML as Used in This Document
C.1
Unified Modeling Language
C.1.1
Relationships
C.1.2
Occurrence Indicators
C.2
XML Document Type Definitions
C.2.1
Element Declarations
C.2.2
Attribute Declarations
C.2.3
Entity Declarations
C.3
XML Documents
C.3.1
The Document Prolog
C.3.2
Character Data Processing in XML
C.3.3
Languages in XML
§
Intellectual Property and Copyright Statements
| TOC |
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.
| TOC |
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 2119Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997.[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."
| TOC |
The Intrusion Detection Message Exchange Format (IDMEF)Wood, M. and M. Erlinger, Intrusion Detection Mesage Exchange Requirements, October 2002.[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:
The diversity of uses for the IDMEF needs to be considered when selecting its method of implementation.
The IDMEF data model is an object-oriented representation of the alert data sent to intrusion detection managers by intrusion detection analyzers.
The data model addresses several problems associated with representing intrusion detection alert data:
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.
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.
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.
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.
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.
The Extensible Markup Language (XML)Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler, Extensible Markup Language (XML) 1.0 (Second Edition), October 2000.[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 >') 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.
- 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 recommendation [4]Hollander, D., Bray, T. and A. Layman, Namespaces in XML, January 1999. 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)Berners-Lee, T., Fielding, R. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, August 1998.[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.
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:
| TOC |
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.
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.
The format of an IDMEF XML document prolog is described in the following sections.
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.
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 document referencing the IDMEF DTD defined by this memo, as shown in the following section.
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:
<!DOCTYPE IDMEF-Message PUBLIC
"-//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.
<!DOCTYPE IDMEF-Message SYSTEM
"/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.1XML Validity and Well-Formedness), 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.
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.
- 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).
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.
All IDMEF elements MUST support the "xml:space" attribute.
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.
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.
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 characters "0x". For example, "0x1a2b".
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.
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.1Character Entity References and Appendix C.3.2.2Character Code References) to represent special characters.
Binary data is represented by the BYTE (and BYTE[]) data type.
Binary data MUST be encoded in its entirety using base64.
Enumerated types are represented by the ENUM data type, and consist of an ordered list of acceptable values.
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]International Organization for Standardization, Data elements and interchange formats - Information interchange - Representation of dates and times, December 2000., as show below. Section references in parentheses refer to sections of the ISO 8601:2000 standard.
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.")
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.
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.
hh:mm:ssZ
hh:mm:ss.ssZ
hh:mm:ss,ssZ
(Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended format.")
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.")
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.
NTP timestamps are represented by the NTPSTAMP data type, and are described in detail in [7]Mills, D., Network Time Protocol (Version 3) Specification, Implementation, March 1992. and [8]Mills, D., Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, October 1996.. 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.4NTP Timestamp Wrap-Around for more information on NTP timestamps.
Port lists are represented by the PORTLIST data type, and consist of 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".
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:
The specification of methods for creating the unique values contained in these attributes is outside the scope of this document.
| TOC |
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.
The relationship between the principal components of the data model is shown in Figure 1Data model overview (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 |
| | +--------------+
| | +--------+ +----------+
| |<>-| Source |<>-| Node |
| | +--------+ +----------+
| | | | +----------+
| | | |<>-| User |
| | | | +----------+
| | | | +----------+
| | | |<>-| Process |
| | | | +----------+
| | | | +----------+
| | | |<>-| Service |
| | +--------+ +----------+
| | +--------+ +----------+
| |<>-| Target |<>-| Node |
| | +--------+ +----------+
| | | | +----------+
| | | |<>-| User |
| | | | +----------+
| | | | +----------+
| | | |<>-| Process |
| | | | +----------+
| | | | +----------+
| | | |<>-| Service | +----------------+
| | | | +----------+ +----| Classification |
| | | | +----------+ | +----------------+
| | | |<>-| File | | +----------------+
| | +--------+ +----------+ | +--| Assessment |
| |<>----------------------------+ | +----------------+
| |<>------------------------------+ +----------------+
| |<>---------------------------------| AdditionalData |
+-------+ +----------------+
| Figure 1: Data model overview |
The individual classes are described in the following sections.
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.
Because DTDs do not support subclassing, the inheritance relationship between IDMEF-Message and the Alert and Heartbeat subclasses shown in Figure 1Data model overview has been replaced with an aggregate relationship. This is declared in the IDMEF DTD as follows:
<!ENTITY % attlist.idmef "
version CDATA #FIXED '1.0'
">
<!ELEMENT IDMEF-Message (
(Alert | Heartbeat)*
)>
<!ATTLIST IDMEF-Message
%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".
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 3The Alert Class. The aggregate classes themselves are described in Section 5.2.4The Core Classes, Section 5.2.5The Time Classes, and Section 5.2.6The Assessment Classes.
+-------------------+
| Alert |
+-------------------+ +------------------+
| STRING messageid |<>----------| Analyzer |
| | +------------------+
| | +------------------+
| |<>----------| CreateTime |
| | +------------------+
| | +------------------+
| |<>----------| Classification |
| | +------------------+
| | 0..1 +------------------+
| |<>----------| DetectTime |
| | +------------------+
| | 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.
- AnalyzerTime
- Zero or one. The current time on the analyzer (see Section 7.3Analyzer-Manager Time Synchronization).
- 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 6Extending the IDMEF).
Because DTDs do not support subclassing, the inheritance relationship between Alert and the ToolAlert, CorrelationAlert, and OverflowAlert subclasses shown in Figure 3The Alert Class has been replaced with an aggregate relationship.
Alert is represented in the XML DTD as follows:
<!ELEMENT Alert (
Analyzer, CreateTime, DetectTime?, AnalyzerTime?,
Source*, Target*, Classification, Assessment?, (ToolAlert |
OverflowAlert | CorrelationAlert)?, AdditionalData*
)>
<!ATTLIST Alert
messageid CDATA '0'
>
The Alert class has one attribute:
- messageid
- Optional. A unique identifier for the alert, see Section 4.2.9Unique Identifiers.
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 in Figure 5The ToolAlert Class.
+------------------+
| 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.
This is represented in the XML DTD as follows:
<!ELEMENT ToolAlert (
name, command?, alertident+
)>
<!ELEMENT alertident (#PCDATA) >
<!ATTLIST alertident
analyzerid CDATA #IMPLIED
>
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 7The CorrelationAlert Class.
+------------------+
| 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 particular correlation method.
- 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 CorrelationAlert.
This is represented in the XML DTD as follows.
<!ELEMENT CorrelationAlert (
name, alertident+
)>
<!ELEMENT alertident (#PCDATA) >
<!ATTLIST alertident
analyzerid CDATA #IMPLIED
>
The OverflowAlert carries additional information related to buffer overflow attacks. It is intended to enable an analyzer to provide the details of the overflow attack itself.
The OverflowAlert class is composed of three aggregate classes, as shown in Figure 9The OverflowAlert Class.
+------------------+
| Alert |
+------------------+
/_\
|
+------------------+
| OverflowAlert |
+------------------+ +---------+
| |<>----------| program |
| | +---------+
| | 0..1 +---------+
| |<>----------| size |
| | +---------+
| | 0..1 +---------+
| |<>----------| buffer |
| | +---------+
+------------------+
| Figure 9: The OverflowAlert Class |
The aggregate classes that make up OverflowAlert are:
- program
- Exactly one. STRING. The program that the overflow attack attempted to run (note: this is not the program that was attacked).
- size
- Zero or one. INTEGER. The size, in bytes, of the overflow (i.e., the number of bytes the attacker sent).
- buffer
- Zero or one. BYTE[]. Some or all of the overflow data itself (dependent on how much the analyzer can capture).
This is represented in the XML DTD as follows:
<!ELEMENT OverflowAlert (
program, size?, buffer?
)>
Analyzers use Heartbeat messages to indicate their current status to managers. Heartbeats are intended to be sent in a regular period, say every ten minutes or every hour. The receipt of a Heartbeat message from an analyzer indicates to the manager that the analyzer is up and running; lack of a Heartbeat message (or more likely, lack of some number of consecutive Heartbeat messages) indicates that the analyzer or its network connection has failed.
All managers MUST support the receipt of Heartbeat messages; however, the use of these messages by analyzers is OPTIONAL. Developers of manager software SHOULD permit the software to be configured on a per-analyzer basis to use/not use Heartbeat messages.
A Heartbeat message is composed of several aggregate classes, as shown in Figure 11The Heartbeat Class. The aggregate classes themselves are described in Section 5.2.4The Core Classes and Section 5.2.5The Time Classes.
+------------------+
| Heartbeat |
+------------------+ +------------------+
| STRING messageid |<>----------| Analyzer |
| | +------------------+
| | +------------------+
| |<>----------| CreateTime |
| | +------------------+
| | 0..1 +------------------+
| |<>----------| HeartbeatInterval|
| | +------------------+
| | 0..1 +------------------+
| |<>----------| AnalyzerTime |
| | +------------------+
| | 0..* +------------------+
| |<>----------| AdditionalData |
| | +------------------+
+------------------+
| Figure 11: The Heartbeat Class |
The aggregate classes that make up Heartbeat are:
- Analyzer
- Exactly one. Identification information for the analyzer that originated the heartbeat.
- CreateTime
- Exactly one. The time the heartbeat was created.
- AnalyzerTime
- Zero or one. The current time on the analyzer (see Section 7.3Analyzer-Manager Time Synchronization).
- HeartbeatInterval
- Zero or one. The interval in seconds at which heartbeats are generated.
- 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 6Extending the IDMEF).
This is represented in the XML DTD as follows:
<!ELEMENT Heartbeat (
Analyzer, CreateTime, HeartbeatInterval?, AnalyzerTime?,
AdditionalData*
)>
<!ATTLIST Heartbeat
messageid CDATA '0'
>
The Heartbeat class has one attribute:
- messageid
- Optional. A unique identifier for the heartbeat, see Section 4.2.9Unique Identifiers.
The core classes -- Analyzer, Source, Target, Classification, and AdditionalData -- are the main parts of Alerts and Heartbeats, as shown in Figure 13The Core Classes.
+-----------+ +----------------+
| Heartbeat | +-------| Analyzer |
+-----------+ | +----------------+
| |<>---+--+
+-----------+ | | 0..* +----------------+
| +-------| AdditionalData |
| +----------------+
+-----------+ |
| Alert | | 0..* +----------------+
+-----------+ | +-------| Source |
| |<>---+ | +----------------+
| | | 0..* +----------------+
| | +-------| Target |
| | | +----------------+
| |<>------+
+-----------+ | +----------------+
+-------| Classification |
+----------------+
| Figure 13: The Core Classes |
The Analyzer class identifies the analyzer from which the alert or heartbeat message originates. Only one analyzer may be encoded for each alert or heartbeat, and that MUST be the analyzer at which the alert or heartbeat originated. Although the IDMEF data model does not prevent the use of hierarchical intrusion detection systems (where alerts get relayed up the tree), it does not provide any way to record the identity of the "relay" analyzers along the path from the originating analyzer to the manager that ultimately receives the alert.
The Analyzer class is composed of three aggregate classes, as shown in Figure 14The Analyzer Class.
+---------------------+
| Analyzer |
+---------------------+ 0..1 +----------+
| STRING analyzerid |<>----------| Node |
| STRING name | +----------+
| STRING manufacturer |
| STRING model | 0..1 +----------+
| STRING version |<>----------| Process |
| STRING class | +----------+
| STRING ostype | 0..1 +----------+
| STRING osversion |<>----------| Analyzer |
+---------------------+ +----------+
| Figure 14: The Analyzer Class |
The aggregate classes that make up Analyzer are:
- Node
- Zero or one. Information about the host or device on which the analyzer resides (network address, network name, etc.).
- Process
- Zero or one. Information about the process in which the analyzer is executing.
- Analyzer
- Zero or one. Information about the analyzer from which the message may have gone through. The idea behind this mechanism is that when a manager receives an alert and want to forward it to another manalyzer, it needs to substitute the original analyzer information with its own. To preserve the original analyzer information, it may be included in the new analyzer definition. This will allow analyzer path tracking.
This is represented in the XML DTD as follows:
<!ELEMENT Analyzer (
Node?, Process?, Analyzer?
)>
<!ATTLIST Analyzer
analyzerid CDATA '0'
name CDATA #IMPLIED
manufacturer CDATA #IMPLIED
model CDATA #IMPLIED
version CDATA #IMPLIED
class CDATA #IMPLIED
ostype CDATA #IMPLIED
osversion CDATA #IMPLIED
>
The Analyzer class has eight attributes:
- analyzerid
- Optional (but see below). A unique identifier for the analyzer, see Section 4.2.9Unique Identifiers.
- This attribute is only "partially" optional. If the analyzer makes use of the "ident" attributes on other classes to provide unique identifiers for those objects, then it MUST also provide a valid "analyzerid" attribute. This requirement is dictated by the uniqueness requirements of the "ident" attribute (they are unique only within the context of a particular "analyzerid"). If the analyzer does not make use of the "ident" attributes however, it may also omit the "analyzerid" attribute.
- name
- Optional. An explicit name for the analyzer, that may be easier to understand that the analyzerid.
- manufacturer
- Optional. The manufacturer of the analyzer software and/or hardware.
- model
- Optional. The model name/number of the analyzer software and/or hardware.
- version
- Optional. The version number of the analyzer software and/or hardware.
- class
- Optional. The class of analyzer software and/or hardware.
- ostype
- Optional. Operating system name. On POSIX 1003.1 compliant systems, this is the value returned in utsname.sysname by the uname() system call, or the output of the "uname -s" command.
- osversion
- Optional. Operating system version. On POSIX 1003.1 compliant systems, this is the value returned in utsname.release by the uname() system call, or the output of the "uname -r" command.
The "manufacturer", "model", "version", and "class" attributes' contents are vendor-specific, but may be used together to identify different types of analyzers (and perhaps make determinations about the contents to expect in other vendor-specific fields of IDMEF messages).
The Classification class provides the "name" of an alert, or other information allowing the manager to determine what it is. This name is chosen by the alert provider.
The Classification class is composed of one aggregate class, as shown in Figure 16The Classification Class.
+----------------+
| Classification |
+----------------+ 0..* +-----------+
| STRING ident |<>----------| Reference |
| STRING text | +-----------+
+----------------+
| Figure 16: The Classification Class |
The aggregate class that make up Classification is:
- Reference
- Zero or more. Information about the message, pointing to external documentation sites, that will provide background information about the alert.
This is represented in the XML DTD as follows:
<!ELEMENT Classification (
Reference?
)>
<!ATTLIST Classification
ident CDATA '0'
text CDATA #REQUIRED
>
The Classification class has two attributes:
- ident
- Optional. A unique identifier for this classification, see Section 4.2.9Unique Identifiers.
- text
- Required. A vendor-provided string identifying the alert message.
The Reference class provides the "name" of an alert, or other information allowing the manager to determine what it is.
The Reference class is composed of two aggregate classes, as shown in Figure 18The Reference Class.
+----------------+
| Reference |
+----------------+ +------+
| STRING origin |<>----------| name |
| STRING meaning | +------+
| | +------+
| |<>----------| url |
| | +------+
+----------------+
| Figure 18: The Reference Class |
The aggregate classes that make up Reference are:
- name
- Exactly one. STRING. The name of the alert, from one of the origins listed below.
- url
- Exactly one. STRING. A URL at which the manager (or the human operator of the manager) can find additional information about the alert. The document pointed to by the URL may include an in-depth description of the attack, appropriate countermeasures, or other information deemed relevant by the vendor.
This is represented in the XML DTD as follows:
<!ENTITY % attvals.origin "
( unknown | vendor-specific | user-specific | bugtraqid |
cve | osvdb )
">
<!ELEMENT Reference (
name, url
)>
<!ATTLIST Reference
origin %attvals.origin; 'unknown'
>
The Reference class has two attributes:
- origin
- Required. The source from which the name of the alert originates. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 12IANA Considerations.)
Rank Keyword Description 0 unknown Origin of the name is not known 1 vendor-specific A vendor-specific name (and hence, URL); this can be used to provide product-specific information 2 user-specific A user-specific name (and hence, URL); this can be used to provide installation-specific information 3 bugtraqid The SecurityFocus ("Bugtraq") vulnerability database identifier (http://www.securityfocus.com/vdb) 4 cve The Common Vulnerabilities and Exposures (CVE) name (http://www.cve.mitre.org/) 5 osvdb The Open Source Vulnerability Database (http://www.osvdb.org) - meaning
- Optional. The meaning of the reference, as understood by the alert provider. This field is only valid if the value of the <origin> attribute is set to "vendor-specific" or "user-specific".
The Source class contains information about the possible source(s) of the event(s) that generated an alert. An event may have more than one source (e.g., in a distributed denial of service attack).
The Source class is composed of four aggregate classes, as shown in Figure 20The Source Class.
+------------------+
| Source |
+------------------+ 0..1 +---------+
| STRING ident |<>----------| Node |
| ENUM spoofed | +---------+
| STRING interface | 0..1 +---------+
| |<>----------| User |
| | +---------+
| | 0..1 +---------+
| |<>----------| Process |
| | +---------+
| | 0..1 +---------+
| |<>----------| Service |
| | +---------+
+------------------+
| Figure 20: The Source Class |
The aggregate classes that make up Source are:
- Node
- Zero or one. Information about the host or device that appears to be causing the events (network address, network name, etc.).
- User
- Zero or one. Information about the user that appears to be causing the event(s).
- Process
- Zero or one. Information about the process that appears to be causing the event(s).
- Service
- Zero or one. Information about the network service involved in the event(s).
This is represented in the XML DTD as follows:
<!ENTITY % attvals.yesno "
( unknown | yes | no )
">
<!ELEMENT Source (
Node?, User?, Process?, Service?
)>
<!ATTLIST Source
ident CDATA '0'
spoofed %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
>
The Source class has three attributes:
- ident
- Optional. A unique identifier for this source, see Section 4.2.9Unique Identifiers.
- spoofed
- Optional. An indication of whether the source is, as far as the analyzer can determine, a decoy. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 12IANA Considerations.)
Rank Keyword Description 0 unknown Accuracy of source information unknown 1 yes Source is believed to be a decoy 2 no Source is believed to be "real" - interface
- Optional. May be used by a network-based analyzer with multiple interfaces to indicate which interface this source was seen on.
The Target class contains information about the possible target(s) of the event(s) that generated an alert. An event may have more than one target (e.g., in the case of a port sweep).
The Target class is composed of four aggregate classes, as shown in Figure 22The Target Class.
+------------------+
| Target |
+------------------+ 0..1 +----------+
| STRING ident |<>----------| Node |
| ENUM decoy | +----------+
| STRING interface | 0..1 +----------+
| |<>----------| User |
| | +----------+
| | 0..1 +----------+
| |<>----------| Process |
| | +----------+
| | 0..1 +----------+
| |<>----------| Service |
| | +----------+
| | 0..n +----------+
| |<>----------| File |
| | +----------+
+------------------+
| Figure 22: The Target Class |
The aggregate classes that make up Target are:
- Node
- Zero or one. Information about the host or device at which the event(s) (network address, network name, etc.) is being directed.
- User
- Zero or one. Information about the user at which the event(s) is being directed.
- Process
- Zero or one. Information about the process at which the event(s) is being directed.
- Service
- Zero or one. Information about the network service involved in the event(s).
- File
- Optional. Information about file(s) involved in the event(s).
This is represented in the XML DTD as follows:
<!ENTITY % attvals.yesno "
( unknown | yes | no )
">
<!ELEMENT Target (
Node?, User?, Process?, Service?, File*
)>
<!ATTLIST Target
ident CDATA '0'
decoy %attvals.yesno; 'unknown'
interface CDATA #IMPLIED
>
The Target class has three attributes:
- ident
- Optional. A unique identifier for this target, see Section 4.2.9Unique Identifiers.
- decoy
- Optional. An indication of whether the target is, as far as the analyzer can determine, a decoy. The permitted values for this attribute are shown below. The default value is "unknown". (See also Section 12IANA Considerations.)
Rank Keyword Description 0 unknown Accuracy of target information unknown 1 yes Target is believed to be a decoy 2 no Target is believed to be "real" - interface
- Optional. May be used by a network-based analyzer with multiple interfaces to indicate which interface this target was seen on.
The Assessment class is used to provide the analyzer's assessment of an event -- its impact, actions taken in response, and confidence.
The Assessment class is composed of three aggregate classes, as shown in Figure 24The Assessment Class.
+------------------+
| Assessment |
+------------------+ 0..1 +------------+
| |<>----------| Impact |
| | +------------+
| | 0..* +------------+
| |<>----------| Action |
| | +------------+
| | 0..1 +------------+
| |<>----------| Confidence |
| | +------------+
+------------------+
| Figure 24: The Assessment Class |
The aggregate classes that make up Assessment are:
- Impact
- Zero or one. The analyzer's assessment of the impact of the event on the target(s).
- Action
- Zero or more. The action(s) taken by the analyzer in response to the event.
- Confidence
- A measurement of the confidence the analyzer has in its evaluation of the event.
This is represented in the XML DTD as follows:
<!ELEMENT Assessment (
Impact?, Action*, Confidence?
)>
The AdditionalData class is used to provide information that cannot be represented by the data model. AdditionalData can be used to provide atomic data (integers, strings, etc.) in cases where only small amounts of additional information need to be sent; it can also be used to extend the data model and the DTD to support the transmission of complex data (such as packet headers). Detailed instructions for extending the data model and the DTD are provided in Section 6Extending the IDMEF.
The AdditionalData element is declared in the XML DTD as follows:
<!ENTITY % attvals.adtype "
( boolean | byte | character | date-time | integer |
ntpstamp | portlist | real | string | byte-string | xml )
">
<!ELEMENT AdditionalData ANY >
<!ATTLIST AdditionalData
type %attvals.adtype; 'string'
meaning CDATA #IMPLIED
>
The AdditionalData class has two attributes:
- type
- Required. The type of data included in the element content. The permitted values for this attribute are shown below. The default value is "string". (See also Section 12IANA Considerations.)
Rank Keyword Description 0 boolean The element contains a boolean value, i.e., the strings "true" or "false" 1 byte The element content is a single 8-bit byte (see Section 4.2.4Bytes) 2 character The element content is a single character (see Section 4.2.3Characters and Strings) 3 date-time The element content is a date-time string (see Section 4.2.6Date-Time Strings) 4 integer The element content is an integer (see Section 4.2.1Integers) 5 ntpstamp The element content is an NTP timestamp (see Section 4.2.7NTP Timestamps) 6 portlist The element content is a list of ports (see Section 4.2.8Port Lists) 7 real The element content is a real number (see Section 4.2.2Real Numbers) 8 string The element content is a string (see Section 4.2.3Characters and Strings) 9 byte-string The element is a byte[] (see Section 4.2.4Bytes) 10 xml The element content is XML-tagged data (see Section 6.2Extending the XML DTD or schema) - meaning
- Optional. A string describing the meaning of the element content. These values will be vendor/implementation dependent; the method for ensuring that managers understand the strings sent by analyzer is outside the scope of this specification. A list of acceptable meaning keywords is not within the scope of the document, although later versions may undertake to establish such a list.
The data model provides three classes for representing time. These classes are aggregates of the Alert and Heartbeat classes.
The CreateTime class is used to indicate the date and time the alert or heartbeat was created by the analyzer. It is represented in the XML DTD as follows:
<!ELEMENT CreateTime (#PCDATA) >
<!ATTLIST CreateTime
ntpstamp CDATA #REQUIRED
>
The DATETIME format of the <CreateTime> element content is described in Section 4.2.6Date-Time Strings.
The CreateTime class has one attribute:
- ntpstamp
- Required. The NTP timestamp representing the same date and time as the element content. The NTPSTAMP format of this attribute's value is described in Section 4.2.7NTP Timestamps.
If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used.
The DetectTime class is used to indicate the date and time the event(s) producing an alert was detected by the analyzer. In the case of more than one event, the time the first event was detected. (This may or may not be the same time as CreateTime; analyzers are not required to send alerts immediately upon detection). It is represented in the XML DTD as follows:
<!ELEMENT DetectTime (#PCDATA) >
<!ATTLIST DetectTime
ntpstamp CDATA #REQUIRED
>
The DATETIME format of the <DetectTime> element content is described in Section 4.2.6Date-Time Strings.
The DetectTime class has one attribute:
- ntpstamp
- Required. The NTP timestamp representing the same date and time as the element content. The NTPSTAMP format of this attribute's value is described in Section 4.2.7NTP Timestamps.
If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used.
The AnalyzerTime class is used to indicate the current date and time on the analyzer. Its values should be filled in as late as possible in the message transmission process, ideally immediately before placing the message "on the wire." It is represented in the XML DTD as follows:
<!ELEMENT AnalyzerTime (#PCDATA) >
<!ATTLIST AnalyzerTime
ntpstamp CDATA #REQUIRED
>
The DATETIME format of the <AnalyzerTime> element content is described in Section 4.2.6Date-Time Strings.
The AnalyzerTime class has one attribute:
- ntpstamp
- Required. The NTP timestamp representing the same date and time as the element content. The NTPSTAMP format of this attribute's value is described in Section 4.2.7NTP Timestamps.
If the date and time represented by the element content and the NTP timestamp differ (should "never" happen), the value in the NTP timestamp MUST be used.
The use of <AnalyzerTime> to perform rudimentary time synchronization between analyzers and managers is discussed in Section 7.3Analyzer-Manager Time Synchronization.
The data model provides three types of "assessments" that an analyzer can make about an event. These classes are aggregates of the Assessment class.
The Impact class is used to provide the analyzer's assessment of the impact of the event on the target(s). It is represented in the XML DTD as follows:
<!ENTITY % attvals.severity "
( info | low | medium | high )
">
<!ENTITY % attvals.completion "
( failed | succeeded )
">
<!ENTITY % attvals.impacttype "
( admin | dos | file | recon | user | other )
">
<!ELEMENT Impact (#PCDATA) >
<!ATTLIST Impact
severity %attvals.severity; #IMPLIED
completion %attvals.completion; #IMPLIED
type %attvals.impacttype; 'other'
>
The Impact class has three attributes:
- severity
- An estimate of the relative severity of the event. The permitted values are shown below. There is no default value. (See also Section 12IANA Considerations.)
Rank Keyword Description O info Alert represents informational activity 1 low Low severity 2 medium Medium severity 3 high High severity - completion
- An indication of whether the analyzer believes the attempt that the event describes was successful or not. The permitted values are shown below. There is no default value. (See also Section 12IANA Considerations.)
Rank Keyword Description 0 failed The attempt was not successful 1 succeeded The attempt succeeded - type
- The type of attempt represented by this event, in relatively broad categories. The permitted values are shown below. The default value is "other." (See also Section 12IANA Considerations.)
Rank Keyword Description 0 admin Administrative privileges were attempted or obtained 1 dos A denial of service was attempted or completed 2 file An action on a file was attempted or completed 3 recon A reconnaissance probe was attempted or completed 4 user User privileges were attempted or obtained 5 other Anything not in one of the above categories
All three attributes are optional. The element itself may be empty, or may contain a textual description of the impact, if the analyzer is able to provide additional details.
The Action class is used to describe any actions taken by the analyzer in response to the event. Is is represented in the XML DTD as follows:
<!ENTITY % attvals.actioncat "
( block-installed | notification-sent | taken-offline |
other )
">
<!ELEMENT Action (#PCDATA) >
<!ATTLIST Action
category %attvals.actioncat; 'other'
>
Action has one attribute:
- category
- The type of action taken. The permitted values are shown below. The default value is "other." (See also Section 12IANA Considerations.)
Rank Keyword Description 0 block-installed A block of some sort was installed to prevent an attack from reaching its destination. The block could be a port block, address block, etc., or disabling a user account. 1 notification-sent A notification message of some sort was sent out-of-band (via pager, e-mail, etc.). Does not include the transmission of this alert. 2 taken-offline A system, computer, or user was taken offline, as when the computer is shut down or a user is logged off. 3 other Anything not in one of the above categories. - The element itself may be empty, or may contain a textual description of the action, if the analyzer is able to provide additional details.
The Confidence class is used to represent the analyzer's best estimate of the validity of its analysis. It is represented in the XML DTD as follows:
<!ENTITY % attvals.rating "
( low | medium | high | numeric )
">
<!ELEMENT Confidence (#PCDATA) >
<!ATTLIST Confidence
rating %attvals.rating; 'numeric'
>
The Confidence class has one attribute:
- rating
- The analyzer's rating of its analytical validity. The permitted values are shown below. The default value is "numeric." (See also Section 12IANA Considerations.)
Rank Keyword Description 0 low The analyzer has little confidence in its validity 1 medium The analyzer has average confidence in its validity 2 high The analyzer has high confidence in its validity 3 numeric The analyzer has provided a posterior probability value indicating its confidence in its validity
This element should be used only when the analyzer can produce meaningful information. Systems that can output only a rough heuristic should use "low", "medium", or "high" as the rating value. In this case, the element content should be omitted.
Systems capable of producing reasonable probability estimates should use "numeric" as the rating value and include a numeric confidence value in the element content. This numeric value should reflect a posterior probability (the probability that an attack has occurred given the data seen by the detection system and the model used by the system). It is a floating point number between 0.0 and 1.0, inclusive. The number of digits should be limited to those representable by a single precision floating point value, and may be represented as described in