view Side-By-Side changes
Extended Incident Handling WG R. Danyliw
CERT
Internet-Draft CERT/NetSA
Intended status: Standards Track J. Meijer
Expires: December 10, 2006 February 9, 2007 SURFnet bv
Y. Demchenko
University of Amsterdam
June
August 08, 2006
The Incident Object Description Exchange Format Data Model and XML
Implementation
draft-ietf-inch-iodef-07.txt
draft-ietf-inch-iodef-08.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 December 10, 2006. February 9, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Danyliw, et al. Expires February 9, 2007 [Page 1]
Internet-Draft IODEF August 2006
Abstract
The purpose of the Incident Object Description Exchange Format (IODEF) is to define defines 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 December 10, 2006 [Page 1]
Internet-Draft IODEF Data Model June 2006
The IODEF satisfies the requirements specified in RFCXXX [17] This Internet-Draft document describes a
the data model for representing incident
information exported from incident handling systems managed by
CSIRTs. An implementation of the data model in IODEF and provides the Extensible Markup
Language (XML) is presented, an associated XML Document Type Definition is
developed, and examples are provided. Schema.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Overview . Notations . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. About the IODEF Data Model . . . . . . . . . . . . . . . . 5
1.4. About the IODEF Implementation . . . . . . . . . . . . . . 6
1.5. Related Work
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2. Formatting Issues
2.1. Integers . . . . . . . . . . . . . . . . . . . . . . 8
2.1. IODEF XML Documents . . . 7
2.2. Real Numbers . . . . . . . . . . . . . . . . 8
2.1.1. The Document Prolog . . . . . . . 7
2.3. Characters and Strings . . . . . . . . . . 8
2.1.2. Languages in the IODEF . . . . . . . . 7
2.4. Multilingual Strings . . . . . . . . 9
2.2. IODEF Data Types . . . . . . . . . . . 7
2.5. Bytes . . . . . . . . . . 9
2.2.1. Integers . . . . . . . . . . . . . . . . 7
2.6. Hexadecimal Bytes . . . . . . . 9
2.2.2. Real Numbers . . . . . . . . . . . . . 8
2.7. Enumerated Types . . . . . . . . 9
2.2.3. Characters and Strings . . . . . . . . . . . . . 8
2.8. Date-Time Strings . . . 10
2.2.4. Multilingual Strings . . . . . . . . . . . . . . . . . 10
2.2.5. Bytes 8
2.9. Timezone string . . . . . . . . . . . . . . . . . . . . . 8
2.10. Port Lists . . . 10
2.2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . 10
2.2.7. Enumerated Types . . . 8
2.11. Postal Address . . . . . . . . . . . . . . . . 11
2.2.8. Date-Time Strings . . . . . . 9
2.12. Person or Organization . . . . . . . . . . . . 11
2.2.9. Timezone string . . . . . . 9
2.13. Telephone and Fax Numbers . . . . . . . . . . . . . 11
2.2.10. Port Lists . . . 9
2.14. Email string . . . . . . . . . . . . . . . . . . . 11
2.2.11. Postal Address . . . . 9
2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 9
3. The IODEF Data Model . . . 11
2.2.12. Person or Organization . . . . . . . . . . . . . . . . 12
2.2.13. Telephone and Fax Numbers . . 10
3.1. IODEF-Document class . . . . . . . . . . . . 12
2.2.14. Email string . . . . . . . 10
3.2. Incident class . . . . . . . . . . . . . . 12
2.2.15. Uniform Resource Identifier strings . . . . . . . . 11
3.3. IncidentID class . 12
2.2.16. Unique Identifiers . . . . . . . . . . . . . . . . . . 12
3. The IODEF Data Model . . 14
3.4. AlternativeID class . . . . . . . . . . . . . . . . . . . 13
3.1. IODEF-Document 15
3.5. RelatedActivity class . . . . . . . . . . . . . . . . . . . 13
3.2. Incident class 15
3.6. AdditionalData . . . . . . . . . . . . . . . . . . . . . . 13
3.3. IncidentID 16
3.7. Contact class . . . . . . . . . . . . . . . . . . . . . 16
3.4. AlternativeID . 18
3.7.1. RegistryHandle class . . . . . . . . . . . . . . . . . . . 17
3.5. RelatedActivity class . . . . . . . . . . . . . . . . . . 18
3.6. AdditionalData . . . . . . . . . . . . . . . . . . . . . . 18
3.7. Contact class . . . . . . . . . . . . . . . . . . . . . . 20
3.7.1. RegistryHandle class . . . . . . . . . . . . . . . . . 23
3.8. Time classes 21
3.8. Time classes . . . . . . . . . . . . . . . . . . . . . . . 24
Danyliw, et al. Expires December 10, 2006 [Page 2]
Internet-Draft IODEF Data Model June 2006 22
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24 22
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24 22
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 24 22
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 24 23
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 24 23
3.9. Method class . . . . . . . . . . . . . . . . . . . . . . . 24 23
Danyliw, et al. Expires February 9, 2007 [Page 2]
Internet-Draft IODEF August 2006
3.9.1. Classification Reference class . . . . . . . . . . . . . . . . . 25 . . 24
3.10. Assessment class . . . . . . . . . . . . . . . . . . . . . 26 24
3.10.1. Impact class . . . . . . . . . . . . . . . . . . . . . 27 25
3.10.2. TimeImpact class . . . . . . . . . . . . . . . . . . . 28 27
3.10.3. MonetaryImpact class . . . . . . . . . . . . . . . . . 30 29
3.10.4. Confidence class . . . . . . . . . . . . . . . . . . . 31 30
3.11. History class . . . . . . . . . . . . . . . . . . . . . . 32 31
3.11.1. HistoryItem class . . . . . . . . . . . . . . . . . . 32
3.12. EventData class . . . . . . . . . . . . . . . . . . . . . 33
3.12.1. Relating the Incident and EventData classes . . . . . 35
3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 35 36
3.13. Expectation class . . . . . . . . . . . . . . . . . . . . 36
3.14. Flow class . . . . . . . . . . . . . . . . . . . . . . . . 39
3.15. System class . . . . . . . . . . . . . . . . . . . . . . . 39
3.16. Node class . . . . . . . . . . . . . . . . . . . . . . . . 41
3.16.1. Counter class . . . . . . . . . . . . . . . . . . . . 42
3.16.2. Address . . . . . . . . . . . . . . . . . . . . . . . 43 44
3.16.3. NodeRole class . . . . . . . . . . . . . . . . . . . . 44 45
3.17. Service class . . . . . . . . . . . . . . . . . . . . . . 45 47
3.17.1. Application class . . . . . . . . . . . . . . . . . . 47 48
3.18. OperatingSystem class . . . . . . . . . . . . . . . . . . 48 50
3.19. Record class . . . . . . . . . . . . . . . . . . . . . . . 48 50
3.19.1. RecordData class . . . . . . . . . . . . . . . . . . . 49 50
3.19.2. RecordPattern class . . . . . . . . . . . . . . . . . 49 51
3.19.3. RecordItem class . . . . . . . . . . . . . . . . . . . 51 53
4. Extending the IODEF . . . Processing Considerations . . . . . . . . . . . . . . . . . . 52 54
4.1. Extending the data model Encoding . . . . . . . . . . . . . . . . . 52
4.2. Extending the XML Schema . . . . . . . . . 54
4.2. IODEF Namespace . . . . . . . . 52
5. Processing Considerations . . . . . . . . . . . . . 54
4.3. Validation . . . . . 56
6. Internationalization issues . . . . . . . . . . . . . . . . . 57
7. Examples . . 55
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 56
5.1. Extending the enumerated values of attributes . . . . 58
7.1. Code Red detection notification . . 56
5.2. Extending classes . . . . . . . . . . . 58
7.2. IODEF-Document with XML signature . . . . . . . . . 56
6. Internationalization issues . . . 60
7.3. IODEF-Document encrypted using XML encryption . . . . . . 60
7.4. IODEF-Document encrypted and signed using XML
signature & encryption . . . . . . . . 59
7. Examples . . . . . . . . . . 60
8. The IODEF Document Schema . . . . . . . . . . . . . . . . . 60
7.1. Worm . 61
9. Security considerations . . . . . . . . . . . . . . . . . . . 78
10. IANA considerations . . . . . . . 60
7.2. Reconnaissance . . . . . . . . . . . . . . 79
11. Acknowledgments . . . . . . . . 61
7.3. Bot-Net Reporting . . . . . . . . . . . . . . . 80
12. References . . . . . 63
7.4. Watch List . . . . . . . . . . . . . . . . . . . . . 81
12.1. Normative References . . . 65
8. The IODEF Schema . . . . . . . . . . . . . . . . 81
Danyliw, et al. Expires December 10, 2006 [Page 3]
Internet-Draft IODEF Data Model June 2006 . . . . . . . 67
9. Security considerations . . . . . . . . . . . . . . . . . . . 88
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 89
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91
12.1. Normative References . . . . . . . . . . . . . . . . . . . 91
12.2. Informative References . . . . . . . . . . . . . . . . . . 82 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 83 93
Intellectual Property and Copyright Statements . . . . . . . . . . 84 94
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 4] 3]
Internet-Draft IODEF Data Model June August 2006
1. Introduction
1.1. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY,"
Organizations require help from other parties to mitigate malicious
activity targeting their network and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [4].
Definitions for some gain insight into potential
threats. This coordination might entail working with an ISP to
filter attack traffic, contacting a remote site to take down a bot-
network, or sharing watch-lists of the common computer security-related
terminology used in this document can be found known malicious IP addresses in Section 2 of [17].
1.2. Overview a
consortium.
The Incident Object Description Exchange Format (IODEF) is a format
for representing computer security information commonly exchanged
between Computer Security Incident Response Teams (CSIRTs). It
provides a
transport an XML representation conforming to the requirements specified in
[17], the Requirements for Format for Incident Report Exchange.
The overriding purpose of the IODEF is to expand and enhance conveying incident information
across administrative domains between parties that have an
operational responsibility of remediation or a watch-and-warning over
a defined constituency. The data model encodes information about
hosts, networks, and the services running on these systems; attack
methodology and associated forensic evidence; impact of the activity;
and limited approaches for documenting workflow.
The overriding purpose of the IODEF is to enhance the operational
capabilities of CSIRTs. Community adoption of the IODEF provides an
improved ability to resolve incidents and convey situational
awareness 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 analysis, specifically when data comes
from multiple constituencies.
Terminology, notation,
Coordinating with other CSIRTs is not strictly a technical problem.
There are numerous procedural, trust, and conventions legal considerations that
might prevent an organization from sharing information. The IODEF
does not attempt to address them. However operational
implementations of the IODEF will need to consider this broader
context.
Section 3 describes the abstract IODEF data model and Section 8
provides the corresponding XML Schema are presented in Sections 2. implementation. The types used
by the data model is described are covered in Section 3, 2. Processing
considerations, the handling of extensions, and internationalization
Danyliw, et al. Expires February 9, 2007 [Page 4]
Internet-Draft IODEF August 2006
issues related to the implementation considerations data model are covered in Sections 4 through 6. 4, 5, and 6
respectively. Examples are listed in Section 7 provides several examples of IODEF
documents. 7. Section 8 formally specifies 1 provides
the XML Schema
implementation of background for the data model. Sections 9 IODEF, and 10 address Section 9 documents the security
considerations.
1.1. Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and IANA considerations, respectively.
1.3. About "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [6].
Definitions for some of the IODEF Data Model common computer security-related
terminology used in this document can be found in Section 2 of [18].
1.2. Notations
The IODEF data model is a specified in two ways, as an abstract data representation that model and as
an XML Schema. Section 3 provides a
framework for sharing information commonly exchanged by CSIRTs about
Danyliw, et al. Expires December 10, 2006 [Page 5]
Internet-Draft Unified Modeling Language (UML)
model describing the individual classes and their relationship with
each other. The semantics of each class are discussed and their
attributes explained. In Section 8, this UML model is converted in
an XML Schema.
For clarity in this document, the term "XML document" will be used
when referring generically to any instance of an XML document. The
term "IODEF document" will be used to refer to specific elements and
attributes of the IODEF schema. Finally, the terms "class", and
"element" will be used interchangeably to reference either a given
UML class in the data model or its corresponding schema
implementation.
1.3. About the IODEF Data Model June 2006
The IODEF data model is a data representation that provides a
framework for sharing information commonly exchanged by CSIRTs about
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 As 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 in
the IODEF that is flexible enough to encompass most of the CSIRT community. operators.
Danyliw, et al. Expires February 9, 2007 [Page 5]
Internet-Draft IODEF August 2006
o Describing an incident for all definitions would require an
incredibly
extremely complex data model. Therefore, the IODEF data model only intends
to be a framework to convey commonly exchanged incident
information. However, it 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 domain of security analysis is not fully standardized and coordination are central must
rely on free-form textual descriptions. The IODEF attempts to the role of
strike a CSIRT.
Hence, tracking the source balance between supporting this free-form content, while
still allowing automated processing of all data incident information.
o The IODEF is central only one of several security relevant data
representations being standardized. Attempts were made to handling the
incident. Therefore, the ensure
they were complimentary. The data model provides ways to explicitly
bind information to a source, and accommodates differences in of the
types Intrusion
Detection Message Exchange Format [19] influenced the design of parties involved in
the incident (e.g., varying levels IODEF.
Further discussion of
confidence the desirable properties for the IODEF can be
found in information, different data sharing arrangements). the Requirements for the Format for Incident Information
Exchange (FINE) [18].
1.4. About the IODEF Implementation
The IODEF implementation uses the is specified as an Extensible Markup
Language (XML)
[1], specifies an XML Schema, and registers an application-specific
namespace [2].
For clarity [1] Schema [2] in this document, the terms "XML" and "XML documents"
will be used when referring to the Extensible Markup Language (XML).
Danyliw, et al. Expires December 10, 2006 [Page 6]
Internet-Draft IODEF Data Model June 2006
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 Section 8.
Implementing the IODEF in XML was made because provides numerous advantages. Its
extensibility makes it
provides:
o all the necessary features to define and extend a specific markup
language for describing security incidents;
o a well understood technique ideal for supporting internationalization
and localization;
o specifying a base of related technologies such as XSL [3], XPATH, and XML-SIG data encoding framework
that supports various character encodings. Likewise, the aid in the manipulation and use of the incident data; and
o a broad community abundance
of developers who already understand how to
build systems around data exchanged in this format.
While XML provides a useful implementation language related technologies (e.g., XSL, XPath, XML-Signature) makes for IODEF, this
implementation also dictates several limitations.
o
simplified manipulation. However, XML is fundamentally a text
representation making which makes 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. Related Work
The IODEF is only one of several security relevant data
representations being standardized. Specifically, the complementary
nature of the Intrusion Detection Message Exchange Format [19] 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 December 10, 2006 February 9, 2007 [Page 7] 6]
Internet-Draft IODEF Data Model June August 2006
2. Formatting Issues
2.1. IODEF XML Documents
This document uses three notations: the Unified Modeling Language
(UML) to describe the Data Types
The various data model, an XML Schema to define elements of the IODEF
syntax, and IODEF XML markup conforming to the specified Schema to
represent the incident data. data model are typed. This
section describes the XML notations and conventions used in this
document and explains particular issues related to using them to
describe the IODEF discusses these data model and syntax. For readers unfamiliar
with types. When possible, these notations, [18] 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 types are
enforced in the XML version used. If UTF-8 encoded Schema.
2.1. Integers
An integer is not used, represented by the
character encoding INTEGER data type. Integer data
MUST also be explicitly specified. encoded in Base 10.
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" INTEGER data type is the name of the character encoding implemented as registered
with the Internet Assigned Numbers Authority (IANA), see [7].
Consistent with the XML standard, if no encoding is specified for an
IODEF document, UTF-8 is assumed. IODEF documents encoded "xs:integer" [3] 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 December 10, 2006 [Page 8]
Internet-Draft IODEF Data Model June 2006
<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:lang" in the top-
level element and letting all other elements "inherit" that
definition.
The valid language codes for the "xs:lang" are described in RFC 3066
[5]. 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:lang".
2.2. IODEF Data Types
The IODEF data model defines a number of data types.
2.2.1. Integers
Integer Real Numbers
Real (floating-point) attributes are represented by the INTEGER REAL data
type. Integer Real 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". 10.
The INTEGER REAL data type is implemented as an "xs:integer" "xs:float" [3] 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
exponent part. An exponent part consists of an 'e' or 'E', followed
Danyliw, et al. Expires December 10, 2006 [Page 9]
Internet-Draft IODEF Data Model June 2006
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. schema.
2.3. Characters and Strings
Single-character attributes are
A single character is represented by the CHARACTER data type. Multi-character attributes of known length are A
character string is 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. Special
characters must be encoded using entity references. See Section 4.1.
The CHARACTER and STRING data types are implement as an "xs:string"
[3] in Schema.
2.2.4. the schema.
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" "iodef:MLStringType" 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. schema.
2.5. Bytes
Binary octets encoded using character code references (see )
A binary octet is represented by the BYTE (and BYTE[]) data type. A sequence of
binary octets is represented by the BYTE[] data type. These octets
are encoded using base64.
The BYTE data type is implemented as an "xs:string" "xs:base64Binary" [3] in Schema.
2.2.6. the
schema.
Danyliw, et al. Expires February 9, 2007 [Page 7]
Internet-Draft IODEF August 2006
2.6. Hexadecimal Bytes
Binary octets encoded using a notation where each
A binary octet is represented by the HEXBIN (and HEXBIN[]) data type.
This octet is encoded as a character tuple consisting of two
hexadecimal digits is represented
by the HEXBIN (and HEXBIN[]) data type. digits.
The HEXBIN data type is implemented as an "xs:string" "xs:hexBinary" [3] in Schema.
Danyliw, et al. Expires December 10, 2006 [Page 10]
Internet-Draft IODEF Data Model June 2006
2.2.7. the
schema.
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 the IODEF Schema, 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. the
schema.
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 [12] [14] documented in RFC 3339 [11]. [13].
The DATETIME data type is implemented as an "xs:dateTime" [3] in Schema.
2.2.9. Timezone the
schema.
2.9. Timezone string
A timezone offset from UTC is represented by the TIMEZONE data type.
It is formatted according to the following regular expression:
"Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".
The TIMEZONE data type is implemented as an "xs:string" with a
regular expression constraint in Schema. the schema. This regular expression
is identical to the timezone representation implemented in an "xs:
dateTime".
2.2.10.
2.10. Port Lists
A list of network ports are represented by the PORTLIST data type,
and consist type. A
PORTLIST consists 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. It is formatted according
to the following regular expression: "\d+(\-\d+)?(\,\d+(\-\d+)?)*".
Danyliw, et al. Expires February 9, 2007 [Page 8]
Internet-Draft IODEF August 2006
For example, "5-25,37,42,43,53,69-119,123-514". "2,5-15,30,32,40-50,55-60".
The PORTLIST data type is implemented as an "xs:string" with a
regular expression constraint in Schema.
2.2.11. the schema.
2.11. Postal Address
A postal address is represented by the POSTAL data type. This data
type is an a ML_STRING whose format is documented in Sections 6.27 of
RFC 2252 [9].
Danyliw, et al. Expires December 10, 2006 [Page 11]
Internet-Draft IODEF Data Model June 2006 [11]. It defines a postal address as a free-form multi-line
string separated by the "$" character.
The POSTAL data type is implemented as an "xs:string" in Schema.
2.2.12. the schema.
2.12. 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 [8]. [10].
The NAME data type is implemented as an "xs:string" in Schema.
2.2.13. the schema.
2.13. 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 6.30 of RFC 2252 [8].
[10].
The PHONE data type is implemented as an "xs:string" in Schema.
2.2.14. the schema.
2.14. 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 [10] [12]
The EMAIL data type is implemented as an "xs:string" in Schema.
2.2.15. the schema.
2.15. Uniform Resource Identifier Locator strings
A uniform resource identifier (URI) locator (URL is represented by the URI URL data type.
The format of the URI URL data type is documented in RFC 2396 [6]. [8].
The URI URL data type is implemented as an "xs:string" 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. schema.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 12] 9]
Internet-Draft IODEF Data Model June August 2006
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
described and the relationship with other classes with will be depicted
with UML. When necessary, specific comments will be made about
corresponding definition in the schema in Section 8
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 ]
| STRING formatid |
+-----------------+
Figure 1: IODEF-Document class
The aggregate class classes that constitutes constitute IODEF-Document is: are:
Incident
One or more. The information related to a single incident.
Signature
Zero or more. Cryptographic signature per [13] [15] to ensure the
integrity and authenticity of the document.
The IODEF-Document class has two attribute: three attributes:
version
Required. STRING. The IODEF specification version number to
which this IODEF document conforms. The value of this attribute
MUST be 1.0 "1.00"
lang
Required. ENUM. A valid language code per RFC 3066 [5]. [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 2.1.2. 6.
Danyliw, et al. Expires February 9, 2007 [Page 10]
Internet-Draft IODEF August 2006
formatid
Optional. STRING. A free-form string to convey processing
instructions to the recipient of the document. Its semantics must
be negotiated out-of-band.
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
identifier with the described activity.
Danyliw, et al. Expires December 10, 2006 [Page 13]
Internet-Draft IODEF Data Model June 2006
+-------------------+ data.
+--------------------+
| Incident |
+-------------------+
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| ENUM lang STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM restriction lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{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 The incident tracking numbers used by other CSIRTs
to refer to the incident described in the document.
RelatedActivity
Zero or one. A list of The incident tracking numbers of related incidents.
Danyliw, et al. Expires February 9, 2007 [Page 11]
Internet-Draft IODEF August 2006
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.
ReportTime
One. The time the incident was reported.
Danyliw, et al. Expires December 10, 2006 [Page 14]
Internet-Draft IODEF Data Model June 2006
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 four 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;
Danyliw, et al. Expires February 9, 2007 [Page 12]
Internet-Draft IODEF August 2006
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 December 10, 2006 [Page 15]
Internet-Draft IODEF Data Model June 2006
5. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-purpose
Optional. STRING. A means by which to extend the purpose
attribute. See Section 5.1.
lang
Required.
Optional. ENUM. A valid language code per RFC 3066 [5]. [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 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
This guideline provides no real security since it is the choice of
the recipient of the document to honor
this guideline. it.
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., (e.g., 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.
Danyliw, et al. Expires February 9, 2007 [Page 13]
Internet-Draft IODEF August 2006
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) that is
unique in the context of the CSIRT and identifies the
Danyliw, et al. Expires December 10, 2006 [Page 16]
Internet-Draft IODEF Data Model June 2006 activity
characterized in an IODEF-Document. IODEF Document. This identifier would serve as
an index into the CSIRT incident handling system. The combination of
the name attribute and the string in the element content MUST be a
globally unique identifier describing the activity. Documents
generated by a given CSIRT MUST NOT reuse the same value unless they
are referencing the same incident.
+------------------+
| IncidentID |
+------------------+
| UID STRING |
| |
| GUID STRING name |
+------------------+
Figure 3: the IncidentID class
The IncidentID class has one attribute:
name
Required. GUID. STRING. An identifier for describing the CSIRT that
created the
IODEF-Document. document. In order to have a globally unique CSIRT
name, the fully qualified domain name (DNS) of associated with the CSIRT
MUST be used.
Danyliw, et al. Expires February 9, 2007 [Page 14]
Internet-Draft IODEF August 2006
3.4. AlternativeID class
The AlternativeID class lists the incident tracking numbers used by
CSIRTs, other CSIRTs than the one generating the document, to refer to the
identical activity described in this the IODEF document.
Thus, a 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 December 10, 2006 [Page 17]
Internet-Draft IODEF Data Model June 2006
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, numbers
or to those of other CSIRTs.
The specifics of how a CSIRT came comes to believe that two incidents are
related is are considered out of scope.
+------------------+
| RelatedActivity |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
Figure 5: RelatedActivity
Danyliw, et al. Expires February 9, 2007 [Page 15]
Internet-Draft IODEF August 2006
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 schema can
be found in Section 4. 5.
Unlike XML, which is self-describing, atomic data must be documented
to convey its meaning. This information is described in the
'meaning' attribute. Since these description are outside the scope
Danyliw, et al. Expires December 10, 2006 [Page 18]
Internet-Draft IODEF Data Model June 2006
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 dtype |
| STRING ext-dtype |
| STRING meaning |
| STRING formatid |
| ENUM restriction |
+------------------+
Figure 6: the AdditionalData class
The AdditionalData class has three five attributes:
Danyliw, et al. Expires February 9, 2007 [Page 16]
Internet-Draft IODEF August 2006
dtype
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" content is of type BOOLEAN.
2. byte. The element content is a single 8-bit byte (see
Section 2.2.5); of type BYTE.
3. character. The element content is a single character (see
Section 2.2.3); of type CHARACTER.
4. date-time. The element content is a date-time string (see
Section 2.2.8); of type DATETIME.
5. integer. The element content is an integer (see
Section 2.2.1); of type INTEGER.
6. portlist. The element content is a port list (see
Section 2.2.10); of type PORTLIST.
7. real. The element content is a real number (see
Section 2.2.2); of type REAL.
8. string. The element content is a string (see Section 2.2.3);
Danyliw, et al. Expires December 10, 2006 [Page 19]
Internet-Draft IODEF Data Model June 2006 of type STRING.
9. file. The element content is a base64 encoded binary file; file
encoded as a BYTE[] type.
10. frame. The element content is a hexbin-encoded layer-2 frame
(see Section 2.2.6) encoded as a
HEXBIN type.
11. packet. The element content is a hexbin-encoded layer-3 packet (see Section 2.2.6) encoded as a
HEXBIN type.
12. ipv4-packet. The element content is an IPv4 hexbin-encoded packet (see Section 2.2.6) encoded
as a HEXBIN type.
13. ipv6-packet. The element content is an IPv6 hexbin-encoded packet (see Section 2.2.6) encoded
as a HEXBIN type.
14. path. The element content is a filesystem path; file-system path encoded as a
STRING type;
15. url. The element content is a URL (see Section 2.2.15;) of type URL.
16. csv. The element content is a common separated value list; list
encoded as a STRING type.
17. winreg. The element content is a Windows registry key; key
encoded as a STRING type.
Danyliw, et al. Expires February 9, 2007 [Page 17]
Internet-Draft IODEF August 2006
18. xml. The element content is XML-tagged data XML (see Section 4); 5).
19. other. The element content should be interpreted using ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-dtype
Optional. STRING. A means by which to extend the
formatid dtype
attribute. See Section 5.1.
meaning
Optional. STRING. A free-form description of the semantics of
the custom data in this class. element
content.
formatid
Optional. STRING. An identifier referencing the format and
semantics of the encapsulated data. element content.
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).
Danyliw, et al. Expires December 10, 2006 [Page 20]
Internet-Draft IODEF Data Model June 2006
The 'type' attribute disambiguates the type of contact information
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.
Danyliw, et al. Expires February 9, 2007 [Page 18]
Internet-Draft IODEF August 2006
+------------------+
| Contact |
+------------------+
| ENUM role |<>--{0..1}--[ ContactName ]
| ENUM type STRING ext-role |<>--{0..*}--[ Description ]
| ENUM restriction type |<>--{0..*}--[ RegistryHandle ]
| STRING ext-type |<>--{0..1}--[ PostalAddress ]
| ENUM restriction |<>--{0..*}--[ Email ]
| |<>--{0..*}--[ Telephone ]
| |<>--{0..1}--[ Fax ]
| |<>--{0..1}--[ Timezone ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..*}?-[ AdditionalData ]
+------------------+
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 many. 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. into the registry of the contact.
PostalAddress
Zero or one. POSTAL. The postal address of the contact formatted
according to Section 2.2.11.
Danyliw, et al. Expires December 10, 2006 [Page 21]
Internet-Draft IODEF Data Model June 2006 2.11.
Email
Zero or many. EMAIL. The email address of the contact formatted
according to Section 2.2.14. 2.14.
Telephone
Zero or many. PHONE. The telephone number of the contact
formatted according to Section 2.2.13. 2.13.
Fax
Zero or one. PHONE. The facsimile telephone number of the
contact formatted according to Section 2.2.13. 2.13.
Danyliw, et al. Expires February 9, 2007 [Page 19]
Internet-Draft IODEF August 2006
Timezone
Zero or one. TIMEZONE. The timezone in which the contact resides
formatted according to Section 2.2.9. 2.9.
Contact
Zero or many. A Contact instances instance contained within another Contact
instance inherit inherits the values of the parent(s). This recursive
definition can be used to group common data pertaining to multiple
points of contact, contact and is especially useful when listing multiple
points of contact
contacts at the same organization. When Contact elements are
defined recursively, only the leaf instances (those Contact
instances not containing other Contact instances) represent actual
points of contact.
AdditionalData
Zero or many. A mechanism by which to extend the data model.
At least one of the aggregate classes MUST be present in an instance
of the Contact class. This is not enforced in the IODEF schema as
there is no simple way to accomplish it.
The Contact class has three five 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.
6. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-role
Optional. STRING. A means by which to extend the role attribute.
See Section 5.1.
Danyliw, et al. Expires February 9, 2007 [Page 20]
Internet-Draft IODEF August 2006
type
Required. ENUM. Indicates the type of contact being described.
This attribute is defined as an enumerated list:
Danyliw, et al. Expires December 10, 2006 [Page 22]
Internet-Draft IODEF Data Model June 2006
1. person. The information for this contact references an
individual.
2. organization. The information for this contact references an
organization.
3. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.7.1. RegistryHandle class
The RegistryHandle class represents a handle to into an Internet
registry or community-specific database. A The handle consists of a name is specified in
the element content, content and the database to which it
belongs specified in the type attribute.
+------------------+ attribute specifies the database.
+---------------------+
| RegistryHandle |
+------------------+
+---------------------+
| STRING |
| |
| ENUM registry |
+------------------+
| STRING ext-registry |
+---------------------+
Figure 8: The RegistryHandle class
The RegistryHandle class has one attribute:
registry
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
Danyliw, et al. Expires February 9, 2007 [Page 21]
Internet-Draft IODEF August 2006
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.
Danyliw, et al. Expires December 10, 2006 [Page 23]
Internet-Draft IODEF Data Model June 2006
3.8. Time classes
The data model uses five different classes
8. ext-value. An escape value used to represent a timestamp.
Their definition extend this attribute.
See Section 5.1.
ext-registry
Optional. STRING. A means by which to extend the registry
attribute. See Section 5.1.
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
a difference in semantics.
The element content of each class is a timestamp formatted according
to the DATETIME data type (see Section 2.2.8). 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.
Danyliw, et al. Expires February 9, 2007 [Page 22]
Internet-Draft IODEF August 2006
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 in 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
Danyliw, et al. Expires December 10, 2006 [Page 24]
Internet-Draft IODEF Data Model June 2006
used in consists of a list
of references describing the attack; attack method and provide a free-form free form
description of the
activity. technique.
+------------------+
| Method |
+------------------+
| ENUM restriction |<>--{0..*}--[ Classification Reference ]
| |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 10: The Method class
The Method class is composed of two aggregate classes.
Classification
Reference
Zero or many. A reference to a well-known vulnerability vulnerability, malware sample,
advisory, or
exploit databases. analysis of an attack technique.
Description
Zero or many. ML_STRING. A free-form text description of the
methodology used by the intruder.
AdditionalData
Zero or many. A mechanism by which to extend the data model.
Either an instance of the Reference or Description class MUST be
present.
The Method class has one attribute:
Danyliw, et al. Expires February 9, 2007 [Page 23]
Internet-Draft IODEF August 2006
restriction
Optional. ENUM. This attribute is defined in Section 3.2.
3.9.1. Classification Reference class
The Classification Reference class is a reference to an external database of
computer vulnerabilities, exposures, a vulnerability, IDS alert,
malware sample, advisory, or viruses. attack technique. A reference consists
of the database a name, the entry name in the database, and
the URI a URL to this entry. reference, and an optional description.
+------------------+
| Classification Reference |
+------------------+
| ENUM origin |<>----------[ name ReferenceName ]
| |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ url Description ]
+------------------+
Figure 11: The Classification Reference class
The aggregate classes that constitute Classification:
Danyliw, et al. Expires December 10, 2006 [Page 25]
Internet-Draft IODEF Data Model June 2006
name Reference:
ReferenceName
One. STRING. The key into the database specified in ML_STRING. Name of the origin
attribute.
url reference.
URL
Zero or many. URI. URL. A URL to additional information about associated with the
vulnerability reference.
Description
Zero or exposure referenced by the name.
The Classification many. ML_STRING. A free-form text description of this
reference.
3.10. Assessment class has one attribute:
origin
Required. ENUM.
The name Assessment class describes the technical and non-technical
repercussions 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 incident on the CSIRT's constituency.
This class was derived from the IDMEF[19].
Danyliw, et al. Expires February 9, 2007 [Page 24]
Internet-Draft IODEF August 2006
+------------------+
| Assessment |
+------------------+
| ENUM restriction |<>--{0..*}--[ Impact ]
| |<>--{0..*}--[ TimeImpact ]
| |<>--{0..*}--[ MonetaryImpact ]
| |<>--{0..1}--[ Confidence ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 12: Assessment class
Danyliw, et al. Expires December 10, 2006 [Page 26]
Internet-Draft IODEF Data Model June 2006
The aggregate classes that constitute Assessment are:
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.
AdditionalData
Zero or many. A mechanism by which to extend the data model.
A least one instance of the possible three impact classes (i.e.,
Impact, TimeImpact, or MonetaryImpact) MUST be present.
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.
This class is based on the IDMEF [19].
Danyliw, et al. Expires February 9, 2007 [Page 25]
Internet-Draft IODEF August 2006
+------------------+
| Impact |
+------------------+
| ML_STRING |
| |
| STRING lang |
| ENUM severity |
| ENUM completion |
| ENUM type |
| STRING ext-type |
+------------------+
Figure 13: Impact class
The element content will be a free-form textual description of the
impact.
The Impact class has three attributes:
Danyliw, et al. Expires December 10, 2006 [Page 27]
Internet-Draft IODEF Data Model June 2006
lang
Required. ENUM. A valid language code per RFC 3066 [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 6.
severity
Optional. ENUM. An estimate of the relative severity of the
activity. The permitted values are shown below. There is no
default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
completion
Optional. ENUM. An indication whether the described activity was
successful. The permitted values are shown below. There is no
default value.
1. failed. The attempted activity was not successful.
2. succeeded. The attempted activity succeeded.
Danyliw, et al. Expires February 9, 2007 [Page 26]
Internet-Draft IODEF August 2006
type
Required. ENUM. Classifies the malicious activity into incident
categories. The permitted values are shown below. The default
value is "other".
1. admin. Administrative privileges were attempted.
2. dos. A denial of service was attempted.
3. file. An action on that impacts the integrity of a file or
database was attempted.
4. info-leak. An attempt was made to exfiltrate information.
5. misconfiguration. An attempt was made to exploit a mis-
configuration in a system.
6. policy. Activity violating site's policy was attempted
7. recon. Reconnaissance activity was attempted.
5.
8. social-engineering. A social engineering attack was
attempted.
9. user. User privileges were attempted.
6.
10. unknown. The classification of this activity is unknown.
7. other. Other activity not captured in
11. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-type
Optional. STRING. A means by which to extend the above categories. type attribute.
See Section 5.1.
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.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 28] 27]
Internet-Draft IODEF Data Model June August 2006
+------------------+
+---------------------+
| TimeImpact |
+------------------+
+---------------------+
| REAL |
| |
| ENUM severity |
| ENUM metric |
| ENUM units STRING ext-metric |
+------------------+
| ENUM duration |
| STRING ext-duration |
+---------------------+
Figure 14: TimeImpact class
The element content will be is a numeric value positive, floating point (REAL) number
specifying a unit of time. The unit duration 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) hours).
2. elapsed. Elapsed time from the beginning of the recovery to
its completion. completion (i.e., wall-clock time).
3. downtime. Duration of time for which some provided service(s)
was not available.
4. ext-value. An escape value used to extend this attribute.
See Section 5.1.
Danyliw, et al. Expires February 9, 2007 [Page 28]
Internet-Draft IODEF August 2006
ext-metric
Optional. STRING. A means by which to extend the metric
attribute. See Section 5.1.
duration
Required. ENUM. Defines a unit of time, that when combined with
the metric attribute, fully describes a metric of impact that will
be conveyed in the element content. The permitted values are
shown below. The default value is "hours".
Danyliw, et al. Expires December 10, 2006 [Page 29]
Internet-Draft IODEF Data Model June 2006 "hour".
1. second. Seconds. The unit of the element content is seconds.
2. minute. Minutes. The unit of the element content is minutes.
3. hour. Hours. The unit of the element content is hours.
4. day. Days. The unit of the element content is days.
5. month. Month. The unit of the element content is months.
6. quarter. Quarter. The unit of the element content is quarters.
7. year. Year. The unit of the element content is years.
8. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-duration
Optional. STRING. A means by which to extend the duration
attribute. See Section 5.1.
3.10.3. MonetaryImpact class
The MonetaryImpact class describes the financial impact of the
activity on an organization. For example, this impact may consider
losses due to the cost of the investigation or recovery, diminished
productivity of the staff, or a tarnished reputation that will affect
future opportunities.
Danyliw, et al. Expires February 9, 2007 [Page 29]
Internet-Draft IODEF August 2006
+------------------+
| MonetaryImpact |
+------------------+
| REAL |
| |
| ENUM severity |
| STRING currency |
+------------------+
Figure 15: MonetaryImpact class
The element content will be is a numeric value positive, floating point number (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
Danyliw, et al. Expires December 10, 2006 [Page 30]
Internet-Draft IODEF Data Model June 2006
3. high. High severity
currency
Required. ENUM. STRING. 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
[15].
[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.
This class if based upon the IDMEF [19]).
Danyliw, et al. Expires February 9, 2007 [Page 30]
Internet-Draft IODEF August 2006
+------------------+
| Confidence |
+------------------+
| REAL |
| |
| ENUM rating |
+------------------+
Figure 16: Confidence class
The element content expresses a numerical assessment in the
confidence of the data when the value of the rating attribute is
"numeric". Otherwise, this element should be empty.
The Confidence class has one attribute.
rating
Required. ENUM. A rating of the analytical validity of the
specified Assessment. The permitted values are shown below.
There is no default value.
1. low. Low confidence in the validity validity.
2. medium. Medium confidence in the validity validity.
3. high. High confidence in the validity
Danyliw, et al. Expires December 10, 2006 [Page 31]
Internet-Draft IODEF Data Model June 2006 validity.
4. numeric. The element content contains a number that conveys
the confidence of the data. The semantics of this number
outside the scope of this specification.
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 ]
| |
+------------------+
Danyliw, et al. Expires February 9, 2007 [Page 31]
Internet-Draft IODEF August 2006
Figure 17: 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.
Danyliw, et al. Expires December 10, 2006 [Page 32]
Internet-Draft IODEF Data Model June 2006
+------------------+
+-------------------+
| HistoryItem |
+------------------+
+-------------------+
| ENUM restriction |<>----------[ DateTime ]
| ENUM action |<>--{0..1}--[ IncidentId ]
| STRING ext-action |<>--{1..*}--[ Description ]
+------------------+
| |<>--{0..*}--[ AdditionalData ]
+-------------------+
Figure 18: HistoryItem class
The aggregate classes that constitute HistoryItem are:
DateTime
One. Timestamp of 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.
Danyliw, et al. Expires February 9, 2007 [Page 32]
Internet-Draft IODEF August 2006
Description
One or many. ML_STRING. A free-form textual description of the
action or event.
AdditionalData
Zero or many. A mechanism by which to extend the data model.
The HistoryItem class has two three attributes:
restriction
Optional. ENUM. This attribute has been defined in Section 3.2.
action
Optional. ENUM. Classifies a performed action or occurannce occurrence
documented in this history log entry. As activity will likely
have been instigated either through a previously conveyed
expectation,
expectation or internal investigation, this attribute is identical
to category attribute of the Expectation class. The
different difference is
only one of tense. When an action is in this class, it has been
completed. See Section 3.13.
ext-action
Optional. STRING. A means by which to extend the action
attribute. See Section 5.1.
3.12. EventData class
The EventData class describes the events a particular event of the incident surrounding for
a particular given 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
Danyliw, et al. Expires December 10, 2006 [Page 33]
Internet-Draft IODEF Data Model June 2006
activity on the organization, and any forensic evidence discovered.
Danyliw, et al. Expires February 9, 2007 [Page 33]
Internet-Draft IODEF August 2006
+------------------+
| 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 19: 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 Contact information for the parties involved in the incident.
event.
Assessment
Zero or one. The impact of the incident event on the target and the
actions taken.
Method
Zero or more. The methodology technique used by the intruders. intruder in the event.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 34]
Internet-Draft IODEF Data Model June August 2006
Flow
Zero or more. A description of the systems or networks involved.
Expectation
Zero or more. Expected The expected action to be performed by the
recipient of for the document. described event.
Record
Zero or one. Supportive data (e.g., log files) that provides
additional information about the event.
EventData
Zero or more. EventData instances contained within another
EventData instance inherit the values of the parent(s); this
recursive definition can be used to group common data pertaining
to multiple events. When EventData elements are defined
recursively, only the leaf instances (those EventData instances
not containing other EventData instances) represent actual events.
AdditionalData
Zero or one. An extension mechanism for data not explicitly
represented in the data model.
At least one of the aggregate classes MUST be present in an instance
of the EventData class. This is not enforced in the IODEF schema as
there is no simple way to accomplish it.
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 incident. In such as case, the interpretation of the more
specific EventData MUST supersede the more generic information
provided in IncidentData.
Danyliw, et al. Expires February 9, 2007 [Page 35]
Internet-Draft IODEF August 2006
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
Danyliw, et al. Expires December 10, 2006 [Page 35]
Internet-Draft IODEF Data Model June 2006
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 (or instance property inheritance) 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.
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 20.
+------------------+
| EventData |
+------------------+
| |<>----[ Contact ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
+------------------+
Figure 20: Recursion in the EventData class
3.13. Expectation class
The Expectation class conveys to the recipient of the IODEF document
the actions the sender is requesting. The scope of the requested
action is limited to purview of the EventData class in which this
class is aggregated.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 36]
Internet-Draft IODEF Data Model June August 2006
+------------------+
+-------------------+
| Expectation |
+------------------+
+-------------------+
| ENUM restriction |<>--{1..*}--[ |<>--{0..*}--[ Description ]
| ENUM severity |<>--{0..1}--[ StartTime ]
| ENUM action |<>--{0..1}--[ EndTime ]
| STRING ext-action |<>--{0..1}--[ Contact ]
+------------------+
+-------------------+
Figure 21: the Expectation class
The aggregate classes that constitute Expectation are:
Description
One
Zero 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. value, and
the semantics of these relative measures are context dependant.
1. low. Low priority
2. medium. Medium priority
3. high. High priority
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 37]
Internet-Draft IODEF Data Model June August 2006
action
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-source-site. Contact the site(s) identified as the
source of the activity.
3. contact-target-site. Contact the site(s) identified as the
target of the activity.
4. contact-sender. Contact the originator of the document.
5. investigate. Investigate the machine(s) systems(s) listed in the
document. event.
6. block-host. Block traffic from the machine(s) listed as
sources in the document. event.
7. block-network. Block traffic from the network(s) lists as
sources in the document. event.
8. block-port. Block the port listed as sources in the
document. event.
9. rate-limit-host. Rate-limit the traffic from the machine(s)
listed as sources in the document. event.
10. rate-limit-network. Rate-limit the traffic from the
network(s) lists as sources in the document. event.
11. rate-limit-port. Rate-limit the port(s) listed as sources in
the document. event.
12. remediate-other. Remediate the activity in a way other than
by rate limiting or blocking.
13. status-triage. Conveys receipts and the triaging of an
incident.
14. status-new-info. Conveys that new information was received
for this incident.
15. other. Perform some custom action described in the
Description class.
16. ext-value. An escape value used to extend this attribute.
See Section 5.1.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 38]
Internet-Draft IODEF Data Model June August 2006
ext-action
Optional. STRING. A means by which to extend the action
attribute. See Section 5.1.
3.14. Flow class
The Flow class groups related the source and target hosts or networks
(represented by System) in an event. hosts.
+------------------+
| Flow |
+------------------+
| |<>--{1..*}--[ System ]
+------------------+
Figure 22: the Flow class
The aggregate class that constitutes Flow is:
System
One or More. A host or network involved in the incident activity. an event.
The Flow System class has no attributes.
3.15. System class
The System class represents describes a computer system or network involved in the
incident. an event.
The systems or networks 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', "source", then the aggregated
classes denote the machine and service from which the activity is
originating. With a category attribute value of 'target' "target" or 'intermediary',
"intermediary", then the machine or service is the one targeted in
the activity.
+------------------+
| System A value of "sensor" dictates that this System was part
of an instrumentation to monitor the network.
Danyliw, et al. Expires February 9, 2007 [Page 39]
Internet-Draft IODEF August 2006
+---------------------+
|
+------------------+ System |
+---------------------+
| ENUM restriction |<>----------[ Node ]
| ENUM category |<>--{0..*}--[ Service ]
| STRING interface ext-category |<>--{0..*}--[ OperatingSystem ]
| STRING interface |<>--{0..*}--[ Counter ]
| ENUM spoofed |<>--{0..*}--[ Counter Description ]
+------------------+
| |<>--{0..*}--[ AdditionalData ]
+---------------------+
Figure 23: the System class
The aggregate classes that constitute System are:
Danyliw, et al. Expires December 10, 2006 [Page 39]
Internet-Draft IODEF Data Model June 2006
Node
One. A host or network involved in the incident.
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.
Description
Zero or more. ML_STRING. A free-form text description of the
System.
AdditionalData
Zero or many. A mechanism by which to extend the data model.
The System class has four five 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. event.
2. target. The System was the target of the attack. event.
Danyliw, et al. Expires February 9, 2007 [Page 40]
Internet-Draft IODEF August 2006
3. intermediate. The System was an intermediary in the attack. event.
4. sensor. The System was a sensor monitoring the event.
5. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
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 December 10, 2006 [Page 40]
Internet-Draft IODEF Data Model June 2006
3.16. Node class
The Node class identifies names a host, network device, system (e.g., PC, router) or network.
This class was derived from the IDMEF [19].
Danyliw, et al. Expires February 9, 2007 [Page 41]
Internet-Draft IODEF August 2006
+---------------+
| Node |
+---------------+
| |<>--{0..1}--[ name |<>--{0..*}--[ NodeName ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ Location ]
| |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ NodeRole ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 24: The Node class
The aggregate classes that constitute Node are:
name
NodeName
Zero or one. STRING. more. ML_STRING. The name of the equipment Node (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 If a name NodeName is not provided, at least one address must Address
MUST be specified.
Location
Zero or one. ML_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 NodeName are given. specified.
NodeRole
Zero or more. The intended purpose of the equipment. Node.
Counter
Zero or more. A counter with which to summarizes properties of
this host or network.
Danyliw, et al. Expires December 10, 2006 [Page 41]
Internet-Draft IODEF Data Model June 2006
3.16.1. Counter class
The Counter class summarize multiple occurrences of some event, or
conveys counts or rates on various features (e.g., packets, sessions,
events).
The value of the counter is the element content, content with its units
Danyliw, et al. Expires February 9, 2007 [Page 42]
Internet-Draft IODEF August 2006
represented in the type attribute. A rate for a given feature can be
expressed by setting the duration attribute. The complete semantics
are entirely context dependant based on the class in which the
Counter is aggregated.
+------------------+
| Counter |
+------------------+
| REAL |
| |
| ENUM type |
| STRING ext-type |
| STRING meaning |
| ENUM duration |
+------------------+
Figure 25: the Counter class
The Counter class has three attribute:
type
Required. ENUM. Specifies the units of the element contents. content.
1. byte. Count of bytes.
2. packet. Count of packets.
3. flow. Count of flow (e.g., NetFlow records).
4. session. Count of sessions
5. alert. Count of notifications generated by another system
(e.g., IDS or SIM).
6. message. Count of messages (e.g., mail messages).
7. event. Count of events
8. other. User defined count ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 42] 43]
Internet-Draft IODEF Data Model June August 2006
meaning
duration
Optional. STRING. Describes the semantics of the element content
if the type attribute is set to other.
duration
Optional. ENUM. If present, ENUM. If present, the Counter class represents a rate
rather than a count over the entire event. In that case, this
attribute specifies the denominator of the rate (where the type
attribute specified the nominator). The possible values of this
attribute are defined in Section 3.10.2
3.16.2. Address
The Address class represents a hardware (layer-2), network (layer-3),
or application (layer-7) address.
This class was derived from the IDMEF [19].
+------------------+
+---------------------+
| Address |
+------------------+
+---------------------+
| ENUM category |
| STRING ext-category |
| STRING vlan-name |
| INTEGER vlan-num |
+------------------+
+---------------------+
Figure 26: the Address class
The Address class has three 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)
Danyliw, et al. Expires December 10, 2006 [Page 43]
Internet-Draft IODEF Data Model June 2006
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)
Danyliw, et al. Expires February 9, 2007 [Page 44]
Internet-Draft IODEF August 2006
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
11. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
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 intended function performed by a
particular host.
+---------------+
+---------------------+
| NodeRole |
+---------------+
+---------------------+
| ML_STRING |
| |
| ENUM category |
| STRING ext-category |
| ENUM lang |
+---------------+
+---------------------+
Figure 27: The NodeRole class
The element content should be empty in all cases other than when the
category attribute is set to "other".
The NodeRole class has two attributes:
Danyliw, et al. Expires February 9, 2007 [Page 45]
Internet-Draft IODEF August 2006
category
Required. ENUM. Functionality provided by a node. If a value of
"other" is specified, a description SHOULD be provided in the
element content.
Danyliw, et al. Expires December 10, 2006 [Page 44]
Internet-Draft IODEF Data Model June 2006
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. (e.g., NNTP, IRC, IM)
7. streaming. Streaming-media server
8. voice. Voice server (e.g. (e.g., SIP, H.323)
9. file. File server (e.g. (e.g., SMB, CVS, AFS)
10. ftp. FTP server
11. p2p. Peer-to-peer node
12. name. Name server (e.g. (e.g., DNS, WINS)
13. directory. Directory server (e.g. (e.g., LDAP, finger, whois)
14. credential. Credential server (e.g. (e.g., domain controller,
Kerberos)
15. print. Print server
16. application. Application server
17. database. Database server
18. infra. Infrastructure server (e.g. (e.g., router, firewall, DHCP)
19. log. Logserver (e.g., syslog)
20. other. other The node performs a role not documented in the element
content.
Danyliw, et al. Expires February 9, 2007 [Page 46]
Internet-Draft IODEF August 2006
21. ext-value. An escape value used to extend this list attribute.
See Section 5.1.
ext-category
Optional. STRING. A means by which to extend the category
attribute. See Section 5.1.
lang
Required. ENUM. A valid language code per RFC 3066 [5]. [7]
constrained by the definition of "xs:language". The
interpretation of this code is described in Section 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
Danyliw, et al. Expires December 10, 2006 [Page 45]
Internet-Draft IODEF Data Model June 2006
with the application listening on that port.
When Service occurs as an aggregate class of a System that is a
source, then this 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 directed.
This class was derived from the IDMEF [19].
+---------------------+
| Service |
+---------------------+
| INTEGER ip_version |<>--{0..1}--[ port Port ]
| INTEGER ip_protocol |<>--{0..1}--[ portlist Portlist ]
| |<>--{0..1}--[ ProtoCode ]
| |<>--{0..1}--[ ProtoType ]
| |<>--{0..1}--[ ProtoFlags ]
| |<>--{0..1}--[ Application ]
+---------------------+
Figure 28: The Service class
The aggregate classes that constitute Service are:
port
Port
Zero or one. INTEGER. A port number.
portlist
Danyliw, et al. Expires February 9, 2007 [Page 47]
Internet-Draft IODEF August 2006
Portlist
Zero or one. PORTLIST. A list of port numbers formatted
according to Section 2.2.10. 2.10.
ProtoCode
Zero or one. INTEGER. A layer-4 protocol-specific code field.
ProtoType
Zero or one. INTEGER. A layer-4 protocol specific type field.
ProtoFlags
Zero or one. INTEGER. A layer-4 protocol specific flag field.
Application
Zero or more. The application bound to the specified port Port or
portlist.
The Service
Portlist.
Either a Port or Portlist class must specify either MUST be specified for a port given
instance of a Service class.
For a given source, System@type="source", a corresponding target,
System@type="target", maybe defined, or portlist.
Danyliw, et al. Expires December 10, 2006 [Page 46]
Internet-Draft IODEF Data Model June 2006
The vice versa. When a Portlist
class is defined in the Service class has two of both the source and target
in a given instance of the Flow class, there MUST be symmetry in the
enumeration of the ports. Thus, if n-ports are listed for a source,
n-ports should be listed for the target. Likewise, the ports should
be listed in an identical sequence such that the n-th port in the
source corresponds to the n-th port of the target. This symmetry in
listing and sequencing of ports applies whether there are 1-to-1,
1-to-many, or many-to-many sources-to-targets. In the 1-to-many or
many-to-many, the exact order in which the System classes are
enumerated in the Flow class is significant.
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 February 9, 2007 [Page 48]
Internet-Draft IODEF August 2006
+--------------------+
| Application |
+--------------------+
| STRING swid |<>--{0..1}--[ url URL ]
| STRING configid |
| STRING vendor |
| STRING family |
| STRING name |
| STRING version |
| STRING patch |
+--------------------+
Figure 29: The Application class
The aggregate classes that constitute Application are:
url
URL
Zero or one. URI. URL. A uri URL 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. configuration of this software.
vendor
Optional. STRING. Vendor name.
Danyliw, et al. Expires December 10, 2006 [Page 47]
Internet-Draft IODEF Data Model June 2006 name of the software.
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. level of the software.
Danyliw, et al. Expires February 9, 2007 [Page 49]
Internet-Draft IODEF August 2006
3.18. OperatingSystem class
The OperatingSystem class describes the operating system running on a
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. tools. These logs
should
provide evidence as to why a CSIRT believes an incident has occurred. substantiate the activity described in the document.
+------------------+
| Record |
+------------------+
| ENUM restriction |<>--{1..*}--[ RecordData ]
+------------------+
Figure 30: 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 Separate instances of the RecordData class SHOULD be used
for each sensor type.
The Record class has one attributes:
Danyliw, et al. Expires December 10, 2006 [Page 48]
Internet-Draft IODEF Data Model June 2006 attribute:
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 February 9, 2007 [Page 50]
Internet-Draft IODEF August 2006
+------------------+
| RecordData |
+------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ Application ]
| |<>--{0..*}--[ RecordPattern ]
| |<>--{1..*}--[ RecordItem ]
+------------------+
Figure 31: 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: attribute:
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 December 10, 2006 February 9, 2007 [Page 49] 51]
Internet-Draft IODEF Data Model June August 2006
log file, audit trail, or forensic data.
+------------------+
+-----------------------+
| RecordPattern |
+------------------+
+-----------------------+
| STRING |
| |
| ENUM type |
| STRING ext-type |
| INTEGER offset |
| ENUM offsetunit |
| STRING ext-offsetunit |
| INTEGER instance |
+------------------+
+-----------------------+
Figure 32: 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. element content. The default is "regex".
1. regex. POSIX PERL regular expression
2. binary. Binhex encoded binary pattern pattern, per the HEXBIN data
type
3. xpath. W3C XPath
offest
Optional. INTEGER. Amount of units (determined by the offsetunit XML Path (XPath) [5]
4. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-type
Optional. STRING. A means by which to extend the type attribute.
See Section 5.1.
offset
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.
Danyliw, et al. Expires February 9, 2007 [Page 52]
Internet-Draft IODEF August 2006
2. binary. Offset is a count of bytes bytes.
3. ext-value. An escape value used to extend this attribute.
See Section 5.1.
ext-offsetunit
Optional. STRING. A means by which to extend the offsetunit
attribute. See Section 5.1.
instance
Optional. INTEGER. Number of types to apply the specified
pattern.
Danyliw, et al. Expires December 10, 2006 [Page 50]
Internet-Draft IODEF Data Model June 2006
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
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 December 10, 2006 February 9, 2007 [Page 51] 53]
Internet-Draft IODEF Data Model June August 2006
4. Extending the Processing Considerations
This section defines additional requirements on creating and parsing
IODEF
In order to support the changing activity of CSIRTS, the documents.
4.1. Encoding
Every IODEF data
model will need to evolve along document MUST begin with them. To allow new features to
be added, both the data model an XML declaration, and MUST
specify 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 XML version used. If UTF-8 encoding is not found in used, the superclass.
o Aggregation allows for entirely new, self-contained classes to
character encoding MUST also be
created explicitly specified. The IODEF
conforms to all XML data encoding conventions and associated constraints.
The XML declaration with no character encoding will read as follows:
<?xml version="1.0" ?>
When a parent class.
Of the two extension mechanisms, inheritance character encoding is preferred, because it
preserves the existing data model and specified, the operations (methods)
executed on XML declaration will read
like 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 following:
<?xml version="1.0" encoding="charset" ?>
Where "charset" is the XML Schema
XML Schema provides a flexible way name of extending the IODEF data model
by defining extension schemas in a separate namespace. character encoding as registered
with the Internet Assigned Numbers Authority (IANA), see [9].
The following guidelines characters have special meaning in XML and MUST be followed when extending the IODEF
Schema
escaped with another schema:
1. their entity reference equivalent: "&", "<", ">", "\""
(double quotation mark), and "'" (apostrophe). These entity
references are "&", "<", ">", """, and "'"
respectively.
4.2. IODEF Namespace
The IODEF extension Schema MUST include an extension schema declares a namespace
definition of "iodef-1.0" and provide a reference to this schema's location registers it
per [4]. Each IODEF document MUST use 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 "iodef-1.0" namespace and declaration of in
the base
IODEF schema top-level element IODEF-Document. It can be added referenced as
follows:
<IODEF-Document
version="1.00" lang="en-US"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
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 URL to the extension Schema schema.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 52] 54]
Internet-Draft IODEF Data Model June August 2006
<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.
4.3. Validation
The location of IODEF documents MUST be well-formed XML and valid per the extension schema should be referenced
described in the Section 8. However, mere 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 validation is RECOMMENDED that all extensions start with "iodef-" prefix
and add specific extension abbreviation such as "ext1".
5. It may be convenient to add not
sufficient for a reference to the extension schema
and import this extension namespace to the base semantically valid IODEF schema.
Elements defined document. There are
numerous data dependant definitions in the extension schema can data model that cannot be used in any place
easily encoded in
final IODEF document. In the example below, the "iodef-xws"
extension is defined schema. They must be handled by additional
logic in the schema that contains one element "iodef-
xws:Principal". This element is composed of the NameIdentifier
element parser. The following are a list of XML type NCName and imports "iodef:Description" element
from discrepancies in
what is more strictly specified in the master IODEF schema.
Danyliw, et al. Expires December 10, 2006 [Page 53]
Internet-Draft IODEF Data Model June 2006
<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, data model but not
enforced in the above IODEF schema:
o The elements or attributes that are defined extension is used as POSTAL, NAME,
PHONE, EMAIL, and URL data-types are implemented as "xs:string",
but more rigid formatting requirements are specified in the
iodef:System element.
Danyliw, et al. Expires December 10, 2006 [Page 54]
Internet-Draft IODEF Data Model June 2006
<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=Joe Smith, OU=AIRG, O=UvA, S=NH, L=Holland, C=NL</NameIdentifier>
</iodef-xws:Principal>
</iodef:System>
Danyliw, et al. Expires December 10, 2006 [Page 55]
Internet-Draft IODEF Data Model June 2006
5. Processing Considerations text.
o The IODEF documents MUST be well-formed, IODEF-Document@lang and when practical, SHOULD
also be valid.
On occasion, MLStringType@lang attributes are
declared as an IODEF-compliant application may receive "xs:language" which constrains values with a well-
formed, or well-formed and
regular expression. However, the value of this attribute still
needs to be validated against the list of possible enumerated
values is defined in [7].
o The MonetaryImpact@currency attribute is declared as an "xs:
string", but the list of valid IODEF document containing tags or
content values is defined in [16].
o All of the tags that aggregated classes Contact and EventData are not expected. These spurious conditions
might include:
o Unrecognized tags used optional
in the schema, but at least one of the extension these aggregated classes (i.e.,
AdditionalData or RecordItem); MUST
be present.
o Unrecognized tags outside of The Confidence@rating attribute determines whether the extension classes; or
o Well-formed and validate document where element or
content of Confidence should be empty.
o The Address@type attribute
values to not conform to determines 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 format of the individual application to decide how to
process any content element
content.
o The attributes AdditionalData@dtype and RecordItem@dtype derived
from iodef:ExtensionType determine the unknown tag. semantics and formatting of
the element content.
o Symmetry in the enumerated ports of a Portlist class is required
between sources and targets. See Section 3.17.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 56] 55]
Internet-Draft IODEF Data Model June August 2006
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
5. Extending 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 support the explicit language on a per-element basis, changing activity of CSIRTS, the xs:
language attribute is used.
For IODEF data
model will need to evolve along with them. This section discusses
how new data elements that have no current representation in the languages data
model can be incorporated into the IODEF. These techniques are
designed so that do adding new data will not use UTF-8 encoding (e.g., Chinese Big5
or Japanese ISO-2022-JP), require a change to the
IODEF schema uses schema. With proven value, well documented extensions can be
incorporated into future versions of the MultilingTextType
type that allows specification. However,
this approach also support private extension relevant only to a binary transformation
closed consortium.
5.1. Extending the enumerated values of non-UTF-8 encoded text. attributes
The intent of the data model was supports a means by which 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 add new enumerated attributes values
to an attribute. For each attribute that can crudely
approximate supports this extension
technique (see XXX for a list), there is a corresponding attribute in
the contents same element whose name is identical less a prefix of "ext-".
This special attribute is referred to as the document. With this approach, a
CSIRT should be able extension attribute, and
the attribute being extended is referred to make some sense of as an IODEF document it might
receive that uses extensible
attribute. For example, an extensible attribute named "foo" will
have 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 corresponding extension attribute named "ext-foo". An element
may have many extensible, and therefore many extension, attributes.
In addition to a one-to-many
cardinality with corresponding extension attribute, each extensible
attribute has "ext-value" as one its parent (i.e., Description class). The primary
intent possible values. This
particular value serves as an escape sequence and has no valid
meaning.
In order to add a new enumerated value to an extensible attribute,
the value of this design was attribute MUST be set to allow "ext-value", and the same description to new
desired value MUST be
repeated set in another the corresponding extension attribute.
For example, an extended instance of the type attribute of the Impact
class but in a different
language. This approach allows recipients speaking different
languages would look as follows:
<Impact type="ext-value" ext-type="new-attack-type">
A given extension attribute MUST NOT be set unless the corresponding
extensible attribute has been set to receive "ext-value".
5.2. Extending classes
Classes can be extended only through the identical document, but allows use of the IODEF
parser AdditionalData
and RecordItem class. These container classes, collectively referred
to as the extensible classes, are implemented by the iodef:
ExtensionType data type in the schema. They provide the ability to
have new atomic or XML-encoded data elements in all of the top-level
classes of the Incident class and a few of the more complicated
Danyliw, et al. Expires February 9, 2007 [Page 56]
Internet-Draft IODEF August 2006
subordinate classes. As there are multiple instances of the
extensible classes in the data model, there is discretion on where to
add a new data element. It is RECOMMENDED that the extension be
placed in the most closely related class to the new information.
Extensions using the atomic data types (i.e., all values of the dtype
attributes other than "xml") MUST:
1. Set the element content of extensible class to the desired value,
and
2. Set the dtype attribute to correspond to the data type of the
element content.
The following guidelines MUST be followed for extensions using XML:
1. The element content of the extensible class MUST be set to the
desired value and the dtype attribute MUST be set to "xml".
2. The extension schema MUST declare a separate namespace. It is
RECOMMENDED that these extensions have the prefix "iodef-". The
base IODEF namespace and schema MUST also be imported in the this
new schema.
3. In the instance of the IODEF document using the extension, the
extension schema MUST be referenced.
4. It is RECOMMENDED that extension schemas follow the naming
convention of the IODEF data model. The names of all elements
are capitalized. For composed names, a capital letter is used
for each word. Attribute names are lower case.
The following schema and XML document excerpt provide a template for
an extension schema and its use in the IODEF document.
This example schema defines a namespace of "iodef-extension1" and a
single element named "newdata".
Danyliw, et al. Expires February 9, 2007 [Page 57]
Internet-Draft IODEF August 2006
<xs:schema
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="iodef-extension1.xsd"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import
namespace="draft-ietf-inch-iodef-080.xsd"
schemaLocation="draft-ietf-inch-iodef-080.xsd"/>
<xs:element name="newdata" type="xs:string" />
</xs:schema>
The following XML excerpt demonstrates the use of the above schema as
an extension to the IODEF.
<IODEF-Document
version="1.00" lang="en-US"
xmlns="http://www.iana.org/iodef"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:iodef="http://www.iana.org/iodef"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xsi:schemaLocation="iodef-extension1.xsd">
<Incident purpose="reporting">
...
<AdditionalData dtype="xml" meaning="xml">
<iodef-extension1:newdata>
Field that could not be represented elsewhere
</iodef-extension1:newdata>
</AdditionalData>
</IODEF-Document
Danyliw, et al. Expires February 9, 2007 [Page 58]
Internet-Draft IODEF August 2006
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.
Since IODEF is implemented as an XML Schema, it implicitly supports
all the different character encodings, such as UTF-8 and UTF-16,
possible with XML. Additionally, each IODEF document MUST specify
the language in which the their contents are encoded. The language
can be specified with the attribute "lang", of type "xs:language" [3]
in the top-level element (i.e., IODEF-Document@lang) and letting all
other elements inherit that definition. All IODEF classes with a
free-form text definition (i.e., all those defined of type iodef:
MLStringType) can also specify a language different from the rest of
the document. The valid language codes for the "xs:lang" are
described in RFC 3066 [7].
The data model supports multiple translations of free-form text. In
the places where free-text is used for descriptive purposes, the
given class always has a one-to-many cardinality to its parent (e.g.,
Description class). The intent is to allow the identical text to be
encoded in different instances of the same class, but each being in a
different language. This approach allows an IODEF document author to
send recipients speaking different languages an identical document.
The IODEF parser SHOULD extract the appropriate language relevant to
the recipient.
While the intent of the data model is to provide internationalization
and localization, the intent is not to do so at the detriment of
interoperability. While the 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 receives even if the text based data elements are
written in a language unfamiliar to the analyst.
Danyliw, et al. Expires February 9, 2007 [Page 59]
Internet-Draft IODEF August 2006
7. Examples
This section provides examples of an incident encoded in the IODEF.
These examples do not necessarily represent the only way to encode a
particular incident.
7.1. Worm
A example of a CSIRT reporting an instance of the Code Red worm.
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example demonstrates a report for a very
old worm (Code Red) -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">189493</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Host sending out Code Red probes</Description>
<!-- An administrative privilege was attempted, but failed -->
<Assessment>
<Impact completion="failed" type="admin"/>
</Assessment>
<Contact role="creator" type="organization">
<ContactName>Example.com CSIRT</ContactName>
<RegistryHandle registry="arin">example-com</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<Port>80</Port>
</Service>
</System>
Danyliw, et al. Expires February 9, 2007 [Page 60]
Internet-Draft IODEF August 2006
</Flow>
<Expectation action="block-host" />
<!-- <RecordItem> has an excerpt from a log -->
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description>
<RecordItem dtype="string">
192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem>
<!-- Additional logs -->
<RecordItem dtype="url">
http://mylogs.example.com/logs/httpd_access</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<!-- Contact was previously made with the source network owner -->
<HistoryItem action="contact-source-site">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>Notification sent to
constituency-contact@192.0.2.200</Description>
</HistoryItem>
</History>
</Incident>
</IODEF-Document>
7.2. Reconnaissance
An example of a CSIRT reporting a scanning activity.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes reconnaissance activity: one-to-one and
one-to-many scanning -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">59334</IncidentID>
<ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
Danyliw, et al. Expires February 9, 2007 [Page 61]
Internet-Draft IODEF August 2006
<Assessment>
<Impact type="recon" completion="succeeded" />
</Assessment>
<Method>
<!-- Reference to the scanning tool "nmap" -->
<Reference>
<ReferenceName>nmap</ReferenceName>
<URL>http://nmap.toolsite.example.com</URL>
</Reference>
</Method>
<!-- Organizational contact and that for staff in that
organization -->
<Contact role="creator" type="organization">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
<Telephone>+1 412 555 12345</Telephone>
<!-- Since this <Contact> is nested, Joe Smith is part of the
CSIRT for example.com -->
<Contact role="tech" type="person" restriction="need-to-know">
<ContactName>Joe Smith</ContactName>
<Email>smith@csirt.example.com</Email>
</Contact>
</Contact>
<EventData>
<!-- Scanning activity as follows:
192.0.2.1:60524 >> 192.0.2.3:137
192.0.2.1:60526 >> 192.0.2.3:138
192.0.2.1:60527 >> 192.0.2.3:139
192.0.2.1:60531 >> 192.0.2.3:445
-->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<Portlist>60524,60526,60527,60531</Portlist>
</Service>
</System>
<System category="target">
<Node>
<Address category="ipv4-addr">192.0.2.201</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<Portlist>137-139,445</Portlist>
</Service>
</System>
</Flow>
Danyliw, et al. Expires February 9, 2007 [Page 62]
Internet-Draft IODEF August 2006
<!-- Scanning activity as follows:
192.0.2.2 >> 192.0.2.3/28:445 -->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.240</Address>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.64/28</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<Port>445</Port>
</Service>
</System>
</Flow>
</EventData>
</Incident>
</IODEF-Document>
7.3. Bot-Net Reporting
An example of a CSIRT reporting a bot-network.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes a compromise and subsequent installation
of bots -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
<Incident purpose="mitigation">
<IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-06-08T05:44:53-05:00</ReportTime>
<Description>Large bot-net</Description>
<Assessment>
<Impact type="dos" severity="high" completion="succeeded" />
</Assessment>
<Method>
<!-- References a given piece of malware, "GT Bot" -->
<Reference>
<ReferenceName>GT Bot</ReferenceName>
</Reference>
<!-- References the vulnerabiliy used to compromise the
Danyliw, et al. Expires February 9, 2007 [Page 63]
Internet-Draft IODEF August 2006
machines -->
<Reference>
<ReferenceName>CA-2003-22</ReferenceName>
<URL>http://www.cert.org/advisories/CA-2003-22.html</URL>
<Description>Root compromise via this IE vulnerability to
install the GT Bot</Description>
</Reference>
</Method>
<!-- A member of the CSIRT that that is coordinating this
incident -->
<Contact type="person" role="irt">
<ContactName>Joe Smith</ContactName>
<Email>jsmith@csirt.example.com</Email>
</Contact>
<EventData>
<Description>These hosts are compromised and acting as bots
communicating with irc.example.com.</Description>
<Flow>
<!-- bot running on 192.0.2.1 and sending DoS traffic at
10,000 bytes/second -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.1</Address>
</Node>
<Counter type="byte" duration="second">10000</Counter>
<Description>bot</Description>
</System>
<!-- a second bot on 192.0.2.3 -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.3</Address>
</Node>
<Counter type="byte" duration="second">250000</Counter>
<Description>bot</Description>
</System>
<!-- Command-and-contro IRC server for these bots-->
<System category="intermediate">
<Node>
<NodeName>irc.example.com</NodeName>
<Address category="ipv4-addr">192.0.2.20</Address>
<DateTime>2006-06-08T01:01:03-05:00</DateTime>
</Node>
<Description>IRC server on #give-me-cmd channel</Description>
</System>
</Flow>
<!-- Request to select take these machines offline -->
<Expectation action="investigate">
<Description>Confirm the appropriate language. source and take machines off-line and
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 57] 64]
Internet-Draft IODEF Data Model June August 2006
7. Examples
This section provides representative examples
remediate</Description>
</Expectation>
</EventData>
</Incident>
</IODEF-Document>
7.4. Watch List
An example of incident data
converted to an IODEF document.
7.1. Code Red detection notification
The following email message is a typical CSIRT conveying a watch-list.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example of an incident
report where one host is infected with demonstrates a worm. The original report
sent by email is presented in Figure 38, and the corresponding
equivalent as an IODEF document trivial IP watch-list -->
<!-- @formatid 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 set to reply "watch-list-043" to demonstrate how additional
semantics about this email.
Your system with the IP number 10.1.1.2 seems to document could be infected
with the Code Red virus. There have been 57 separate instances of this activity detected from this IP.
For more information see http://www.domain.org/react/code_redII.html
Please fix the problem or inform a person who is responsible
for this machine.
>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 38: Code Red detection notification: initial report
<?xml version="1.0" encoding="UTF-8"?> conveyed assuming both
parties understood it-->
<IODEF-Document version="1.00"
xmlns="draft-ietf-inch-iodef-070.xsd" lang="en" formatid="watch-list-043"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="draft-ietf-inch-iodef-070.xsd">
<Incident purpose="reporting"> purpose="reporting" restriction="private">
<IncidentID name="CERT-DOMAIN.COM">CERT-DOMAIN.COM#189</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
Danyliw, et al. Expires December 10, 2006 [Page 58]
Internet-Draft IODEF Data Model June 2006
<Description>Host sending out Code Red probes</Description> name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-08-01T00:00:00-05:00</ReportTime>
<Description>Watch-list of known bad IPs or networks</Description>
<Assessment>
<Impact completion="failed" type="admin"/> type="admin" completion="succeeded" />
<Impact type="recon" completion="succeeded" />
</Assessment>
<Contact role="creator" type="organization">
<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 type="organization" role="creator">
<ContactName>CSIRT for 10.1.1.2</ContactName>
<RegistryHandle registry="apnic">example-foo</RegistryHandle>
<Email>Constituency-contact@10.1.1.2.pl</Email> example.com</ContactName>
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Separate <EventData> used to convey different <Expectation> -->
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">10.1.1.2</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">10.5.0.0/16</Address> category="ipv4-addr">192.0.2.53</Address>
</Node>
<Service ip_version="4" ip_protocol="6">
<port>80</port>
</Service>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<Expectation action="block-host">
<Description>Track and clean host</Description>
</Expectation>
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description>
<RecordItem dtype="string">
10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem>
<RecordItem dtype="url">http://mydomain.com/logs/httpd_access</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<HistoryItem action="contact-source-site">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>Notification sent
<!-- Expectation class indicating that sender of list would like
to constituency-contact@10.1.1.2</Description> be notified if activity from the host is seen -->
<Expectation action="contact-sender" />
</EventData>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 59] 65]
Internet-Draft IODEF Data Model June August 2006
</HistoryItem>
</History>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Description>
Source of heavy scanning over past 1-month
</Description>
</System>
</Flow>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.241</Address>
</Node>
<Description>C2 IRC server</Description>
</System>
</Flow>
<!-- Expectation class recommends that these networks
be filtered -->
<Expectation action="block-host" />
</EventData>
</Incident>
</IODEF-Document>
Figure 39: 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 December 10, 2006 February 9, 2007 [Page 60] 66]
Internet-Draft IODEF Data Model June August 2006
8. The IODEF Document Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef="draft-ietf-inch-iodef-070.xsd"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="draft-ietf-inch-iodef-070.xsd"
targetNamespace="urn:ietf:params:xml:ns:iodef-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import
namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
schemaLocation=
"http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<!--
********************************************************************
********************************************************************
*** Incident Object Description and Exchange Format XML Schema ***
*** Version 06, May 08, August 2006 ***
*** draft-ietf-inch-iodef-06 draft-ietf-inch-iodef-08 ***
********************************************************************
********************************************************************
-->
<!--
=====================================================================
====================================================================
== 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"/> ref="iodef:Incident"
maxOccurs="unbounded"/>
<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"/>
type="xs:language" use="required"/>
<xs:attribute name="formatid"
type="xs:string"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Incident class ===
====================================================================
-->
<xs:element name="Incident">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"/>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 61] 67]
Internet-Draft IODEF Data Model June August 2006
====================================================================
-->
<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:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-purpose"
type="xs:string" use="optional"/>
<xs:attribute name="lang"
type="xs:language"/>
<xs:attribute name="restriction"
Danyliw, et al. Expires February 9, 2007 [Page 68]
Internet-Draft IODEF August 2006
type="iodef:restriction-type" default="private"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== IncidentID class ==
====================================================================
-->
<xs:element name="IncidentID" type="iodef:IncidentIDType"/>
<xs:complexType name="IncidentIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name"
type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
====================================================================
== AlternativeID class ==
====================================================================
-->
<xs:element name="AlternativeID">
<xs:complexType>
Danyliw, et al. Expires December 10, 2006 [Page 62]
Internet-Draft IODEF Data Model June 2006
<xs:sequence>
<xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</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 name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
Danyliw, et al. Expires February 9, 2007 [Page 69]
Internet-Draft IODEF August 2006
====================================================================
=== 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"/>
<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"/>
Danyliw, et al. Expires December 10, 2006 [Page 63]
Internet-Draft IODEF Data Model June 2006
<xs:element ref="iodef:Timezone"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
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"/>
Danyliw, et al. Expires February 9, 2007 [Page 70]
Internet-Draft IODEF August 2006
<xs:enumeration value="tech"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-role"
type="xs:string" use="optional"/>
<xs:attribute name="type">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="person"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="ContactName"
type="iodef:MLStringType"/>
<xs:element name="RegistryHandle">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="registry">
<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:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-registry"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="PostalAddress" type="iodef:MLStringType"/>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 64] 71]
Internet-Draft IODEF Data Model June August 2006
</xs:complexType>
</xs:element>
<xs:element name="Email" 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="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]"/>
</xs:restriction>
</xs:simpleType>
<!--
====================================================================
=== History class ===
=== - HistoryItem
====================================================================
-->
<xs:element name="History">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:HistoryItem"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="default"/>
</xs:complexType>
</xs:element>
Danyliw, et al. Expires February 9, 2007 [Page 72]
Internet-Draft IODEF August 2006
<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:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<xs:attribute name="action"
type="iodef:action-type" default="other"/>
<xs:attribute name="ext-action"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Expectation class ===
====================================================================
Danyliw, et al. Expires December 10, 2006 [Page 65]
Internet-Draft IODEF Data Model June 2006
-->
<xs:element name="Expectation">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description"
minOccurs="0" 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 name="restriction"
type="iodef:restriction-type" default="default"/>
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="action"
type="iodef:action-type" default="other"/>
<xs:attribute name="ext-action"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
Danyliw, et al. Expires February 9, 2007 [Page 73]
Internet-Draft IODEF August 2006
=== Method class ===
=== - Classification
====================================================================
-->
<xs:element name="Method">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:Classification" minOccurs="0" maxOccurs="unbounded"/> ref="iodef:Reference"/>
<xs:element ref="iodef:Description" ref="iodef:Description"/>
</xs:choice>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="Classification"> name="Reference">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:name"/> name="ReferenceName"
type="iodef:MLStringType"/>
<xs:element ref="iodef:URL"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:url" ref="iodef:Description"
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>
Danyliw, et al. Expires December 10, 2006 [Page 66]
Internet-Draft IODEF Data Model June 2006
</xs:element>
<!--
====================================================================
=== Assessment class ===
=== - Impact
=== - TimeImpact
=== - MonetaryImpact
=== - Confidence
====================================================================
-->
<xs:element name="Assessment">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:Impact" minOccurs="0" maxOccurs="unbounded"/> ref="iodef:Impact"/>
<xs:element ref="iodef:TimeImpact" minOccurs="0" maxOccurs="unbounded"/> ref="iodef:TimeImpact"/>
<xs:element ref="iodef:MonetaryImpact" minOccurs="0" maxOccurs="unbounded"/> ref="iodef:MonetaryImpact"/>
</xs:choice>
<xs:element ref="iodef:Confidence"
Danyliw, et al. Expires February 9, 2007 [Page 74]
Internet-Draft IODEF August 2006
minOccurs="0"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<xs:element name="Impact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<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="admin"/>
<xs:enumeration value="dos"/>
<xs:enumeration value="extortion"/>
<xs:enumeration value="file"/>
<xs:enumeration value="info-leak"/>
<xs:enumeration value="misconfiguration"/>
<xs:enumeration value="recon"/>
<xs:enumeration value="policy"/>
<xs:enumeration value="social-engineering"/>
<xs:enumeration value="user"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="other"/> value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="TimeImpact">
<xs:complexType>
<xs:simpleContent>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 67] 75]
Internet-Draft IODEF Data Model June August 2006
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="TimeImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:float"> base="iodef:PositiveFloatType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="metric"
use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="labor"/>
<xs:enumeration value="elapsed"/>
<xs:enumeration value="downtime"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-metric"
type="xs:string" use="optional"/>
<xs:attribute name="duration"
type="iodef:duration-type"/>
<xs:attribute name="ext-duration"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="MonetaryImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:float"> base="iodef:PositiveFloatType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="currency"
type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:complexType mixed="true">
<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>
<!--
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 68] 76]
Internet-Draft IODEF Data Model June August 2006
</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"/>
<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 name="restriction"
type="iodef:restriction-type" default="default"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Flow class ===
====================================================================
-->
<xs:element name="Flow">
<xs:complexType>
Danyliw, et al. Expires February 9, 2007 [Page 77]
Internet-Draft IODEF August 2006
<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:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
Danyliw, et al. Expires December 10, 2006 [Page 69]
Internet-Draft IODEF Data Model June 2006
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<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:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="spoofed"
default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
Danyliw, et al. Expires February 9, 2007 [Page 78]
Internet-Draft IODEF August 2006
<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:choice maxOccurs="unbounded">
<xs:element ref="iodef:name" name="NodeName"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<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"
default="ipv4-addr">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
Danyliw, et al. Expires December 10, 2006 [Page 70]
Internet-Draft IODEF Data Model June 2006
<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"/>
Danyliw, et al. Expires February 9, 2007 [Page 79]
Internet-Draft IODEF August 2006
<xs:enumeration value="ipv6-net-mask"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<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="iodef:MLStringType"/>
<xs:element name="NodeRole">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<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:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 71] 80]
Internet-Draft IODEF Data Model June August 2006
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Service Class ===
====================================================================
-->
<xs:element name="Service">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:element ref="iodef:port"/> name="Port"
type="xs:integer"/>
<xs:element ref="iodef:portlist"/> name="Portlist"
type="iodef:PortlistType"/>
</xs:choice>
<xs:element name="ProtoType"
type="xs:integer" minOccurs="0"/>
<xs:element name="ProtoCode"
type="xs:integer" minOccurs="0"/>
<xs:element name="ProtoField"
type="xs:integer" minOccurs="0"/>
<xs:element ref="iodef:Application" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ip_version"
type="xs:integer" default="4"/> use="required"/>
<xs:attribute name="ip_protocol" type="xs:integer"/>
type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="port" type="xs:integer"/>
<xs:element name="portlist" type="xs:string"/>
<xs:simpleType name="PortlistType">
<xs:restriction base="xs:string">
<xs:pattern value="\d+(\-\d+)?(\,\d+(\-\d+)?)*"/>
</xs:restriction>
</xs:simpleType>
<!--
====================================================================
=== Application and OperatingSystem class ===
====================================================================
-->
<xs:complexType name="SoftwareType">
<xs:sequence>
<xs:element ref="iodef:url" ref="iodef:URL"
Danyliw, et al. Expires February 9, 2007 [Page 81]
Internet-Draft IODEF August 2006
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"/>
<!--
====================================================================
Danyliw, et al. Expires December 10, 2006 [Page 72]
Internet-Draft IODEF Data Model June 2006
=== Counter class ===
====================================================================
-->
<xs:element name="Counter">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="byte"/>
<xs:enumeration value="packet"/>
<xs:enumeration value="flow"/>
<xs:enumeration value="session"/>
<xs:enumeration value="event"/>
<xs:enumeration value="alert"/>
<xs:enumeration value="message"/>
<xs:enumeration value="other"/> value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<xs:attribute name="meaning"
type="xs:string" use="optional"/>
Danyliw, et al. Expires February 9, 2007 [Page 82]
Internet-Draft IODEF August 2006
<xs:attribute name="duration"
type="iodef:duration-type"/>
</xs:extension>
</xs:simpleContent>
</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 name="restriction"
type="iodef:restriction-type"/>
</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"/>
Danyliw, et al. Expires December 10, 2006 [Page 73]
Internet-Draft IODEF Data Model June 2006
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</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"/>
Danyliw, et al. Expires February 9, 2007 [Page 83]
Internet-Draft IODEF August 2006
<xs:enumeration value="binary"/>
<xs:enumeration value="xpath"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
<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:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-offsetunit"
type="xs:string" use="optional"/>
<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" name="URL"
type="xs:string"/>
<!--
====================================================================
=== Complex Re-used Data Types ===
====================================================================
-->
<xs:complexType name="MLStringType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:simpleType name="PositiveFloatType">
<xs:restriction base="xs:float">
<xs:minExclusive value="0"/>
</xs:restriction>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 74] 84]
Internet-Draft IODEF Data Model June August 2006
</xs:simpleType>
<xs:complexType name="MLStringType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:language"/> type="xs:language" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="ExtensionType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="dtype"
type="iodef:dtype-type" use="required"/>
<xs:attribute name="ext-dtype"
type="xs:string" use="optional"/>
<xs:attribute name="meaning"
type="xs:string"/>
<xs:attribute name="formatid"
type="xs:string"/>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
<!--
====================================================================
=== Global attribute type declarations. ===
====================================================================
-->
<!--
| @restriction: defines restrictions on access to an element's content
-->
<xs:simpleType name="restriction-type">
<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>
<!--
| @severity: conveys the severity or priority of something
-->
<xs:simpleType name="severity-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
Danyliw, et al. Expires February 9, 2007 [Page 85]
Internet-Draft IODEF August 2006
</xs:restriction>
</xs:simpleType>
<!--
| @duration: units of time
-->
<xs:simpleType name="duration-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="second"/>
<xs:enumeration value="minute"/>
<xs:enumeration value="hour"/>
<xs:enumeration value="day"/>
Danyliw, et al. Expires December 10, 2006 [Page 75]
Internet-Draft IODEF Data Model June 2006
<xs:enumeration value="month"/>
<xs:enumeration value="quarter"/>
<xs:enumeration value="year"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<!--
| @action: actions taken
-->
<xs:simpleType name="action-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="nothing"/>
<xs:enumeration value="contact-source-site"/>
<xs:enumeration value="contact-target-site"/>
<xs:enumeration value="contact-sender"/>
<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="remediate-other"/>
<xs:enumeration value="status-triage"/>
<xs:enumeration value="status-new-info"/>
<xs:enumeration value="other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
<!--
| @dtype: data types for extensions
-->
<xs:simpleType name="dtype-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="boolean"/>
<xs:enumeration value="byte"/>
<xs:enumeration value="character"/>
Danyliw, et al. Expires February 9, 2007 [Page 86]
Internet-Draft IODEF August 2006
<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"/>
Danyliw, et al. Expires December 10, 2006 [Page 76]
Internet-Draft IODEF Data Model June 2006
<xs:enumeration value="csv"/>
<xs:enumeration value="winreg"/>
<xs:enumeration value="xml"/>
<xs:enumeration value="other"/> value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 77] 87]
Internet-Draft IODEF Data Model June August 2006
9. Security considerations
This draft describes a
The IODEF data model itself does not directly introduce security
issues. Rather, it defines a data representation for incident information. Due to
the sensitive nature of some of the data
information 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 [13] MUST will likely be used for ensuring
integrity considered sensitive.
The underlying messaging format and non-repudiation, while XML Encryption [14] MUST be protocol used to ensure the confidentiality exchange
instances 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 the IODEF document can be found in must provide appropriate guarantees of
confidentiality, integrity, and authenticity. A transport protocol
such as the IODEF
Implementation Guide [20]. Real-time Inter-network Defense (RID) protocol [20] and
its associated transport binding IODEF/RID over SOAP [21] provide
such security.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 78] 88]
Internet-Draft IODEF Data Model June August 2006
10. IANA considerations
This document uses URNs to describe an XML namespaces namespace and XML schemas schema
conforming to a registry mechanism described in [16] [17]
Registration request for the iodef IODEF namespace:
o URI: urn:ietf:params:xml:ns:iodef-1.0
o Registrant Contact: See the "Author's Address" section 10.2 of this
document.
o XML: None. Namespace URIs do not represent an XML specification.
Registration request for the iodef IODEF XML schema:
o URI: urn:ietf:params:xml:schema:iodef-1.0
o Registrant Contact: See the "Author's Address" section 10.2 of this
document.
o XML: See the "IODEF Document Schema" of section in Section 8 of this document.
FIXME: Many of the enumerated types in this document are subject to
future extension, and should be defined by an IANA registry. The
IANA Considerations section must explicitly list each of these
enumerated types. Extensions to this registry may only be made by
IETF Informational RFCs. We will request that IANA maintain this
registry as an XML Schema defining a set of xs:simpleType elements
for named types to be referenced by a future revision of the IODEF
schema, further requiring that each value in each simpleType be
annotated as to the RFC creating it.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 79] 89]
Internet-Draft IODEF Data Model June August 2006
11. Acknowledgments
The following groups and individuals, listed alphabetically,
contributed substantially to this document and should be recognized
for their efforts.
o the Patrick Cain, Coop-Cain Group, Inc.
o The eCSIRT.net Project
o The Incident Object Description and Exchange Format Working-Group
of the TERENA task-force (TF-CSIRT)
o the eCSIRT.net project Glenn Mansfield Keeni, Cyber Solutions, Inc.
o Hiroyuki Kido, NARA Institute of Science and Technology
o Kathleen Moriarty, MIT Lincoln Labs
o Brian Trammell, CERT/NetSA
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 80] 90]
Internet-Draft IODEF Data Model June August 2006
12. References
12.1. Normative References
[1] 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>.
[2] World Wide Web Consortium, "XML XML Schema Part 1: Structures
Second Edition", W3C Recommendation , October 2004,
<http://www.w3.org/TR/xmlschema-1/>.
[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second
Edition", W3C Recommendation , October 2004,
<http://www.w3.org/TR/xmlschema-2/>.
[4] World Wide Web Consortium, "Namespaces in XML", W3C
Recommendation , January 1999,
<http://www.w3.org/TR/REC-xml-names/>.
[3]
[5] World Wide Web Consortium, "Extensible Stylesheet "XML Path Language
(XSL) Version 1.0", (XPath) 2.0", W3C
Candidate Recommendation , October 2001,
<http://www.w3.org/TR/xsl/>.
[4] June 2006,
<http://www.w3.org/TR/xpath20/>.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[5]
[7] Alvestrand, H., "Tags for the Identification of Languages",
RFC 3066, January 2001.
[6]
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[7]
[9] Freed, N., "IANA Charset Registration Procedures", BCP 2278,
January 1998.
[8]
[10] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
[9]
[11] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[10]
[12] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[11]
[13] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[12]
Danyliw, et al. Expires February 9, 2007 [Page 91]
Internet-Draft IODEF August 2006
[14] International Organization for Standardization, "International
Standard: Data elements and interchange formats - Information
interchange - Representation of dates and times", ISO 8601,
Second Edition, December 2000.
[13]
[15] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
Danyliw, et al. Expires December 10, 2006 [Page 81]
Internet-Draft IODEF Data Model June 2006
March 2002.
[14] 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/>.
[15]
[16] International Organization for Standardization, "International
Standard: Codes for the representation of currencies and funds,
ISO 4217:2001", ISO 4217:2001, August 2001.
[16]
[17] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
12.2. Informative References
[17]
[18] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the
Format for Incident Information Exchange (FINE)", RFC XXX,
December 2005.
[18] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
Language Reference Model, ISBN 020130998X, Addison-Wesley",
1998.
December 2005.
[19] Curry, D. and H. Debar, "Intrusion Detection Message Exchange
Format", RFC XXX, July 2004. March 2006.
[20] Danyliw, R., "The IODEF Implementation Guide", Moriarty, K., "Incident Handling: Real-time Inter-network
Defense", RFC XXX, June 2006.
[21] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", RFC XXX, 2003.
June 2006.
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 82] 92]
Internet-Draft IODEF Data Model June August 2006
Authors' Addresses
Roman Danyliw
CERT Coordination Center Program
Pittsburgh
USA
Email: rdd@cert.org
Jan Meijer
SURFnet bv
Utrecht
Netherlands
Email: jan.meijer@surfnet.nl
Yuri Demchenko
University of Amsterdam
Amsterdam
Netherlands
Email: demch@chello.nl
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 83] 93]
Internet-Draft IODEF Data Model June August 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
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.
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 (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).
Danyliw, et al. Expires December 10, 2006 February 9, 2007 [Page 84] 94]
----