Extended Incident Handling R. Danyliw
Working Group CERT/CC
Internet-Draft J. Meijer
Expires: May 13, 2006 SURFnet bv
Y. Demchenko
University of Amsterdam
November 9, 2005
The Incident Object Description Exchange Format Data Model and XML
Implementation
draft-ietf-inch-iodef-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 May 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The purpose of the Incident Object Description Exchange Format
(IODEF) is to define a data representation that provides a framework
for sharing information commonly exchanged by Computer Security
Incident Response Teams (CSIRTs) about computer security incidents.
Danyliw, et al. Expires May 13, 2006 [Page 1]
Internet-Draft IODEF Data Model November 2005
The IODEF satisfies the requirements specified in RFCXXX [1]
This Internet-Draft describes a data model for representing incident
information exported from incident handling systems managed by
CSIRTs. An implementation of the data model in the Extensible Markup
Language (XML) is presented, an XML Document Type Definition is
developed, and examples are provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 About the IODEF Data Model . . . . . . . . . . . . . . . . 5
1.4 About the IODEF Implementation . . . . . . . . . . . . . . 6
1.5 About the Transport Protocol . . . . . . . . . . . . . . . 7
1.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . 7
2. Formatting Issues . . . . . . . . . . . . . . . . . . . . . 9
2.1 IODEF XML Documents . . . . . . . . . . . . . . . . . . . 9
2.1.1 The Document Prolog . . . . . . . . . . . . . . . . . 9
2.1.2 Languages in the IODEF . . . . . . . . . . . . . . . . 10
2.2 IODEF Data Types . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Integers . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Real Numbers . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Characters and Strings . . . . . . . . . . . . . . . . 11
2.2.4 Multilingual Strings . . . . . . . . . . . . . . . . . 11
2.2.5 Bytes . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.6 Hexadecimal Bytes . . . . . . . . . . . . . . . . . . 11
2.2.7 Enumerated Types . . . . . . . . . . . . . . . . . . . 12
2.2.8 Date-Time Strings . . . . . . . . . . . . . . . . . . 12
2.2.9 Port Lists . . . . . . . . . . . . . . . . . . . . . . 12
2.2.10 Postal Address . . . . . . . . . . . . . . . . . . . 12
2.2.11 Person or Organization . . . . . . . . . . . . . . . 12
2.2.12 Telephone and Fax Numbers . . . . . . . . . . . . . 13
2.2.13 Email string . . . . . . . . . . . . . . . . . . . . 13
2.2.14 Uniform Resource Identifier strings . . . . . . . . 13
2.2.15 Timezone string . . . . . . . . . . . . . . . . . . 13
2.2.16 Unique Identifiers . . . . . . . . . . . . . . . . . 13
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . 14
3.1 IODEF-Document class . . . . . . . . . . . . . . . . . . . 14
3.2 Incident class . . . . . . . . . . . . . . . . . . . . . . 14
3.3 IncidentID class . . . . . . . . . . . . . . . . . . . . . 17
3.4 AlternativeID class . . . . . . . . . . . . . . . . . . . 18
3.5 RelatedActivity class . . . . . . . . . . . . . . . . . . 19
3.6 AdditionalData . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Contact class . . . . . . . . . . . . . . . . . . . . . . 21
3.7.1 RegistryHandle class . . . . . . . . . . . . . . . . . 24
3.8 Time classes . . . . . . . . . . . . . . . . . . . . . . . 24
Danyliw, et al. Expires May 13, 2006 [Page 2]
Internet-Draft IODEF Data Model November 2005
3.8.1 StartTime . . . . . . . . . . . . . . . . . . . . . . 25
3.8.2 EndTime . . . . . . . . . . . . . . . . . . . . . . . 25
3.8.3 DetectTime . . . . . . . . . . . . . . . . . . . . . . 25
3.8.4 ReportTime . . . . . . . . . . . . . . . . . . . . . . 25
3.8.5 DateTime . . . . . . . . . . . . . . . . . . . . . . . 25
3.9 Method class . . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1 Classification class . . . . . . . . . . . . . . . . . 26
3.10 Assessment class . . . . . . . . . . . . . . . . . . . . 27
3.10.1 Impact class . . . . . . . . . . . . . . . . . . . . 28
3.10.2 TimeImpact class . . . . . . . . . . . . . . . . . . 28
3.10.3 MonetaryImpact class . . . . . . . . . . . . . . . . 29
3.10.4 Confidence class . . . . . . . . . . . . . . . . . . 30
3.11 History class . . . . . . . . . . . . . . . . . . . . . 31
3.11.1 HistoryItem class . . . . . . . . . . . . . . . . . 31
3.12 EventData class . . . . . . . . . . . . . . . . . . . . 33
3.12.1 Relating the Incident and EventData classes . . . . 34
3.12.2 Cardinality of EventData . . . . . . . . . . . . . . 35
3.13 Expectation class . . . . . . . . . . . . . . . . . . . 36
3.14 Flow class . . . . . . . . . . . . . . . . . . . . . . . 37
3.15 System class . . . . . . . . . . . . . . . . . . . . . . 38
3.16 Node class . . . . . . . . . . . . . . . . . . . . . . . 40
3.16.1 Counter class . . . . . . . . . . . . . . . . . . . 41
3.16.2 Address . . . . . . . . . . . . . . . . . . . . . . 41
3.16.3 NodeRole class . . . . . . . . . . . . . . . . . . . 43
3.17 Service class . . . . . . . . . . . . . . . . . . . . . 44
3.17.1 Application class . . . . . . . . . . . . . . . . . 45
3.18 OperatingSystem class . . . . . . . . . . . . . . . . . 46
3.19 Record class . . . . . . . . . . . . . . . . . . . . . . 47
3.19.1 RecordData class . . . . . . . . . . . . . . . . . . 47
3.19.2 RecordPattern class . . . . . . . . . . . . . . . . 48
3.19.3 RecordItem class . . . . . . . . . . . . . . . . . . 49
4. Extending the IODEF . . . . . . . . . . . . . . . . . . . . 51
4.1 Extending the data model . . . . . . . . . . . . . . . . . 51
4.2 Extending the XML Schema . . . . . . . . . . . . . . . . . 51
5. Processing Considerations . . . . . . . . . . . . . . . . . 55
6. Internationalization issues . . . . . . . . . . . . . . . . 56
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.1 Code Red detection notification . . . . . . . . . . . . . 57
7.2 IODEF-Document with XML signature . . . . . . . . . . . . 59
7.3 IODEF-Document encrypted using XML encryption . . . . . . 59
7.4 IODEF-Document encrypted and signed using XML signature
& encryption . . . . . . . . . . . . . . . . . . . . . . . 59
8. The IODEF Document Schema . . . . . . . . . . . . . . . . . 60
9. Security considerations . . . . . . . . . . . . . . . . . . 77
10. IANA considerations . . . . . . . . . . . . . . . . . . . . 78
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 79
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
12.1 Normative References . . . . . . . . . . . . . . . . . . 80
Danyliw, et al. Expires May 13, 2006 [Page 3]
Internet-Draft IODEF Data Model November 2005
12.2 Informative References . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 81
Intellectual Property and Copyright Statements . . . . . . . 82
Danyliw, et al. Expires May 13, 2006 [Page 4]
Internet-Draft IODEF Data Model November 2005
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 Object Description Exchange Format (IODEF) is a format
for representing computer security information exchanged between
Computer Security Incident Response Teams (CSIRTs). It provides a
transport representation conforming to the requirements specified in
[1], the Requirements for Format for Incident Report Exchange.
The overriding purpose of the IODEF is to expand and enhance the
operational capabilities of CSIRTs. Community adoption of the IODEF
provides an improved ability to resolve incidents by simplifying
collaboration and data sharing. This structured format provided by
the IODEF allows for:
o increased automation in processing of incident data since the
resources of security analysts to parse free-form textual
documents 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 interoperable tools for incident
handling and subsequent analysis specifically when data comes from
multiple constituencies.
Terminology, notation, and conventions of the data model and XML
Schema are presented in Sections 2. The data model is described in
Section 3, and the implementation considerations are covered in
Sections 4 through 6. Section 7 provides several examples of IODEF
documents. Section 8 formally specifies the XML Schema
implementation of the data model. Sections 9 and 10 address the
security and IANA considerations, respectively.
1.3 About the IODEF Data Model
The IODEF data model is a data representation that provides a
framework for sharing information commonly exchanged by CSIRTs about
Danyliw, et al. Expires May 13, 2006 [Page 5]
Internet-Draft IODEF Data Model November 2005
computer security incidents. A number of considerations were made in
the design of the data model.
o The intent of the data model is to support the automated
processing of incident data. Hence, little consideration was made
to ensure human-readability. Despite the still prevalent practice
of manual incident report generation, this model is sufficiently
complex that it will be unwieldy to create and process without
software.
o The data model serves as a transport format. Therefore, its
specific representation is not the optimal representation for on-
disk storage, long-term archiving, or in-memory processing.
o Since there is no precise, widely agreed upon definition for an
incident, the data model does not attempt to dictate one through
its implementation. Rather, a broad understanding is assumed that
is flexible enough to encompass most of the CSIRT community.
o Describing an incident for all definitions would require an
incredibly complex data model. Therefore, the IODEF data model
only intends to be a framework to convey commonly exchanged
incident information. However, it ensures that there are ample
mechanisms for extensibility to support organization-specific
information, and techniques to reference information kept outside
of the explicit data model.
o Incidents have a life-cycle that dictates the exact type,
quantity, and detail of the data that will be present at a given
time (e.g., newly reported incidents may only contain the most
rudimentary details, but closed incidents may contain a detailed
analysis). The data model deals with this situation.
o Communication and coordination are central to the role of a CSIRT.
Hence, tracking the source of all data is central to handling the
incident. Therefore, the data model provides ways to explicitly
bind information to a source, and accommodates differences in the
types of parties involved in the incident (e.g., varying levels of
confidence in information, different data sharing arrangements).
1.4 About the IODEF Implementation
The IODEF implementation uses the Extensible Markup Language (XML)
[2], specifies an XML Schema, and registers an application-specific
namespace [3].
For clarity in this document, the terms "XML" and "XML documents"
Danyliw, et al. Expires May 13, 2006 [Page 6]
Internet-Draft IODEF Data Model November 2005
will be used when referring to 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 Schema. Finally, the terms "class" and "subclass" will be
used as synonyms for an XML element.
The choice to implement the IODEF in XML was made because it
provides:
o all the necessary features to define and extend a specific markup
language for describing security incidents;
o a well understood technique for supporting internationalization
and localization;
o a base of related technologies such as XSL [4], XPATH, and XML-SIG
that the aid in the manipulation and use of the incident data; and
o a broad community of developers who already understand how to
build systems around data exchanged in this format.
While XML provides a useful implementation language for IODEF, this
implementation also dictates several limitations.
o XML is a text representation making it inherently inefficient
either when binary data must be embedded or very large volumes of
data must be exchanged.
o The data model is designed as a transport representation, and the
use of XML further reinforces the inefficiency of using the IODEF
for other purposes. Due to the overhead of the parser, XML is not
an optimal in-memory representation. Furthermore, storing,
searching, and retrieving native XML documents is problematic on a
large scale dictating that this format is also a poor choice as a
storage and archive format.
1.5 About the Transport Protocol
Currently, there is no transport protocol specified for exchanging
IODEF documents. The working group has realized that this omission
is an impediment to interoperability, and is working on identifying
candidate protocols. It is likely that SOAP will be used as the
messaging envelope, and HTTP will be the underlying transport.
1.6 Related Work
The IODEF is only one of several security relevant data
Danyliw, et al. Expires May 13, 2006 [Page 7]
Internet-Draft IODEF Data Model November 2005
representations being standardized. Specifically, the complementary
nature of the Intrusion Detection Message Exchange Format [7] bears
mention given that many incidents represented in the IODEF may have
first been discovered through the use of intrusion detection system
output formatted according to the IDMEF. Given this relationship,
the IODEF data model makes use of certain classes defined in the
IDMEF data model.
Danyliw, et al. Expires May 13, 2006 [Page 8]
Internet-Draft IODEF Data Model November 2005
2. Formatting Issues
2.1 IODEF XML Documents
This document uses three notations: the Unified Modeling Language
(UML) to describe the data model, an XML Schema to define the IODEF
syntax, and IODEF XML markup conforming to the specified Schema to
represent the incident data.
This section describes the XML notations and conventions used in this
document and explains particular issues related to using them to
describe the IODEF data model and syntax. For readers unfamiliar
with these notations [17] 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 MUST begin with an XML declaration, and MUST
specify the XML version used. If UTF-8 encoded is not used, the
character encoding MUST also be explicitly specified.
The XML declaration with no character encoding will read as follows:
<?xml version="1.0" ?>
When a character encoding is specified, the XML declaration will read
like the following:
<?xml version="1.0" encoding="charset" ?>
where "charset" is the name of the character encoding as registered
with the Internet Assigned Numbers Authority (IANA), see [9].
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.1.2 IODEF Namespace
Each IODEF document must use the IODEF namespace "iodef" as follows:
Danyliw, et al. Expires May 13, 2006 [Page 9]
Internet-Draft IODEF Data Model November 2005
<IODEF-Document version="1.0"
xmlns:iodef="http://iana.org/iodef" xsi:schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd"
where the string "http://iana.org/iodef/ietf-inch-iodef-1.0.xsd" is
the URI to the schema.
2.1.2 Languages in the IODEF
IODEF messages SHOULD specify the language in which their contents
are encoded. In general, the language can be specified with the
attribute "language" that has reserved type "xs:language" in the top-
level element and letting all other elements "inherit" that
definition.
The valid language codes for the "xs:language" are described in RFC
3066 [6]. If no language is specified, English "en-US" SHOULD be
assumed.
For the IODEF classes that support free-form text in a language that
differ from the rest of the document, this language can be specified
by local attribute "xs:language".
2.2 IODEF Data Types
The IODEF data model defines a number of 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".
The INTEGER data type is implemented as an "xs:integer" in Schema
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
Danyliw, et al. Expires May 13, 2006 [Page 10]
Internet-Draft IODEF Data Model November 2005
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.
The REAL data type is implemented as an "xs:float" in Schema.
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 to
represent special characters.
The CHARACTER and STRING data types are implement as an "xs:string"
in Schema.
2.2.4 Multilingual Strings
STRING data that represents multi-character attributes in a language
different than the default encoding of the document are of the
ML_STRING data type.
The ML_STRING data type is implemented as an "xs:string" in Schema.
Likewise, all elements that are of this type also have a
corresponding "lang" attribute to dictate the language per
Section 2.1.2.
2.2.5 Bytes
Binary octets encoded using character code references (see ) is
represented by the BYTE (and BYTE[]) data type.
The BYTE data type is implemented as an "xs:string" in Schema.
2.2.6 Hexadecimal Bytes
Binary octets encoded using a notation where each octet is encoded as
a character tuple consisting of two hexadecimal digits is represented
by the HEXBIN (and HEXBIN[]) data type.
The HEXBIN data type is implemented as an "xs:string" in Schema.
Danyliw, et al. Expires May 13, 2006 [Page 11]
Internet-Draft IODEF Data Model November 2005
2.2.7 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 Schema, the enumerated type
keywords are used as attribute values.
The ENUM data type is implemented as a series of "xs:NMTOKEN" in
Schema.
2.2.8 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 [13] documented in RFC 3339 [12].
The DATEIME data type is implemented as an "xs:dateTime" in Schema.
2.2.9 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".
The PORTLIST data type is implemented as an "xs:string" in Schema.
2.2.10 Postal Address
A postal address is represented by the POSTAL data type. This data
type is an ML_STRING whose format is documented in Sections 5.17 -
5.19 of RFC 2256 [10].
The POSTAL data type is implemented as an "xs:string" in Schema.
2.2.11 Person or Organization
The name of an individual or organization is represented by the NAME
data type. This data type is an ML_STRING whose format is documented
in Section 5.4 of RFC 2256 [10].
The NAME data type is implemented as an "xs:string" in Schema.
Danyliw, et al. Expires May 13, 2006 [Page 12]
Internet-Draft IODEF Data Model November 2005
2.2.12 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
[10].
The PHONE data type is implemented as an "xs:string" in Schema.
2.2.13 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 [11]
The EMAIL data type is implemented as an "xs:string" in Schema.
2.2.14 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].
The URI data type is implemented as an "xs:string" in Schema.
2.2.15 Timezone string
A timezone offset from UTC is represented by the TIMEZONE data type.
It is formatted according to the following regular expression:
[+-][0-9][0-9][0-9][0-9].
The TIMEZONE data type is implemented as an "xs:string" with a
regular expression constraint in Schema.
2.2.16 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.
The UID and GUID data types are implemented as an "xs:string" in
Schema.
Danyliw, et al. Expires May 13, 2006 [Page 13]
Internet-Draft IODEF Data Model November 2005
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 will be
documented and the relationship with other classes with be depicted
with UML.
3.1 IODEF-Document class
The IODEF-Document class is the top level class in the IODEF data
model. All IODEF documents are an instance of this class.
+-----------------+
| IODEF-Document |
+-----------------+
| STRING version |<>--{1..*}--[ Incident ]
| ENUM lang |<>--{0..*}--[ ds:Signature ]
+-----------------+
Figure 1: IODEF-Document class
The aggregate class that constitutes IODEF-Document is:
Incident
One or more. The information related to a single incident.
Signature
Zero or more. Cryptographic signature per [14] to ensure the
integrity and authenticity of the document.
The IODEF-Document class has two attribute:
version
Required. STRING. The IODEF specification version number to
which this IODEF document conforms. The value of this attribute
MUST be 1.0
lang
Required. ENUM. A valid language code per RFC 3066 [6]. The
interpretation of this code is described in Section 2.1.2.
3.2 Incident class
Every incident is represented by an instance of the Incident class.
This class provides a standardized representation for commonly
exchanged incident data and associates a CSIRT assigned unique
Danyliw, et al. Expires May 13, 2006 [Page 14]
Internet-Draft IODEF Data Model November 2005
identifier with the described activity.
+-------------------+
| Incident |
+-------------------+
| ENUM purpose |<>----------[ IncidentID ]
| ENUM lang |<>--{0..1}--[ AlternativeID ]
| ENUM restriction |<>--{0..1}--[ RelatedActivity ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+-------------------+
Figure 2: the Incident class
The aggregate classes that constitute Incident are:
IncidentID
One. An incident tracking number assigned to this incident by the
CSIRT that generated the IODEF document.
AlternativeID
Zero or one. A list of incident tracking numbers used by other
CSIRTs to refer to the incident described in the document.
RelatedActivity
Zero or one. A list of incident tracking numbers of related
incidents.
DetectTime
Zero or one. The time the incident was first detected.
StartTime
Zero or one. The time the incident started.
EndTime
Zero or one. The time the incident ended.
Danyliw, et al. Expires May 13, 2006 [Page 15]
Internet-Draft IODEF Data Model November 2005
ReportTime
One. The time the incident was reported.
Description
Zero or more. ML_STRING. A free-form textual description of the
incident.
Assessment
One or more. A characterization of the impact of the incident.
Method
Zero or more. The techniques used by the intruder in the
incident.
Contact
One or more. Contact information for the parties involved in the
incident.
EventData
Zero or more. Description of the events comprising the incident,
History
Zero or one. A log of significant events or actions that occurred
during the course of handling the incident.
AdditionalData
Zero or more. Mechanism by which to extend the data model.
The Incident class has three attributes:
purpose
Required. ENUM. The purpose attribute represents the reason why
the IODEF document was created. It is closely related to the
Expectation class (Section 3.13). This attribute is defined as an
enumerated list:
1. traceback. The document was sent for trace-back purposes;
2. mitigation. The document was sent to request aid in
mitigating the described activity;
3. reporting. The document was sent to comply with reporting
requirements;
4. other. The document was sent for purposes specified in the
Expectation class.
Danyliw, et al. Expires May 13, 2006 [Page 16]
Internet-Draft IODEF Data Model November 2005
lang
Required. ENUM. A valid language code per RFC 3066 [6].
restriction
Optional. ENUM. This attribute indicates the disclosure
guidelines to which the sender expects the recipient of the IODEF-
Document to adhere. Naturally, this provides no real security
since 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 all of
the high-level classes (i.e., children of the Incident class) have
a restriction attribute. Therefore, a child can override the
guidelines of a parent class, be it to restrict 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".
Note that the default value of the restriction attribute is only
defined in the context of the Incident class. In other classes
where this attribute is used, no default is specified.
1. public. There are no restrictions placed in 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 an incident tracking number (UID)
Danyliw, et al. Expires May 13, 2006 [Page 17]
Internet-Draft IODEF Data Model November 2005
that is unique in the context of the CSIRT and identifies the
activity characterized in an IODEF-Document.
+------------------+
| IncidentID |
+------------------+
| UID |
| |
| GUID name |
+------------------+
Figure 3: the IncidentID class
The IncidentID class has one attribute:
name
Required. GUID. An identifier for the CSIRT that created the
IODEF-Document. In order to have a globally unique CSIRT name,
the domain name (DNS) of the CSIRT MUST be used.
3.4 AlternativeID class
The AlternativeID class lists the incident tracking numbers used by
other CSIRTs to refer to activity described in this IODEF document.
Thus, a tracking number listed as an AlternativeID references the
same incident detected by another CSIRT. The incident tracking
numbers of the CSIRT that generated the IODEF document should never
be considered an AlternativeID.
+------------------+
| AlternativeID |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
Figure 4: the AlternativeID class
The aggregate class that constitutes AlternativeID is:
IncidentID
One or more. The incident tracking number of another CSIRT.
The AlternativeID class has one attribute:
Danyliw, et al. Expires May 13, 2006 [Page 18]
Internet-Draft IODEF Data Model November 2005
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.5 RelatedActivity class
The RelatedActivity class lists the incident tracking numbers of
incidents that are related to the one described in the IODEF
document. These references may be 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 5: RelatedActivity class
The aggregate class that constitutes RelatedActivity is:
IncidentID
One or more. The incident tracking number of a related incident.
The RelatedActivity class has one attribute:
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 types (e.g., integers,
strings) are provided with a mechanism to annotate their meaning.
The class can also be used to extend the data model (and the
associated Schema) to support proprietary extensions by encapsulating
entire XML documents conforming to another Schema (e.g., IDMEF). A
detailed discussion for extending the data model and the Schema can
be found in Section 4.
Unlike XML, which is self-describing, atomic data must be documented
Danyliw, et al. Expires May 13, 2006 [Page 19]
Internet-Draft IODEF Data Model November 2005
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 type |
| STRING meaning |
| STRING formatid |
| ENUM restriction |
+------------------+
Figure 6: the AdditionalData class
The AdditionalData class has three attributes:
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"
2. byte. The element content is a single 8-bit byte (see
Section 2.2.5);
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.8);
5. integer. The element content is an integer (see
Section 2.2.1);
6. portlist. The element content is a port list (see
Section 2.2.9);
Danyliw, et al. Expires May 13, 2006 [Page 20]
Internet-Draft IODEF Data Model November 2005
7. real. The element content is a real number (see
Section 2.2.2);
8. string. The element content is a string (see Section 2.2.3);
9. file. The element content is a base64 encoded binary file;
10. frame. The element content is a hexbin-encoded layer-2 frame
(see Section 2.2.6)
11. packet. The element content is a hexbin-encoded layer-3
packet (see Section 2.2.6)
12. ipv4-packet. The element content is an IPv4 hexbin-encoded
packet (see Section 2.2.6)
13. ipv6-packet. The element content is an IPv6 hexbin-encoded
packet (see Section 2.2.6)
14. path. The element content is a filesystem path;
15. url. The element content is a URL (see Section 2.2.14;)
16. xml. The element content is XML-tagged data (see Section 4).
meaning
Optional. STRING. A free-form description of the semantics of
the custom data in this class.
formatid
Optional. STRING. An identifier referencing the format and
semantics of the encapsulated data.
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.7 Contact class
The Contact class describes contact information for organizations and
personnel involved in the incident. This class allows for the naming
of the involved party, specifying contact information for them, and
identifying their role in the incident.
People and organizations are treated interchangeably as contacts; one
can be associated with the other using the recursive definition of
the class (the Contact class is aggregated into the Contact class).
The 'type' attribute disambiguates the type of contact information
Danyliw, et al. Expires May 13, 2006 [Page 21]
Internet-Draft IODEF Data Model November 2005
being provided.
This recursive definition provides a way to relate information
without requiring the explicit use of identifiers in the classes.
For example, separate contact information for two individuals from
the same organization would not require duplicating the organization
information.
+------------------+
| Contact |
+------------------+
| ENUM role |<>--{0..1}--[ ContactName ]
| ENUM type |<>--{0..*}--[ Description ]
| ENUM restriction |<>--{0..*}--[ RegistryHandle ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..*}--[ Email ]
| |<>--{0..*}--[ Telephone ]
| |<>--{0..1}--[ Fax ]
| |<>--{0..1}--[ Timezone ]
| |<>--{0..*}--[ Contact ]
+------------------+
Figure 7: the Contact class
The aggregate classes that constitute the Contact class are:
ContactName
Zero or one. ML_STRING. The name of the contact. The contact
may either be an organization or a person. The type attribute
disambiguates the semantics.
Description
Zero or one. ML_STRING. A free-form description of this contact.
In the case of a person, this is often the organizational title of
the individual.
RegistryHandle
Zero or many. A handle name in a registry.
PostalAddress
Zero or one. POSTAL. The postal address of the contact
formatted according to Section 2.2.10.
Danyliw, et al. Expires May 13, 2006 [Page 22]
Internet-Draft IODEF Data Model November 2005
Email
Zero or many. EMAIL. The email address of the contact formatted
according to Section 2.2.13.
Telephone
Zero or many. PHONE. The telephone number of the contact
formatted according to Section 2.2.12.
Fax
Zero or one. PHONE. The facsimile telephone number of the
contact formatted according to Section 2.2.12.
Timezone
Zero or one. TIMEZONE. The timezone in which the contact resides
formatted according to Section 2.2.15.
Contact
Zero or many. Recursive definition of Contact allowing for the
grouping of information.
The Contact class has three attributes:
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 handling
of the incident.
type
Required. ENUM. Indicates the type of contact being described.
This attribute is defined as an enumerated list:
1. person.
2. organization.
Danyliw, et al. Expires May 13, 2006 [Page 23]
Internet-Draft IODEF Data Model November 2005
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.7.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 8: 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. afrinic. African Internet Numbers Registry
7. local. A database local to the CSIRT.
3.8 Time classes
The data model uses five different classes to represent a timestamp.
Their definition is identical, but each has a distinct name to convey
Danyliw, et al. Expires May 13, 2006 [Page 24]
Internet-Draft IODEF Data Model November 2005
a difference in semantics.
The element content of each class is a timestamp formated according
to the DATETIME data type (see Section 2.2.8).
+----------------------------------+
| {Start| End| Report| Detect}Time |
+----------------------------------+
| DATETIME |
+----------------------------------+
Figure 9: the Time classes
3.8.1 StartTime
The StartTime class represents the time the incident began.
3.8.2 EndTime
The EndTime class represents the time the incident ended.
3.8.3 DetectTime
The DetectTime class represents the time the first activity of the
incident was detected.
3.8.4 ReportTime
The ReportTime class represents the time the incident was reported.
This timestamp SHOULD coincide to the time at which the IODEF
document is generated.
3.8.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.9 Method class
The Method class describes the methodology used by the intruder to
perpetrate the events of the incident. This class can reference
well-known vulnerability or exploit databases; the intruder tools
used in the attack; and provide a free-form description of the
activity.
Danyliw, et al. Expires May 13, 2006 [Page 25]
Internet-Draft IODEF Data Model November 2005
+------------------+
| Method |
+------------------+
| ENUM restriction |<>--{0..*}--[ Classification ]
| |<>--{0..*}--[ Description ]
+------------------+
Figure 10: 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. ML_STRING. A free-form text description of the
methodology used by the intruder.
The Method class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.9.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 name in the database, and
the URI to this entry.
+------------------+
| Classification |
+------------------+
| ENUM origin |<>----------[ name ]
| |<>--{0..*}--[ url ]
+------------------+
Figure 11: The Classification class
The aggregate classes that constitute Classification:
name
One. STRING. The key into the database specified in the origin
attribute.
Danyliw, et al. Expires May 13, 2006 [Page 26]
Internet-Draft IODEF Data Model November 2005
url
Zero or many. URI. A URL to additional information about the
vulnerability or exposure referenced by the name.
The Classification class has one attribute:
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. Mitre 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. A custom database whose URL is specified in the url
class, and the name of the entry is specified in the name
class.
3.10 Assessment class
The Assessment class describes the technical and non-technical
repercussions of the incident on the CSIRT's constituency.
Note: The IODEF definition of the Assessment class reuses the IDMEF
definition (see Section 4.2.4.5 of [7]), but also extends it.
+------------------+
| Assessment |
+------------------+
| ENUM restriction |<>--{0..*}--[ Impact ]
| |<>--{0..*}--[ TimeImpact ]
| |<>--{0..*}--[ MonetaryImpact ]
| |<>--{0..1}--[ Confidence ]
+------------------+
Figure 12: Assessment class
The aggregate classes that constitute Assessment are:
Danyliw, et al. Expires May 13, 2006 [Page 27]
Internet-Draft IODEF Data Model November 2005
Impact
Zero or many. Technical impact of the incident on a network.
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
financial loss.
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.10.1 Impact class
The Impact class allows for categorizing and describing the technical
impact of the incident on the network of an organization.
Note: The IODEF definition of the Impact class reuses the IDMEF
definition (see Section 4.2.6.1 of [7]).
3.10.2 TimeImpact class
The TimeImpact class describes the impact of the incident on an
organization as a function of time. It provides a way to convey down
time and recovery time.
+------------------+
| TimeImpact |
+------------------+
| REAL |
| |
| ENUM severity |
| ENUM metric |
| ENUM units |
+------------------+
Figure 13: TimeImpact class
The element content will be a numeric value (REAL) specifying a unit
Danyliw, et al. Expires May 13, 2006 [Page 28]
Internet-Draft IODEF Data Model November 2005
of time. The unit and metric attributes will imply the semantics of
the element content.
The TimeImpact class has three attributes:
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 element content
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.10.3 MonetaryImpact class
The MonetaryImpact class describes the financial impact of the
activity on an organization. For example, this impact may consider
Danyliw, et al. Expires May 13, 2006 [Page 29]
Internet-Draft IODEF Data Model November 2005
losses due to the cost of the investigation or recovery, diminished
productivity of the staff, or a tarnished reputation that will affect
future opportunities.
+------------------+
| MonetaryImpact |
+------------------+
| REAL |
| |
| ENUM severity |
| STRING currency |
+------------------+
Figure 14: MonetaryImpact class
The element content will be a numeric value (REAL) specifying a unit
of currency described in the currency attribute.
The MonetaryImpact class has two attributes:
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
[16]. There is no default value.
3.10.4 Confidence class
The Confidence class represents a best estimate of the validity and
accuracy of the described impact (see Section 3.10) of the incident
activity. This estimate can be expressed as a category, or a numeric
calculation.
Note: The IODEF definition of the Confidence class reuses the IDMEF
definition (see Section 4.2.6.3 of [7]).
Danyliw, et al. Expires May 13, 2006 [Page 30]
Internet-Draft IODEF Data Model November 2005
3.11 History class
The History class is a log of the significant events or actions
performed by the involved parties 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 15: The History class
The class that constitutes History is:
HistoryItem
One or many. Entry 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.11.1 HistoryItem class
The HistoryItem class is an entry in the History (Section 3.11) log
that documents a particular action or event that occurred in the
course of handling the incident. The details of the entry are a
free-form description, but each can be categorized with the type
attribute.
+------------------+
| HistoryItem |
+------------------+
| ENUM restriction |<>----------[ DateTime ]
| ENUM type |<>--{0..1}--[ IncidentId ]
| |<>--{1..*}--[ Description ]
+------------------+
Danyliw, et al. Expires May 13, 2006 [Page 31]
Internet-Draft IODEF Data Model November 2005
Figure 16: HistoryItem class
The aggregate classes that constitute HistoryItem are:
DateTime
One. Timestamp of the this entry in the history log (e.g., when
the action described in the Description was taken).
IncidentID
Zero or One. In a history log created by multiple parties, the
IncidentID provides a mechanism to specify which CSIRT created a
particular entry and references this organization's incident
tracking number. When a single organization is maintaining the
log, this class can be ignored.
Description
One or many. STRING. A free-form textual description of the
action or event.
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
documented in this history log entry. The 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).
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. A custom entry.
Danyliw, et al. Expires May 13, 2006 [Page 32]
Internet-Draft IODEF Data Model November 2005
3.12 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, and any forensic evidence discovered.
+------------------+
| EventData |
+------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..1}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{0..*}--[ Flow ]
| |<>--{0..*}--[ Expectation ]
| |<>--{0..1}--[ Record ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 17: The EventData class
The aggregate classes that constitute EventData are:
Description
Zero or more. ML_STRING. A free-form textual description of the
event.
DetectTime
Zero or one. The time the event was detected.
StartTime
Zero or one. The time the event started.
EndTime
Zero or one. The time the event ended.
Contact
Zero or more. The different parties involved in the incident
Danyliw, et al. Expires May 13, 2006 [Page 33]
Internet-Draft IODEF Data Model November 2005
Assessment
Zero or one. The impact of the incident on the target and the
actions taken.
Method
Zero or more. The methodology used by the intruders.
Flow
Zero or more. A description of the systems or networks involved.
Expectation
Zero or more. Expected action to be performed by the recipient of
the document.
Record
Zero or one. Supportive data (e.g., log files) that provides
additional information about the event.
EventData
Zero or more. Recursive definition of EventData allowing for the
grouping of data
AdditionalData
Zero or one. An extension mechanism for data not explicitly
represented in the data model.
The EventData class has one attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.12.1 Relating the Incident and EventData classes
There is substantial overlap in the Incident and EventData classes.
Nevertheless, the semantics of these classes are quite different.
The Incident class provides summary information about the entire
incident, while the EventData class provides information about the
individual events comprising the incident. In the most common case,
the EventData class will provide more specific information for the
general description provided in the Incident class. However, it may
also be possible that the overall summarized information about the
incident conflicts with some individual information in an EventData
class when there is a substantial composition of various events in
the an incident.
Danyliw, et al. Expires May 13, 2006 [Page 34]
Internet-Draft IODEF Data Model November 2005
3.12.2 Cardinality of EventData
The EventData class can be thought of as a container for 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. With an instance of the EventData class, hosts
hosts (i.e., System class) are grouped around these common
properties.
The recursive definition of the EventData 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 or duplicating information. Instead, the
relative depth (nesting) of a class is used to group (relate)
information.
Nested EventData classes imply that while the child classes share the
properties of the parent, there is some properties for which they do
not agree. Therefore, in order express these distinct properties,
the nesting approach was used. In such a scheme, a parent EventData
class MUST always have more than one EventData child.
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 Flow class. It happens that there is
a common technical contact (i.e., Contact class) for these two
machines, but the impact (i.e., Assessment class) on them is
different. A depiction of the representation for this situation can
be found in Figure 18.
+------------------+
| EventData |
+------------------+
| |<>----[ Contact ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
+------------------+
Figure 18: Recursion in the EventData class
Danyliw, et al. Expires May 13, 2006 [Page 35]
Internet-Draft IODEF Data Model November 2005
3.13 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 severity |<>--{0..1}--[ StartTime ]
| ENUM category |<>--{0..1}--[ EndTime ]
| |<>--{0..1}--[ Contact ]
+------------------+
Figure 19: the Expectation class
The aggregate classes that constitute Expectation are:
Description
One or many. ML_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
Incident 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.
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 Expectations class has three attributes:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
severity
Optional. ENUM. Indicates the desired priority of the action.
This attribute is an enumerated list with no default value.
1. low. Low priority
Danyliw, et al. Expires May 13, 2006 [Page 36]
Internet-Draft IODEF Data Model November 2005
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. investigate. Investigate the machine(s) listed in the
document.
5. block-host. Block traffic from the machine(s) listed as
sources in the document.
6. block-network. Block traffic from the network(s) lists as
sources in the document.
7. block-port. Block the port listed as sources in the
document.
8. rate-limit-host. Rate-limit the traffic from the machine(s)
listed as sources in the document.
9. rate-limit-network. Rate-limit the traffic from the
network(s) lists as sources in the document.
10. rate-limit-port. Rate-limit the port(s) listed as sources in
the document.
11. other. Perform some custom action described in the
Description class.
3.14 Flow class
The Flow class groups the source and target hosts or networks
(represented by System) in an event.
Danyliw, et al. Expires May 13, 2006 [Page 37]
Internet-Draft IODEF Data Model November 2005
+------------------+
| Flow |
+------------------+
| |<>--{1..*}--[ System ]
+------------------+
Figure 20: the Flow class
The aggregate class that constitutes Flow is:
System
One or More. A host or network involved in the incident activity.
The Flow System class has no attributes.
3.15 System class
The System class represents a computer or network involved in the
incident.
The systems represented by this class are categorized according to
the role they played in the incident through the category attribute.
The value of this category attribute dictates the semantics of the
aggregated classes in the System class. If the category attribute
has a value of 'source', then the aggregated classes denote the
machine and service from which the activity is originating. With a
category attribute value of 'target' or 'intermediary', then the
machine or service is the one targeted in the activity.
+------------------+
| System |
+------------------+
| ENUM restriction |<>----------[ Node ]
| ENUM category |<>--{0..*}--[ Service ]
| STRING interface |<>--{0..*}--[ OperatingSystem ]
| ENUM spoofed |<>--{0..*}--[ Counter ]
+------------------+
Figure 21: the System class
The aggregate classes that constitute System are:
Node
One. A host or network involved in the incident.
Danyliw, et al. Expires May 13, 2006 [Page 38]
Internet-Draft IODEF Data Model November 2005
Service
Zero or more. A network service running on the system.
OperatingSystem
Zero or one. The operating system running on the system.
Counter
Zero or more. A counter with which to summarize properties of
this host or network.
The System class has four attribute:
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
category
Required. ENUM. Classifies the role the host or network played
in the incident. The possible values are:
1. source. The System was the source of the attack.
2. target. The System was the target of the attack.
3. intermediate. The System was an intermediary in the attack.
interface
Optional. STRING. Specifies the interface on which the event(s)
on this System originated. If the Node class specifies a network
rather than a host, this attribute has no meaning.
spoofed
Optional. ENUM. An indication of confidence in 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 attribute value is
unknown
2. yes. The category attribute value 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 attribute value is believed to be correct.
Danyliw, et al. Expires May 13, 2006 [Page 39]
Internet-Draft IODEF Data Model November 2005
3.16 Node class
The Node class identifies a host, network device, or network.
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 and DateTime classes.
+---------------+
| Node |
+---------------+
| |<>--{0..1}--[ name ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ Location ]
| |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ NodeRole ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 22: The Node class
The aggregate classes that constitute Node are:
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 hardware, network, or application address of
the Node. Unless a name is provided, at least one address must be
specified.
Location
Zero or one. STRING. A free-from description of the physical
location of the equipment.
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.
Danyliw, et al. Expires May 13, 2006 [Page 40]
Internet-Draft IODEF Data Model November 2005
Counter
Zero or more. A counter with which to summarizes properties of
this host or network.
3.16.1 Counter class
The Counter class summarize multiple occurrences of some event, or
conveys counts on various features (e.g., packets, sessions, events).
The value of the counter is the element content, with its units
represented in the type attribute. The complete semantics are
entirely context dependant based on the class in which the Counter is
aggregated.
+------------------+
| Counter |
+------------------+
| INTEGER |
| |
| ENUM type |
| STRING meaning |
+------------------+
Figure 23: the Counter class
The Counter class has two attribute:
type
Optional. ENUM. Specifies the units of the element contents.
1. packet. Count of packets.
2. session. Count of sessions
3. event. Count of events
4. other. User defined count
meaning
Optional. STRING. Describes the semantics of the element content
if the type attribute is set to other.
3.16.2 Address
The Address class represents a hardware (layer-2), network (layer-3),
Danyliw, et al. Expires May 13, 2006 [Page 41]
Internet-Draft IODEF Data Model November 2005
or application (layer-7) address.
This class was originally derived from the IDMEF specification [7].
+------------------+
| Address |
+------------------+
| ENUM category |
| STRING vlan-name |
| INTEGER vlan-num |
+------------------+
Figure 24: the Address class
The Address class has four attributes:
category
Required. ENUM. The type of address represented. The permitted
values for this attribute are shown below. The default value is
"ipv4-addr".
1. asn. Autonomous System Number
2. atm. Asynchronous Transfer Mode (ATM) address
3. e-mail. Electronic mail address (RFC 822)
4. ipv4-addr. IPv4 host address in dotted-decimal notation
(a.b.c.d)
5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits (a.b.c.d/nn)
6. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation
(a.b.c.d/w.x.y.z)
7. ipv6-addr. IPv6 host address
8. ipv6-net. IPv6 network address, slash, significant bits
9. ipv6-net-mask. IPv6 network address, slash, network mask
10. mac. Media Access Control (MAC) address
Danyliw, et al. Expires May 13, 2006 [Page 42]
Internet-Draft IODEF Data Model November 2005
vlan-name
Optional. STRING. The name of the Virtual LAN to which the
address belongs.
vlan-num
Optional. STRING. The number of the Virtual LAN to which the
address belongs.
3.16.3 NodeRole class
The NodeRole class describes (based on a pre-defined list) the
function performed by a particular host.
+---------------+
| NodeRole |
+---------------+
| STRING |
| |
| ENUM category |
| ENUM lang |
+---------------+
Figure 25: 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 two attributes:
category
Required. Functionality provided by a node. If a value of
"other" is specified, a description SHOULD be provided in the
element 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)
Danyliw, et al. Expires May 13, 2006 [Page 43]
Internet-Draft IODEF Data Model November 2005
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)
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
lang
Required. ENUM. A valid language code per RFC 3066 [6].
3.17 Service class
The Service class describes a network service of a host or network.
The service is identified by specific port or list of ports, along
with the application listening on that port.
When Service occurs as an aggregate class of a System that is a
source, then that the service is the one from which activity of
interest is originating. Conversely, when Service occurs as an
aggregate class of a System that is a target, then that service is
the one to which activity of interest is being directed.
This class was originally derived from the IDMEF specification, see
Section 4.2.7.4 of [7].
Danyliw, et al. Expires May 13, 2006 [Page 44]
Internet-Draft IODEF Data Model November 2005
+---------------------+
| Service |
+---------------------+
| INTEGER ip_version |<>--{0..1}--[ port ]
| INTEGER ip_protocol |<>--{0..1}--[ portlist ]
| |<>--{0..1}--[ Application ]
+---------------------+
Figure 26: The Service class
The aggregate classes that constitute Service are:
port
Zero or one. INTEGER. A port number.
portlist
Zero or one. PORTLIST. A list of port numbers formatted
according to Section 2.2.9.
Application
Zero or more. The application bound to the specified port or
portlist.
The Service class must specify either a port or portlist.
The Service class has two attributes:
ip_version
Required. INTEGER. The IP version number.
ip_protocol
Required. INTEGER. The IANA protocol number.
3.17.1 Application class
The Application class describes an application running on a System
providing a Service.
Danyliw, et al. Expires May 13, 2006 [Page 45]
Internet-Draft IODEF Data Model November 2005
+--------------------+
| Application |
+--------------------+
| STRING swid |<>--{0..1}--[ url ]
| STRING configid |
| STRING vendor |
| STRING family |
| STRING name |
| STRING version |
| STRING patch |
+--------------------+
Figure 27: The Application class
The aggregate classes that constitute Application are:
url
Zero or one. URI. A uri describing the application.
The Application class has seven attributes:
swid
Optional. STRING. An identifier that can be used to reference
this software.
configid
Optional. STRING. An identifier that can be used to reference a
particular configuration.
vendor
Optional. STRING. Vendor name.
family
Optional. STRING. Family of the software.
name
Optional. STRING. Name of the software.
version
Optional. STRING. Version of the software.
patch
Optional. STRING. Patch or service pack level.
3.18 OperatingSystem class
The OperatingSystem class describes the operating system running on a
Danyliw, et al. Expires May 13, 2006 [Page 46]
Internet-Draft IODEF Data Model November 2005
System. The definition is identical to the Application class
(Section 3.17.1).
3.19 Record class
The Record class is a container class for log and audit data that
provides supportive information about the incident. The source of
this data will often 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 CSIRT believes an incident has occurred.
+------------------+
| 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. Seperate instances of the RecordData class SHOULD be used
for each sensor type.
The Record class has one attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
3.19.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.
Danyliw, et al. Expires May 13, 2006 [Page 47]
Internet-Draft IODEF Data Model November 2005
+------------------+
| RecordData |
+------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ Application ]
| |<>--{0..*}--[ RecordPattern ]
| |<>--{1..*}--[ RecordItem ]
+------------------+
Figure 29: The RecordData class
The aggregate classes that constitutes RecordData is:
DateTime
Zero or one. Timestamp of the RecordItem data.
Description
Zero or more. ML_STRING. Free-form textual description of the
provided RecordItem data. At minimum, this description should
convey the significance of the provided RecordItem data.
Application
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.19.2 RecordPattern class
The RecordPattern class describes where in the content of the
RecordItem relevant information can be found. It provides a way to
reference subsets of information, identified by a pattern, in a large
log file, audit trail, or forensic data.
Danyliw, et al. Expires May 13, 2006 [Page 48]
Internet-Draft IODEF Data Model November 2005
+------------------+
| RecordPattern |
+------------------+
| STRING |
| |
| ENUM type |
| INTEGER offset |
| ENUM offsetunit |
| INTEGER instance |
+------------------+
Figure 30: The RecordPattern class
The specific pattern to search with in the RecordItem is defined in
the body of the element. It is further annotated by four attributes:
type
Required. ENUM. Describes the type of pattern that is being
specified in the body of the element. The default is "regex".
1. regex. POSIX regular expression
2. binary. Binhex encoded binary pattern
3. xpath. W3C XPath
offest
Optional. INTEGER. Amount of units (determined by the offsetunit
attribute) to seek into the RecordItem data before matching the
pattern.
offsetunit
Optional. ENUM. Describes the units of the offset attribute.
The default is "line".
1. line. Offset is a count of lines.
2. binary. Offset is a count of bytes
instance
Optional. INTEGER. Number of types to apply the specified
pattern.
3.19.3 RecordItem class
The RecordItem class provides a way to incorporate relevant logs,
audit trails, or forensic data to support the conclusions made during
Danyliw, et al. Expires May 13, 2006 [Page 49]
Internet-Draft IODEF Data Model November 2005
the course of analyzing the incident. The class supports both the
direct encapsulation of the data, as well as, provides primitives to
reference data stored elsewhere.
This class is identical to AdditionalData class (Section 3.6).
Danyliw, et al. Expires May 13, 2006 [Page 50]
Internet-Draft IODEF Data Model November 2005
4. Extending the IODEF
In order to support the changing activity of CSIRTS, the IODEF data
model will need to evolve along with them. To allow new features to
be added, both the data model and the Schema can be extended as
described in this section. As these extensions mature, they can 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 Schema (see Section 4.2) which set limits on
where extensions to the data model may be made.
4.2 Extending the XML Schema
XML Schema provides a flexible way of extending the IODEF data model
by defining extension schemas in a separate namespace.
The following guidelines MUST be followed when extending the IODEF
Schema with another schema:
1. The IODEF extension Schema MUST include an extension namespace
definition and provide a reference to this schema's location per
the XML Schema specification:
<xs:schema targetNamespace="http://iana.org/iodef-ext1"
xmlns:iodef-ext1="http://iana.org/iodef-ext1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
2. The import of the base namespace and declaration of the base
IODEF schema can be added to the extension Schema
Danyliw, et al. Expires May 13, 2006 [Page 51]
Internet-Draft IODEF Data Model November 2005
<xs:schema targetNamespace="http://iana.org/iodef-ext1"
xmlns:iodef-ext1="http://iana.org/iodef-ext1"
xmlns:iodef="http://iana.org/iodef"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified" >
<xs:import namespace="http://iana.org/iodef"
schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd">
3. The location of the extension schema should be referenced in the
XML document that uses it.
<IODEF-Document xmlns:iodef-ext1="http://iana.org/iodef-ext1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://iana.org/iodef-ext1
http://iana.org/iodef-ext1/ietf-inch-iodef-ext1.xsd">
4. It is RECOMMENDED that all extensions starts with "iodef-" prefix
and add specific extension abbreviation such as "ext1".
5. It may be convenient to add a reference to the extension schema
and import this extension namespace to the base IODEF schema.
Elements defined in the extension schema can be used in any place in
final IODEF document. In the example below, the "iodef-xws"
extension is defined by the schema that contains one element "iodef-
xws:Principal". This element is composed of the NameIdentifier
element of XML type NCName and imports "iodef:Description" element
from the master IODEF schema.
Danyliw, et al. Expires May 13, 2006 [Page 52]
Internet-Draft IODEF Data Model November 2005
<xs:schema targetNamespace="http://iana.org/iodef-xws"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:iodef-xws="http://iana.org/iodef-xws"
xmlns:iodef="http://iana.org/iodef"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://iana.org/iodef"
schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd">
<xs:element name="Principal" type="iodef-xws:PrincipalType"/>
<xs:complexType name="PrincipalType">
<xs:sequence>
<xs:element ref="iodef-xws:NameIdentifier"/>
<xs:element ref="iodef:Description" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="principalcat" type="xs:string"/>
</xs:complexType>
<xs:element name="NameIdentifier" type="iodef-xws:NameIdentifierType"/>
<xs:complexType name="NameIdentifierType" type="xs:NCName">
</schema>
In the example below, the above defined extension is used in the
iodef:System element.
Danyliw, et al. Expires May 13, 2006 [Page 53]
Internet-Draft IODEF Data Model November 2005
<IODEF-Document xmlns:iodef="http://iana.org/iodef"
xmlns:iodef-xws="http://iana.org/iodef-xws"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://iana.org/iodef
http://iana.org/iodef-xws/draft-ietf-inch-iodef-1.0.xsd"
xsi:schemaLocation="http://iana.org/iodef-xws
http://iana.org/iodef-xws/draft-ietf-inch-iodef-xws.xsd"
version="1.0">
<Incident restriction="private" purpose="traceback">
<IncidentID Issuer="String" restriction="default">Text</IncidentID>
[.....]
<iodef:System restriction="default" interface="VLAN" systemcat="source" spoofed="unknown">
[.....]
<iodef-xws:Principal iodef-xws:principalcat="other">
<NameIdentifier>CN=Yuri Demchenko, OU=AIRG, O=UvA, S=NH, L=Holland, C=NL</NameIdentifier>
</iodef-xws:Principal>
</iodef:System>
Danyliw, et al. Expires May 13, 2006 [Page 54]
Internet-Draft IODEF Data Model November 2005
5. Processing Considerations
The IODEF documents MUST be well-formed, and when practical, SHOULD
also be valid.
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;
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.
Danyliw, et al. Expires May 13, 2006 [Page 55]
Internet-Draft IODEF Data Model November 2005
6. Internationalization issues
Internationalization and localization is of specific concern to the
IODEF, since it is only through collaboration, often across language
barriers, that certain incidents be resolved. The IODEF supports
this goal by depending on XML constructs, and through explicit design
choices in the data model.
The IODEF leverages that XML natively supports different character
encodings that is specified for whole document. The default encoding
is UTF-8 whereby allowing information encoded in an IODEF document to
be in all languages that are supported by UCS/Unicode. In order to
disambiguate the explicit language on a per-element basis, the xs:
language attribute is used.
For the languages that do not use UTF-8 encoding (e.g., Chinese Big5
or Japanese ISO-2022-JP), the IODEF schema uses the MultilingTextType
type that allows a binary transformation of non-UTF-8 encoded text.
The intent of the data model was to provide internationalization and
localization, but not to the detriment of inter-operability. While
IODEF does support different languages, the data model also relies
heavily on standardized enumerated attributes that can crudely
approximate the contents of the document. With this approach, a
CSIRT should be able to make some sense of an IODEF document it might
receive that uses a language unfamiliar to its analysts.
Likewise, the data model was designed so that classes where free-text
might be used for descriptive purposes always have a one-to-many
cardinality with its parent (i.e., Description class). The primary
intent of this design was to allow the same description to be
repeated in another instance of the class but in a different
language. This approach allows recipients speaking different
languages to receive the identical document, but allows the IODEF
parser to select the appropriate language.
Danyliw, et al. Expires May 13, 2006 [Page 56]
Internet-Draft IODEF Data Model November 2005
7. Examples
This section provides representative examples of incident data
converted to an IODEF document.
7.1 Code Red detection notification
The following email message is a typical example of an incident
report where one host is infected with a worm. The original report
sent by email is presented in Figure 36, and the corresponding
equivalent as an IODEF document is shown below.
From e-citizen@domain.com
Date: 13 Sep 2001 23:19:24 -0000
To: cert-domain@domain.com
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.domain.org/react/code_redII.html
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 36: Code Red detection notification: initial report
<IODEF-Document version="1.00">
<Incident purpose="reporting">
<IncidentID name="CERT-DOMAIN.COM">CERT-DOMAIN.COM#189</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Host sending out Code Red probes</Description>
<Assessment>
<Impact completion="failed" type="admin"/>
</Assessment>
<Contact role="creator" type="organization">
Danyliw, et al. Expires May 13, 2006 [Page 57]
Internet-Draft IODEF Data Model November 2005
<ContactName>CERT-FOR-OUR-DOMAIN.PL</ContactName>
<Email>cert-for-our-domain.pl@ourdomain.pl</Email>
</Contact>
<Contact role="tech" type="organization">
<ContactName>Constituency-contact for 10.1.1.2</ContactName>
<Email>Constituency-contact@10.1.1.2.pl</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">10.1.1.2</Address>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">10.5.0.0/16</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<port>80</port>
</Service>
</System>
</Flow>
<Expectation category="investigate">
<Description>Track and clean host</Description>
</Expectation>
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description>
<RecordItem type="string">10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem>
<RecordItem type="url">
http://mydomain.com/logs/httpd_access
</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<HistoryItem category="notification">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>
Notification sent to constituency-contact@10.1.1.2
</Description>
</HistoryItem>
</History>
</Incident>
</IODEF-Document>
Danyliw, et al. Expires May 13, 2006 [Page 58]
Internet-Draft IODEF Data Model November 2005
Figure 37: 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
Danyliw, et al. Expires May 13, 2006 [Page 59]
Internet-Draft IODEF Data Model November 2005
8. The IODEF Document Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="draft-ietf-inch-iodef-050.xsd"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:iodef="draft-ietf-inch-iodef-050.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!--
********************************************************************
********************************************************************
*** Incident Object Description and Exchange Format XML Schema ***
*** Version 05, November 2005 ***
*** draft-ietf-inch-iodef-05 ***
********************************************************************
********************************************************************
-->
<!--
=====================================================================
== IODEF-Document class ==
====================================================================
-->
<xs:annotation>
<xs:documentation>Root Element IODEF-Document</xs:documentation>
</xs:annotation>
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident"/>
<xs:element ref="ds:Signature" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" fixed="1.00"/>
<xs:attribute name="lang" type="xs:language"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Incident class ===
Danyliw, et al. Expires May 13, 2006 [Page 60]
Internet-Draft IODEF Data Model November 2005
====================================================================
-->
<xs:element name="Incident">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"/>
<xs:element ref="iodef:AlternativeID" minOccurs="0"/>
<xs:element ref="iodef:RelatedActivity" minOccurs="0"/>
<xs:element ref="iodef:DetectTime" minOccurs="0"/>
<xs:element ref="iodef:StartTime" minOccurs="0"/>
<xs:element ref="iodef:EndTime" minOccurs="0"/>
<xs:element ref="iodef:ReportTime"/>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment" maxOccurs="unbounded"/>
<xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Contact" maxOccurs="unbounded"/>
<xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:History" minOccurs="0"/>
<xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="purpose" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="traceback"/>
<xs:enumeration value="mitigation"/>
<xs:enumeration value="reporting"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="lang" type="xs:language"/>
<xs:attribute ref="iodef:restriction" default="private"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== IncidentID class ==
====================================================================
-->
<xs:element name="IncidentID" type="iodef:IncidentIDType"/>
<xs:complexType name="IncidentIDType" mixed="true">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
<!--
====================================================================
== AlternativeID class ==
====================================================================
-->
Danyliw, et al. Expires May 13, 2006 [Page 61]
Internet-Draft IODEF Data Model November 2005
<xs:element name="AlternativeID">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== RelatedActivity class ==
====================================================================
-->
<xs:element name="RelatedActivity">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== AdditionalData class ===
====================================================================
-->
<xs:element name="AdditionalData" type="iodef:ExtensionType"/>
<!--
====================================================================
=== Contact class ===
=== - ContactName
=== - RegistryHandle
=== - PostalAddress
=== - Email
=== - Telephone
=== - Fax
=== - TimeZone
=== - Contact (recursive)
====================================================================
-->
<xs:element name="Contact">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ContactName" minOccurs="0"/>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:RegistryHandle" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
Danyliw, et al. Expires May 13, 2006 [Page 62]
Internet-Draft IODEF Data Model November 2005
<xs:element ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Telephone" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Fax" minOccurs="0"/>
<xs:element ref="iodef:TimeZone" minOccurs="0"/>
<xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="role">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="tech"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="person"/>
<xs:enumeration value="organization"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<xs:element name="ContactName" type="iodef:MLStringType" />
<xs:element name="RegistryHandle">
<xs:complexType mixed="true">
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="internic"/>
<xs:enumeration value="apnic"/>
<xs:enumeration value="arin"/>
<xs:enumeration value="lacnic"/>
<xs:enumeration value="ripe"/>
<xs:enumeration value="afrinic"/>
<xs:enumeration value="local"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
Danyliw, et al. Expires May 13, 2006 [Page 63]
Internet-Draft IODEF Data Model November 2005
<xs:element name="PostalAddress" type="iodef:MLStringType" />
<xs:element name="Email" type="xs:string"/>
<xs:element name="Telephone" type="xs:string"/>
<xs:element name="Fax" type="xs:string"/>
<!--
====================================================================
=== Time-based classes ===
====================================================================
-->
<xs:element name="DateTime" type="xs:dateTime"/>
<xs:element name="ReportTime" type="xs:dateTime"/>
<xs:element name="DetectTime" type="xs:dateTime"/>
<xs:element name="StartTime" type="xs:dateTime"/>
<xs:element name="EndTime" type="xs:dateTime"/>
<xs:element name="TimeZone" type="iodef:TimeZoneType"/>
<xs:simpleType name="TimeZoneType">
<xs:restriction base="xs:string">
<xs:pattern value="[+-][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>
<!--
====================================================================
=== History class ===
=== - HistoryItem
====================================================================
-->
<xs:element name="History">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:HistoryItem" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction" default="default"/>
</xs:complexType>
</xs:element>
<xs:element name="HistoryItem">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:DateTime"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/>
<xs:element ref="iodef:Description" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
<xs:attribute name="category" default="other">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="triaged"/>
<xs:enumeration value="notification"/>
<xs:enumeration value="shared-info"/>
Danyliw, et al. Expires May 13, 2006 [Page 64]
Internet-Draft IODEF Data Model November 2005
<xs:enumeration value="received-info"/>
<xs:enumeration value="remediation"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Expectation class ===
====================================================================
-->
<xs:element name="Expectation">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description" maxOccurs="unbounded"/>
<xs:element ref="iodef:StartTime" minOccurs="0"/>
<xs:element ref="iodef:EndTime" minOccurs="0"/>
<xs:element ref="iodef:Contact" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction" default="default"/>
<xs:attribute ref="iodef:severity"/>
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="nothing"/>
<xs:enumeration value="contact-site"/>
<xs:enumeration value="contact-me"/>
<xs:enumeration value="investigate"/>
<xs:enumeration value="block-host"/>
<xs:enumeration value="block-network"/>
<xs:enumeration value="block-port"/>
<xs:enumeration value="rate-limit-host"/>
<xs:enumeration value="rate-limit-network"/>
<xs:enumeration value="rate-limit-port"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Method class ===
=== - Classification
====================================================================
-->
Danyliw, et al. Expires May 13, 2006 [Page 65]
Internet-Draft IODEF Data Model November 2005
<xs:element name="Method">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Classification" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<xs:element name="Classification">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:name"/>
<xs:element ref="iodef:url" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="origin" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="bugtraqid"/>
<xs:enumeration value="cve"/>
<xs:enumeration value="certcc"/>
<xs:enumeration value="vendor"/>
<xs:enumeration value="local"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Assessment class ===
=== - Impact
=== - TimeImpact
=== - MonetaryImpact
=== - Confidence
====================================================================
-->
<xs:element name="Assessment">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Impact" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:TimeImpact" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:MonetaryImpact" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Confidence" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
Danyliw, et al. Expires May 13, 2006 [Page 66]
Internet-Draft IODEF Data Model November 2005
</xs:element>
<xs:element name="Impact">
<xs:complexType>
<xs:attribute ref="iodef:severity"/>
<xs:attribute name="completion">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="failed"/>
<xs:enumeration value="succeeded"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="type" use="optional" default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="none"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="dos"/>
<xs:enumeration value="file"/>
<xs:enumeration value="recon"/>
<xs:enumeration value="user"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="lang" type="xs:language"/>
</xs:complexType>
</xs:element>
<xs:element name="TimeImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:float">
<xs:attribute ref="iodef:severity"/>
<xs:attribute name="unit" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="labor"/>
<xs:enumeration value="elapsed"/>
<xs:enumeration value="downtime"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="metric" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
Danyliw, et al. Expires May 13, 2006 [Page 67]
Internet-Draft IODEF Data Model November 2005
<xs:enumeration value="days"/>
<xs:enumeration value="hours"/>
<xs:enumeration value="minutes"/>
<xs:enumeration value="seconds"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="MonetaryImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:float">
<xs:attribute ref="iodef:severity"/>
<xs:attribute name="currency" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:complexType>
<xs:attribute name="rating" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
<xs:enumeration value="numeric"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== EventData class ===
====================================================================
-->
<xs:element name="EventData">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:DetectTime" minOccurs="0"/>
Danyliw, et al. Expires May 13, 2006 [Page 68]
Internet-Draft IODEF Data Model November 2005
<xs:element ref="iodef:StartTime" minOccurs="0"/>
<xs:element ref="iodef:EndTime" minOccurs="0"/>
<xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment" minOccurs="0"/>
<xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Flow" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Expectation" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Record" minOccurs="0"/>
<xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction" default="default"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Flow class ===
====================================================================
-->
<xs:element name="Flow">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:System" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== System class ===
====================================================================
-->
<xs:element name="System">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef:Service" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:OperatingSystem" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
<xs:attribute name="interface" type="xs:string"/>
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="source"/>
<xs:enumeration value="target"/>
<xs:enumeration value="intermediate"/>
</xs:restriction>
Danyliw, et al. Expires May 13, 2006 [Page 69]
Internet-Draft IODEF Data Model November 2005
</xs:simpleType>
</xs:attribute>
<xs:attribute name="spoofed" default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Node class ===
====================================================================
-->
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:name" minOccurs="0"/>
<xs:element ref="iodef:Address" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Location" minOccurs="0"/>
<xs:element ref="iodef:DateTime" minOccurs="0"/>
<xs:element ref="iodef:NodeRole" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Address">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/>
<xs:enumeration value="mac"/>
<xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/>
Danyliw, et al. Expires May 13, 2006 [Page 70]
Internet-Draft IODEF Data Model November 2005
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="vlan-name" type="xs:string"/>
<xs:attribute name="vlan-num" type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Location" type="xs:string"/>
<xs:element name="NodeRole">
<xs:complexType mixed="true">
<xs:attribute name="category" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="client"/>
<xs:enumeration value="server-internal"/>
<xs:enumeration value="server-public"/>
<xs:enumeration value="www"/>
<xs:enumeration value="mail"/>
<xs:enumeration value="messaging"/>
<xs:enumeration value="streaming"/>
<xs:enumeration value="voice"/>
<xs:enumeration value="file"/>
<xs:enumeration value="ftp"/>
<xs:enumeration value="p2p"/>
<xs:enumeration value="name"/>
<xs:enumeration value="directory"/>
<xs:enumeration value="credential"/>
<xs:enumeration value="print"/>
<xs:enumeration value="application"/>
<xs:enumeration value="database"/>
<xs:enumeration value="infra"/>
<xs:enumeration value="log"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="lang" type="xs:language"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Service Class ===
====================================================================
-->
Danyliw, et al. Expires May 13, 2006 [Page 71]
Internet-Draft IODEF Data Model November 2005
<xs:element name="Service">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element ref="iodef:port"/>
<xs:element ref="iodef:portlist"/>
</xs:choice>
<xs:element ref="iodef:Application" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ip_version" type="xs:integer" default="4"/>
<xs:attribute name="ip_protocol" type="xs:integer"/>
</xs:complexType>
</xs:element>
<xs:element name="port" type="xs:integer"/>
<xs:element name="portlist" type="xs:string"/>
<!--
====================================================================
=== Application and OperatingSystem class ===
====================================================================
-->
<xs:complexType name="SoftwareType">
<xs:sequence>
<xs:element ref="iodef:url" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="swid" type="xs:string" default="0"/>
<xs:attribute name="configid" type="xs:string" default="0"/>
<xs:attribute name="vendor" type="xs:string"/>
<xs:attribute name="family" type="xs:string"/>
<xs:attribute name="name" type="xs:string"/>
<xs:attribute name="version" type="xs:string"/>
<xs:attribute name="patch" type="xs:string"/>
</xs:complexType>
<xs:element name="Application" type="iodef:SoftwareType" />
<xs:element name="OperatingSystem" type="iodef:SoftwareType" />
<!--
====================================================================
=== Counter class ===
====================================================================
-->
<xs:element name="Counter">
<xs:complexType>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="packet"/>
Danyliw, et al. Expires May 13, 2006 [Page 72]
Internet-Draft IODEF Data Model November 2005
<xs:enumeration value="session"/>
<xs:enumeration value="event"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="meaning" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Record class ===
====================================================================
-->
<xs:element name="Record">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:RecordData" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<xs:element name="RecordData">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:DateTime" minOccurs="0"/>
<xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Application" minOccurs="0"/>
<xs:element ref="iodef:RecordPattern" minOccurs="0" maxOccurs="unbounded" />
<xs:element ref="iodef:RecordItem" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="iodef:restriction"/>
</xs:complexType>
</xs:element>
<xs:element name="RecordPattern">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="regex"/>
<xs:enumeration value="binary"/>
<xs:enumeration value="xpath"/>
</xs:restriction>
Danyliw, et al. Expires May 13, 2006 [Page 73]
Internet-Draft IODEF Data Model November 2005
</xs:simpleType>
</xs:attribute>
<xs:attribute name="offset" type="xs:integer" use="optional" />
<xs:attribute name="offsetunit" use="optional" default="line">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="line"/>
<xs:enumeration value="byte"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="instance" type="xs:integer" use="optional" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="RecordItem" type="iodef:ExtensionType"/>
<!--
====================================================================
=== Miscellaneous simple classes ===
====================================================================
-->
<xs:element name="Description" type="iodef:MLStringType" />
<xs:element name="name" type="xs:string"/>
<xs:element name="url" type="xs:string"/>
<!--
====================================================================
=== Complex Data Types ===
====================================================================
-->
<xs:complexType name="MLStringType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ExtensionType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" use="required">
<xs:simpleType>
Danyliw, et al. Expires May 13, 2006 [Page 74]
Internet-Draft IODEF Data Model November 2005
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="boolean"/>
<xs:enumeration value="byte"/>
<xs:enumeration value="character"/>
<xs:enumeration value="date-time"/>
<xs:enumeration value="integer"/>
<xs:enumeration value="ntpstamp"/>
<xs:enumeration value="portlist"/>
<xs:enumeration value="real"/>
<xs:enumeration value="string"/>
<xs:enumeration value="file"/>
<xs:enumeration value="path"/>
<xs:enumeration value="frame"/>
<xs:enumeration value="packet"/>
<xs:enumeration value="ipv4-packet"/>
<xs:enumeration value="ipv6-packet"/>
<xs:enumeration value="url"/>
<xs:enumeration value="xml"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="meaning" type="xs:string"/>
<xs:attribute name="formatid" type="xs:string"/>
<xs:attribute ref="iodef:restriction"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
====================================================================
=== Global attribute list declarations. ===
====================================================================
-->
<!--
| @restriction: defines restrictions on access to an element's content
-->
<xs:attribute name="restriction">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="default"/>
<xs:enumeration value="public"/>
<xs:enumeration value="need-to-know"/>
<xs:enumeration value="private"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
Danyliw, et al. Expires May 13, 2006 [Page 75]
Internet-Draft IODEF Data Model November 2005
<!--
| @severity: conveys the severity or priority of something
-->
<xs:attribute name="severity">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:schema>
Danyliw, et al. Expires May 13, 2006 [Page 76]
Internet-Draft IODEF Data Model November 2005
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 the IODEF document itself is RECOMMENDED.
When used, the applied protective measures MUST use cryptographic
techniques. XML Digital Signatures [14] MUST be used for ensuring
integrity and non-repudiation, while XML Encryption [15] MUST be used
to ensure the confidentiality of an IODEF document. Examples using
signatures and encryption on an IODEF document can be found in
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)
Additional information on applying XML Digital Signatures and XML
Encryption to an IODEF document can be found in the IODEF
Implementation Guide [18].
Danyliw, et al. Expires May 13, 2006 [Page 77]
Internet-Draft IODEF Data Model November 2005
10. IANA considerations
Must be written
Danyliw, et al. Expires May 13, 2006 [Page 78]
Internet-Draft IODEF Data Model November 2005
11. Acknowledgments
The following groups contributed substantially to this document and
should be recognized for their efforts.
o the Incident Object Description and Exchange Format Working-Group
of the TERENA task-force (TF-CSIRT)
o the eCSIRT.net project
Danyliw, et al. Expires May 13, 2006 [Page 79]
Internet-Draft IODEF Data Model November 2005
12. References
12.1 Normative References
[1] Demchenko, Y., Hiroyuki, H., and G. Keeni, "Requirements for
Format for Incident Report Exchange", RFC XXX, November 2004.
[2] World Wide Web Consortium, "Extensible Markup Language (XML)
1.0 (Second Edition)", W3C Recommendation , October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[3] World Wide Web Consortium, "Namespaces in XML", W3C
Recommendation , January 1999,
<http://www.w3.org/TR/REC-xml-names/>.
[4] World Wide Web Consortium, "Extensible Stylesheet Language
(XSL) Version 1.0", W3C Recommendation , October 2001,
<http://www.w3.org/TR/xsl/>.
[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, July 2004.
[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] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[11] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[12] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[13] International Organization for Standardization, "International
Standard: Data elements and interchange formats - Information
interchange - Representation of dates and times", ISO 8601,
Second Edition, December 2000.
Danyliw, et al. Expires May 13, 2006 [Page 80]
Internet-Draft IODEF Data Model November 2005
[14] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[15] Imamura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax
and Processing, W3C Recommendation", December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[16] International Organization for Standardization, "International
Standard: Codes for the representation of currencies and funds,
ISO 4217:2001", ISO 4217:2001, August 2001.
12.2 Informative References
[17] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
Language Reference Model, ISBN 020130998X, Addison-Wesley",
1998.
[18] Danyliw, R., "The IODEF Implementation Guide", RFC XXX, 2003.
Authors' Addresses
Roman Danyliw
CERT Coordination Center
Pittsburgh
USA
Email: rdd@cert.org
Jan Meijer
SURFnet bv
Utrecht
Netherlands
Email: jan.meijer@surfnet.nl
Yuri Demchenko
University of Amsterdam
Netherlands
Email: demch@chello.nl
Danyliw, et al. Expires May 13, 2006 [Page 81]
Internet-Draft IODEF Data Model November 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Danyliw, et al. Expires May 13, 2006 [Page 82]
Internet-Draft IODEF Data Model November 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Danyliw, et al. Expires May 13, 2006 [Page 83]
