Network Working Group J. Meijer
Internet-Draft SURFnet bv
Expires: September 29, 2003 R. Danyliw
CERT Coordination Center
Y. Demchenko
NLnet Labs
March 31, 2003
The Incident Data Exchange Format Data Model and XML Implementation
draft-ietf-inch-iodef-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 September 29, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The purpose of the Incident Data Exchange Format (IODEF) is to define
data formats for information related to computer security incidents
typically exchanged between collaborating Computer Security Incident
Response Teams (CSIRTs). The IODEF satisfies the requirements
specified in RFCXXX [1]
This Internet-Draft describes a data model for representing commonly
exchanged incident information exported from incident handling
systems managed by CSIRTs. An implementation of the data model in
Meijer, et al. Expires September 29, 2003 [Page 1]
Internet-Draft IODEF Data Model and Implementation March 2003
the Extensible Markup Language (XML) is presented, an XML Document
Type Definition is developed, and examples are provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 About the IODEF Data Model . . . . . . . . . . . . . . . . 4
1.3.1 Issues with Representing Incident Data . . . . . . . . . . 5
1.4 About the IODEF Implementation . . . . . . . . . . . . . . 6
1.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . 6
2. Notational conventions and formatting issues . . . . . . . 8
2.1 IODEF XML Documents . . . . . . . . . . . . . . . . . . . 8
2.1.1 The Document Prolog . . . . . . . . . . . . . . . . . . . 8
2.1.2 Character Data Processing in the IODEF . . . . . . . . . . 9
2.1.3 Languages in the IODEF . . . . . . . . . . . . . . . . . . 10
2.2 IODEF Data Types . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Integers . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 Characters and Strings . . . . . . . . . . . . . . . . . . 11
2.2.4 Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.5 Enumerated Types . . . . . . . . . . . . . . . . . . . . . 12
2.2.6 Date-Time Strings . . . . . . . . . . . . . . . . . . . . 12
2.2.7 NTP Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
2.2.8 Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.9 Postal Address . . . . . . . . . . . . . . . . . . . . . . 12
2.2.10 Person or Organization . . . . . . . . . . . . . . . . . . 13
2.2.11 Telephone and Fax Numbers . . . . . . . . . . . . . . . . 13
2.2.12 Email string . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.13 Uniform Resource Identifier strings . . . . . . . . . . . 13
2.2.14 Unique Identifiers . . . . . . . . . . . . . . . . . . . . 13
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . 14
3.1 IODEF-Document . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Incident class . . . . . . . . . . . . . . . . . . . . . . 14
3.3 IncidentID class . . . . . . . . . . . . . . . . . . . . . 16
3.4 AlternativeID class . . . . . . . . . . . . . . . . . . . 17
3.5 RelatedActivity class . . . . . . . . . . . . . . . . . . 18
3.6 AdditionalData . . . . . . . . . . . . . . . . . . . . . . 19
3.7 IncidentData . . . . . . . . . . . . . . . . . . . . . . . 20
3.8 Contact class . . . . . . . . . . . . . . . . . . . . . . 22
3.8.1 RegistryHandle class . . . . . . . . . . . . . . . . . . . 25
3.9 Time classes . . . . . . . . . . . . . . . . . . . . . . . 26
3.9.1 StartTime . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9.2 EndTime . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9.3 DetectTime . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9.4 ReportTime . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9.5 DateTime . . . . . . . . . . . . . . . . . . . . . . . . . 27
Meijer, et al. Expires September 29, 2003 [Page 2]
Internet-Draft IODEF Data Model and Implementation March 2003
3.10 Expectation class . . . . . . . . . . . . . . . . . . . . 27
3.11 Method class . . . . . . . . . . . . . . . . . . . . . . . 28
3.11.1 Classification class . . . . . . . . . . . . . . . . . . . 29
3.12 Assessment class . . . . . . . . . . . . . . . . . . . . . 30
3.12.1 Impact class . . . . . . . . . . . . . . . . . . . . . . . 31
3.12.2 TimeImpact class . . . . . . . . . . . . . . . . . . . . . 33
3.12.3 MonetaryImpact class . . . . . . . . . . . . . . . . . . . 34
3.12.4 LifeImpact class . . . . . . . . . . . . . . . . . . . . . 35
3.12.5 Confidence class . . . . . . . . . . . . . . . . . . . . . 36
3.13 History class . . . . . . . . . . . . . . . . . . . . . . 38
3.13.1 HistoryItem class . . . . . . . . . . . . . . . . . . . . 38
3.14 EventData class . . . . . . . . . . . . . . . . . . . . . 40
3.15 Relating the IncidentData and EventData classes . . . . . 42
3.16 Cardinality of EventData . . . . . . . . . . . . . . . . . 43
3.17 System class . . . . . . . . . . . . . . . . . . . . . . . 44
3.18 Node class . . . . . . . . . . . . . . . . . . . . . . . . 46
3.18.1 Address . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.18.2 NodeRole class . . . . . . . . . . . . . . . . . . . . . . 48
3.19 FileList class . . . . . . . . . . . . . . . . . . . . . . 50
3.20 User . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.21 Process . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.22 Service . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.23 Record class . . . . . . . . . . . . . . . . . . . . . . . 50
3.23.1 RecordData class . . . . . . . . . . . . . . . . . . . . . 51
4. Extending the IODEF . . . . . . . . . . . . . . . . . . . 55
4.1 Extending the data model . . . . . . . . . . . . . . . . . 55
4.2 Extending the XML DTD . . . . . . . . . . . . . . . . . . 55
5. Processing Considerations . . . . . . . . . . . . . . . . 58
5.1 XML Validity and Well-Formedness . . . . . . . . . . . . . 58
5.2 Unrecognized Data and XML Tags . . . . . . . . . . . . . . 58
6. Internationalization issues . . . . . . . . . . . . . . . 60
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.1 Code Red detection notification . . . . . . . . . . . . . 61
7.2 IODEF-Document with XML signature . . . . . . . . . . . . 63
7.3 IODEF-Document encrypted using XML encryption . . . . . . 63
7.4 IODEF-Document encrypted and signed using XML signature
& encryption . . . . . . . . . . . . . . . . . . . . . . . 63
8. The IODEF Document Type Definition . . . . . . . . . . . . 64
9. Security considerations . . . . . . . . . . . . . . . . . 77
10. IANA considerations . . . . . . . . . . . . . . . . . . . 78
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 79
Normative References . . . . . . . . . . . . . . . . . . . 80
Informative References . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 82
Intellectual Property and Copyright Statements . . . . . . 83
Meijer, et al. Expires September 29, 2003 [Page 3]
Internet-Draft IODEF Data Model and Implementation March 2003
1. Introduction
1.1 Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].
Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of [1].
1.2 Overview
The Incident Data Exchange Format (IODEF) is intended to be a
standard format for computer security information exchanged by
Computer Security Incident Response Teams (CSIRTs). The development
and subsequent deployment of an incident data format that extends
beyond a closed communities would improve the operational
capabilities of the CSIRTs.
Assuming widespread adoption of the IODEF by the community, an
organization can potentially benefit from:
o the increased ease to collaborate with other CSIRTs, on behalf it
its constituency, to resolve incidents;
o increased automation in the processing of incident data, since the
commitment of security analysts to parse free-form textual
document will be reduced;
o decreased effort in normalizing similar data (even when highly
structured) from different sources; and
o a common format on which to build inter-operable tools for
incident handling, such as correlation systems that process data
from different sites.
Terminology, notation, and conventions of the data model and XML DTD
are presented in Sections 2. The data model is described in Section
3, and the implementation considerations are covered in Sections 4
through 6, and 9. Section 7 provides several examples of IODEF
documents for representative incidents. Section 8 formally specifies
the XML DTD implementation of the data model.
1.3 About the IODEF Data Model
The IODEF data model is an object-oriented representation of
information reported, maintained, and exchanged by a CSIRT about a
Meijer, et al. Expires September 29, 2003 [Page 4]
Internet-Draft IODEF Data Model and Implementation March 2003
computer security incident.
1.3.1 Issues with Representing Incident Data
The IODEF data model addresses several problems in representing
incident data:
o There is no precise, widely agreed upon definition for an
incident. Therefore, the data model does not attempt to imply a
definition through its implementation. Rather, a broad
understanding is assumed that is flexible enough to encompass most
of the CSIRT community.
o Incident data is inherently heterogeneous. It may encompass many
functional purposes such as a description of intruder behavior or
an analysis process correlating related incidents.
An object-oriented model provides extensibility via aggregation
and sub-classing while preserving the consistency of the model.
If the data model required modification, it is extended with new
classes. In implementations that do not recognize these
extensions, the basic subset of the data model will still be
understood.
o Incidents have a life-cycle, which causes potentially different
information or levels of detail to be present depending on their
stage in the cycle. For example, newly reported incidents may
only contain a short description of the involved parties. On the
other hand, closed incidents can contain a full description
complete with the associated evidence and annotation of actions
taken by the CSIRT. The data model that represents this
information must be flexible to accommodate different needs.
o Communication and coordination are central to the role of a CSIRT.
As a result of this activity, incident information can originate
from a number of sources. Tracking the all the sources of data is
key to managing this information.
The data model defines support classes that accommodate the
differences between incident reporters. This support includes
various meta information to represent the reporter's identity as
well as prescribe a confidence level to the submitted information.
o Incident data may contain sensitive information. Such information
should not be exposed to unauthorized parties during
collaboration.
The data model allows for a granular tagging in the individual
classes to indication restrictions on the usage of the data.
However, it is the role of the incident handling system
implementing the data model to honor these labels.
Meijer, et al. Expires September 29, 2003 [Page 5]
Internet-Draft IODEF Data Model and Implementation March 2003
1.4 About the IODEF Implementation
The IODEF implementation uses the Extensible Markup Language (XML)
[2]. XML-based specifications define an XML DTD or Schema and
register a specific XML namespace [3]. The IODEF conforms to the
IETF-defined procedure for registering an application-specific XML
namespace [9].
For clarity in this document, we will use the terms "XML" and "XML
documents" when speaking in the general case about the Extensible
Markup Language (XML). The terms "IODEF description", "IODEF
markup" and "IODEF document" will be used to refer to specific
elements (tags) and attributes of the IODEF DTD. Furthermore, the
terms "class" and "subclass" are synonymous to an element in the
XML DTD.
The implementation of the IODEF in XML has many benefits:
o XML provides all the necessary features to define a specific
markup language for describing security incidents. It also defines
a standard way to extend this language, either for later revisions
("standard" extensions), or for organizational-specific use
("non-standard" extensions).
o Software tools for processing XML documents are widely available
in commercial and open source forms.
o XML can aid in implementing internationalization and localization
since it is required (and therefore IODEF documents are required)
to support both the UTF-8 and UTF-16 encodings of ISO/IEC 10646
(Universal Multiple-Octet Coded Character Set, "UCS") and Unicode.
XML also provides support for specifying, on a per-element basis,
the language in which the element's content is written, making the
IODEF easy to adapt to the local languages in which a CSIRTs
operates.
o XML coupled with XSL [4], a style language, allows IODEF documents
to be aggregated, filtered, discarded, and rearranged.
o XML is free (no license, license fees or royalties).
1.5 Related Work
The IODEF and the IDMEF [7] are complementary formats. The latter
represents data generated by an intrusion detection system. Such
event data is commonly used by a CSIRT as the basis for an incident
report or investigation which is represented by the IODEF.
Meijer, et al. Expires September 29, 2003 [Page 6]
Internet-Draft IODEF Data Model and Implementation March 2003
The IODEF data model makes use of certain classes defined in the
IDMEF, although the semantics of some of these classes has changed.
Due to their related nature, the data in an IDMEF message can be
easily represented in an IODEF document. Through various extension
mechanisms, it is possible to include IDMEF messages outright in an
IODEF document. Alternatively, the similarity in structure of the
data model makes it possible to decompose the key IDMEF data and
include it in the corresponding IODEF classes. However, this
transformation may not preserve the original semantics of the data.
Meijer, et al. Expires September 29, 2003 [Page 7]
Internet-Draft IODEF Data Model and Implementation March 2003
2. Notational conventions and formatting issues
2.1 IODEF XML Documents
This document uses three notations: the Unified Modeling Language
(UML) to describe the data model, an Extensible Markup Language (XML)
Document Type Definition (DTD) to define the IODEF syntax, and IODEF
XML markup conforming to the specified DTD to represent the incident
data.
This section describes the XML notations and conventions used in this
memo and explains particular issues related to using them to describe
the IODEF data model and syntax. For readers unfamiliar with these
notations [19] and [7] will provide a comprehensive reference.
2.1.1 The Document Prolog
The "prolog" of an XML document, that part that precedes anything
else, consists of the XML declaration and the document type
declaration.
2.1.1.1 XML Declaration
Every IODEF document starts with an XML declaration. The XML
declaration specifies the version of XML being used, and optionally
the character encoding being used (see Section 2.1.2).
The XML declaration looks like:
IODEF documents exchanged between applications MUST begin with an XML
declaration and MUST specify the XML version in use. Specification of
the encoding in use is REQUIRED if UTF-8 encoding is not used.
2.1.1.2 IODEF DTD Formal Public Identifier
The formal public identifier (FPI) for the IODEF Document Type
Definition described in this document is:
"-//IETF//DTD RFCxxxx IODEF v0.0//EN"
NOTE: The "RFCxxxx" text in the FPI value will be replaced with the
actual RFC number when this document is published as an RFC.
This FPI MUST be used in the document type declaration within an XML
document referencing the IODEF DTD defined by this document, as shown
in Section 2.1.1.3.
Meijer, et al. Expires September 29, 2003 [Page 8]
Internet-Draft IODEF Data Model and Implementation March 2003
2.1.1.3 IODEF DTD Document Type Declaration
The document type declaration for an XML document referencing the
IODEF DTD will be specified in the following ways:
The last component of the document type declaration is the FPI
specified in Section 2.1.1.2.
The last component of the document type declaration is a URI that
points to a copy of the Document Type Definition.
2.1.2 Character Data Processing in the IODEF
A document's XML declaration specifies the character encoding to be
used in the document, as follows:
where "charset" is the name of the character encoding, as registered
with the Internet Assigned Numbers Authority (IANA), see [9].
The XML standard requires that XML processors support the UTF-8 and
UTF-16 encodings of ISO/IEC 10646 (UCS) and Unicode, making all XML
applications (and therefore, all IODEF-compliant applications)
compatible with these common character encodings.
While XML supports other character encodings (e.g., UTF-7, UTF-32),
implementers should carefully consider the portability implications
of using character encodings other than UTF-8 and UTF-16.
Consistent with the XML standard, if no encoding is specified for an
IODEF document, UTF-8 is assumed. IODEF 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).
2.1.2.1 Character Entity References
Within XML documents, certain characters have special meanings in
some contexts. To include the actual character itself in one of
these contexts, a special escape sequence, called an entity
reference, must be used.
The characters that sometimes need to be escaped, and their entity
Meijer, et al. Expires September 29, 2003 [Page 9]
Internet-Draft IODEF Data Model and Implementation March 2003
references, are:
Character Entity Reference
---------------------------------
& &
< <
> >
" "
' '
Figure 1
It is RECOMMENDED that IODEF-compliant applications use the entity
reference form whenever writing these characters in data, to avoid
any possibility of misinterpretation.
2.1.2.2 Character Code References
Any character defined by the ISO/IEC 10646 and Unicode standards may
be included in an XML document by the use of a character reference. A
character reference is started with the characters '&' and '#', and
ended with the character ';'. Between these characters, the
character code for the character inserted.
If the character code is preceded by an 'x' it is interpreted in
hexadecimal (base 16), otherwise, it is interpreted in decimal (base
10). For instance, the ampersand (&) is encoded as & or &
and the less-than sign (<) is encoded as < or <.
Any one-, two-, or four-byte character specified in the ISO/IEC 10646
and Unicode standards can be included in a document using this
technique.
2.1.2.3 White Space Processing
All IODEF elements support the "xml:space" attribute. If "xml:space"
is set to "preserve," the IODEF processing application MUST treat all
white space in the element's content as significant. If "xml:space"
is "default," the application is free to do whatever it normally
would with white space in the element's content.
2.1.3 Languages in the IODEF
All IODEF tags support the "xml:lang" attribute thereby allowing each
element to identify the language in which its content is. The valid
language code for the "xml:lang" attribute are described in RFC 3066
[6].
Meijer, et al. Expires September 29, 2003 [Page 10]
Internet-Draft IODEF Data Model and Implementation March 2003
IODEF messages SHOULD specify the language in which their contents
are encoded. In general, the language can be specified with the
"xml:lang" attribute in the top-level element and letting all other
elements "inherit" that definition.
If no language is specified in an IODEF document, English SHOULD be
assumed.
2.2 IODEF Data Types
2.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
characters "0x". For example, "0x1a2b".
2.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 "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".
IODEF-compliant applications MUST support both the '.' and ',' radix
characters.
2.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
Section 2.1.2.1 and Section 2.1.2.2) to represent special characters.
Meijer, et al. Expires September 29, 2003 [Page 11]
Internet-Draft IODEF Data Model and Implementation March 2003
2.2.4 Bytes
Binary data is represented by the BYTE (and BYTE[]) data type.
Binary data MUST be encoded in its entirety using character code
references (see ).
2.2.5 Enumerated Types
Enumerated types are represented by the ENUM data type, and consist
of an ordered list of acceptable values. Each value has a
representative keyword. Within an IODEF document, the enumerated
type keywords are used as attribute values
2.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 [15] documented in RFC 3339 [14].
2.2.7 NTP Timestamps
NTP timestamps are represented by the NTPSTAMP data type, and are
described in detail in RFC 1305 [10] and RFC 2030 [11]. 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.
IODEF documents MUST encode NTP timestamps as two 32-bit hexadecimal
values, separated by a period ('.'). For example,
"0x12345678.0x87654321".
2.2.8 Port Lists
A list of network ports 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".
2.2.9 Postal Address
A postal address is represented by the POSTAL data type. The format
of this address data is the documented in Sections 5.17 - 5.19 of RFC
2256 [12].
Meijer, et al. Expires September 29, 2003 [Page 12]
Internet-Draft IODEF Data Model and Implementation March 2003
2.2.10 Person or Organization
The name of an individual or organization is represented by the NAME
data type. The format of the NAME data type is documented in Section
5.4 of RFC 2256 [12].
2.2.11 Telephone and Fax Numbers
A telephone number is represented by the PHONE data type. The format
of the PHONE data type is documented in Section 5.21 of RFC 2256
[12].
2.2.12 Email string
An email address is represented by the EMAIL data type. The format
of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [13]
2.2.13 Uniform Resource Identifier strings
A uniform resource identifier (URI) is represented by the URI data
type. The format of the URI data type is documented in RFC 2396 [8].
2.2.14 Unique Identifiers
A unique identifier in the context of particular creator of IODEF
documents (e.g., a CSIRT) is represented by the UID data type. A
globally unique identifier is represented by the GUID data type. The
UID and GUID data types are constructed from alphanumeric strings.
Meijer, et al. Expires September 29, 2003 [Page 13]
Internet-Draft IODEF Data Model and Implementation March 2003
3. The IODEF Data Model
In this section, the individual components of the IODEF data model
will be discussed in detail. For each class, the semantics with be
documented and the relationship between other classes with be
presented with an UML diagram.
3.1 IODEF-Document
The IODEF-Document class is the top level class in the IODEF data
model and the DTD. All IODEF documents are instances of the
IODEF-Documents class.
+-----------------+
| IODEF-Document |
+-----------------+
| STRING version |<>--{1..*}--[ Incident ]
| |
+-----------------+
Figure 2: IODEF-Document class
The aggregate class that constitutes IODEF-Document is:
Incident
One. The Incident class contains all the incident-related
information.
The IODEF-Document class has one attribute:
version
Required. STRING. The version of the IODEF specification to
which the IODEF document conforms. The value of this attribute
MUST be 1.0
3.2 Incident class
Every incident reported to or handled by a CSIRT is represented by an
instance of the Incident class. This class provides a standardized
representation for commonly exchanged incident data and associates a
unique identifier with the described activity.
Meijer, et al. Expires September 29, 2003 [Page 14]
Internet-Draft IODEF Data Model and Implementation March 2003
+-------------------+
| Incident |
+-------------------+
| ENUM purpose |<>----------[ IncidentID ]
| ENUM restriction |
| |<>--{0..1}--[ AlternativeIDs ]
| |
| |<>----------[ IncidentData ]
| |
| |<>--{0..1}--[ RelatedActivity ]
| |
| |<>--{0..*}--[ AdditionalData ]
+-------------------+
Figure 3: the Incident class
The aggregate classes that constitute Incident are:
IncidentID
One. The incident tracking number or unique identifier assigned
to this incident by the party that generated the document.
AlternativeIDs
Zero or one. A list of incident tracking numbers used by other
CSIRTs to refer to same activity as described in the document.
RelatedActivity
Zero or one. A list of incident tracking numbers referencing
related incidents.
IncidentData
Zero or more. The event(s) that constitute the incident about
which the IODEF-Document conveys information.
AdditionalData
Zero or more. Extension area for data that cannot be represented
anywhere else.
The Incident class has two attributes:
purpose
Required. ENUM. The purpose of the IODEF document. This
attribute is defined as an enumerated list:
1. handling. The IODEF-Document was sent for incident-handling
purposes;
2. statistics. The IODEF-Document was sent to be included in a
Meijer, et al. Expires September 29, 2003 [Page 15]
Internet-Draft IODEF Data Model and Implementation March 2003
data-repository for statistical purposes;
3. warning. The IODEF-Document was sent as a warning;
4. other. The IODEF-Document was sent for purposes specified in
the AdditionalData element.
restriction
Optional. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient of the
IODEF-Document to adhere. However, it is the choice of the
recipient of the document to honor this guideline.
The value of this attribute is logically inherited by the children
of this class. That is to say, the disclosure rules applied to
this class, also apply to its children.
It is possible to set a granular disclosure policy, since many of
the high-level classes have a restriction attribute. Therefore, a
child can override the guidelines of a parent class, be it to
tighten or relax the disclosure rules (i.e., a child has a weaker
policy than an ancestor; or an ancestor has a weak policy, and the
children selectively apply more rigid controls). The implicit
value of the restriction attribute for a class that did not
specify one can be found in the closest ancestor that did specify
a value.
This attribute is defined as an enumerated value with a default
value of "private".
1. public. There is no restriction level applied to the
information;
2. need-to-know. The information may be shared with other
parties that are involved in the incident (e.g., multiple
victim sites can be informed of each other);
3. private. The information may not be shared.
4. default. The information can be shared according to an
information disclosure policy pre-arranged by the
communicating parties.
3.3 IncidentID class
The IncidentID class represents the incident tracking number or
Meijer, et al. Expires September 29, 2003 [Page 16]
Internet-Draft IODEF Data Model and Implementation March 2003
identifier used by a CSIRT or reporter to uniquely identify (in their
organization) the activity characterized in this IODEF-Document.
+------------------+
| IncidentID |
+------------------+
| UID |
| |
| GUID name |
+------------------+
Figure 4: the IncidentID class
The element content represents an incident tracking number (UID) that
is unique in the context of the CSIRT.
The IncidentID class has one attribute:
name
Required. GUID. An identifier for the CSIRT that created the
IODEF-Document.
3.4 AlternativeID class
The AlternativeID class references the incident tracking numbers or
unique identifiers used by other entities (e.g., CSIRTs) to refer to
activity identical to that characterized in this IODEF-Document.
Thus, tracking numbers listed as an AlternativeID are the same events
detected by another CSIRT, but seem from a different perspective. It
follows, the incident tracking numbers of the organization that
generated the IODEF-Document should never be considered an
AlternativeID.
If the incident is not the identical activity, but is related (e.g.,
same methodology or intruder), then its incident tracking number
should instead be represented in the RelatedActivity (Section 3.5)
class.
Meijer, et al. Expires September 29, 2003 [Page 17]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| AlternativeID |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
Figure 5: the AlternativeID class
The aggregate classes that constitute AlternativeID are:
IncidentID
One or more. Unique identifiers assigned by another entity for
the identical activity characterized in the IODEF-Document.
The AlternativeID class has one attribute:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.5 RelatedActivity class
The RelatedActivity class references the incident tracking numbers or
unique identifiers of incidents that are related to the one described
in the IODEF document. These references may to local incident
tracking numbers, as well as, to those of other CSIRTs.
The specifics of how a CSIRT came to believe that two incidents are
related is considered out of scope.
+------------------+
| RelatedActivity |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
Figure 6: RelatedActivity class
The aggregate classes that constitute RelatedActivity are:
IncidentID
One or more. Unique identifiers assigned by the CSIRT.
The RelatedActivity class has one attribute:
Meijer, et al. Expires September 29, 2003 [Page 18]
Internet-Draft IODEF Data Model and Implementation March 2003
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.6 AdditionalData
The AdditionalData class serves as an extension mechanism for
information not otherwise represented in the data model. For
relatively simple information, atomic data (integers, strings, etc.)
types are provided with a mechanism to annotate their meaning. The
class can also be used to extend the data model and the DTD to
support proprietary extensions by encapsulating entire XML documents
conforming to another DTD (e.g., IDMEF). A detailed discussion for
extending the data model and the DTD can be found in Section 4.
Unlike XML, which is self-describing, atomic data must typically be
documented to convey its meaning. This information is described in
the 'meaning' attribute. Since these description are outside the
scope of the specification, some additional coordination may be
required to ensure that a recipient of a document using the
AdditionalData classes can make sense of the custom extensions.
+------------------+
| AdditionalData |
+------------------+
| ANY |
| |
| ENUM restriction |
| ENUM type |
| STRING meaning |
+------------------+
Figure 7: the AdditionalData class
The AdditionalData class has three attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
type
Required. ENUM. The data type of the element content. The
permitted values for this attribute are shown below. The default
value is "string".
1. boolean. The element contains a boolean value, i.e., the
strings "true" or "false"
Meijer, et al. Expires September 29, 2003 [Page 19]
Internet-Draft IODEF Data Model and Implementation March 2003
2. byte. The element content is a single 8-bit byte (see
Section 2.2.4);
3. character. The element content is a single character (see
Section 2.2.3);
4. date-time. The element content is a date-time string (see
Section 2.2.6);
5. integer. The element content is an integer (see Section
2.2.1);
6. ntpstamp. The element content is a NTP timestamp (see
Section 2.2.7);
7. portlist. The element content is a port list (see Section
2.2.8);
8. real. The element content is a real number (see xref
target="dt_real_numbers" />);
9. string. The element content is a string (see Section 2.2.3);
10. xml. The element content is XML-tagged data (see Section 4).
meaning
Optional. STRING. A description of the semantics of the custom
data in this class.
3.7 IncidentData
The IncidentData class summarizes the details of the incident
activity and a CSIRT's handling of the information, as well as,
groups the security events that constitute the incident.
Many of the aggregated classes of IncidentData are also found in
EventData, albeit with different occurrence indicators. However, the
semantics of these classes is quite different. The classes of
IncidentData reflect information relevant across the entire incident,
while the classes of EventData provide information only relevant to
the given event or system node being described. The relationship
between the IncidentData and EventData classes is complementary. The
latter provides summary information, while the former provides more
specific details. For example, the overall impact of the incident
(represented in IncidentData) might be denial of service, but it
might be worth mentioning that there were specific machines
(represented in EventData) which also suffered a root compromise. In
Meijer, et al. Expires September 29, 2003 [Page 20]
Internet-Draft IODEF Data Model and Implementation March 2003
another example, an organizational contact can be provided in
IncidentData class, while more specific contacts for the individual
hosts can be in the EventData class.
IncidentData also ensures that certain mandatory information will be
present in the data model.
+------------------+
| IncidentData |
+------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| |
| |<>--{1..*}--[ Assessment ]
| |
| |<>--{0..*}--[ Method ]
| |
| |<>--{0..1}--[ DetectTime ]
| |
| |<>--{0..1}--[ StartTime ]
| |
| |<>--{0..1}--[ EndTime ]
| |
| |<>----------[ ReportTime ]
| |
| |<>--{1..*}--[ Contact ]
| |
| |<>--{0..*}--[ Expectation ]
| |
| |<>--{0..1}--[ History ]
| |
| |<>--{0..*}--[ EventData ]
| |
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 8: the IncidentData class
The aggregate classes that constitute IncidentData are:
Description
Zero or more. STRING. A free-form textual description of the
incident activity
Assessment
One or more. A characterization of the impact the incident
activity.
Meijer, et al. Expires September 29, 2003 [Page 21]
Internet-Draft IODEF Data Model and Implementation March 2003
Method
Zero or more. The techniques (e.g., tools, vulnerabilities) used
by the intruder.
DetectTime
Zero or one. The time the incident activity was first detected.
StartTime
Zero or one. The time the incident activity started.
EndTime
Zero or one. The time the incident activity ended.
ReportTime
One. The time the incident activity was reported.
Contact
One or more. Contact information for the parties involved in the
incident.
Expectation
Zero or more. Expected action to be performed by the recipient of
the document.
History
Zero or one. Documents significant events or actions that
occurred during the course of handling the incident.
EventData
Zero or more. Details on the Data on the (security) events that
lead to the incident.
AdditionalData
Zero or more. An area to extend the data model with information
that can not be represented elsewhere.
The IncidentData class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.8 Contact class
The Contact class describes contact information for organizations and
personnel involved in the incident. This class encapsulates naming
the involved party, specifying contact information to reach them, and
identifying their role in the incident.
Meijer, et al. Expires September 29, 2003 [Page 22]
Internet-Draft IODEF Data Model and Implementation March 2003
People and organizations are treated interchangeably as contacts; one
can be associated with the other using the recursive definition of
the class. The 'type' attribute determines the type of contact
information being provided.
The recursive definition of this class (the Contact class is
aggregated into the Contact class) provides a way to relate
information without requiring the explicit use of identifiers in the
classes. When grouping people into organizations it is RECOMMENDED
to nest the persons instances into an organization instance of this
class.
+------------------+
| Contact |
+------------------+
| ENUM restriction |<>--{0..1}--[ name ]
| ENUM role |
| ENUM type |<>--{0..*}--[ Description ]
| |
| |<>--{0..*}--[ RegistryHandle ]
| |
| |<>--{0..1}--[ PostalAddress ]
| |
| |<>--{0..*}--[ Email ]
| |
| |<>--{0..*}--[ Telephone ]
| |
| |<>--{0..1}--[ Fax ]
| |
| |<>--{0..1}--[ Timezone ]
| |
| |<>--{0..*}--[ Contact ]
+------------------+
Figure 9: the Contact class
The aggregate classes that constitute the Contact class are:
name
Zero or one. NAME. The name of the contact. The contact may
either be an organization or a person. The type attribute
dictates the semantics (organization or person).
Description
Zero or one. STRING. Free-form description of the this contact.
In the case of a person, this is often the organizational title of
the individual.
Meijer, et al. Expires September 29, 2003 [Page 23]
Internet-Draft IODEF Data Model and Implementation March 2003
RegistryHandle
Zero or many. The handle name in a registry. Care must be taken
to ensure that a handle is meaningful to the recipient.
Intra-organizational handles are of not much use for
extra-organizational communication.
PostalAddress
Zero or one. POSTAL. The postal address of the contact formatted
according to Section 2.2.9.
Email
Zero or many. EMAIL. The email address of the contact formatted
according to Section 2.2.12.
Telephone
Zero or many. PHONE. The telephone number of the contact
formatted according to .
Fax
Zero or one. PHONE. The facsimile telephone number of the
contact formatted according to .
Timezone
Zero or one. STRING. The timezone in which the contact resides.
Contact
Zero or many. Recursive definition of Contact, allowing for
grouping of data. An example of this is an organization with
multiple contact persons.
The Contact class has three attributes:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
role
Required. ENUM. Indicates the role the Contact fulfills. This
attribute is defined as an enumerated list:
1. creator. The entity that generate the IODEF document.
2. admin. An administrative contact for a host or network.
3. tech. A technical contact for a host or network.
4. irt. The CSIRT involved in handling the incident.
5. cc. An entity that is to be kept informed about the the
Meijer, et al. Expires September 29, 2003 [Page 24]
Internet-Draft IODEF Data Model and Implementation March 2003
handling of the incident.
type
Required. ENUM. Indicates the type of Contact being provided.
This attribute is defined as an enumerated list:
1. person.
2. organization.
3.8.1 RegistryHandle class
The RegistryHandle class represents a handle to an Internet registry
or community-specific database. A handle consists of a name
specified in the element content, and the database to which it
belongs specified in the type attribute.
+------------------+
| RegistryHandle |
+------------------+
| STRING |
| |
| ENUM type |
+------------------+
Figure 10: The RegistryHandle class
The RegistryHandle class has one attribute:
type
Required. ENUM. The database to which the handle belongs. The
default value is 'local'. The possible values are:
1. internic. Internet Network Information Center
2. apnic. Asia Pacific Network Information Center
3. arin. American Registry for Internet Numbers
4. lacnic. Regional Latin-American and Caribbean IP Address
Registry
5. ripe. Reseaux IP Europeens
6. ti. TERNEA Trusted Introducer
Meijer, et al. Expires September 29, 2003 [Page 25]
Internet-Draft IODEF Data Model and Implementation March 2003
7. local. A database local to the CSIRT.
3.9 Time classes
The data model uses for different classes to represent a timestamp.
Their definition is identical, but each is named differently to
convey a semantic difference.
The element content of each class is a timestamp formated according
to the DATETIME data type (see Section 2.2.6).
+----------------------------------+
| {Start| End| Report| Detect}Time |
+----------------------------------+
| DATETIME |
| |
| NTPSTAMP ntpstamp |
+----------------------------------+
Figure 11: the Time classes
The Time classes have one attribute:
ntpstamp
Optional. NTPTIMESTAMP. The NTP timestamp representing the
timestamp in the element content. The NTPSTAMP format of this
attribute's value is described in Section 2.2.7.
The use of the ntpstamp attribute is optional since it is redundant.
However, it has been maintained to ensure compatibility with the
IDMEF [7]. Representing a timestamp in both the element content and
attribute is NOT RECOMMENDED. However, if both are used, their
values MUST be identical.
3.9.1 StartTime
The StartTime class represents timestamp for the start of an
activity.
3.9.2 EndTime
The EndTime class represents the timestamp for the end of an
activity.
3.9.3 DetectTime
Meijer, et al. Expires September 29, 2003 [Page 26]
Internet-Draft IODEF Data Model and Implementation March 2003
The DetectTime class represents the timestamp of when an activity was
first detected.
3.9.4 ReportTime
The ReportTime class represents the timestamp of when a detected
activity was reported.
3.9.5 DateTime
The DateTime class is a generic representation of a timestamp. Its
semantics should be inferred from the parent class into which it is
aggregated.
3.10 Expectation class
The Expectation class conveys to the recipient of the IODEF document
the actions the sender is requesting.
+------------------+
| Expectation |
+------------------+
| ENUM restriction |<>--{1..*}--[ Description ]
| ENUM priority |
| ENUM category |<>--{0..1}--[ StartTime ]
| |
| |<>--{0..1}--[ EndTime ]
| |
| |<>--{0..1}--[ Contact ]
+------------------+
Figure 12: the Expectation class
The aggregate classes that constitute Expectation are:
Description
One or many. STRING. A free-form description of the desired
action(s).
StartTime
Zero or one. The time at which the action should be performed. A
timestamp that is earlier than the ReportTime specified in the
IncidentData class denotes that the expectation should be
fulfilled as soon as possible. The absence of this element leaves
the execution of the expectation to the discretion of the
recipient.
Meijer, et al. Expires September 29, 2003 [Page 27]
Internet-Draft IODEF Data Model and Implementation March 2003
EndTime
Zero or one. The time by which the action should be completed.
If the action is not carried out by this time, it should no longer
be performed.
Contact
Zero or one. The expected actor for the action. The 'role'
attribute of the Contact MUST be set to "actor".
The Expectations class has three attributes:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
priority
Optional. ENUM. Indicates the desired priority of the action.
This attribute is an enumerated list with no default value.
1. low. Low priority
2. medium. Medium priority
3. high. High priority
category
Optional. ENUM. Classifies the type of action requested. This
attribute is an enumerated list with no default value.
1. nothing. No action is requested. Do nothing with the
information.
2. contact-site. Contact the listed site in the recipient's
constituency.
3. contact-me. Contact the originator of the document.
4. block. Block or investigate machines listed in the document
in the recipient's constituency.
3.11 Method class
The Method class provides information about the methodology used by
the intruder to perpetrate the events of the incident. This class
can reference well-known vulnerability or exploit databases, list the
intruder tools used in the attack, and provide for a free-form
description of the activity.
Meijer, et al. Expires September 29, 2003 [Page 28]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| Method |
+------------------+
| ENUM restriction |<>--{0..*}--[ Classification ]
| |
| |<>--{0..*}--[ Description ]
+------------------+
Figure 13: The Method class
The Method class is composed of two aggregate classes.
Classification
Zero or many. A reference to a well-known vulnerability or
exploit databases.
Description
Zero or many. STRING A free-form text description of the
methodology used in the incident.
The Method class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.11.1 Classification class
The Classification class is a reference to an external database of
computer vulnerabilities, exposures, or viruses. A reference
consists of the database name, the entry in the database, and the URI
to this entry.
+------------------+
| Classification |
+------------------+
| ENUM restriction |<>----------[ name ]
| ENUM origin |
| |<>----------[ url ]
+------------------+
Figure 14: The Classification class
The aggregate classes that constitute Classification:
name
One. STRING. The name of the reference to the database specified
in the origin attribute.
Meijer, et al. Expires September 29, 2003 [Page 29]
Internet-Draft IODEF Data Model and Implementation March 2003
url
One. URI. A URL to additional information about the
vulnerability or exposure referenced by the name.
The Classification class has two attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
origin
Required. ENUM. The name of the database to which the reference
is being made. The permitted values are shown below.
1. bugtraqid. Bugtraq
2. cve. Common Vulnerabilities or Exposures
3. certcc. CERT Coordination Center Vulnerability Catalog
4. vendor. A product vendor whose name should be specified in
the name class
5. local. A local database.
6. other.
3.12 Assessment class
The Assessment class describes the technical and non-technical
repercussions of the incident activity.
Note: The IODEF definition of the Assessment class reuses the IDMEF
definition (see Section 4.2.4.5 of [7]), but also extends it.
Meijer, et al. Expires September 29, 2003 [Page 30]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| Assessment |
+------------------+
| ENUM restriction |<>--{0..*}--[ Impact ]
| |
| |<>--{0..*}--[ TimeImpact ]
| |
| |<>--{0..*}--[ MonetaryImpact ]
| |
| |<>--{0..*}--[ LifeImpact ]
| |
| |<>--{0..1}--[ Confidence ]
+------------------+
Figure 15: Assessment class
The aggregate classes that constitute Assessment are:
Impact
Zero or many. Technical impact of the activity on the computers
and networks.
TimeImpact
Zero or many. Impact of the activity measured with respect to
time.
MonetaryImpact
Zero or many. Impact of the activity measured with respect to
money.
LifeImpact
Zero or many. Impact of the activity measured with respect to
human life.
Confidence
Zero or one. An estimate of confidence in the assessment.
The Assessment class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.12.1 Impact class
The Impact class allows for classifying as well as providing a
description of the technical impact due to the incident activity on
the computers and networks of an organization.
Meijer, et al. Expires September 29, 2003 [Page 31]
Internet-Draft IODEF Data Model and Implementation March 2003
Attributes allow the impact to be classified according to the
consequences on the host and the severity of these consequences. The
element content is used for the description.
Note: The IODEF definition of the Impact class reuses the IDMEF
definition (see Section 4.2.6.1 of [7]), but also extends it and
alters the semantics.
+------------------+
| Impact |
+------------------+
| STRING |
| |
| ENUM restriction |
| ENUM severity |
| ENUM completion |
| ENUM type |
+------------------+
Figure 16: Impact class
The element content may be empty, or contain a free-form description
(STRING) of the technical impact.
The Impact class has four attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
completion
Optional. ENUM. An indication of whether the creator of the
IODEF document believes the activity was successful. The
permitted values are shown below. There is no default value.
1. failed. The attempt was not successful
2. succeeded. The attempt succeeded
Meijer, et al. Expires September 29, 2003 [Page 32]
Internet-Draft IODEF Data Model and Implementation March 2003
type
Required. ENUM. The type of impact in relatively broad
categories. The permitted values are shown below. The default
value is "unknown."
1. admin. Administrative privileges were attempted or obtained
2. dos. A denial of service was attempted or completed
3. file. An action on a file was attempted or completed
4. recon. A reconnaissance probe was attempted or completed
5. user. User privileges were attempted or obtained
6. none. The activity did not have any (technical) impact
7. unknown. The impact of the activity is unknown
8. other. Anything not in one of the above categories
3.12.2 TimeImpact class
The TimeImpact class describes the non-technical impact of the
activity on an organization as a function of time. Different types of
time calculations and well as units can be used.
+------------------+
| TimeImpact |
+------------------+
| REAL |
| |
| ENUM restriction |
| ENUM severity |
| ENUM metric |
| ENUM units |
+------------------+
Figure 17: TimeImpact class
The element content will be a numeric value (REAL) specifying the
impact as a function of time. The attributes represent the specific
units and metric.
The TimeImpact class has four attributes:
Meijer, et al. Expires September 29, 2003 [Page 33]
Internet-Draft IODEF Data Model and Implementation March 2003
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
metric
Required. ENUM. Defines the metric in which the time is
expressed. The permitted values are shown below. There is no
default value.
1. labor. Total staff-time to recovery from the activity (e.g.,
2 employees working 4 hours each would be 8 hours)
2. elapsed. Elapsed time from the beginning of the recovery to
its completion.
3. downtime. Duration of time for which some provided service(s)
was not available.
units
Required. ENUM. Defines the units in which the metric is
expressed. The permitted values are shown below. The default
value is "hours".
1. seconds. Seconds
2. minutes. Minutes
3. hours. Hours
4. days. Days
3.12.3 MonetaryImpact class
The MonetaryImpact class describes the financial impact of the
activity on an organization. For example, this impact may consider
loss due to the cost of the investigation or recovery, diminished
productivity of the staff, or a tarnished reputation that will affect
Meijer, et al. Expires September 29, 2003 [Page 34]
Internet-Draft IODEF Data Model and Implementation March 2003
future opportunities.
+------------------+
| MonetaryImpact |
+------------------+
| REAL |
| |
| ENUM restriction |
| ENUM severity |
| ENUM metric |
| STRING currency |
+------------------+
Figure 18: MonetaryImpact class
The element content will be a numeric value (REAL) specifying the
impact as a function of money. The attributes represent the specific
currency and metric.
The MonetaryImpact class has four attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
currency
Required. ENUM. Defines the currency in which the monetary
impact is expressed. The permitted values are defined in ISO
4217:2001, Codes for the representation of currencies and funds
[18]. There is no default value.
3.12.4 LifeImpact class
The LifeImpact class describes the loss of human life or injury due
to an incident.
Meijer, et al. Expires September 29, 2003 [Page 35]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| LifeImpact |
+------------------+
| INTEGER |
| |
| ENUM restriction |
| ENUM severity |
| ENUM metric |
+------------------+
Figure 19: LifeImpact class
The element content will be a numeric value (INTEGER) specifying the
impact as a function of human life. The attributes represent the
specific metric.
The LifeImpact class has three attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
metric
Required. ENUM. Defines the metric in which the LifeImpact is
expressed. The permitted values are shown below. There is no
default value.
1. Deaths
2. Injuries
3.12.5 Confidence class
The Confidence class represents a best estimate of the validity and
accuracy of the described impact (see Section 3.12) of the incident
activity. This estimate can be expressed as a category, or a numeric
calculation.
Meijer, et al. Expires September 29, 2003 [Page 36]
Internet-Draft IODEF Data Model and Implementation March 2003
Note: The IODEF definition of the Confidence class reuses the IDMEF
definition (see Section 4.2.6.3 of [7]), but also extends it and
alters the semantics.
The Confidence class has been reused from the IDMEF [7], it has been
extended and has been altered.
+------------------+
| Confidence |
+------------------+
| REAL |
| |
| ENUM restriction |
| ENUM rating |
+------------------+
Figure 20: Confidence class
The element content may be empty if the rating attribute is not set
to "numeric". Otherwise, a confidence value (REAL) must be provided.
The Confidence class has two attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
rating
Required. ENUM. Indicates the confidence the CSIRT has in its
assessment. The permitted values are shown below. The default
value is "numeric."
1. low
2. medium
3. high
4. numeric. The CSIRT has provided a probability value
indicating its confidence in its assessment.
5. unknown
This element SHOULD only be used when the CSIRT can produce
meaningful information. When only a rough estimate is possible
"low", "medium", or "high" SHOULD be used as the rating value.
When a reasonable probability estimate is possible "numeric" SHOULD
Meijer, et al. Expires September 29, 2003 [Page 37]
Internet-Draft IODEF Data Model and Implementation March 2003
be used as the rating value and include a numeric confidence value in
the element content. This numeric value is a floating point number
between 0.0 and 1.0, inclusive.
Different CSIRTs may compute and represent confidence values in
different ways. Care should be taken to take proper notice of the
exact meaning of the confidence values of different CSIRTs when
comparing confidence values.
3.13 History class
The History class is a log or diary of the significant events that
occurred or actions performed by the involved parties (e.g., initial
reporter, investigating CSIRT, or involved system administrators)
during the course of handling the incident.
The level of detail maintained in this log is left up to the
discretion of those handling the incident.
+------------------+
| History |
+------------------+
| ENUM restriction |<>--{1..*}--[ HistoryItem ]
| |
+------------------+
Figure 21: The History class
The class that constitute History are:
HistoryItem
One or many. Entries in the history log of significant events or
actions performed by the involved parties.
The History class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.13.1 HistoryItem class
The HistoryItem class is a particular entry in the History (Section
3.13) log that documents a particular significant action or event
that occurred in the course of handling the current incident. This
details of the entry in this log are a free-form description, but
each can also be categorized.
Meijer, et al. Expires September 29, 2003 [Page 38]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| HistoryItem |
+------------------+
| ENUM restriction |<>--{0..1}--[ IncidentID ]
| ENUM type |
| |<>----------[ DateTime ]
| |
| |<>--{1..*}--[ Description ]
+------------------+
Figure 22: HistoryItem class
The aggregate classes that constitute HistoryItem are:
IncidentID
Zero or One. In history logs created by multiple parties, the
IncidentID provides a way specify which CSIRT created the
particular entry and reference this organizations local incident
tracking number for this activity. When a single organization is
maintaining the history log, this class can be ignored.
DateTime
One. Timestamp of the this entry in the history log (e.g., when
the action described in the Description was taken).
Description
One or many. STRING. A free-form textual description of the
action or event to be document in the history log.
The HistoryItem class has two attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
type
Optional. ENUM. Classifies the type of activity or event being
document in this history log entry. The particular details of the
entry are a free-form description documented in the Description
class. Possible values are an enumerated list whose default value
is "other":
1. triaged. The incident data was received and processed by an
IHS
2. notification. Notification to an involved party in the
incident was sent (e.g., a CSIRT sending a message to the
attacking site).
Meijer, et al. Expires September 29, 2003 [Page 39]
Internet-Draft IODEF Data Model and Implementation March 2003
3. shared-info. Information about this incident was shared with
party not directly involved.
4. received-info. Additional information about the incident was
received
5. remediation. The incident has been resolved; a short
description may be included.
6. other.
3.14 EventData class
The EventData class describes the events of the incident surrounding
a particular set of hosts or networks. This description includes the
systems from which the activity originated and those targeted, an
assessment of the techniques used by the intruder, the impact of the
activity on the organization, a list of incident handling tasks
performed, and and any forensic evidence discovered.
Meijer, et al. Expires September 29, 2003 [Page 40]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| EventData |
+------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| |
| |<>--{0..1}--[ Assessment ]
| |
| |<>--{0..*}--[ Method ]
| |
| |<>--{0..1}--[ DetectTime ]
| |
| |<>--{0..1}--[ StartTime ]
| |
| |<>--{0..1}--[ EndTime ]
| |
| |<>--{0..*}--[ Contact ]
| |
| |<>--{0..1}--[ History ]
| |
| |<>--{0..*}--[ System ]
| |
| |<>--{0..1}--[ Record ]
| |
| |<>--{0..*}--[ EventData ]
| |
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 23: The EventData class
The aggregate classes that constitute EventData are:
Description
Zero or more. STRING. A free-form textual description of the
event.
System
Zero or more. The systems (nodes, networks) involved in the event
as either sources, targets or intermediaries.
Method
Zero or more. The methods by which the event was staged.
Information about tools used and vulnerabilities exploited.
Record
Zero or one. Support data (e.g., log files) that provides
information on the events.
Meijer, et al. Expires September 29, 2003 [Page 41]
Internet-Draft IODEF Data Model and Implementation March 2003
StartTime
Zero or one. The time the event started.
EndTime
Zero or one. The time the event ended.
DetectTime
Zero or one. The time the event was detected.
Contact
Zero or more. The different parties involved in the incident
Assessment
Zero or one. Indicates the impact of the incident on the target
and the actions taken.
AdditionalData
Zero or one. Anything that can not be put in one of the other
elements
Event
Zero or more. Recursive definition of Event, allowing for
grouping of data
The EventData class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.15 Relating the IncidentData and EventData classes
At first glance, the duplication in the aggregate classes of
IncidentData and EventData are obvious. However, the semantics of
these classes are quite different. IncidentData provides summary
information about the entire incident, while EventData provides
information about a subset of the incident.
For example, note that the Assessment class is aggregated in both
classes. Consider a case where IncidentData:Assessment:MonetaryImpact
has been assigned a value of x. Now, consider a value of y (where y
< x) being assigned to a given MonetaryImpact class that is
aggregated in the EventData class. The semantics of these two values
is some monetary loss. In the case of the figure in the IncidentData
class, this loss is incident-wide. The figure in EventData is a
subset of this overall loss, and allows one to associate a particular
loss with a given subset of events that constitute the incident. It
effectively provides a breakdown (or more specific description) of
Meijer, et al. Expires September 29, 2003 [Page 42]
Internet-Draft IODEF Data Model and Implementation March 2003
the overall loss previously specified in the IncidentData class.
3.16 Cardinality of EventData
The recursive definition of this class (the EventData class is
aggregated into the EventData class) provides a way to related
information without requiring the explicit use of unique attribute
identifiers in the classes. The depth of an element in the XML tree
is used to related information.
The EventData class can be thought of as a container describing the
properties of an event in an incident. These properties include: the
hosts involved, impact of the incident activity on the hosts,
forensic logs, etc. One groups (via an instance of the EventData
class) hosts (i.e., System class) around these common properties.
A child EventData class (and all its siblings) logically "inherits"
the aggregated classes of a parent EventData class. However, the
presence of sibling EventData classes (it "never" makes sense to have
only one EventData child in an EventData class) means that there are
some disjoin properties of the event. These children of the parent
EventData class represent these differences, while still retaining a
way to represent the common properties (i.e., the parent-child
relationship).
For example, an EventData class might be used to describe two
machines involved in an incident. This description can be achieved
using multiple instances of the System class. It happens that the
technical contact (i.e., Contact class) for these two machines is
identical, but the impact (i.e., Assessment class) is different. The
problem lies in representing two hosts with a common contact, but
different impacts without duplicating any information. This event
can be represent with the following design represented in Figure 24.
Meijer, et al. Expires September 29, 2003 [Page 43]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| EventData |
+------------------+
| |<>----[ Contact ]
| |
| |<>----[ EventData ]<>----[ System ]
| | [ ]<>----[ Assessment ]
| |
| |<>----[ EventData ]<>----[ System ]
| | [ ]<>----[ Assessment ]
+------------------+
Figure 24: Recursion in the EventData class
3.17 System class
The System class represents the technical information for a given
computer or network involved in the incident.
The systems represented by this class are categorized according to
the role they played in the incident via through the category
attribute. The value of this category attribute dictates the
semantics of the aggregated classes in the System class.
The meaning of the Node, User, Process, and Service class depend on
the value of the category attribute of the System class. If the
System class category attribute is 'source', then the described
aggregated classes denote the machine, user, process, or service from
which the activity is originating. With a category attribute value
of 'target' or 'intermediary', then the described machine, user,
process, or service is the one targeted in the activity.
Meijer, et al. Expires September 29, 2003 [Page 44]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| System |
+------------------+
| ENUM restriction |<>----------[ Node ]
| ENUM category |
| STRING interface |<>--{0..*}--[ User ]
| ENUM spoofed |
| |<>--{0..*}--[ Process ]
| |
| |<>--{0..*}--[ Service ]
| |
| |<>--{0..1}--[ FileList ]
+------------------+
Figure 25: the System class
The aggregate classes that constitute System are:
Node
One. A host or network involved in the incident activity.
User
Zero or more. The application or operating system user running on
the specified host that was involved in the incident.
Process
Zero or more. The process targeted or the source of the attack on
the specified host,
Service
Zero or one. The network service targeted on the host specified
in Node.
FileList
Zero or one. Information about the files on the host involved in
the incident.
The System class has four attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
category
Required. ENUM. Classifies the role the System played in the
incident activity. The possible values are:
1. source. The System was the source of the attack
Meijer, et al. Expires September 29, 2003 [Page 45]
Internet-Draft IODEF Data Model and Implementation March 2003
2. target. The System was the target of the attack
3. intermediate. The System was an intermediate machine used in
the attack.
interface
Optional. STRING. Specifies the interface on which the event(s)
on this System originated.
spoofed
Optional. ENUM. An indication of confidence as to whether this
System was the true target or attacking host. The permitted
values for this attribute are shown below. The default value is
"unknown".
1. unknown. The accuracy of the category information is unknown
2. yes. The category value classifying the host or network as an
source or target is probably incorrect. In the case of a
source, the System is likely a decoy; with a target, the
System was likely not the intended victim.
3. no. The category value classifying the host or network as a
source or target is believed to be correct.
3.18 Node class
The Node class is used to identify a host or network device (e.g.,
routers, switches).
The base definition of the class is reused from the IDMEF
specification, see Section 4.2.7.1 of [7]. However, the class has
been extended by adding the NodeRole class.
Meijer, et al. Expires September 29, 2003 [Page 46]
Internet-Draft IODEF Data Model and Implementation March 2003
+---------------+
| Node |
+---------------+
| ENUM category |<>--{0..1}--[ Location ]
| |
| |<>--{0..1}--[ name ]
| |
| |<>--{0..*}--[ Address ]
| |
| |<>--{0..1}--[ DateTime ]
| |
| |<>--{0..*}--[ NodeRole ]
+---------------+
Figure 26: The Node class
The aggregate classes that constitute Node are:
Location
Zero or one. STRING. The physical location of the equipment.
name
Zero or one. STRING. The name of the equipment (e.g., fully
qualified domain name). This information MUST be provided if no
Address information is given.
Address
Zero or more. The network or hardware address of the equipment.
Unless a name is provided, at least one address must be specified.
DateTime
Zero or one. A timestamp of when the resolution between the name
and address was performed. This information SHOULD be provided if
both an Address and name are given.
NodeRole
Zero or more. The intended purpose of the equipment.
The Node class has one attribute:
category
Optional. ENUM. The context in which the Address and name
classes should be considered, if relevant. The permitted values
for this attribute are shown below. The default value is
"unknown".
1. unknown. Domain unknown or not relevant
Meijer, et al. Expires September 29, 2003 [Page 47]
Internet-Draft IODEF Data Model and Implementation March 2003
2. ads. Windows 2000 Advanced Directory Services
3. afs. Andrew File System (Transarc)
4. coda. Coda Distributed File System
5. dfs. Distributed File System (IBM)
6. dns. Domain Name System
7. hosts. Local hosts file
8. kerberos. Kerberos realm
9. nds. Novell Directory Services
10. nis. Network Information Services (Sun)
11. nisplus. Network Information Services Plus (Sun)
12. nt. Windows NT domain
13. wfw. Windows for Workgroups
3.18.1 Address
The Address class represents a network, hardware, and application
address. This class is reused outright from the IDMEF specification,
see Section 4.2.7.1.1 of [7].
3.18.2 NodeRole class
The NodeRole class describes (based on a pre-defined list) the
function performed by a particular host.
Meijer, et al. Expires September 29, 2003 [Page 48]
Internet-Draft IODEF Data Model and Implementation March 2003
+---------------+
| NodeRole |
+---------------+
| STRING |
| |
| ENUM category |
+---------------+
Figure 27: The NodeRole class
The element content should be empty in all cases other than when the
category attribute is set to "other".
The NodeRole class has one attributes:
category
Required. Functionality provided by a node. If a value of
"other" is specified, a description SHOULD be provided in the
element's content. The default value is "other".
1. client. Client computer
2. server-internal. Server with internal services
3. server-public. Server with public services
4. www. WWW server
5. mail. Mail server
6. messaging. Messaging server (e.g. NNTP, IRC, IM)
7. streaming. Streaming-media server
8. voice. Voice server (e.g. SIP, H.323)
9. file. File server (e.g. SMB, CVS, AFS)
10. ftp. FTP server
11. p2p. Peer-to-peer node
12. name. Name server (e.g. DNS, WINS)
13. directory. Directory server (e.g. LDAP, finger, whois)
14. credential. Credential server (e.g. domain controller,
Kerberos)
Meijer, et al. Expires September 29, 2003 [Page 49]
Internet-Draft IODEF Data Model and Implementation March 2003
15. print. Print server
16. application. Application server
17. database. Database server
18. infra. Infrastructure server (e.g. router, firewall, DHCP)
19. log. Logserver
20. other. other role not in this list
3.19 FileList class
The FileList class describes files and other file-like objects on
hosts involved in an incident. This class is reused outright from
the IDMEF specification, see Section 4.2.7.5 of [7].
3.20 User
The User class describes an application or operating system user
account involved in an incident. This class is reused outright from
the IDMEF specification, see Section 4.2.7.2 of [7].
3.21 Process
The Process class describes a running program on a given host
involved in an incident. This class is reused outright from the
IDMEF specification, see Section 4.2.7.3 of [7].
3.22 Service
The Service class describes a network service of a host. This class
is reused outright from the IDMEF specification, see Section 4.2.7.4
of [7].
3.23 Record class
The Record class groups log or audit data that provides a record of
the incident activity. The source of this data will typically be the
output of monitoring tools (e.g., IDMEF messages generated by an IDS,
connection logs from a web server) that were used to uncover the
malicious activity. These logs should provide evidence as to why a
reporter to CSIRT believes an incident has occurred.
Meijer, et al. Expires September 29, 2003 [Page 50]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| Record |
+------------------+
| ENUM restriction |<>--{1..*}--[ RecordData ]
+------------------+
Figure 28: Record class
The aggregate class that constitutes Record is:
RecordData
One or more. Log or audit data generated by a particular type of
sensor.
The Record class has one attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.23.1 RecordData class
The RecordData class groups log or audit data from a given sensor
(e.g., IDS, firewall log) and provides a way to annotate the output.
+------------------+
| RecordData |
+------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ]
| |
| |<>--{0..*}--[ Description ]
| |
| |<>--{0..1}--[ Analyzer ]
| |
| |<>--{1..*}--[ RecordItem ]
+------------------+
Figure 29: The RecordData class
The aggregate classes that constitutes RecordData is:
DateTime
Zero or one. Timestamp information for the RecordItem data.
Description
Zero or more. STRING. Free-form textual description of the
provided RecordItem data. At minimum, this description should
Meijer, et al. Expires September 29, 2003 [Page 51]
Internet-Draft IODEF Data Model and Implementation March 2003
convey the significance of the provided RecordItem data.
Analyzer
Zero or one. Information about the sensor used to generate the
RecordItem data.
RecordItem
One or more. Log, audit, or forensic data.
The RecordData class has one attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.23.1.1 Analyzer class
The Analyzer class identifies the sensor (e.g., IDS, firewall, web
server) used to generate particular log or audit data. The definition
of the class is reused from the IDMEF specification, see Section
4.2.7.3 of [7]. However, in this context, the definition of an
analyzer is expanded beyond merely an IDS.
3.23.1.2 RecordItem class
The RecordItem class provides a way to incorporate relevant logs,
audit trails, or forensic data to support the conclusions made during
the course of analyzing the incident. This data can be directly
encapsulated as part of this document, or can be referenced whereby
using this class as merely a pointer to the relevant information.
The dtype attribute will dictate the type of log data that will be
found in this class. This class is very similar to the
AdditionalData class (Section 3.6) in that it is essentially an
extension class that can support proprietary representations of
security event data, not all of which is necessarily in XML.
Meijer, et al. Expires September 29, 2003 [Page 52]
Internet-Draft IODEF Data Model and Implementation March 2003
+------------------+
| RecordItem |
+------------------+
| ANY |
| |
| ENUM type |
+------------------+
Figure 30: The RecordItem class
The Recorditem class has one attribute:
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".
1. boolean. The element contains a boolean value, i.e., the
strings "true" or "false"
2. byte. The element content is a single 8-bit byte (see
Section 2.2.4);
3. character. The element content is a single character (see
Section 2.2.3);
4. date-time. The element content is a date-time string (see
Section 2.2.6);
5. integer. The element content is an integer (see Section
2.2.1);
6. ntpstamp. The element content is a NTP timestamp (see
Section 2.2.7);
7. portlist. The element content is a port list (see Section
2.2.8);
8. real. The element content is a real number (see xref
target="dt_real_numbers" />);
9. string. The element content is a string (see Section 2.2.3);
10. file. The element content is a base64 encoded binary file;
11. path. The element content is a filesystem path;
12. url. The element content is a URL (see Section 2.2.13;)
Meijer, et al. Expires September 29, 2003 [Page 53]
Internet-Draft IODEF Data Model and Implementation March 2003
13. xml. The element content is XML-tagged data (see Section 4).
Meijer, et al. Expires September 29, 2003 [Page 54]
Internet-Draft IODEF Data Model and Implementation March 2003
4. Extending the IODEF
In order to support the changing activity of CSIRTS, the IODEF data
model and DTD will need to evolve along with them. To allow new
features to be added, both the data model and the DTD can be extended
as described in this section. As these extensions mature, they can
then be incorporated into future versions of the specification or
published separately.
4.1 Extending the data model
There are two mechanisms for extending the IODEF data model:
inheritance and aggregation.
o By using inheritance, new subclasses may be derived and given
additional attributes or operations not found in the superclass.
o Aggregation allows for entirely new, self-contained classes to be
created and associated with a parent class.
Of the two extension mechanisms, inheritance is preferred, because it
preserves the existing data model and the operations (methods)
executed on the classes of the model. There are explicit guidelines
for extending the XML DTD (see Section 4.2) which set limits on where
extensions to the data model may be made.
4.2 Extending the XML DTD
There are two ways to extend the IODEF XML DTD:
1. The AdditionalData (see Section 3.6) and RecordItem (see Section
3.23.1.2) classes allow implementers to include arbitrary
"atomic" data. (e.g., integers, strings). This approach SHOULD
be used whenever possible.
2. The AdditionalData and RecordItem classes allow implementers to
extend the IODEF XML DTD with additional DTDs that describe
arbitrarily complex data types and relationships.
The following guidelines MUST be followed when extending the IODEF
DTD with another DTD in the extension classes:
1. The IODEF description MUST include a document type declaration
(see Section 2.1.1.3);
2. The document type declaration MUST define a parameter entity that
contains the location of the extension DTD, and then reference
Meijer, et al. Expires September 29, 2003 [Page 55]
Internet-Draft IODEF Data Model and Implementation March 2003
that entity:
% x-extension; ]>
In this example, the "x-extension" parameter entity is defined
and then referenced, causing the DTD for the extension to be read
by the XML parser.
The name of the parameter entity defined for this purpose MUST be
a string beginning with "x-"; there are no other restrictions on
the name (other than those imposed on all entity names by XML).
Multiple extensions may be included by defining multiple entities
and referencing them. For example:
%x-extension;
%x-another; ]>
3. Extension DTDs MUST declare all of their elements and attributes
in a separate XML namespace. Extension DTDs MUST NOT declare any
elements or attributes in the "IODEF" or default namespaces.
For example, the "test" extension might be declared as follows:
4. Extensions MUST only be included in the AdditionalData class of
the Incident class whose "type" attribute is "xml". For example:
Meijer, et al. Expires September 29, 2003 [Page 56]
Internet-Draft IODEF Data Model and Implementation March 2003
...
...
...
...
Meijer, et al. Expires September 29, 2003 [Page 57]
Internet-Draft IODEF Data Model and Implementation March 2003
5. Processing Considerations
This section discusses some of the special considerations that must
be taken into account by implementers of the IODEF.
5.1 XML Validity and Well-Formedness
The IODEF documents MUST be well-formed, and when possible and
practical the documents SHOULD also be valid.
It is expected that IODEF-compliant applications will normally not
include the IODEF DTD in their communications. Instead, the DTD will
be referenced in the document type declaration section of the IODEF
document (see Section 2.1.1.3.
While an XML document SHOULD contain a document type declaration.
This requirement imposes a significant overhead on an IODEF-compliant
application in bandwidth consumption and computation for the DTD may
need to be downloaded and parsed before use by the XML parser.
Implementers MAY decide to have entities who regularly exchange IODEF
message 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 it from IODEF documents.
The method for negotiating this agreement is outside the scope of
this document.
NOTE: Care must be taken in negotiating any such agreements, as each
entities will have to keep state on this agreed upon document type
definition. The management complexity of these negotiations grows
more complex as entities make such arrangements with many
collaborators.
5.2 Unrecognized Data and XML Tags
On occasion, an IODEF-compliant application may receive a well-
formed, or well-formed and valid IODEF document containing tags or
content in the tags that are not expected. These spurious conditions
might include:
o Unrecognized tags used in one of the extension classes (i.e.,
AdditionalData or RecordItem);
o Unrecognized tags outside of the extension classes; or
o Well-formed and validate document where element or attribute
values to not conform to the expected values identified by an
enumerated list;
Meijer, et al. Expires September 29, 2003 [Page 58]
Internet-Draft IODEF Data Model and Implementation March 2003
IODEF-compliant applications MUST continue to process IODEF documents
that contain unknown tags, provided that these documents are
well-formed. It is up to the individual application to decide how to
process any content from the unknown tag.
Meijer, et al. Expires September 29, 2003 [Page 59]
Internet-Draft IODEF Data Model and Implementation March 2003
6. Internationalization issues
Internationalization and localization is of specific concern to the
IODEF. It is only through collaboration, often across language
barriers, that certain incidents be resolved.
XML already supports different character encodings. This flexibility
will allow information encoded in the IODEF to be in most written
languages. Furthermore, XML also provides the xml:lang attribute
through which the type of language being used in a given element can
be specified. By including this attribute in the %attlist.global
entity found in all elements, users of the IODEF can use different
languages in the same document.
The data model ensures that the cardinality of the Description class
is always one-to-many with its parent. One of the intents for this
design was to allow the same description to be repeated in another
instance of the Description class, but in a different language.
Parsers of the IODEF document, could extract only the elements with
the relevant language.
Supporting different languages allows CSIRTs to localize the IODEF.
However, it does not aid data interchange if the recipient of a
document does not understand the underlying language. In order to
ensure that the recipient can at least crudely approximate the
contents of the document, the data model relies on enumerated
attributes that are standardized to convey meaning (e.g.,
%attlist.purpose).
Meijer, et al. Expires September 29, 2003 [Page 60]
Internet-Draft IODEF Data Model and Implementation March 2003
7. Examples
These examples provide an idea of what IODEF-Documents can look like.
It must be stressed that as IODEF is a data-exchange-format, it does
not specify detailed rules on which elements and attributes to use
under all imaginable circumstances.
7.1 Code Red detection notification
The following message is a typical example of an incident where one
host is infected with a worm. The initial report is sent in by
email, the subsequently shown IODEF-Document illustrates the
communication between the responsible CSIRT and its constituent. The
constituent is a contact for the CSIRT and responsible for
coordinating the required actions at his site.
From e-citizen@hisdomain.de
Date: 13 Sep 2001 23:19:24 -0000
From: e-citizen@hisdomain.de
To: cert-for-ourdomain.pl@ourdomain.pl
Subject: 10.1.1.2 - Code Red Virus detected
Automated message,
you don't have to reply to this email.
Your system with the IP number 10.1.1.2 seems to be infected
with the Code Red virus.
For more information see http://www.incidents.org/react/code_redII.php
Please fix the problem or inform a person who is responsible
for that machine to do so.
>From our web server logs (Port 80):
10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Figure 35: Code Red detection notification: initial report
CERT-FOR-OUR-DOMAIN.PL#189
Meijer, et al. Expires September 29, 2003 [Page 61]
Internet-Draft IODEF Data Model and Implementation March 2003
Host sending out Code Red probes
2001-09-13T23:19:24+00:00
Track and clean host
CERT-FOR-OUR-DOMAIN.PL
cert-for-our-domain.pl@ourdomain.pl
Constituency-contact for 10.1.1.2
Constituency-contact@10.1.1.2.pl
CERT-FOR-OUR-DOMAIN.PL#189
Notification sent to
Constituency-contact@10.1.1.2.pl
2001-09-14T08:19:01+00:00
10.1.1.2
80
2001-09-13T18:11:21+02:00
Web-server logs
10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Meijer, et al. Expires September 29, 2003 [Page 62]
Internet-Draft IODEF Data Model and Implementation March 2003
Figure 36: Code Red detection notification: CSIRT response
7.2 IODEF-Document with XML signature
7.3 IODEF-Document encrypted using XML encryption
7.4 IODEF-Document encrypted and signed using XML signature & encryption
Meijer, et al. Expires September 29, 2003 [Page 63]
Internet-Draft IODEF Data Model and Implementation March 2003
8. The IODEF Document Type Definition
Meijer, et al. Expires September 29, 2003 [Page 67]
Internet-Draft IODEF Data Model and Implementation March 2003
Meijer, et al. Expires September 29, 2003 [Page 68]
Internet-Draft IODEF Data Model and Implementation March 2003
Meijer, et al. Expires September 29, 2003 [Page 71]
Internet-Draft IODEF Data Model and Implementation March 2003
Meijer, et al. Expires September 29, 2003 [Page 72]
Internet-Draft IODEF Data Model and Implementation March 2003
Meijer, et al. Expires September 29, 2003 [Page 76]
Internet-Draft IODEF Data Model and Implementation March 2003
9. Security considerations
Due to the sensitive nature of some of the data that might be
represented in the IODEF, the integrity, confidentiality, and
non-repudiation of these documents in transit SHOULD be ensured.
Although this protection can be provided by the transport mechanism,
applying this security to an instance of the IODEF itself is
RECOMMENDED. However, the specific protective measures applied to an
IODEF document (be in through XML or the underlying transport
protocol) should be driven by the requirements of the collaborators.
The applied protective measures MUST use cryptographic techniques.
XML Digital Signatures [16] SHOULD be used for ensuring integrity
and non-repudiation, and XML Encryption [17] SHOULD be used to ensure
the confidentiality of an IODEF document. Examples using signatures
and encryption on an IODEF document can be found in the Examples
chapter (Section 7):
o IODEF-Document with XML signature (Section 7.2)
o IODEF-Document encrypted using XML encryption (Section 7.3)
o IODEF-Document encrypted and signed using XML signature &
encryption (Section 7.4)
Information on the implementation-specifics of applying XML Digital
Signatures and XML Encryption to an IODEF-Document can be found in
the IODEF Implementation Guide [20].
When using cryptographic techniques the issue of key management
(whether symmetric or public key cryptography is used) must be
addressed.
Overall security measures must be applied to secure the
IODEF-Document processing environment. The definition of these
measures is outside the scope of this memo.
Meijer, et al. Expires September 29, 2003 [Page 77]
Internet-Draft IODEF Data Model and Implementation March 2003
10. IANA considerations
Meijer, et al. Expires September 29, 2003 [Page 78]
Internet-Draft IODEF Data Model and Implementation March 2003
11. Acknowledgments
The following groups contributed substantially to this document and
should be recognized for their efforts. This document would not exist
without their help:
o the Incident Object Description and Exchange Format Working-Group
of the TERENA task-force (TF-CSIRT)
o the eCSIRT.net project
Meijer, et al. Expires September 29, 2003 [Page 79]
Internet-Draft IODEF Data Model and Implementation March 2003
Normative References
[1] Demchenko, Y., Hiroyuki, H. and G. Keeni, "Requirements for
Format for Incident Report Exchange", RFC XXX, September 2003.
[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", , October 2000, .
[3] World Wide Web Consortium, "Namespaces in XML", , January 1999,
.
[4] World Wide Web Consortium, "Extensible Stylesheet Language
(XSL) Version 1.0", , October 2001, .
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] Alvestrand, H., "Tags for the Identification of Languages", RFC
3066, January 2001.
[7] Curry, D. and H. Debar, "Intrusion Detection Message Exchange
Format", RFC XXX, January 2003.
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[9] Freed, N., "IANA Charset Registration Procedures", BCP 2278,
January 1998.
[10] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation, and Analysis", BCP 2278, March 1992.
[11] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 2030, October 1996.
[12] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[13] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[14] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[15] International Organization for Standardization, "International
Standard: Data elements and interchange formats - Information
Meijer, et al. Expires September 29, 2003 [Page 80]
Internet-Draft IODEF Data Model and Implementation March 2003
interchange - Representation of dates and times", ISO 8601,
Second Edition, December 2000.
[16] Eastlake 3rd, D., Reagle, J. and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, March
2002.
[17] Imamura, T., Dillaway, B. and E. Simon, "XML Encryption Syntax
and Processing, W3C Recommendation", December 2002, .
[18] International Organization for Standardization, "International
Standard: Codes for the representation of currencies and funds,
ISO 4217:2001", ISO 4217:2001, August 2001.
Meijer, et al. Expires September 29, 2003 [Page 81]
Internet-Draft IODEF Data Model and Implementation March 2003
Informative References
[19] Rumbaugh, J., Jacobson, I. and G. Booch, "The Unified Modeling
Language Reference Model, ISBN 020130998X, Addison-Wesley",
1998.
[20] Helme, A. and R. Danyliw, "The IODEF Implementation Guide,
document to be created by the INCH WG", 2003.
Authors' Addresses
Jan Meijer
SURFnet bv
P.O. Box 19035
Utrecht NL-3501 DA
Netherlands
Phone: +31 302 305 305
EMail: jan.meijer@surfnet.nl
Roman Danyliw
CERT Coordination Center
4500 Fifth Ave.
Pittsburgh, PA 15213
USA
Phone: +1 412 268 7090
EMail: rdd@cert.org
Yuri Demchenko
NLnet Labs
Netherlands
EMail: demch@chello.nl
Meijer, et al. Expires September 29, 2003 [Page 82]
Internet-Draft IODEF Data Model and Implementation March 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Meijer, et al. Expires September 29, 2003 [Page 83]
Internet-Draft IODEF Data Model and Implementation March 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Meijer, et al. Expires September 29, 2003 [Page 84]