view Side-By-Side changes

Extended Incident Handling WG                                    R. Danyliw
Internet-Draft
Working Group                                                    CERT/CC
Expires: February 9, 2006
Internet-Draft                                                 J. Meijer
Expires: May 13, 2006                                         SURFnet bv
                                                            Y. Demchenko
                                                 University of Amsterdam
                                                          August 8,
                                                        November 9, 2005


   The Incident Object Description Exchange Format Data Model and XML
                             Implementation
                      draft-ietf-inch-iodef-04.txt
                      draft-ietf-inch-iodef-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 3, May 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The purpose of the Incident Object Description Exchange Format
   (IODEF) is to define a data representation that provides a framework
   for sharing information commonly exchanged by Computer Security
   Incident Response Teams (CSIRTs) about computer security incidents.



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 1]

Internet-Draft              IODEF Data Model                 August               November 2005


   The IODEF satisfies the requirements specified in  RFCXXX [1]

   This Internet-Draft describes a data model for representing incident
   information exported from incident handling systems managed by
   CSIRTs.  An implementation of the data model in the Extensible Markup
   Language (XML) is presented, an XML Document Type Definition is
   developed, and examples are provided.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   5
     1.2  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3  About the IODEF Data Model . . . . . . . . . . . . . . . .   5
     1.4  About the IODEF Implementation . . . . . . . . . . . . . .   6
     1.5  About the Transport Protocol . . . . . . . . . . . . . . .   7
     1.6  Related Work . . . . . . . . . . . . . . . . . . . . . . .   7
   2.   Formatting Issues  . . . . . . . . . . . . . . . . . . . . .   9
     2.1  IODEF XML Documents  . . . . . . . . . . . . . . . . . . .   9
       2.1.1  The Document Prolog  . . . . . . . . . . . . . . . . .   9
       2.1.2  Languages in the IODEF . . . . . . . . . . . . . . . .  10
     2.2  IODEF Data Types . . . . . . . . . . . . . . . . . . . . .  10
       2.2.1  Integers . . . . . . . . . . . . . . . . . . . . . . .  10
       2.2.2  Real Numbers . . . . . . . . . . . . . . . . . . . . .  10
       2.2.3  Characters and Strings . . . . . . . . . . . . . . . .  11
       2.2.4  Multilingual Strings . . . . . . . . . . . . . . . . .  11
       2.2.5  Bytes  . . . . . . . . . . . . . . . . . . . . . . . .  11
       2.2.6  Hexadecimal Bytes  . . . . . . . . . . . . . . . . . .  11
       2.2.7  Enumerated Types . . . . . . . . . . . . . . . . . . .  11  12
       2.2.8  Date-Time Strings  . . . . . . . . . . . . . . . . . .  11  12
       2.2.9  Port Lists . . . . . . . . . . . . . . . . . . . . . .  12
       2.2.10   Postal Address . . . . . . . . . . . . . . . . . . .  12
       2.2.11   Person or Organization . . . . . . . . . . . . . . .  12
       2.2.12   Telephone and Fax Numbers  . . . . . . . . . . . . .  12  13
       2.2.13   Email string . . . . . . . . . . . . . . . . . . . .  12  13
       2.2.14   Uniform Resource Identifier strings  . . . . . . . .  12  13
       2.2.15   Timezone string  . . . . . . . . . . . . . . . . . .  12  13
       2.2.16   Unique Identifiers . . . . . . . . . . . . . . . . .  12  13
   3.   The IODEF Data Model . . . . . . . . . . . . . . . . . . . .  13  14
     3.1  IODEF-Document class . . . . . . . . . . . . . . . . . . .  13  14
     3.2  Incident class . . . . . . . . . . . . . . . . . . . . . .  13  14
     3.3  IncidentID class . . . . . . . . . . . . . . . . . . . . .  16  17
     3.4  AlternativeID class  . . . . . . . . . . . . . . . . . . .  17  18
     3.5  RelatedActivity class  . . . . . . . . . . . . . . . . . .  18  19
     3.6  AdditionalData . . . . . . . . . . . . . . . . . . . . . .  18  19
     3.7  Contact class  . . . . . . . . . . . . . . . . . . . . . .  20  21
       3.7.1  RegistryHandle class . . . . . . . . . . . . . . . . .  22  24
     3.8  Time classes . . . . . . . . . . . . . . . . . . . . . . .  23  24



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 2]

Internet-Draft              IODEF Data Model                 August               November 2005


       3.8.1  StartTime  . . . . . . . . . . . . . . . . . . . . . .  23  25
       3.8.2  EndTime  . . . . . . . . . . . . . . . . . . . . . . .  23  25
       3.8.3  DetectTime . . . . . . . . . . . . . . . . . . . . . .  23  25
       3.8.4  ReportTime . . . . . . . . . . . . . . . . . . . . . .  23  25
       3.8.5  DateTime . . . . . . . . . . . . . . . . . . . . . . .  24  25
     3.9  Expectation class  . . . . . . . . . . . . . . . . . . . .  24
     3.10  Method class . . . . . . . . . . . . . . . . . . . . . . .  25
       3.10.1
       3.9.1  Classification class . . . . . . . . . . . . . . . . .  26
     3.11
     3.10   Assessment class . . . . . . . . . . . . . . . . . . . .  27
       3.11.1
       3.10.1   Impact class . . . . . . . . . . . . . . . . . . . .  28
       3.11.2
       3.10.2   TimeImpact class . . . . . . . . . . . . . . . . . .  28
       3.11.3
       3.10.3   MonetaryImpact class . . . . . . . . . . . . . . . .  29
       3.11.4
       3.10.4   Confidence class . . . . . . . . . . . . . . . . . .  30
     3.12
     3.11   History class  . . . . . . . . . . . . . . . . . . . . .  31
       3.12.1
       3.11.1   HistoryItem class  . . . . . . . . . . . . . . . . .  31
     3.13
     3.12   EventData class  . . . . . . . . . . . . . . . . . . . .  33
       3.13.1
       3.12.1   Relating the Incident and EventData classes  . . . .  34
       3.13.2
       3.12.2   Cardinality of EventData . . . . . . . . . . . . . .  35
     3.13   Expectation class  . . . . . . . . . . . . . . . . . . .  36
     3.14   Flow class . . . . . . . . . . . . . . . . . . . . . . .  36  37
     3.15   System class . . . . . . . . . . . . . . . . . . . . . .  36  38
     3.16   Node class . . . . . . . . . . . . . . . . . . . . . . .  38  40
       3.16.1   Counter class  . . . . . . . . . . . . . . . . . . .  39  41
       3.16.2   Address  . . . . . . . . . . . . . . . . . . . . . .  39  41
       3.16.3   NodeRole class . . . . . . . . . . . . . . . . . . .  41  43
     3.17   Service class  . . . . . . . . . . . . . . . . . . . . .  42  44
       3.17.1   Application class  . . . . . . . . . . . . . . . . .  43  45
     3.18   OperatingSystem class  . . . . . . . . . . . . . . . . .  44  46
     3.19   Record class . . . . . . . . . . . . . . . . . . . . . .  45  47
       3.19.1   RecordData class . . . . . . . . . . . . . . . . . .  46  47
       3.19.2   RecordPattern class  . . . . . . . . . . . . . . . .  48
       3.19.3   RecordItem class . . . . . . . . . . . . . . . . . .  47  49
   4.   Extending the IODEF  . . . . . . . . . . . . . . . . . . . .  49  51
     4.1  Extending the data model . . . . . . . . . . . . . . . . .  49  51
     4.2  Extending the XML Schema . . . . . . . . . . . . . . . . .  49  51
   5.   Processing Considerations  . . . . . . . . . . . . . . . . .  53  55
   6.   Internationalization issues  . . . . . . . . . . . . . . . .  54  56
   7.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  55  57
     7.1  Code Red detection notification  . . . . . . . . . . . . .  55  57
     7.2  IODEF-Document with XML signature  . . . . . . . . . . . .  57  59
     7.3  IODEF-Document encrypted using XML encryption  . . . . . .  57  59
     7.4  IODEF-Document encrypted and signed using XML signature
          & encryption . . . . . . . . . . . . . . . . . . . . . . .  57  59
   8.   The IODEF Document Schema  . . . . . . . . . . . . . . . . .  58  60
   9.   Security considerations  . . . . . . . . . . . . . . . . . .  78  77
   10.  IANA considerations  . . . . . . . . . . . . . . . . . . . .  79  78
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  80  79
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  81  80
     12.1   Normative References . . . . . . . . . . . . . . . . . .  81  80



Danyliw, et al.           Expires May 13, 2006                  [Page 3]

Internet-Draft              IODEF Data Model               November 2005


     12.2   Informative References . . . . . . . . . . . . . . . . .  82



Danyliw, et al.         Expires February 3, 2006                [Page 3]

Internet-Draft              IODEF Data Model                 August 2005  81
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  82  81
        Intellectual Property and Copyright Statements . . . . . . .  84  82
















































Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 4]

Internet-Draft              IODEF Data Model                 August               November 2005


1.  Introduction

1.1  Terminology

   The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
   "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [5].

   Definitions for some of the common computer security-related
   terminology used in this document can be found in Section 2 of [1].

1.2  Overview

   The Incident Object Description Exchange Format (IODEF) is a format
   for representing computer security information exchanged between
   Computer Security Incident Response Teams (CSIRTs).  It provides a
   transport representation conforming to the requirements specified in
   [1], the Requirements for Format for Incident Report Exchange.

   The overriding purpose of the IODEF is to expand and enhance the
   operational capabilities of CSIRTs.  Community adoption of the IODEF
   provides an improved ability to resolve incidents by simplifying
   collaboration and data sharing.  This structured format provided by
   the IODEF allows for:

   o  increased automation in processing of incident data since the
      resources of security analysts to parse free-form textual
      documents will be reduced;

   o  decreased effort in normalizing similar data (even when highly
      structured) from different sources; and

   o  a common format on which to build interoperable tools for incident
      handling and subsequent analysis specifically when data comes from
      multiple constituencies.

   Terminology, notation, and conventions of the data model and XML
   Schema are presented in Sections 2.  The data model is described in
   Section 3, and the implementation considerations are covered in
   Sections 4 through 6.  Section 7 provides several examples of IODEF
   documents.  Section 8 formally specifies the XML Schema
   implementation of the data model.  Sections 9 and 10 address the
   security and IANA considerations, respectively.

1.3  About the IODEF Data Model

   The IODEF data model is a data representation that provides a
   framework for sharing information commonly exchanged by CSIRTs about



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 5]

Internet-Draft              IODEF Data Model                 August               November 2005


   computer security incidents.  A number of considerations were made in
   the design of the data model.

   o  The intent of the data model is to support the automated
      processing of incident data.  Hence, little consideration was made
      to ensure human-readability.  Despite the still prevalent practice
      of manual incident report generation, this model is sufficiently
      complex that it will be unwieldy to create and process without
      software.

   o  The data model serves as a transport format.  Therefore, its
      specific representation is not the optimal representation for on-
      disk storage, long-term archiving, or in-memory processing.

   o  Since there is no precise, widely agreed upon definition for an
      incident, the data model does not attempt to dictate one through
      its implementation.  Rather, a broad understanding is assumed that
      is flexible enough to encompass most of the CSIRT community.

   o  Describing an incident for all definitions would require an
      incredibly complex data model.  Therefore, the IODEF data model
      only intends to be a framework to convey commonly exchanged
      incident information.  However, it ensures that there are ample
      mechanisms for extensibility to support organization-specific
      information, and techniques to reference information kept outside
      of the explicit data model.

   o  Incidents have a life-cycle that dictates the exact type,
      quantity, and detail of the data that will be present at a given
      time (e.g., newly reported incidents may only contain the most
      rudimentary details, but closed incidents may contain a detailed
      analysis).  The data model deals with this situation.

   o  Communication and coordination are central to the role of a CSIRT.
      Hence, tracking the source of all data is central to handling the
      incident.  Therefore, the data model provides ways to explicitly
      bind information to a source, and accommodates differences in the
      types of parties involved in the incident (e.g., varying levels of
      confidence in information, different data sharing arrangements).


1.4  About the IODEF Implementation

   The IODEF implementation uses the Extensible Markup Language (XML)
   [2], specifies an XML Schema, and registers an application-specific
   namespace [3].

   For clarity in this document, the terms "XML" and "XML documents"



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 6]

Internet-Draft              IODEF Data Model                 August               November 2005


   will be used when referring to the Extensible Markup Language (XML).
   The terms "IODEF description", "IODEF markup" and "IODEF document"
   will be used to refer to specific elements (tags) and attributes of
   the IODEF Schema.  Finally, the terms "class" and "subclass" will be
   used as synonyms for an XML element.

   The choice to implement the IODEF in XML was made because it
   provides:

   o  all the necessary features to define and extend a specific markup
      language for describing security incidents;

   o  a well understood technique for supporting internationalization
      and localization;

   o  a base of related technologies such as XSL [4], XPATH, and XML-SIG
      that the aid in the manipulation and use of the incident data; and

   o  a broad community of developers who already understand how to
      build systems around data exchanged in this format.

   While XML provides a useful implementation language for IODEF, this
   implementation also dictates several limitations.

   o  XML is a text representation making it inherently inefficient
      either when binary data must be embedded or very large volumes of
      data must be exchanged.

   o  The data model is designed as a transport representation, and the
      use of XML further reinforces the inefficiency of using the IODEF
      for other purposes.  Due to the overhead of the parser, XML is not
      an optimal in-memory representation.  Furthermore, storing,
      searching, and retrieving native XML documents is problematic on a
      large scale dictating that this format is also a poor choice as a
      storage and archive format.


1.5  About the Transport Protocol

   Currently, there is no transport protocol specified for exchanging
   IODEF documents.  The working group has realized that this omission
   is an impediment to interoperability, and is working on identifying
   candidate protocols.  It is likely that SOAP will be used as the
   messaging envelope, and HTTP will be the underlying transport.

1.6  Related Work

   The IODEF is only one of several security relevant data



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 7]

Internet-Draft              IODEF Data Model                 August               November 2005


   representations being standardized.  Specifically, the complementary
   nature of the Intrusion Detection Message Exchange Format [7] bears
   mention given that many incidents represented in the IODEF may have
   first been discovered through the use of intrusion detection system
   output formatted according to the IDMEF.  Given this relationship,
   the IODEF data model makes use of certain classes defined in the
   IDMEF data model.












































Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 8]

Internet-Draft              IODEF Data Model                 August               November 2005


2.  Formatting Issues

2.1  IODEF XML Documents

   This document uses three notations: the Unified Modeling Language
   (UML) to describe the data model, an XML Schema to define the IODEF
   syntax, and IODEF XML markup conforming to the specified Schema to
   represent the incident data.

   This section describes the XML notations and conventions used in this
   document and explains particular issues related to using them to
   describe the IODEF data model and syntax.  For readers unfamiliar
   with these notations [17] and [7] will provide a comprehensive
   reference.

2.1.1  The Document Prolog

   The "prolog" of an XML document, that part that precedes anything
   else, consists of the XML declaration and the document type
   declaration.

2.1.1.1  XML Declaration

   Every IODEF document MUST begin with an XML declaration, and MUST
   specify the XML version used.  If UTF-8 encoded is not used, the
   character encoding MUST also be explicitly specified.

   The XML declaration with no character encoding will read as follows:

   <?xml version="1.0" ?>

   When a character encoding is specified, the XML declaration will read
   like the following:

   <?xml version="1.0" encoding="charset" ?>

   where "charset" is the name of the character encoding as registered
   with the Internet Assigned Numbers Authority (IANA), see [9].

   Consistent with the XML standard, if no encoding is specified for an
   IODEF document, UTF-8 is assumed.  IODEF documents encoded in UTF-16
   MUST begin with the Byte Order Mark described by ISO/IEC 10646 Annex
   E and Unicode Appendix B (the "ZERO WIDTH NO-BREAK SPACE" character,
   #xFEFF).

2.1.1.2  IODEF Namespace

   Each IODEF document must use the IODEF namespace "iodef" as follows:



Danyliw, et al.           Expires February 3, May 13, 2006                  [Page 9]

Internet-Draft              IODEF Data Model                 August               November 2005


   <IODEF-Document version="1.0"
                   xmlns:iodef="http://iana.org/iodef" xsi:schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd"

   where the string "http://iana.org/iodef/ietf-inch-iodef-1.0.xsd" is
   the URI to the schema.

2.1.2  Languages in the IODEF

   IODEF messages SHOULD specify the language in which their contents
   are encoded.  In general, the language can be specified with the
   attribute "language" that has reserved type "xs:language" in the top-
   level element and letting all other elements "inherit" that
   definition.

   The valid language codes for the "xs:language" are described in RFC
   3066 [6].  If no language is specified, English "en-US" SHOULD be
   assumed.

   For the IODEF classes that support free-form text in a language that
   differ from the rest of the document, this language can be specified
   by local attribute "xs:language".

2.2  IODEF Data Types

   The IODEF data model defines a number of data types.

2.2.1  Integers

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

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

   Base 16 integer encoding uses the digits '0' through '9' and 'a'
   through 'f' (or their upper case equivalents), and is preceded by the
   characters "0x".  For example, "0x1a2b".

   The INTEGER data type is implemented as an "xs:integer" in Schema

2.2.2  Real Numbers

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

   Real encoding is that of the POSIX "strtod" library function: an
   optional sign ('+' or '-') followed by a non-empty string of decimal
   digits, optionally containing a radix character, then an optional



Danyliw, et al.           Expires May 13, 2006                 [Page 10]

Internet-Draft              IODEF Data Model               November 2005


   exponent part.  An exponent part consists of an 'e' or 'E', followed
   by an optional sign, followed by one or more decimal digits.  For



Danyliw, et al.         Expires February 3, 2006               [Page 10]

Internet-Draft              IODEF Data Model                 August 2005
   example, "123.45e02", "-567,89e-03".

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

2.2.3  Characters and Strings

   Single-character

   The REAL data type is implemented as an "xs:float" in Schema.

2.2.3  Characters and Strings

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

   Character and string data have no special formatting requirements,
   other than the need to occasionally use character references to
   represent special characters.

   The CHARACTER and STRING data types are implement as an "xs:string"
   in Schema.

2.2.4  Multilingual Strings

   STRING data that represents multi-character attributes in a language
   different than the default encoding of the document are of the
   ML_STRING data type.

   The ML_STRING data type is implemented as an "xs:string" in Schema.
   Likewise, all elements that are of this type also have a
   corresponding "lang" attribute to dictate the language per
   Section 2.1.2.

2.2.5  Bytes

   Binary octets encoded using character code references (see ) is
   represented by the BYTE (and BYTE[]) data type.

   The BYTE data type is implemented as an "xs:string" in Schema.

2.2.6  Hexadecimal Bytes

   Binary octets encoded using a notation where each octet is encoded as
   a character tuple consisting of two hexadecimal digits is represented
   by the HEXBIN (and HEXBIN[]) data type.

   The HEXBIN data type is implemented as an "xs:string" in Schema.




Danyliw, et al.           Expires May 13, 2006                 [Page 11]

Internet-Draft              IODEF Data Model               November 2005


2.2.7  Enumerated Types

   Enumerated types are represented by the ENUM data type, and consist
   of an ordered list of acceptable values.  Each value has a
   representative keyword.  Within an IODEF Schema, the enumerated type
   keywords are used as attribute values.

   The ENUM data type is implemented as a series of "xs:NMTOKEN" in
   Schema.

2.2.8  Date-Time Strings

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

   Date-time strings are formatted according to a subset of ISO 8601:
   2000 [13] documented in RFC 3339 [12].




Danyliw, et al.         Expires February 3, 2006               [Page 11]

Internet-Draft              IODEF Data Model                 August 2005

   The DATEIME data type is implemented as an "xs:dateTime" in Schema.

2.2.9  Port Lists

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

   The PORTLIST data type is implemented as an "xs:string" in Schema.

2.2.10  Postal Address

   A postal address is represented by the POSTAL data type.  The format
   of this address  This data
   type is an ML_STRING whose format is documented in Sections 5.17 -
   5.19 of RFC 2256 [10].

   The POSTAL data type is implemented as an "xs:string" in Schema.

2.2.11  Person or Organization

   The name of an individual or organization is represented by the NAME
   data type.  The format of the NAME  This data type is an ML_STRING whose format is documented
   in Section 5.4 of RFC 2256 [10].

   The NAME data type is implemented as an "xs:string" in Schema.





Danyliw, et al.           Expires May 13, 2006                 [Page 12]

Internet-Draft              IODEF Data Model               November 2005


2.2.12  Telephone and Fax Numbers

   A telephone number is represented by the PHONE data type.  The format
   of the PHONE data type is documented in Section 5.21 of RFC 2256
   [10].

   The PHONE data type is implemented as an "xs:string" in Schema.

2.2.13  Email string

   An email address is represented by the EMAIL data type.  The format
   of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11]

   The EMAIL data type is implemented as an "xs:string" in Schema.

2.2.14  Uniform Resource Identifier strings

   A uniform resource identifier (URI) is represented by the URI data
   type.  The format of the URI data type is documented in RFC 2396 [8].

   The URI data type is implemented as an "xs:string" in Schema.

2.2.15  Timezone string

   A timezone offset from UTC is represented by the TIMEZONE data type.
   It is formatted according to the following regular expression:
   [+-][0-9][0-9][0-9][0-9].

   The TIMEZONE data type is implemented as an "xs:string" with a
   regular expression constraint in Schema.

2.2.16  Unique Identifiers

   A unique identifier in the context of particular creator of IODEF
   documents (e.g., a CSIRT) is represented by the UID data type.  A
   globally unique identifier is represented by the GUID data type.  The
   UID and GUID data types are constructed from alphanumeric strings.

   The UID and GUID data types are implemented as an "xs:string" in
   Schema.











Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 12] 13]

Internet-Draft              IODEF Data Model                 August               November 2005


3.  The IODEF Data Model

   In this section, the individual components of the IODEF data model
   will be discussed in detail.  For each class, the semantics will be
   documented and the relationship with other classes with be depicted
   with UML.

3.1  IODEF-Document class

   The IODEF-Document class is the top level class in the IODEF data
   model.  All IODEF documents are an instance of this class.


   +-----------------+
   | IODEF-Document  |
   +-----------------+
   | STRING version  |<>--{1..*}--[ Incident     ]
   |                 | ENUM lang       |<>--{0..*}--[ ds:Signature ]
   +-----------------+

                      Figure 1: IODEF-Document class

   The aggregate class that constitutes IODEF-Document is:

   Incident
      One or more.  The information related to a single incident.

   Signature
      Zero or more.  Cryptographic signature per [14] to ensure the
      integrity and authenticity of the document.

   The IODEF-Document class has one two attribute:

   version
      Required.  STRING.  The IODEF specification version number to
      which the this IODEF document conforms.  The value of this attribute
      MUST be 1.0

   lang
      Required.  ENUM.  A valid language code per RFC 3066 [6].  The
      interpretation of this code is described in Section 2.1.2.


3.2  Incident class

   Every incident is represented by an instance of the Incident class.
   This class provides a standardized representation for commonly
   exchanged incident data and associates a CSIRT assigned unique
   identifier with the described activity.



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 13] 14]

Internet-Draft              IODEF Data Model                 August               November 2005


   identifier with the described activity.


   +-------------------+
   | Incident          |
   +-------------------+
   | ENUM purpose      |<>----------[ IncidentID      ]
   | ENUM restriction lang         |<>--{0..1}--[ AlternativeID   ]
   | ENUM restriction  |<>--{0..1}--[ RelatedActivity ]
   |                   |<>--{0..*}--[ Description     ]
   |                   |<>--{1..*}--[ Assessment      ]
   |                   |<>--{0..*}--[ Method          ]
   |                   |<>--{0..1}--[ DetectTime      ]
   |                   |<>--{0..1}--[ StartTime       ]
   |                   |<>--{0..1}--[ EndTime         ]
   |                   |<>----------[ ReportTime      ]
   |                   |<>--{0..*}--[ Description     ]
   |                   |<>--{1..*}--[ Contact Assessment      ]
   |                   |<>--{0..*}--[ Expectation Method          ]
   |                   |<>--{0..1}--[ History                   |<>--{1..*}--[ Contact         ]
   |                   |<>--{0..*}--[ EventData       ]
   |                   |<>--{0..1}--[ History         ]
   |                   |<>--{0..*}--[ AdditionalData  ]
   +-------------------+

                       Figure 2: the Incident class

   The aggregate classes that constitute Incident are:

   IncidentID
      One. An incident tracking number assigned to this incident by the
      CSIRT that generated the IODEF document.

   AlternativeID
      Zero or one.  A list of incident tracking numbers used by other
      CSIRTs to refer to the incident described in the document.

   RelatedActivity
      Zero or one.  A list of incident tracking numbers of related
      incidents.

   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.





Danyliw, et al.         Expires February 3, 2006               [Page 14]

Internet-Draft              IODEF Data Model                 August 2005

   DetectTime
      Zero or one.  The time the incident was first detected.

   StartTime
      Zero or one.  The time the incident started.

   EndTime
      Zero or one.  The time the incident ended.





Danyliw, et al.           Expires May 13, 2006                 [Page 15]

Internet-Draft              IODEF Data Model               November 2005


   ReportTime
      One. The time the incident was reported.

   Description
      Zero or more.  ML_STRING.  A free-form textual description of the
      incident.

   Assessment
      One or more.  A characterization of the impact of the incident.

   Method
      Zero or more.  The techniques used by the intruder in the
      incident.

   Contact
      One or more.  Contact information for the parties involved in the
      incident.

   Expectation

   EventData
      Zero or more.  Expected action to be performed by the recipient  Description of the document. events comprising the incident,

   History
      Zero or one.  A log of significant events or actions that occurred
      during the course of handling the incident.

   EventData
      Zero or more.  Description of the events comprising the incident,

   AdditionalData
      Zero or more.  Mechanism by which to extend the data model.

   The Incident class has two three attributes:

   purpose
      Required.  ENUM.  The purpose attribute represents the reason why
      the IODEF document was created.  It is closely related to the
      Expectation class (Section 3.9). 3.13).  This attribute is defined as an
      enumerated list:

      1.  traceback.  The document was sent for trace-back purposes;

      2.  mitigation.  The document was sent to request aid in
          mitigating the described activity;

      3.  reporting.  The document was sent to comply with reporting
          requirements;

      4.  other.  The document was sent for purposes specified in the
          Expectation class.





Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 15] 16]

Internet-Draft              IODEF Data Model                 August               November 2005


   lang
      Required.  ENUM.  A valid language code per RFC 3066 [6].

   restriction
      Optional.  ENUM.  This attribute indicates the disclosure
      guidelines to which the sender expects the recipient of the IODEF-
      Document to adhere.  Naturally, this provides no real security
      since it is the choice of the recipient of the document to honor
      this guideline.

      The value of this attribute is logically inherited by the children
      of this class.  That is to say, the disclosure rules applied to
      this class, also apply to its children.

      It is possible to set a granular disclosure policy, since all of
      the high-level classes (i.e., children of the Incident class) have
      a restriction attribute.  Therefore, a child can override the
      guidelines of a parent class, be it to restrict or relax the
      disclosure rules (i.e., a child has a weaker policy than an
      ancestor; or an ancestor has a weak policy, and the children
      selectively apply more rigid controls).  The implicit value of the
      restriction attribute for a class that did not specify one can be
      found in the closest ancestor that did specify a value.

      This attribute is defined as an enumerated value with a default
      value of "private".

      Note that the default value of the restriction attribute is only
      defined in the context of the Incident class.  In other classes
      where this attribute is used, no default is specified.

      1.  public.  There are no restrictions placed in the information;

      2.  need-to-know.  The information may be shared with other
          parties that are involved in the incident (e.g., multiple
          victim sites can be informed of each other);

      3.  private.  The information may not be shared.

      4.  default.  The information can be shared according to an
          information disclosure policy pre-arranged by the
          communicating parties.



3.3  IncidentID class

   The IncidentID class represents an incident tracking number (UID)



Danyliw, et al.           Expires May 13, 2006                 [Page 17]

Internet-Draft              IODEF Data Model               November 2005


   that is unique in the context of the CSIRT and identifies the
   activity characterized in an IODEF-Document.




Danyliw, et al.         Expires February 3, 2006               [Page 16]

Internet-Draft              IODEF Data Model                 August 2005

   +------------------+
   | IncidentID       |
   +------------------+
   | UID              |
   |                  |
   | GUID   name      |
   +------------------+

                      Figure 3: the IncidentID class

   The IncidentID class has one attribute:

   name
      Required.  GUID.  An identifier for the CSIRT that created the
      IODEF-Document.  In order to have a globally unique CSIRT name,
      the domain name (DNS) of the CSIRT MUST be used.


3.4  AlternativeID class

   The AlternativeID class lists the incident tracking numbers used by
   other CSIRTs to refer to activity described in this IODEF document.
   Thus, a tracking number listed as an AlternativeID references the
   same incident detected by another CSIRT.  The incident tracking
   numbers of the CSIRT that generated the IODEF document should never
   be considered an AlternativeID.


         +------------------+
         | AlternativeID    |
         +------------------+
         | ENUM restriction |<>--{1..*}--[ IncidentID ]
         |                  |
         +------------------+


                     Figure 4: the AlternativeID class

   The aggregate class that constitutes AlternativeID is:

   IncidentID
      One or more.  The incident tracking number of another CSIRT.

   The AlternativeID class has one attribute:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.




Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 17] 18]

Internet-Draft              IODEF Data Model                 August               November 2005


   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.


3.5  RelatedActivity class

   The RelatedActivity class lists the incident tracking numbers of
   incidents that are related to the one described in the IODEF
   document.  These references may be to local incident tracking
   numbers, as well as, to those of other CSIRTs.

   The specifics of how a CSIRT came to believe that two incidents are
   related is considered out of scope.


         +------------------+
         | RelatedActivity  |
         +------------------+
         | ENUM restriction |<>--{1..*}--[ IncidentID ]
         |                  |
         +------------------+

                      Figure 5: RelatedActivity class

   The aggregate class that constitutes RelatedActivity is:

   IncidentID
      One or more.  The incident tracking number of a related incident.

   The RelatedActivity class has one attribute:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.


3.6  AdditionalData

   The AdditionalData class serves as an extension mechanism for
   information not otherwise represented in the data model.  For
   relatively simple information, atomic data types (e.g., integers,
   strings) are provided with a mechanism to annotate their meaning.
   The class can also be used to extend the data model (and the
   associated Schema) to support proprietary extensions by encapsulating
   entire XML documents conforming to another Schema (e.g., IDMEF).  A
   detailed discussion for extending the data model and the Schema can
   be found in Section 4.

   Unlike XML, which is self-describing, atomic data must be documented



Danyliw, et al.           Expires May 13, 2006                 [Page 19]

Internet-Draft              IODEF Data Model               November 2005


   to convey its meaning.  This information is described in the
   'meaning' attribute.  Since these description are outside the scope



Danyliw, et al.         Expires February 3, 2006               [Page 18]

Internet-Draft              IODEF Data Model                 August 2005
   of the specification, some additional coordination may be required to
   ensure that a recipient of a document using the AdditionalData
   classes can make sense of the custom extensions.


   +------------------+
   | AdditionalData   |
   +------------------+
   | ANY              |
   |                  |
   | ENUM restriction |
   | ENUM type        |
   | STRING meaning   |
   | STRING formatid  |


   | ENUM restriction |
   +------------------+

                    Figure 6: the AdditionalData class

   The AdditionalData class has three attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.

   type
      Required.  ENUM.  The data type of the element content.  The
      permitted values for this attribute are shown below.  The default
      value is "string".

      1.   boolean.  The element contains a boolean value, i.e., the
           strings "true" or "false"

      2.   byte.  The element content is a single 8-bit byte (see
           Section 2.2.5);

      3.   character.  The element content is a single character (see
           Section 2.2.3);

      4.   date-time.  The element content is a date-time string (see
           Section 2.2.8);

      5.   integer.  The element content is an integer (see
           Section 2.2.1);

      6.   portlist.  The element content is a port list (see
           Section 2.2.9);





Danyliw, et al.           Expires May 13, 2006                 [Page 20]

Internet-Draft              IODEF Data Model               November 2005


      7.   real.  The element content is a real number (see
           Section 2.2.2);




Danyliw, et al.         Expires February 3, 2006               [Page 19]

Internet-Draft              IODEF Data Model                 August 2005

      8.   string.  The element content is a string (see Section 2.2.3);

      9.   file.  The element content is a base64 encoded binary file;

      10.  frame.  The element content is a hexbin-encoded layer-2 frame
           (see Section 2.2.6)

      11.  packet.  The element content is a hexbin-encoded layer-3
           packet (see Section 2.2.6)

      12.  ipv4-packet.  The element content is an IPv4 hexbin-encoded
           packet (see Section 2.2.6)

      13.  ipv6-packet.  The element content is an IPv6 hexbin-encoded
           packet (see Section 2.2.6)

      14.  path.  The element content is a filesystem path;

      15.  url.  The element content is a URL (see Section 2.2.14;)

      16.  xml.  The element content is XML-tagged data (see Section 4).

   meaning
      Optional.  STRING.  A free-form description of the semantics of
      the custom data in this class.

   formatid
      Optional.  STRING.  An identifier referencing the format and
      semantics of the encapsulated data.

   restriction
      Optional.  ENUM.  This attribute has been defined in 	Section 3.2.


3.7  Contact class

   The Contact class describes contact information for organizations and
   personnel involved in the incident.  This class allows for the naming
   of the involved party, specifying contact information for them, and
   identifying their role in the incident.

   People and organizations are treated interchangeably as contacts; one
   can be associated with the other using the recursive definition of
   the class (the Contact class is aggregated into the Contact class).
   The 'type' attribute disambiguates the type of contact information



Danyliw, et al.           Expires May 13, 2006                 [Page 21]

Internet-Draft              IODEF Data Model               November 2005


   being provided.

   This recursive definition provides a way to relate information
   without requiring the explicit use of identifiers in the classes.
   For example, separate contact information for two individuals from
   the same organization would not require duplicating the organization
   information.


   +------------------+
   | Contact          |


   +------------------+
   | ENUM restriction role        |<>--{0..1}--[ name ContactName    ]
   | ENUM role type        |<>--{0..*}--[ Description    ]
   | ENUM type restriction |<>--{0..*}--[ RegistryHandle ]
   |                  |<>--{0..1}--[ PostalAddress  ]
   |                  |<>--{0..*}--[ Email          ]
   |                  |<>--{0..*}--[ Telephone      ]
   |                  |<>--{0..1}--[ Fax            ]
   |                  |<>--{0..1}--[ Timezone       ]
   |                  |<>--{0..*}--[ Contact        ]
   +------------------+



                        Figure 7: the Contact class

   The aggregate classes that constitute the Contact class are:





Danyliw, et al.         Expires February 3, 2006               [Page 20]

Internet-Draft              IODEF Data Model                 August 2005


   name

   ContactName
      Zero or one.  NAME.  ML_STRING.  The name of the contact.  The contact
      may either be an organization or a person.  The type attribute
      disambiguates the semantics.

   Description
      Zero or one.  ML_STRING.  A free-form description of this contact.
      In the case of a person, this is often the organizational title of
      the individual.

   RegistryHandle
      Zero or many.  A handle name in 	a registry.

   PostalAddress
      Zero or one.  POSTAL.  The postal 	address of the contact
      formatted according to Section 2.2.10.

   Email
      Zero or many.  EMAIL.  The email address




Danyliw, et al.           Expires May 13, 2006                 [Page 22]

Internet-Draft              IODEF Data Model               November 2005


   Email
      Zero or many.  EMAIL.  The email address of the contact formatted
      according to Section 2.2.13.

   Telephone
      Zero or many.  PHONE.  The telephone number 	of the contact
      formatted according to Section 2.2.12.

   Fax
      Zero or one.  PHONE.  The facsimile telephone number of the
      contact formatted according to Section 2.2.12.

   Timezone
      Zero or one.  TIMEZONE.  The timezone in which the contact resides
      formatted according to Section 2.2.15.

   Contact
      Zero or many.  Recursive definition of Contact allowing for the
      grouping of information.

   The Contact class has three attributes:

   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.

   role
      Required.  ENUM.  Indicates the role the contact fulfills.  This
      attribute is defined as an enumerated list:

      1.  creator.  The entity that generate the IODEF document.




Danyliw, et al.         Expires February 3, 2006               [Page 21]

Internet-Draft              IODEF Data Model                 August 2005

      2.  admin.  An administrative contact for a host or network.

      3.  tech.  A technical contact for a host or network.

      4.  irt.  The CSIRT involved in handling the incident.

      5.  cc.  An entity that is to be kept informed about the handling
          of the incident.

   type
      Required.  ENUM.  Indicates the type of contact being described.
      This attribute is defined as an enumerated list:

      1.  person.

      2.  organization.







Danyliw, et al.           Expires May 13, 2006                 [Page 23]

Internet-Draft              IODEF Data Model               November 2005


   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.


3.7.1  RegistryHandle class

   The RegistryHandle class represents a handle to an Internet registry
   or community-specific database.  A handle consists of a name
   specified in the element content, and the database to which it
   belongs specified in the type attribute.


   +------------------+
   | RegistryHandle   |
   +------------------+
   | STRING           |
   |                  |
   | ENUM type        |
   +------------------+

                    Figure 8: The RegistryHandle class

   The RegistryHandle class has one attribute:

   type
      Required.  ENUM.  The database to which the handle belongs.  The
      default value is 'local'.  The possible values are:

      1.  internic.  Internet Network Information Center

      2.  apnic.  Asia Pacific Network Information Center




Danyliw, et al.         Expires February 3, 2006               [Page 22]

Internet-Draft              IODEF Data Model                 August 2005

      3.  arin.  American Registry for Internet Numbers

      4.  lacnic.  Regional Latin-American and Caribbean IP Address
          Registry

      5.  ripe.  Reseaux IP Europeens

      6.  afrinic.  African Internet Numbers Registry

      7.  local.  A database local to the CSIRT.


3.8  Time classes

   The data model uses five different classes to represent a timestamp.
   Their definition is identical, but each has a distinct name to convey



Danyliw, et al.           Expires May 13, 2006                 [Page 24]

Internet-Draft              IODEF Data Model               November 2005


   a difference in semantics.

   The element content of each class is a timestamp formated according
   to the DATETIME data type (see Section 2.2.8).


   +----------------------------------+
   | {Start| End| Report| Detect}Time |
   +----------------------------------+
   | DATETIME                         |
   +----------------------------------+

                        Figure 9: the Time classes


3.8.1  StartTime

   The StartTime class represents the time the incident began.

3.8.2  EndTime

   The EndTime class represents the time the incident ended.

3.8.3  DetectTime

   The DetectTime class represents the time the first activity of the
   incident was detected.

3.8.4  ReportTime

   The ReportTime class represents the time the incident was reported.
   This timestamp SHOULD coincide to the time at which the IODEF
   document is generated.




Danyliw, et al.         Expires February 3, 2006               [Page 23]

Internet-Draft              IODEF Data Model                 August 2005

3.8.5  DateTime

   The DateTime class is a generic representation of a timestamp.  Its
   semantics should be inferred from the parent class into which it is
   aggregated.

3.9  Expectation  Method class

   The Expectation Method class conveys describes the methodology used by the intruder to
   perpetrate the recipient events of the IODEF document incident.  This class can reference
   well-known vulnerability or exploit databases; the actions intruder tools
   used in the sender is requesting. attack; and provide a free-form description of the
   activity.




Danyliw, et al.           Expires May 13, 2006                 [Page 25]

Internet-Draft              IODEF Data Model               November 2005


   +------------------+
   | Expectation Method           |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ Description ]
   | ENUM priority    |<>--{0..1}--[ StartTime   ]
   | ENUM category    |<>--{0..1}--[ EndTime |<>--{0..*}--[ Classification ]
   |                  |<>--{0..1}--[ Contact                  |<>--{0..*}--[ Description    ]
   +------------------+

                        Figure 10: the Expectation The Method class

   The Method class is composed of two aggregate classes that constitute Expectation are: classes.

   Classification
      Zero or many.  A reference to a well-known vulnerability or
      exploit databases.

   Description
      One
      Zero or many.  ML_STRING.  A free-form text 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
      methodology used by the
      Incident intruder.

   The Method class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is defined in 	Section 3.2.


3.9.1  Classification class denotes that the expectation should be fulfilled as
      soon as possible.

   The absence Classification class is a reference to an external database of this element leaves the
      execution
   computer vulnerabilities, exposures, or viruses.  A reference
   consists of the expectation to the discretion of database name, the recipient.

   EndTime
      Zero or one.  The time by which entry name in the action should be completed.
      If database, and
   the action is not carried out by URI to this time, it should no longer
      be performed.

   Contact
      Zero or one.  The expected actor for the action. entry.

   +------------------+
   | Classification   |
   +------------------+
   | ENUM origin      |<>----------[ name ]
   |                  |<>--{0..*}--[ url  ]
   +------------------+

                    Figure 11: The Expectations Classification class has three attributes:

   The aggregate classes that constitute Classification:

   name
      One. STRING.  The key into the database specified in the origin
      attribute.





Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 24] 26]

Internet-Draft              IODEF Data Model                 August               November 2005


   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.

   priority
      Optional.  ENUM.  Indicates


   url
      Zero or many.  URI.  A URL to additional information about the desired priority
      vulnerability or exposure referenced by the name.

   The Classification class has one attribute:

   origin
      Required.  ENUM.  The name of the action.
      This attribute database to which the reference
      is an enumerated list with no default value. being made.  The permitted values are shown below.

      1.  low.  Low priority  bugtraqid.  Bugtraq

      2.  medium.  Medium priority  cve.  Mitre Common Vulnerabilities or Exposures

      3.  high.  High priority

   category
      Optional.  ENUM.  Classifies  certcc.  CERT Coordination Center Vulnerability Catalog

      4.  vendor.  A product vendor whose name should be specified in
          the type of action requested.  This
      attribute is an enumerated list with no default value.

      1.  nothing.  No action name class

      5.  local.  A local database.

      6.  other.  A custom database whose URL is requested.  Do nothing with the
          information.

      2.  contact-site.  Contact the listed site specified in the recipient's
          constituency.

      3.  contact-me.  Contact url
          class, and the originator name of the document.

      4.  investigate.  Investigate the machine(s) listed in the
          document.

      5.  block.  Block traffic from the machine(s) listed in the
          document.

      6.  other.  Perform some custom action described entry is specified in the
          Description name
          class.


3.10  Method  Assessment class

   The Method Assessment class describes the methodology used by technical and non-technical
   repercussions of the intruder to
   perpetrate incident on the events CSIRT's constituency.

   Note: The IODEF definition of the incident.  This Assessment class can reference
   well-known vulnerability or exploit databases; the intruder tools
   used in reuses the attack; and provide a free-form description IDMEF
   definition (see Section 4.2.4.5 of the
   activity.









Danyliw, et al.         Expires February 3, 2006               [Page 25]

Internet-Draft              IODEF Data Model                 August 2005 [7]), but also extends it.


         +------------------+
         | Method Assessment       |
         +------------------+
         | ENUM restriction |<>--{0..*}--[ Classification Impact         ]
         |                  |                  |<>--{0..*}--[ TimeImpact     ]
         |                  |<>--{0..*}--[ Description MonetaryImpact ]
         |                  |<>--{0..1}--[ Confidence     ]
         +------------------+

                        Figure 11: The Method 12: Assessment class

   The Method class is composed of two aggregate classes.

   Classification classes that constitute Assessment are:




Danyliw, et al.           Expires May 13, 2006                 [Page 27]

Internet-Draft              IODEF Data Model               November 2005


   Impact
      Zero or many.  A reference to  Technical impact of the incident on a well-known vulnerability network.

   TimeImpact
      Zero or
      exploit databases.

   Description many.  Impact of the activity measured with respect to
      time.

   MonetaryImpact
      Zero or many.  ML_STRING.  A free-form text description  Impact of the
      methodology used by activity measured with respect to
      financial loss.

   Confidence
      Zero or one.  An estimate of confidence in the intruder. assessment.

   The Method Assessment class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.


3.10.1  Classification  Impact class

   The Classification Impact class is a reference to an external database allows for categorizing and describing the technical
   impact of
   computer vulnerabilities, exposures, or viruses.  A reference
   consists the incident on the network of an organization.

   Note: The IODEF definition of the database name, Impact class reuses the entry name in IDMEF
   definition (see Section 4.2.6.1 of [7]).

3.10.2  TimeImpact class

   The TimeImpact class describes the database, and impact of the URI incident on an
   organization as a function of time.  It provides a way to this entry. convey down
   time and recovery time.


         +------------------+
         | Classification TimeImpact       |
         +------------------+
         | REAL             |
         |                  |
         | ENUM restriction |<>----------[ name ] severity    |
         | ENUM origin      |<>--{0..1}--[ url  ] metric      |
         | ENUM units       |
         +------------------+

                        Figure 12: The Classification 13: TimeImpact class

   The aggregate classes that constitute Classification:

   name
      One. STRING.  The key into the database specified in the origin
      attribute. element content will be a numeric value (REAL) specifying a unit



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 26] 28]

Internet-Draft              IODEF Data Model                 August               November 2005


   url
      Zero or One. URI.  A URL to additional information about


   of time.  The unit and metric attributes will imply the
      vulnerability or exposure referenced by semantics of
   the name. element content.

   The Classification TimeImpact class has two attribute:

   restriction three attributes:

   severity
      Optional.  ENUM.  This attribute  An estimate of the relative severity of the
      activity.  The permitted values are shown below.  There is defined in Section 3.2.

   origin no
      default value.

      1.  low.  Low severity

      2.  medium.  Medium severity

      3.  high.  High severity

   metric
      Required.  ENUM.  The name of  Defines the database to metric in which the reference time is being made.
      expressed.  The permitted values are shown below.  There is no
      default value.

      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  labor.  Total staff-time to recovery from the name class

      5.  local.  A local database.

      6.  other.  A custom database whose URL is specified in activity (e.g.,
          2 employees working 4 hours each would be 8 hours)

      2.  elapsed.  Elapsed time from the url
          class, and beginning of the name recovery to
          its completion.

      3.  downtime.  Duration of time for which some provided service(s)
          was not available.

   units
      Required.  ENUM.  Defines the entry is specified units in which the name
          class.


3.11  Assessment element content
      is expressed.  The permitted values are shown below.  The default
      value is "hours".

      1.  seconds.  Seconds.

      2.  minutes.  Minutes.

      3.  hours.  Hours.

      4.  days.  Days.


3.10.3  MonetaryImpact class

   The Assessment MonetaryImpact class describes the technical and non-technical
   repercussions financial impact of the incident
   activity on the CSIRT's constituency.

   Note: The IODEF definition of the Assessment class reuses the IDMEF
   definition (see Section 4.2.4.5 of [7]), but also extends it.


         +------------------+
         | Assessment       |
         +------------------+
         | ENUM restriction |<>--{0..*}--[ Impact         ]
         |                  |<>--{0..*}--[ TimeImpact     ]
         |                  |<>--{0..*}--[ MonetaryImpact ]
         |                  |<>--{0..1}--[ Confidence     ]
         +------------------+

                        Figure 13: Assessment class an organization.  For example, this impact may consider



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 27] 29]

Internet-Draft              IODEF Data Model                 August               November 2005


   The aggregate classes that constitute Assessment are:

   Impact
      Zero or many.  Technical impact of


   losses due to the incident on a network.

   TimeImpact
      Zero or many.  Impact cost of the activity measured with respect to
      time.

   MonetaryImpact
      Zero investigation or many.  Impact recovery, diminished
   productivity of the activity measured with respect to
      financial loss.

   Confidence
      Zero staff, or one.  An estimate of confidence in the assessment.

   The Assessment class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.


3.11.1  Impact class

   The Impact class allows for categorizing and describing the technical
   impact of the incident on the network of an organization.

   Note: The IODEF definition of the Impact class reuses the IDMEF
   definition (see Section 4.2.6.1 of [7]).

3.11.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. tarnished reputation that will affect
   future opportunities.


         +------------------+
         | TimeImpact MonetaryImpact   |
         +------------------+
         | REAL             |
         |                  |
         | ENUM severity    |
         | ENUM metric      |
         | ENUM units STRING currency  |
         +------------------+

                      Figure 14: TimeImpact MonetaryImpact class



Danyliw, et al.         Expires February 3, 2006               [Page 28]

Internet-Draft              IODEF Data Model                 August 2005

   The element content will be a numeric value (REAL) specifying a unit
   of time.  The unit and metric attributes will imply the semantics of currency described in the element content. currency attribute.

   The TimeImpact MonetaryImpact class has three two attributes:

   severity
      Optional.  ENUM.  An estimate of the relative severity of the
      activity.  The permitted values are shown below.  There is no
      default value.

      1.  low.  Low severity

      2.  medium.  Medium severity

      3.  high.  High severity

   metric

   currency
      Required.  ENUM.  Defines the metric currency in which the time monetary
      impact is expressed.  The permitted values are shown below. defined in ISO
      4217:2001, Codes for the representation  of currencies and funds
      [16].  There is no default value.

      1.  labor.  Total staff-time to recovery from


3.10.4  Confidence class

   The Confidence class represents a best estimate of the activity (e.g.,
          2 employees working 4 hours each would be 8 hours)

      2.  elapsed.  Elapsed time from validity and
   accuracy of the beginning described impact (see Section 3.10) of the recovery to
          its completion.

      3.  downtime.  Duration incident
   activity.  This estimate can be expressed as a category, or a numeric
   calculation.

   Note: The IODEF definition of time for which some provided service(s)
          was not available.

   units
      Required.  ENUM.  Defines the units in which Confidence class reuses the element content
      is expressed.  The permitted values are shown below.  The default
      value is "hours".

      1.  seconds.  Seconds.

      2.  minutes.  Minutes.

      3.  hours.  Hours.

      4.  days.  Days.


3.11.3  MonetaryImpact class

   The MonetaryImpact class describes the financial impact of the



Danyliw, et al.         Expires February 3, 2006               [Page 29]

Internet-Draft              IODEF Data Model                 August 2005


   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.


         +------------------+
         | MonetaryImpact   |
         +------------------+
         | REAL             |
         |                  |
         | ENUM severity    |
         | STRING currency  |
         +------------------+

                      Figure 15: MonetaryImpact class

   The element content will be a numeric value (REAL) specifying a unit
   of currency described in the currency attribute.

   The MonetaryImpact class has two attributes:

   severity
      Optional.  ENUM.  An estimate of the relative severity of the
      activity.  The permitted values are shown below.  There is no
      default value.

      1.  low.  Low severity

      2.  medium.  Medium severity

      3.  high.  High severity

   currency
      Required.  ENUM.  Defines the currency in which the monetary
      impact is expressed.  The permitted values are defined in ISO
      4217:2001, Codes for the representation  of currencies and funds
      [16].  There is no default value.


3.11.4  Confidence class

   The Confidence class represents a best estimate of the validity and
   accuracy of the described impact IDMEF
   definition (see Section 3.11) of the incident
   activity.  This estimate can be expressed as a category, or a numeric
   calculation.

   Note: The IODEF definition 4.2.6.3 of the Confidence class reuses the IDMEF [7]).



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 30]

Internet-Draft              IODEF Data Model                 August               November 2005


   definition (see Section 4.2.6.3 of [7]).

3.12


3.11  History class

   The History class is a log of the significant events or actions
   performed by the involved parties during the course of handling the
   incident.

   The level of detail maintained in this log is left up to the
   discretion of those handling the incident.


   +------------------+
   | History          |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ HistoryItem ]
   |                  |
   +------------------+

                       Figure 16: 15: The History class

   The class that constitutes History is:

   HistoryItem
      One or many.  Entry in the history log of significant events or
      actions performed by the involved parties.

   The History class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.


3.12.1


3.11.1  HistoryItem class

   The HistoryItem class is an entry in the History (Section 3.12) 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 February 3, 2006               [Page 31]

Internet-Draft              IODEF Data Model                 August 2005


   +------------------+
   | HistoryItem      |
   +------------------+
   | ENUM restriction |<>--{0..1}--[ IncidentID |<>----------[ DateTime    ]
   | ENUM type        |<>----------[ DateTime        |<>--{0..1}--[ IncidentId  ]
   |                  |<>--{1..*}--[ Description ]
   +------------------+




Danyliw, et al.           Expires May 13, 2006                 [Page 31]

Internet-Draft              IODEF Data Model               November 2005


                       Figure 17: 16: HistoryItem class

   The aggregate classes that constitute HistoryItem are:

   DateTime
      One. Timestamp of the this entry in the history log (e.g., when
      the action described in the Description was taken).

   IncidentID
      Zero or One. In a history log created by multiple parties, the
      IncidentID provides a mechanism to specify which CSIRT created a
      particular entry and references this organization's incident
      tracking number.  When a single organization is maintaining the
      log, this class can be ignored.

   DateTime
      One. Timestamp of the this entry in the history log (e.g., when
      the action described in the Description was taken).

   Description
      One or many.  STRING.  A free-form textual description of the
      action or event.

   The HistoryItem class has two attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.

   type
      Optional.  ENUM.  Classifies the type of activity or event
      documented in this history log entry.  The possible values are an
      enumerated list whose default value is "other":

      1.  triaged.  The incident data was received and processed by an
          IHS.

      2.  notification.  Notification to an involved party in the
          incident was sent (e.g., a CSIRT sending a message to the
          attacking site).

      3.  shared-info.  Information about this incident was shared with
          party not directly involved.





Danyliw, et al.         Expires February 3, 2006               [Page 32]

Internet-Draft              IODEF Data Model                 August 2005

      4.  received-info.  Additional information about the incident was
          received.

      5.  remediation.  The incident has been resolved; a short
          description may be included.

      6.  other.  A custom entry.


3.13





Danyliw, et al.           Expires May 13, 2006                 [Page 32]

Internet-Draft              IODEF Data Model               November 2005


3.12  EventData class

   The EventData class describes the events of the incident surrounding
   a particular set of hosts or networks.  This description includes the
   systems from which the activity originated and those targeted, an
   assessment of the techniques used by the intruder, the impact of the
   activity on the organization, and any forensic evidence discovered.


   +------------------+
   | EventData        |
   +------------------+
   | ENUM restriction |<>--{0..*}--[ Description    ]
   |                  |<>--{0..1}--[ DetectTime     ]
   |                  |<>--{0..1}--[ StartTime      ]
   |                  |<>--{0..1}--[ EndTime        ]
   |                  |<>--{0..*}--[ Contact        ]
   |                  |<>--{0..1}--[ Assessment     ]
   |                  |<>--{0..*}--[ Method         ]
   |                  |<>--{0..*}--[ Flow           ]
   |                  |<>--{0..*}--[ Expectation    ]
   |                  |<>--{0..1}--[ Record         ]
   |                  |<>--{0..*}--[ EventData      ]
   |                  |<>--{0..*}--[ AdditionalData ]
   +------------------+

                      Figure 18: 17: The EventData class

   The aggregate classes that constitute EventData are:

   Description
      Zero or more.  ML_STRING.  A free-form textual description of the
      event.

   DetectTime
      Zero or one.  The time the event was detected.







Danyliw, et al.         Expires February 3, 2006               [Page 33]

Internet-Draft              IODEF Data Model                 August 2005

   StartTime
      Zero or one.  The time the event started.

   EndTime
      Zero or one.  The time the event ended.

   Contact
      Zero or more.  The different parties involved in the incident






Danyliw, et al.           Expires May 13, 2006                 [Page 33]

Internet-Draft              IODEF Data Model               November 2005


   Assessment
      Zero or one.  The impact of the incident on the target and the
      actions taken.

   Method
      Zero or more.  The methodology used by the intruders.

   Flow
      Zero or more.  A description of the systems or networks involved.

   Expectation
      Zero or more.  Expected action to be performed by the recipient of
      the document.

   Record
      Zero or one.  Support  Supportive data (e.g., log files) that provides
      additional information about the event.

   EventData
      Zero or more.  Recursive definition of EventData allowing for the
      grouping of data

   AdditionalData
      Zero or one.  An extension mechanism for data not explicitly
      represented in the data model.

   The EventData class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is defined in Section 3.2.


3.13.1


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



Danyliw, et al.         Expires February 3, 2006               [Page 34]

Internet-Draft              IODEF Data Model                 August 2005
   class when there is a substantial composition of various events in
   the an incident.

3.13.2






Danyliw, et al.           Expires May 13, 2006                 [Page 34]

Internet-Draft              IODEF Data Model               November 2005


3.12.2  Cardinality of EventData

   The EventData class can be thought of as a container for the
   properties of an event in an incident.  These properties include: the
   hosts involved, impact of the incident activity on the hosts,
   forensic logs, etc.  With an instance of the EventData class, hosts
   hosts 	(i.e., System class) are grouped around these common
   properties.

   The recursive definition of the EventData class (the EventData class
   is aggregated into the EventData class) provides a way to related
   information without requiring the explicit use of unique attribute
   identifiers in the classes or duplicating information.  Instead, the
   relative depth (nesting) of a class is used to group (relate)
   information.

   Nested EventData classes imply that while the child classes share the
   properties of the parent, there is some properties for which they do
   not agree.  Therefore, in order express these distinct properties,
   the nesting approach was used.  In such a scheme, a parent EventData
   class MUST always have more than one EventData child.

   For example, an EventData class might be used to describe two
   machines involved in an incident.  This description can be achieved
   using multiple instances of the System 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 19. 18.


   +------------------+
   | EventData        |
   +------------------+
   |                  |<>----[ Contact    ]
   |                  |
   |                  |<>----[ EventData  ]<>----[ System Flow     ]
   |                  |      [            ]<>----[ Assessment ]
   |                  |
   |                  |<>----[ EventData  ]<>----[ System Flow     ]
   |                  |      [            ]<>----[ Assessment ]
   +------------------+

                Figure 19: 18: Recursion in the EventData class







Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 35]

Internet-Draft              IODEF Data Model                 August               November 2005


3.14  Flow


3.13  Expectation class

   The Flow Expectation class groups conveys to the source and target hosts or networks in an
   event. recipient of the IODEF document
   the actions the sender is requesting.

   +------------------+
   | Flow Expectation      |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ System Description ]
   | ENUM severity    |<>--{0..1}--[ StartTime   ]
   | ENUM category    |<>--{0..1}--[ EndTime     ]
   |                  |<>--{0..1}--[ Contact     ]
   +------------------+

                     Figure 20: 19: the Flow Expectation class

   The aggregate class classes that constitutes Flow is:

   System constitute Expectation are:

   Description
      One or More. many.  ML_STRING.  A host or network involved in free-form description of the incident activity.

   The Flow System class has no attributes.

3.15  System class

   The System class represents a computer desired
      action(s).

   StartTime
      Zero or network involved in the
   incident. one.  The systems represented by this class are categorized according to time at which the role they played action should be performed.  A
      timestamp that is earlier than the ReportTime specified in the incident through
      Incident class denotes that the category attribute. expectation should be fulfilled as
      soon as possible.  The value absence of this category attribute dictates element leaves the semantics
      execution of the
   aggregated classes in the System class.  If expectation to the category attribute
   has a value discretion of 'source', then the aggregated classes denote the
   machine and service from recipient.

   EndTime
      Zero or one.  The time by which the activity action should be completed.
      If the action is originating.  With a
   category attribute value of 'target' not carried out by this time, it should no longer
      be performed.

   Contact
      Zero or 'intermediary', then one.  The expected actor for the
   machine or service action.

   The Expectations class has three attributes:

   restriction
      Optional.  ENUM.  This attribute is the one targeted defined in Section 3.2.

   severity
      Optional.  ENUM.  Indicates the activity.


   +------------------+
   | System           |
   +------------------+
   | ENUM restriction |<>----------[ Node            ]
   | ENUM category    |<>--{0..*}--[ Service         ]
   | STRING interface |<>--{0..*}--[ OperatingSystem ]
   | ENUM spoofed     |<>--{0..*}--[ Counter         ]
   +------------------+

                        Figure 21: desired priority of the System class

   The aggregate classes that constitute System are:



Danyliw, et al.         Expires February 3, 2006               [Page 36]

Internet-Draft              IODEF Data Model                 August 2005


   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.

   The System class has four attribute:

   restriction
      Optional.  ENUM. action.
      This attribute is defined in Section 3.2. an enumerated list with no default value.

      1.  low.  Low priority




Danyliw, et al.           Expires May 13, 2006                 [Page 36]

Internet-Draft              IODEF Data Model               November 2005


      2.  medium.  Medium priority

      3.  high.  High priority

   category
      Required.
      Optional.  ENUM.  Classifies the role type of action requested.  This
      attribute is an enumerated list with no default value.

      1.   nothing.  No action is requested.  Do nothing with the host or network played
           information.

      2.   contact-site.  Contact the listed site in the incident.  The possible values are:

      1.  source.  The System was recipient's
           constituency.

      3.   contact-me.  Contact the source originator of the attack.

      2.  target.  The System was the target of document.

      4.   investigate.  Investigate the attack.

      3.  intermediate.  The System was an intermediary machine(s) listed in the attack.

   interface
      Optional.  STRING.  Specifies
           document.

      5.   block-host.  Block traffic from the interface on which machine(s) listed as
           sources in the event(s)
      on this System originated.  If document.

      6.   block-network.  Block traffic from the Node class specifies a network
      rather than a host, this attribute has no meaning.

   spoofed
      Optional.  ENUM.  An indication of confidence network(s) lists as
           sources 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 document.

      7.   block-port.  Block the category attribute value is
          unknown

      2.  yes.  The category attribute value is probably incorrect.  In port listed as sources in the case of a source,
           document.

      8.   rate-limit-host.  Rate-limit the System is likely a decoy; with a
          target, traffic from the System was likely not machine(s)
           listed as sources in the intended victim.

      3.  no. document.

      9.   rate-limit-network.  Rate-limit the traffic from the
           network(s) lists as sources in the document.

      10.  rate-limit-port.  Rate-limit the port(s) listed as sources in
           the document.

      11.  other.  Perform some custom action described in the
           Description class.


3.14  Flow class

   The category attribute value is believed to be correct. Flow class groups the source and target hosts or networks
   (represented by System) in an event.






Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 37]

Internet-Draft              IODEF Data Model                 August               November 2005


3.16  Node class

   The Node class identifies a host, network device, or network.

   The base definition of the class is reused from the IDMEF
   specification, see Section 4.2.7.1 of [7].  However, the class has
   been extended by adding the NodeRole and DateTime classes.


   +---------------+
   |     Node      |
   +---------------+
   |               |<>--{0..1}--[ Location ]
   |               |<>--{0..1}--[ name     ]
   |               |<>--{0..*}--[ Address  ]


   +------------------+
   |               |<>--{0..1}--[ DateTime ] Flow             |               |<>--{0..*}--[ NodeRole ]
   +------------------+
   |               |<>--{0..*}--[ Counter                  |<>--{1..*}--[ System   ]
   +---------------+
   +------------------+

                         Figure 22: The Node 20: the Flow class

   The aggregate classes class that constitute Node are:

   Location
      Zero constitutes Flow is:

   System
      One or one.  STRING. More.  A free-from description of the physical
      location of the equipment.

   name
      Zero host or one.  STRING.  The name of network involved in the equipment (e.g., fully
      qualified domain name).  This information MUST be provided if incident activity.

   The Flow System class has no
      Address information is given.

   Address
      Zero or more. attributes.

3.15  System class

   The hardware, network, System class represents a computer or application address network involved in the
   incident.

   The systems represented by this class are categorized according to
   the role they played in the incident through the category attribute.
   The value of this category attribute dictates the semantics of the Node.  Unless
   aggregated classes in the System class.  If the category attribute
   has a name is provided, at least one address must be
      specified.

   DateTime
      Zero or one.  A timestamp value of when 'source', then the resolution between aggregated classes denote the name
      and address was performed.  This information SHOULD be provided if
      both an Address
   machine and name are given.

   NodeRole
      Zero service from which the activity is originating.  With a
   category attribute value of 'target' or more. 'intermediary', then the
   machine or service is the one targeted in the activity.


   +------------------+
   | System           |
   +------------------+
   | ENUM restriction |<>----------[ Node            ]
   | ENUM category    |<>--{0..*}--[ Service         ]
   | STRING interface |<>--{0..*}--[ OperatingSystem ]
   | ENUM spoofed     |<>--{0..*}--[ Counter         ]
   +------------------+

                        Figure 21: the System class

   The intended purpose of aggregate classes that constitute System are:

   Node
      One. A host or network involved in the equipment. incident.






Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 38]

Internet-Draft              IODEF Data Model                 August               November 2005


   Service
      Zero or more.  A network service running on the system.

   OperatingSystem
      Zero or one.  The operating system running on the system.

   Counter
      Zero or more.  A counter with which to summarizes summarize properties of
      this host or network.


3.16.1  Counter class

   The Counter System class summarize multiple occurrences of some event, or
   conveys counts on various features (e.g., packets, sessions, events).

   The value of the counter has four attribute:

   restriction
      Optional.  ENUM.  This attribute is the element content, with its units
   represented defined in Section 3.2.

   category
      Required.  ENUM.  Classifies the type attribute.  The complete semantics are
   entirely context dependant based on role the class host or network played
      in which the Counter is
   aggregated.


   +------------------+
   | Counter          |
   +------------------+
   | INTEGER          |
   |                  |
   | ENUM type        |
   | STRING meaning   |
   +------------------+

                       Figure 23: incident.  The possible values are:

      1.  source.  The System was the Counter class source of the attack.

      2.  target.  The Counter System was the target of the attack.

      3.  intermediate.  The System was an intermediary in the attack.

   interface
      Optional.  STRING.  Specifies the interface on which the event(s)
      on this System originated.  If the Node class specifies a network
      rather than a host, this attribute has two attribute:

   type no meaning.

   spoofed
      Optional.  ENUM.  Specifies the units  An indication of confidence in whether this
      System was the element contents. true target or attacking host.  The permitted
      values for this attribute are shown below.  The default value is
      "unknown".

      1.  packet.  Count  unknown.  The accuracy of packets. the category attribute value is
          unknown

      2.  session.  Count of sessions

      3.  event.  Count of events

      4.  other.  User defined count

   meaning
      Optional.  STRING.  Describes  yes.  The category attribute value is probably incorrect.  In
          the semantics case of a source, the element content
      if System is likely a decoy; with a
          target, the type System was likely not the intended victim.

      3.  no.  The category attribute value is set believed to other.


3.16.2  Address

   The Address class represents a hardware (layer-2), network (layer-3), be correct.







Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 39]

Internet-Draft              IODEF Data Model                 August               November 2005


3.16  Node class

   The Node class identifies a host, network device, or application (layer-7) address.

   This network.

   The base definition of the class was originally derived is reused from the IDMEF specification
   specification, see Section 4.2.7.1 of [7].


   +------------------+  However, the class has
   been extended by adding the NodeRole and DateTime classes.


   +---------------+
   |     Address     Node      |
   +------------------+
   +---------------+
   | ENUM category               |<>--{0..1}--[ name     ]
   |               |<>--{0..*}--[ Address  ]
   | STRING vlan-name               |<>--{0..1}--[ Location ]
   |               |<>--{0..1}--[ DateTime ]
   | INTEGER vlan-num               |<>--{0..*}--[ NodeRole ]
   |
   +------------------+               |<>--{0..*}--[ Counter  ]
   +---------------+

                         Figure 24: the Address class 22: The Address Node class has four attributes:

   category
      Required.  ENUM.  The type of address represented.  The permitted
      values for this attribute are shown below.

   The default value is
      "ipv4-addr".

      1.   asn.  Autonomous System Number

      2.   atm.  Asynchronous Transfer Mode (ATM) address

      3.   e-mail.  Electronic mail address (RFC 822)

      4.   ipv4-addr.  IPv4 host address in dotted-decimal notation
           (a.b.c.d)

      5.   ipv4-net.  IPv4 network address in dotted-decimal notation,
           slash, significant bits (a.b.c.d/nn)

      6.   ipv4-net-mask.  IPv4 network address in dotted-decimal
           notation, slash, network mask in dotted-decimal notation
           (a.b.c.d/w.x.y.z)

      7.   ipv6-addr.  IPv6 host address

      8.   ipv6-net.  IPv6 network address, slash, significant bits

      9.   ipv6-net-mask.  IPv6 network address, slash, network mask

      10.  mac.  Media Access Control (MAC) address






Danyliw, et al.         Expires February 3, 2006               [Page 40]

Internet-Draft              IODEF Data Model                 August 2005


   vlan-name
      Optional. aggregate classes that constitute Node are:

   name
      Zero or one.  STRING.  The name of the Virtual LAN to which equipment (e.g., fully
      qualified domain name).  This information MUST be provided if no
      Address information is given.

   Address
      Zero or more.  The hardware, network, or application address of
      the Node.  Unless a name is provided, at least one address belongs.

   vlan-num
      Optional. must be
      specified.

   Location
      Zero or one.  STRING.  The number  A free-from description of the Virtual LAN to which physical
      location of the
      address belongs.


3.16.3  NodeRole class

   The NodeRole class describes (based equipment.

   DateTime
      Zero or one.  A timestamp of when the resolution between the name
      and address was performed.  This information SHOULD be provided if
      both an Address and name are given.

   NodeRole
      Zero or more.  The intended purpose of the equipment.






Danyliw, et al.           Expires May 13, 2006                 [Page 40]

Internet-Draft              IODEF Data Model               November 2005


   Counter
      Zero or more.  A counter with which to summarizes properties of
      this host or network.


3.16.1  Counter class

   The Counter class summarize multiple occurrences of some event, or
   conveys counts on a pre-defined list) various features (e.g., packets, sessions, events).

   The value of the
   function performed by a particular host.


         +---------------+ counter is the element content, with its units
   represented in the type attribute.  The complete semantics are
   entirely context dependant based on the class in which the Counter is
   aggregated.


   +------------------+
   | NodeRole Counter          |
         +---------------+
   +------------------+
   | STRING INTEGER          |
   |                  |
   | ENUM category type        |
         +---------------+
   | STRING meaning   |
   +------------------+

                       Figure 25: The NodeRole 23: the Counter class

   The Counter class has two attribute:

   type
      Optional.  ENUM.  Specifies the units of the element contents.

      1.  packet.  Count of packets.

      2.  session.  Count of sessions

      3.  event.  Count of events

      4.  other.  User defined count

   meaning
      Optional.  STRING.  Describes the semantics of the element content should be empty in all cases other than when
      if the
   category type attribute is set to "other". other.


3.16.2  Address

   The NodeRole Address class has one attributes:

   category
      Required.  Functionality provided by a node.  If a value of
      "other" is specified, represents a description SHOULD be provided in the
      element content.  The default value is "other".

      1.   client.  Client computer

      2.   server-internal.  Server with internal services

      3.   server-public.  Server with public services

      4.   www.  WWW server

      5.   mail.  Mail server

      6.   messaging.  Messaging server (e.g.  NNTP, IRC, IM) hardware (layer-2), network (layer-3),



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 41]

Internet-Draft              IODEF Data Model                 August               November 2005


      7.   streaming.  Streaming-media server

      8.   voice.  Voice server (e.g.  SIP, H.323)

      9.   file.  File server (e.g.  SMB, CVS, AFS)

      10.  ftp.  FTP server

      11.  p2p.  Peer-to-peer node

      12.  name.  Name server (e.g.  DNS, WINS)

      13.  directory.  Directory server (e.g.  LDAP, finger, whois)

      14.  credential.  Credential server (e.g. domain controller,
           Kerberos)

      15.  print.  Print server

      16.  application.  Application server

      17.  database.  Database server

      18.  infra.  Infrastructure server (e.g. router, firewall, DHCP)

      19.  log.  Logserver

      20.  other. other role not in this list


3.17  Service class

   The Service class describes a network service of a host or network.
   The service is identified by specific port


   or list of ports, along
   with the application listening on that port.

   When Service occurs as an aggregate class of a System that is a
   source, then that the service is the one from which activity of
   interest is originating.  Conversely, when Service occurs as an
   aggregate class of a System that is a target, then that service is
   the one to which activity of interest is being directed. (layer-7) address.

   This class was originally derived from the IDMEF specification, see
   Section 4.2.7.4 of specification [7].







Danyliw, et al.         Expires February 3, 2006               [Page 42]

Internet-Draft              IODEF Data Model                 August 2005


   +--------------------+


   +------------------+
   |   Service     Address      |
   +--------------------+
   +------------------+
   | ENUM category    | STRING ip_version  |<>--{0..1}--[ port        ]
   | STRING ip_protocol |<>--{0..1}--[ portlist    ] vlan-name |                    |<>--{0..1}--[ Application ]
   +--------------------+
   | INTEGER vlan-num |
   +------------------+

                       Figure 26: 24: the Address class

   The Service class

   The aggregate classes that constitute Service are:

   port
      Zero or one.  INTEGER.  A port number.

   portlist
      Zero or one.  PORTLIST.  A list of port numbers formatted
      according to Section 2.2.9.

   Application
      Zero or more.  The application bound to the specified port or
      portlist.

   The Service class must specify either a port or portlist.

   The Service Address class has two four attributes:

   ip_version

   category
      Required.  INTEGER.  ENUM.  The IP version number.

   ip_protocol
      Required.  INTEGER. type of address represented.  The IANA protocol number.


3.17.1  Application class permitted
      values for this attribute are shown below.  The Application class describes an application running on a default value is
      "ipv4-addr".

      1.   asn.  Autonomous System
   providing a Service. Number

      2.   atm.  Asynchronous Transfer Mode (ATM) address

      3.   e-mail.  Electronic mail address (RFC 822)

      4.   ipv4-addr.  IPv4 host address in dotted-decimal notation
           (a.b.c.d)

      5.   ipv4-net.  IPv4 network address in dotted-decimal notation,
           slash, significant bits (a.b.c.d/nn)

      6.   ipv4-net-mask.  IPv4 network address in dotted-decimal
           notation, slash, network mask in dotted-decimal notation
           (a.b.c.d/w.x.y.z)

      7.   ipv6-addr.  IPv6 host address

      8.   ipv6-net.  IPv6 network address, slash, significant bits

      9.   ipv6-net-mask.  IPv6 network address, slash, network mask

      10.  mac.  Media Access Control (MAC) address






Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 43] 42]

Internet-Draft              IODEF Data Model                 August               November 2005


   +--------------------+
   |   Application      |
   +--------------------+
   | STRING appid       |<>--{0..1}--[ name         ]
   | STRING configid    |<>--{0..1}--[ url        ]
   | STRING vendor      |
   | STRING version     |
   +--------------------+

                     Figure 27: The Application class

   The aggregate classes that constitute Application are:

   name
      Zero or one.


   vlan-name
      Optional.  STRING.  The name of the application.

   url
      Zero or one.  URI.  A uri describing Virtual LAN to which the application.

   The Application class has four attributes:

   appid
      address belongs.

   vlan-num
      Optional.  STRING. .

   configid
      Optional.  STRING. .

   vendor
      Optional.  STRING. .

   version
      Optional.  STRING. .


3.18  OperatingSystem  The number of the Virtual LAN to which the
      address belongs.


3.16.3  NodeRole class

   The OperatingSystem NodeRole class describes the operating system running (based on a
   System.













Danyliw, et al.         Expires February 3, 2006               [Page 44]

Internet-Draft              IODEF Data Model                 August 2005


   +--------------------+ pre-defined list) the
   function performed by a particular host.


         +---------------+
         |  OperatingSystem NodeRole      |
   +--------------------+
         +---------------+
         | STRING        |
         |               |
         | STRING vendor      |
   | STRING version ENUM category |
         | STRING patch ENUM lang     |
   +--------------------+
         +---------------+

                       Figure 28: 25: The OperatingSystem NodeRole class

   The operating system name listed element content should be empty in all cases other than when the body of the element
   category attribute is
   further annotated by three attributes:

   vendor
      Optional.  STRING.  Name of the OS vendor.

   version
      Optional.  STRING.  Version number of the OS.

   patch
      Optional.  STRING.  Patch level of the OS.


3.19  Record class set to "other".

   The Record NodeRole class is has two attributes:

   category
      Required.  Functionality provided by 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 node.  If a value of monitoring tools (e.g., IDMEF
   messages generated by an IDS, connection logs from
      "other" is specified, a web server) that
   were used to uncover description SHOULD be provided in the malicious activity.  These logs should
   provide evidence as to why a CSIRT believes an incident has occurred.


   +------------------+
   | Record           |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ RecordData ]
   +------------------+

                          Figure 29: Record class
      element content.  The aggregate class that constitutes Record is:







Danyliw, et al.         Expires February 3, 2006               [Page 45]

Internet-Draft              IODEF Data Model                 August 2005


   RecordData
      One or more.  Log or audit data generated by a particular type of
      sensor.  Seperate instances of the RecordData class SHOULD be used
      for each sensor type.

   The Record class has one attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.


3.19.1  RecordData class

   The RecordData class groups log or audit data from a given sensor
   (e.g., IDS, firewall log) and provides a way to annotate the output.


   +------------------+
   | RecordData       |
   +------------------+
   | ENUM restriction |<>--{0..1}--[ DateTime    ]
   |                  |<>--{0..*}--[ Description ]
   |                  |<>--{0..1}--[ Application ]
   |                  |<>--{1..*}--[ RecordItem  ]
   +------------------+

                      Figure 30: 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: default value is "other".

      1.   client.  Client computer

      2.   server-internal.  Server with internal services

      3.   server-public.  Server with public services

      4.   www.  WWW server

      5.   mail.  Mail server

      6.   messaging.  Messaging server (e.g.  NNTP, IRC, IM)




Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 46] 43]

Internet-Draft              IODEF Data Model                 August               November 2005


   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.


3.19.2  RecordItem class

   The RecordItem class provides a way to incorporate relevant logs,
   audit trails, or forensic data to support the conclusions made during
   the course of analyzing the incident.  The class supports both the
   direct encapsulation of the data, as well as, provides primitives to
   reference data stored elsewhere.

   The dtype attribute will dictate the type of log data that will be
   found


      7.   streaming.  Streaming-media server

      8.   voice.  Voice server (e.g.  SIP, H.323)

      9.   file.  File server (e.g.  SMB, CVS, AFS)

      10.  ftp.  FTP server

      11.  p2p.  Peer-to-peer node

      12.  name.  Name server (e.g.  DNS, WINS)

      13.  directory.  Directory server (e.g.  LDAP, finger, whois)

      14.  credential.  Credential server (e.g. domain controller,
           Kerberos)

      15.  print.  Print server

      16.  application.  Application server

      17.  database.  Database server

      18.  infra.  Infrastructure server (e.g. router, firewall, DHCP)

      19.  log.  Logserver

      20.  other. other role not in this class.  This list

   lang
      Required.  ENUM.  A valid language code per RFC 3066 [6].


3.17  Service class

   The Service class describes a network service of a host or network.
   The service is very similar to identified by specific port or list of ports, along
   with the
   AdditionalData application listening on that port.

   When Service occurs as an aggregate class (Section 3.6) in of a System that it is an extension
   mechanism a
   source, then that can support proprietary representations the service is the one from which activity of security
   event data, not all
   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 necessarily in XML.


   +------------------+
   | RecordItem       |
   +------------------+
   | ANY being directed.

   This class was originally derived from the IDMEF specification, see
   Section 4.2.7.4 of [7].




Danyliw, et al.           Expires May 13, 2006                 [Page 44]

Internet-Draft              IODEF Data Model               November 2005


   +---------------------+
   |   Service           |
   +---------------------+
   | INTEGER ip_version  |<>--{0..1}--[ port        ]
   | ENUM type        |
   | STRING formatid INTEGER ip_protocol |<>--{0..1}--[ portlist    ]
   |


   +------------------+                     |<>--{0..1}--[ Application ]
   +---------------------+

                       Figure 31: 26: The RecordItem Service class

   The aggregate classes that constitute Service are:

   port
      Zero or one.  INTEGER.  A port number.

   portlist
      Zero or one.  PORTLIST.  A list of port numbers formatted
      according to Section 2.2.9.

   Application
      Zero or more.  The application bound to the specified port or
      portlist.

   The Service class must specify either a port or portlist.

   The Recorditem Service class has two attributes:

   type

   ip_version
      Required.  INTEGER.  The type of data included in the element content.  The
      permitted values for this attribute are shown below.  The default
      value is "string".

      1.   boolean. IP version number.

   ip_protocol
      Required.  INTEGER.  The element contains a boolean value, i.e., the
           strings "true" or "false"

      2.   byte. IANA protocol number.


3.17.1  Application class

   The element content is Application class describes an application running on a single 8-bit byte (see
           Section 2.2.5);

      3.   character.  The element content is System
   providing a single character (see
           Section 2.2.3); Service.













Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 47] 45]

Internet-Draft              IODEF Data Model                 August               November 2005


      4.   date-time.  The element content is a date-time string (see
           Section 2.2.8);

      5.   integer.


   +--------------------+
   |   Application      |
   +--------------------+
   | STRING swid        |<>--{0..1}--[ url        ]
   | STRING configid    |
   | STRING vendor      |
   | STRING family      |
   | STRING name        |
   | STRING version     |
   | STRING patch       |
   +--------------------+

                     Figure 27: The element content is an integer (see
           Section 2.2.1);

      6.   portlist. Application class

   The element content is a port list (see
           Section 2.2.9);

      7.   real. aggregate classes that constitute Application are:

   url
      Zero or one.  URI.  A uri describing the application.

   The element content is a real number (see
           Section 2.2.2);

      8.   string.  The element content is a string (see Section 2.2.3);

      9.   file.  The element content is a base64 encoded binary file;

      10.  frame.  The element content is a hexbin-encoded layer-2 frame
           (see Section 2.2.6)

      11.  packet.  The element content is a hexbin-encoded layer-3
           packet (see Section 2.2.6)

      12.  ipv4-packet.  The element content is an IPv4 hexbin-encoded
           packet (see Section 2.2.6)

      13.  ipv6-packet.  The element content is an IPv6 hexbin-encoded
           packet (see Section 2.2.6)

      14.  path.  The element content is a filesystem path;

      15.  url.  The element content is a URL (see Section 2.2.14;)

      16.  xml.  The element content is XML-tagged data (see Section 4).

   formatid Application class has seven attributes:

   swid
      Optional.  STRING.  An identifier referencing that can be used to reference
      this software.

   configid
      Optional.  STRING.  An identifier that can be used to reference a
      particular configuration.

   vendor
      Optional.  STRING.  Vendor name.

   family
      Optional.  STRING.  Family of the format and semantics software.

   name
      Optional.  STRING.  Name of the encapsulated data. software.

   version
      Optional.  STRING.  Version of the software.

   patch
      Optional.  STRING.  Patch or service pack level.


3.18  OperatingSystem class

   The OperatingSystem class describes the operating system running on a



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 48] 46]

Internet-Draft              IODEF Data Model                 August               November 2005


4.  Extending the IODEF

   In order


   System.  The definition is identical to support the changing activity of CSIRTS, 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 IODEF incident.  The source of
   this data
   model will need to evolve along with them.  To allow new features to often be added, both the data model and the Schema can be extended as
   described in this section.  As these extensions mature, they can be
   incorporated into future versions output of monitoring tools (e.g., IDMEF
   messages generated by an IDS, connection logs from a web server) that
   were used to uncover the specification or published
   separately.

4.1  Extending the data model

   There are two mechanisms for extending the IODEF data model:
   inheritance and aggregation.

   o  By using inheritance, new subclasses may be derived and given
      additional attributes or operations not found in the superclass.

   o  Aggregation allows for entirely new, self-contained classes malicious activity.  These logs should
   provide evidence as to be
      created and associated with why a parent class.

   Of the two extension mechanisms, inheritance is preferred, because it
   preserves the existing CSIRT believes an incident has occurred.


   +------------------+
   | Record           |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ RecordData ]
   +------------------+

                          Figure 28: Record class

   The aggregate class that constitutes Record is:

   RecordData
      One or more.  Log or audit data model and the operations (methods)
   executed on the classes generated by a particular type of
      sensor.  Seperate instances of the model.  There are explicit guidelines RecordData class SHOULD be used
      for extending the XML Schema (see each sensor type.

   The Record class has one attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 4.2) which set limits on
   where extensions to the 3.2.


3.19.1  RecordData class

   The RecordData class groups log or audit data model may be made.

4.2  Extending the XML Schema

   XML Schema from a given sensor
   (e.g., IDS, firewall log) and provides a flexible way of extending to annotate the output.













Danyliw, et al.           Expires May 13, 2006                 [Page 47]

Internet-Draft              IODEF data model
   by defining extension schemas in a separate namespace. Data Model               November 2005


   +------------------+
   | RecordData       |
   +------------------+
   | ENUM restriction |<>--{0..1}--[ DateTime        ]
   |                  |<>--{0..*}--[ Description     ]
   |                  |<>--{0..1}--[ Application     ]
   |                  |<>--{0..*}--[ RecordPattern   ]
   |                  |<>--{1..*}--[ RecordItem      ]
   +------------------+

                      Figure 29: The following guidelines MUST be followed when extending the IODEF
   Schema with another schema:

   1. RecordData class

   The IODEF extension Schema MUST include an extension namespace
       definition and provide a reference to 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 schema's location per description should
      convey 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 significance of the base namespace and declaration provided RecordItem data.

   Application
      Zero or one.  Information about the sensor used to generate the
      RecordItem data.

   RecordItem
      One or more.  Log, audit, or forensic data.

   The RecordData class has one attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in Section 3.2.


3.19.2  RecordPattern class

   The RecordPattern class describes where in the content of the base
       IODEF schema
   RecordItem relevant information can be added found.  It provides a way to the extension Schema
   reference subsets of information, identified by a pattern, in a large
   log file, audit trail, or forensic data.










Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 49] 48]

Internet-Draft              IODEF Data Model                 August               November 2005


   <xs:schema targetNamespace="http://iana.org/iodef-ext1"
              xmlns:iodef-ext1="http://iana.org/iodef-ext1"
              xmlns:iodef="http://iana.org/iodef"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified" >

   <xs:import namespace="http://iana.org/iodef"
              schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd">

   3.


   +------------------+
   | RecordPattern    |
   +------------------+
   | STRING           |
   |                  |
   | ENUM type        |
   | INTEGER offset   |
   | ENUM offsetunit  |
   | INTEGER instance |
   +------------------+

                    Figure 30: The RecordPattern class

   The location of the extension schema should be referenced in the
       XML document that uses it.

   <IODEF-Document xmlns:iodef-ext1="http://iana.org/iodef-ext1"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://iana.org/iodef-ext1
                   http://iana.org/iodef-ext1/ietf-inch-iodef-ext1.xsd">

   4.  It is RECOMMENDED that all extensions starts with "iodef-" prefix
       and add specific extension abbreviation such as "ext1".

   5.  It may be convenient to add a reference to the extension schema
       and import this extension namespace pattern to the base IODEF schema.

   Elements defined search with in the extension schema can be used in any place RecordItem is defined in
   final IODEF document.  In
   the example below, body of the "iodef-xws"
   extension element.  It is defined further annotated by four attributes:

   type
      Required.  ENUM.  Describes the schema type of pattern that contains one element "iodef-
   xws:Principal".  This element is composed being
      specified in the body of the NameIdentifier
   element element.  The default is "regex".

      1.  regex.  POSIX regular expression

      2.  binary.  Binhex encoded binary pattern

      3.  xpath.  W3C XPath

   offest
      Optional.  INTEGER.  Amount of XML type NCName and imports "iodef:Description" element
   from units (determined by the master IODEF schema.





















Danyliw, et al.         Expires February 3, 2006               [Page 50]

Internet-Draft              IODEF Data Model                 August 2005


   <xs:schema targetNamespace="http://iana.org/iodef-xws"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"
              xmlns:iodef-xws="http://iana.org/iodef-xws"
              xmlns:iodef="http://iana.org/iodef"
              xmlns:xs="http://www.w3.org/2001/XMLSchema">

   <xs:import namespace="http://iana.org/iodef"
              schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd">

   <xs:element name="Principal" type="iodef-xws:PrincipalType"/>
      <xs:complexType name="PrincipalType">
      <xs:sequence>
         <xs:element ref="iodef-xws:NameIdentifier"/>
         <xs:element ref="iodef:Description" minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="principalcat" type="xs:string"/>
   </xs:complexType>

   <xs:element name="NameIdentifier" type="iodef-xws:NameIdentifierType"/>
   <xs:complexType name="NameIdentifierType" type="xs:NCName">

   </schema>

   In offsetunit
      attribute) to seek into the example below, RecordItem data before matching the above defined extension
      pattern.

   offsetunit
      Optional.  ENUM.  Describes the units of the offset attribute.
      The default is used in "line".

      1.  line.  Offset is a count of lines.

      2.  binary.  Offset is a count of bytes

   instance
      Optional.  INTEGER.  Number of types to apply the
   iodef:System element. specified
      pattern.


3.19.3  RecordItem class

   The RecordItem class provides a way to incorporate relevant logs,
   audit trails, or forensic data to support the conclusions made during



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 51] 49]

Internet-Draft              IODEF Data Model                 August               November 2005


   <IODEF-Document xmlns:iodef="http://iana.org/iodef"
                   xmlns:iodef-xws="http://iana.org/iodef-xws"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://iana.org/iodef
                   http://iana.org/iodef-xws/draft-ietf-inch-iodef-1.0.xsd"
                   xsi:schemaLocation="http://iana.org/iodef-xws
                   http://iana.org/iodef-xws/draft-ietf-inch-iodef-xws.xsd"
                   version="1.0">

   <Incident restriction="private" purpose="traceback">
   <IncidentID Issuer="String" restriction="default">Text</IncidentID>

   [.....]

   <iodef:System restriction="default" interface="VLAN" systemcat="source" spoofed="unknown">

   [.....]

   <iodef-xws:Principal iodef-xws:principalcat="other">
   <NameIdentifier>CN=Yuri Demchenko, OU=AIRG, O=UvA, S=NH, L=Holland, C=NL</NameIdentifier>
   </iodef-xws:Principal>

   </iodef:System>


   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 February 3, May 13, 2006                 [Page 52] 50]

Internet-Draft              IODEF Data Model                 August               November 2005


5.  Processing Considerations

   The


4.  Extending the IODEF documents MUST be well-formed, and when practical, SHOULD
   also

   In order to support the changing activity of CSIRTS, the IODEF data
   model will need to evolve along with them.  To allow new features to
   be valid.

   On occasion, an IODEF-compliant application may receive a well-
   formed, or well-formed added, both the data model and valid IODEF document containing tags or
   content in the tags that are not expected.  These spurious conditions
   might include:

   o  Unrecognized tags used Schema can be extended as
   described in one this section.  As these extensions mature, they can be
   incorporated into future versions of the extension classes (i.e.,
      AdditionalData specification or RecordItem);

   o  Unrecognized tags outside of published
   separately.

4.1  Extending the extension classes; or data model

   There are two mechanisms for extending the IODEF data model:
   inheritance and aggregation.

   o  Well-formed  By using inheritance, new subclasses may be derived and validate document where element given
      additional attributes or attribute
      values to operations not conform to found in the expected values identified by an
      enumerated list;

   IODEF-compliant applications MUST continue superclass.

   o  Aggregation allows for entirely new, self-contained classes to process IODEF documents
   that contain unknown tags, provided that these documents are well-
   formed.  It be
      created and associated with a parent class.

   Of the two extension mechanisms, inheritance is up preferred, because it
   preserves the existing data model and the operations (methods)
   executed on the classes of the model.  There are explicit guidelines
   for extending the XML Schema (see Section 4.2) which set limits on
   where extensions to the individual application data model may be made.

4.2  Extending the XML Schema

   XML Schema provides a flexible way of extending the IODEF data model
   by defining extension schemas in a separate namespace.

   The following guidelines MUST be followed when extending the IODEF
   Schema with another schema:

   1.  The IODEF extension Schema MUST include an extension namespace
       definition and provide a reference to decide how this schema's location per
       the XML Schema specification:

   <xs:schema targetNamespace="http://iana.org/iodef-ext1"
              xmlns:iodef-ext1="http://iana.org/iodef-ext1"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified">

   2.  The import of the base namespace and declaration of the base
       IODEF schema can be added to
   process any content from the unknown tag. extension Schema





Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 53] 51]

Internet-Draft              IODEF Data Model                 August               November 2005


6.  Internationalization issues

   Internationalization and localization is


   <xs:schema targetNamespace="http://iana.org/iodef-ext1"
              xmlns:iodef-ext1="http://iana.org/iodef-ext1"
              xmlns:iodef="http://iana.org/iodef"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified" >

   <xs:import namespace="http://iana.org/iodef"
              schemaLocation="http://iana.org/iodef/ietf-inch-iodef-1.0.xsd">

   3.  The location of specific concern to the
   IODEF, since it is only through collaboration, often across language
   barriers, that certain incidents extension schema should be resolved.  The IODEF supports
   this goal by depending on XML constructs, and through explicit design
   choices referenced in the data model.

   The IODEF leverages that
       XML natively supports different character
   encodings document that uses it.

   <IODEF-Document xmlns:iodef-ext1="http://iana.org/iodef-ext1"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://iana.org/iodef-ext1
                   http://iana.org/iodef-ext1/ietf-inch-iodef-ext1.xsd">

   4.  It is specified for whole document.  The default encoding
   is UTF-8 whereby allowing information encoded in an IODEF document to
   be in all languages RECOMMENDED that are supported by UCS/Unicode.  In order all extensions starts with "iodef-" prefix
       and add specific extension abbreviation such as "ext1".

   5.  It may be convenient to
   disambiguate the explicit language on add a per-element basis, the xs:
   language attribute is used.

   For the languages that do not use UTF-8 encoding (e.g., Chinese Big5
   or Japanese ISO-2022-JP), reference to the IODEF extension schema uses the MultilingTextType
   type that allows a binary transformation of non-UTF-8 encoded text.

   The intent of the data model was to provide internationalization
       and
   localization, but not import this extension namespace to the detriment of inter-operability.  While base IODEF does support different languages, schema.

   Elements defined in the data model also relies
   heavily on standardized enumerated attributes that extension schema can crudely
   approximate the contents of the document.  With this approach, a
   CSIRT should be able to make some sense of an used in any place in
   final IODEF document it might
   receive that uses a language unfamiliar to its analysts.

   Likewise, document.  In the data model was designed so example below, the "iodef-xws"
   extension is defined by the schema that classes where free-text
   might be used for descriptive purposes always have a one-to-many
   cardinality with its parent (i.e., Description class).  The primary
   intent contains one element "iodef-
   xws:Principal".  This element is composed of this design was to allow the same description to be
   repeated in another instance NameIdentifier
   element of XML type NCName and imports "iodef:Description" element
   from the class but in a different
   language.  This approach allows recipients speaking different
   languages to receive the identical document, but allows the master IODEF
   parser to select the appropriate language. schema.





















Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 54] 52]

Internet-Draft              IODEF Data Model                 August               November 2005


7.  Examples

   This section provides representative examples of incident data
   converted to an IODEF document.

7.1  Code Red detection notification

   The following email message is a typical


   <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 of an incident
   report where one host is infected with a worm.  The original report
   sent by email is presented in Figure 37, and below, the corresponding
   equivalent as an IODEF document above defined extension is shown below.


   From e-citizen@domain.com
   Date: 13 Sep 2001 23:19:24 -0000
   To: cert-domain@domain.com
   Subject: 10.1.1.2 - Code Red Virus detected

   Automated message,
   you don't have to reply to this email.

   Your system with the IP number 10.1.1.2 seems to be infected
   with the Code Red virus.

   For more information see http://www.domain.org/react/code_redII.html

   Please fix used in the problem or inform a person who is responsible
   for that machine to do so.

   >From our web server logs (Port 80):
   10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

        Figure 37: Code Red detection notification: initial report



   <IODEF-Document version="1.0">
      <Incident restriction="need-to-know" purpose="handling">
         <IncidentID name="CERT-DOMAIN.COM">CERT-DOMAIN.COM#189</IncidentID>
         <Description>Host sending out Code Red probes</Description>
         <Assessment>
            <Impact severity="low" completion="failed" type="none"></Impact>
         </Assessment>
         <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
         <Contact role="creator" role="irt" type="organization">
   iodef:System element.

























Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 55] 53]

Internet-Draft              IODEF Data Model                 August               November 2005


            <name>CERT-FOR-OUR-DOMAIN.PL</name>
            <Email>cert-for-our-domain.pl@ourdomain.pl</Email>
         </Contact>
         <Contact role="tech" type="organization">
            <name>Constituency-contact for 10.1.1.2</name>
            <Email>Constituency-contact@10.1.1.2.pl</Email>
         </Contact>
         <Expectation category="investigate">
            <Description>Track and clean host</Description>
         </Expectation>
         <EventData>
             <Flow>
                <System category="source">
                   <Node>
                     <Address category="ipv4-addr">10.1.1.2</Address>
                   </Node>
                </System>
                <System category="target">
                   <Service ip_version=4" ip_protocol="6">
                     <port>80</port>
                   </Service>
                </System>
             </Flow>
             <Record>
                <RecordData>
                   <DateTime>2001-09-13T18:11:21+02:00</DateTime>
                   <Description>Web-server logs</Description>
                   <RecordItem>
   10.1.1.2 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                   </RecordItem>
                </RecordData>
             </Record>
         </EventData>
         <History>
             <HistoryItem type="notification">
                  <Description>Notification sent to
                           Constituency-contact@10.1.1.2
                  </Description>
                  <DateTime>2001-09-14T08:19:01+00:00</DateTime>
               </HistoryItem>
          </History>
      </Incident>
   </IODEF-Document>


   <IODEF-Document xmlns:iodef="http://iana.org/iodef"
                   xmlns:iodef-xws="http://iana.org/iodef-xws"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="http://iana.org/iodef
                   http://iana.org/iodef-xws/draft-ietf-inch-iodef-1.0.xsd"
                   xsi:schemaLocation="http://iana.org/iodef-xws
                   http://iana.org/iodef-xws/draft-ietf-inch-iodef-xws.xsd"
                   version="1.0">

   <Incident restriction="private" purpose="traceback">
   <IncidentID Issuer="String" restriction="default">Text</IncidentID>

   [.....]

   <iodef:System restriction="default" interface="VLAN" systemcat="source" spoofed="unknown">

   [.....]

   <iodef-xws:Principal iodef-xws:principalcat="other">
   <NameIdentifier>CN=Yuri Demchenko, OU=AIRG, O=UvA, S=NH, L=Holland, C=NL</NameIdentifier>
   </iodef-xws:Principal>

   </iodef:System>




























Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 56] 54]

Internet-Draft              IODEF Data Model                 August               November 2005


        Figure 38: 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


5.  Processing Considerations

   The IODEF documents MUST be well-formed, and signed using XML signature &
     encryption when practical, SHOULD
   also be valid.

   On occasion, an IODEF-compliant application may receive a well-
   formed, or well-formed and valid IODEF document containing tags or
   content in the tags that are not expected.  These spurious conditions
   might include:

   o  Unrecognized tags used in one of the extension classes (i.e.,
      AdditionalData or RecordItem);

   o  Unrecognized tags outside of the extension classes; or

   o  Well-formed and validate document where element or attribute
      values to not conform to the expected values identified by an
      enumerated list;

   IODEF-compliant applications MUST continue to process IODEF documents
   that contain unknown tags, provided that these documents are well-
   formed.  It is up to the individual application to decide how to
   process any content from the unknown tag.




























Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 57] 55]

Internet-Draft              IODEF Data Model                 August               November 2005


8.  The IODEF Document Schema



   <?xml version="1.0" encoding="UTF-8"?>

   <xs:schema targetNamespace="draft-ietf-inch-iodef-043.xsd"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"
              xmlns:iodef="draft-ietf-inch-iodef-043.xsd"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
              schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>

   <!--
    ********************************************************************
    ********************************************************************
    *** Incident Object Description


6.  Internationalization issues

   Internationalization and Exchange Format 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 Schema   ***
    ***               Version 04, August 2005                        ***
    ***              draft-ietf-inch-iodef-04                        ***
    ********************************************************************
    ********************************************************************
    -->

   <!--
    ====================================================================
    ==  Element definitions                                           ==
    ====================================================================
    -->

   <!--
   =====================================================================
    == IODEF-Document class                                           ==
    ====================================================================
   -->
     <xs:annotation>
       <xs:documentation>Root Element IODEF-Document</xs:documentation>
     </xs:annotation>
     <xs:element name="IODEF-Document">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Incident"/>
           <xs:element ref="ds:Signature" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="version" type="xs:string" fixed="0.40"/>
       </xs:complexType>



Danyliw, et al.         Expires February 3, 2006               [Page 58]

Internet-Draft constructs, and through explicit design
   choices in the data model.

   The IODEF Data Model                 August 2005


     </xs:element>

   <!--

    ====================================================================
    ===  Incident class                                          ===
    ====================================================================
   -->
     <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:Description" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Contact" maxOccurs="unbounded"/>
           <xs:element ref="iodef:ReportTime"/>
           <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:Expectation" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Assessment" 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 ref="iodef:restriction" default="private"/>
         <xs:attribute ref="iodef:purpose" use="required"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ==  IncidentID class                                              ==
    ====================================================================
    -->
     <xs:element name="IncidentID" type="iodef:IncidentIDType"/>
     <xs:complexType name="IncidentIDType" mixed="true">
       <xs:attribute name="Issuer" type="xs:string" use="required"/>
       <xs:attribute ref="iodef:restriction"/>
     </xs:complexType>
     <!--
    ====================================================================
    ==  AlternativeID class                                           ==
    ====================================================================
    -->
     <xs:element name="AlternativeID">
       <xs:complexType>



Danyliw, et al.         Expires February 3, 2006               [Page 59]

Internet-Draft 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 Data Model                 August 2005


         <xs:sequence>
           <xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ==  RelatedActivity class                                         ==
    ====================================================================
    -->
     <xs:element name="RelatedActivity">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  AdditionalData class                                        ===
    ====================================================================
    -->
     <xs:element name="AdditionalData" type="iodef:AdditionalDataType"/>
     <xs:complexType name="AdditionalDataType">
       <xs:sequence>
         <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
         <!-- (0,unbounded) elements from any (target document to
   be in all languages that are supported by UCS/Unicode.  In order to
   disambiguate the explicit language on a per-element basis, the xs:
   language attribute is used.

   For the languages that do not use UTF-8 encoding (e.g., Chinese Big5
   or Japanese ISO-2022-JP), the IODEF schema uses the MultilingTextType
   type that allows a binary transformation of non-UTF-8 encoded text.

   The intent of the data model was to provide internationalization and external) namespace -->
       </xs:sequence>
       <xs:attribute ref="iodef:dtype" use="required"/>
       <xs:attribute name="meaning" type="xs:string"/>
     </xs:complexType>
     <!--
    ====================================================================
    ===  Contact class                                               ===
    ===    - Name
    ===    - RegistryHandle
    ===    - PostalAddress
    ===    - Email
    ===    - Telephone
    ===    - Fax
    ===    - TimeZone
    ===    - Contact (recursive)
   ====================================================================
    -->
     <xs:element name="Contact">
       <xs:complexType>



Danyliw, et al.         Expires February 3, 2006               [Page 60]

Internet-Draft
   localization, but not to the detriment of inter-operability.  While
   IODEF Data Model                 August 2005


         <xs:sequence>
           <!-- <xs:element ref="iodef:NameIdentifier" minOccurs="0"/> -->
           <xs:element ref="iodef:name" 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"/>
           <xs:element ref="iodef:TimeZone" minOccurs="0"/>
           <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:contactrole" use="required"/>
         <xs:attribute ref="iodef:contacttype" use="required"/>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <!--<xs:attribute ref="iodef:format"/> -->
     <xs:element name="RegistryHandle">
       <xs:complexType mixed="true">
         <xs:attribute ref="iodef:registrytype" use="required"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="PostalAddress">
       <xs:complexType mixed="true">
         <xs:attribute name="lang" type="xs:language"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="Email" type="xs:string"/>
     <xs:element name="Telephone" type="xs:string"/>
     <xs:element name="Fax" type="xs:string"/>
   <!--
    ====================================================================
    ===  Time-based classes                                          ===
    ====================================================================
    -->
     <xs:element name="DateTime" type="xs:dateTime"/>
     <xs:element name="ReportTime" type="xs:dateTime"/>
     <xs:element name="DetectTime" type="xs:dateTime"/>
     <xs:element name="StartTime" type="xs:dateTime"/>
     <xs:element name="EndTime" type="xs:dateTime"/>
     <xs:element name="TimeZone" type="iodef:TimeZoneType"/>
     <xs:simpleType name="TimeZoneType">
       <xs:restriction base="xs:string">
         <xs:pattern value="[+-][0-9][0-9][0-9][0-9]"/>
       </xs:restriction>
     </xs:simpleType>
     <!--



Danyliw, et al.         Expires February 3, 2006               [Page 61]

Internet-Draft 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 Data Model                 August 2005


    ====================================================================
    ===  History class                                               ===
    ===    - HistoryItem
    ====================================================================
    -->
     <xs:element name="History">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:HistoryItem" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction" default="default"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="HistoryItem">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:DateTime"/>
           <xs:element ref="iodef:IncidentID" minOccurs="0"/>
           <xs:element ref="iodef:Description" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
         <xs:attribute ref="iodef:historycat" default="other"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Expectation class                                           ===
    ====================================================================
    -->
     <xs:element name="Expectation">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Description" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Contact" minOccurs="0"/>
           <xs:element ref="iodef:StartTime" minOccurs="0"/>
           <xs:element ref="iodef:EndTime" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction" default="default"/>
         <xs:attribute ref="iodef:priority"/>
         <xs:attribute ref="iodef:expectcat"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Method document it might
   receive that uses a language unfamiliar to its analysts.

   Likewise, the data model was designed so that classes where free-text
   might be used for descriptive purposes always have a one-to-many
   cardinality with its parent (i.e., Description class).  The primary
   intent of this design was to allow the same description to be
   repeated in another instance of the class                                                ===
    ===    - Classification
    ====================================================================
    --> but in a different
   language.  This approach allows recipients speaking different
   languages to receive the identical document, but allows the IODEF
   parser to select the appropriate language.
















Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 62] 56]

Internet-Draft              IODEF Data Model                 August               November 2005


     <xs:element name="Method">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Classification" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Description" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="Classification">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:name"/>
           <xs:element ref="iodef:url"/>
         </xs:sequence>
         <xs:attribute ref="iodef:origin" use="required"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Assessment class                                            ===
    ===


7.  Examples

   This section provides representative examples of incident data
   converted to an IODEF document.

7.1  Code Red detection notification

   The following email message is a typical example of an incident
   report where one host is infected with a worm.  The original report
   sent by email is presented in Figure 36, and the corresponding
   equivalent as an IODEF document is shown below.


   From e-citizen@domain.com
   Date: 13 Sep 2001 23:19:24 -0000
   To: cert-domain@domain.com
   Subject: 10.1.1.2 - Impact
    === Code Red Virus detected

   Automated message,
   you don't have to reply to this email.

   Your system with the IP number 10.1.1.2 seems to be infected
   with the Code Red virus.

   For more information see http://www.domain.org/react/code_redII.html

   Please fix the problem or inform a person who is responsible
   for that machine to do so.

   >From our web server logs (Port 80):
   10.1.1.2 - TimeImpact
    === - MonetaryImpact
    === [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

        Figure 36: Code Red detection notification: initial report



   <IODEF-Document version="1.00">
     <Incident  purpose="reporting">
       <IncidentID name="CERT-DOMAIN.COM">CERT-DOMAIN.COM#189</IncidentID>
       <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
       <Description>Host sending out Code Red probes</Description>
       <Assessment>
         <Impact completion="failed" type="admin"/>
       </Assessment>
       <Contact role="creator" type="organization">



Danyliw, et al.           Expires May 13, 2006                 [Page 57]

Internet-Draft              IODEF Data Model               November 2005


         <ContactName>CERT-FOR-OUR-DOMAIN.PL</ContactName>
         <Email>cert-for-our-domain.pl@ourdomain.pl</Email>
       </Contact>
       <Contact role="tech" type="organization">
         <ContactName>Constituency-contact for 10.1.1.2</ContactName>
         <Email>Constituency-contact@10.1.1.2.pl</Email>
       </Contact>
       <EventData>
         <Flow>
           <System category="source">
             <Node>
               <Address category="ipv4-addr">10.1.1.2</Address>
             </Node>
           </System>
           <System category="target">
               <Node>
                  <Address category="ipv4-net">10.5.0.0/16</Address>
               </Node>
             <Service ip_version="4" ip_protocol="6">
               <port>80</port>
             </Service>
           </System>
         </Flow>
           <Expectation category="investigate">
         <Description>Track and clean host</Description>
           </Expectation>
         <Record>
           <RecordData>
             <DateTime>2001-09-13T18:11:21+02:00</DateTime>
             <Description>Web-server logs</Description>
             <RecordItem type="string">10.1.1.2 - - Confidence
    ====================================================================
    -->
     <xs:element name="Assessment">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Impact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:TimeImpact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:MonetaryImpact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Confidence" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="Impact">
       <xs:complexType>
         <xs:attribute ref="iodef:severity"/>
         <xs:attribute ref="iodef:completion"/>
         <xs:attribute ref="iodef:impacttype" use="optional" default="unknown"/>
         <xs:attribute name="lang" type="xs:language"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="TimeImpact">
       <xs:complexType mixed="true"> [13/Sep/2001:18:11:21 +0200] "GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
             </RecordItem>
             <RecordItem type="url">
               http://mydomain.com/logs/httpd_access
             </RecordItem>
           </RecordData>
         </Record>
       </EventData>
       <History>
         <HistoryItem category="notification">
           <DateTime>2001-09-14T08:19:01+00:00</DateTime>
           <Description>
              Notification sent to constituency-contact@10.1.1.2
           </Description>
         </HistoryItem>
       </History>
     </Incident>
   </IODEF-Document>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 63] 58]

Internet-Draft              IODEF Data Model                 August               November 2005


         <xs:attribute ref="iodef:severity"/>
         <xs:attribute name="unit" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="labor"/>
               <xs:enumeration value="elapsed"/>
               <xs:enumeration value="downtime"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="metric" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="days"/>
               <xs:enumeration value="hours"/>
               <xs:enumeration value="minutes"/>
               <xs:enumeration value="seconds"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>
     <xs:element name="MonetaryImpact">
       <xs:complexType mixed="true">
         <xs:attribute ref="iodef:severity"/>
         <xs:attribute name="currency" type="xs:string"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="Confidence">
       <xs:complexType>
         <xs:attribute ref="iodef:rating" use="required"/>
       </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:Contact" 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:Flow" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:System" minOccurs="0" maxOccurs="unbounded"/>


        Figure 37: Code Red detection notification: CSIRT response


7.2  IODEF-Document with XML signature

7.3  IODEF-Document encrypted using XML encryption

7.4  IODEF-Document encrypted and signed using XML signature &
     encryption










































Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 64] 59]

Internet-Draft              IODEF Data Model                 August               November 2005


           <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Assessment" minOccurs="0"/>
           <xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Record" minOccurs="0"/>
           <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction" default="default"/>
       </xs:complexType>
     </xs:element>


8.  The IODEF Document Schema



   <?xml version="1.0" encoding="UTF-8"?>

   <xs:schema targetNamespace="draft-ietf-inch-iodef-050.xsd"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"
              xmlns:iodef="draft-ietf-inch-iodef-050.xsd"
              xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
              schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
   <!--
    ====================================================================
    ===  Flow class                                                ===
    ====================================================================
    ********************************************************************
    ********************************************************************
    *** Incident Object Description and Exchange Format XML Schema   ***
    ***               Version 05, November 2005                      ***
    ***               draft-ietf-inch-iodef-05                       ***
    ********************************************************************
    ********************************************************************
    -->
     <xs:element name="Flow">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:System" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

   <!--
    ====================================================================
    ===  System
   =====================================================================
    == IODEF-Document class                                                ===                                           ==
    ====================================================================
   -->
     <xs:annotation>
       <xs:documentation>Root Element IODEF-Document</xs:documentation>
     </xs:annotation>
     <xs:element name="System"> name="IODEF-Document">
       <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"/> ref="iodef:Incident"/>
           <xs:element ref="iodef:Counter" ref="ds:Signature" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
         <xs:attribute name="interface" type="xs:string"/>
         <xs:attribute ref="iodef:systemcat"/> name="version" type="xs:string" fixed="1.00"/>
         <xs:attribute ref="iodef:spoofed" default="unknown"/> name="lang" type="xs:language"/>
       </xs:complexType>
     </xs:element>

   <!--

    ====================================================================
    === Node  Incident class                                          ===
   ====================================================================
   -->
     <xs:element name="Node">
       <xs:complexType>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 65] 60]

Internet-Draft              IODEF Data Model                 August               November 2005


    ====================================================================
   -->
     <xs:element name="Incident">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:DateTime" ref="iodef:IncidentID"/>
           <xs:element ref="iodef:AlternativeID" minOccurs="0"/>
           <xs:element ref="iodef:name" ref="iodef:RelatedActivity" minOccurs="0"/>
           <xs:element ref="iodef:Address" minOccurs="0" maxOccurs="unbounded"/> ref="iodef:DetectTime" minOccurs="0"/>
           <xs:element ref="iodef:Location" ref="iodef:StartTime" minOccurs="0"/>
           <xs:element ref="iodef:NodeRole" ref="iodef:EndTime" minOccurs="0"/>
           <xs:element ref="iodef:ReportTime"/>
           <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Counter" ref="iodef:Assessment" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
           <xs:element name="Address">
       <xs:complexType>
         <xs:attribute ref="iodef:addrcat" use="required"/>
         <xs:attribute name="vlan-name" type="xs:string"/>
         <xs:attribute name="vlan-num" type="xs:string"/>
       </xs:complexType>
     </xs:element> ref="iodef:Contact" maxOccurs="unbounded"/>
           <xs:element name="Location" type="xs:string"/> ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element name="NodeRole">

       <xs:complexType mixed="true"> ref="iodef:History" minOccurs="0"/>
           <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:noderolecat" use="required"/> name="purpose" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="traceback"/>
               <xs:enumeration value="mitigation"/>
               <xs:enumeration value="reporting"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="lang" type="xs:language"/>
         <xs:attribute ref="iodef:restriction" default="private"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Service Class                                               ===
    ==  IncidentID class                                              ==
    ====================================================================
    -->
     <xs:element name="Service">
       <xs:complexType>
         <xs:sequence>
           <xs:choice>
             <xs:element ref="iodef:port"/>
             <xs:element ref="iodef:portlist"/>
           </xs:choice>
           <xs:element ref="iodef:Application" minOccurs="0"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
     <xs:element name="port" type="xs:string"/>
     <xs:element name="portlist" type="xs:string"/> name="IncidentID" type="iodef:IncidentIDType"/>
     <xs:complexType name="IncidentIDType" mixed="true">
       <xs:attribute name="name" type="xs:string" use="required"/>
     </xs:complexType>
     <!--
    ====================================================================
    ===  Application
    ==  AlternativeID class                                           ===                                           ==
    ====================================================================
    -->



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 66] 61]

Internet-Draft              IODEF Data Model                 August               November 2005


    -->


     <xs:element name="Application"> name="AlternativeID">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:url" minOccurs="0"/>
           <xs:element ref="iodef:name" minOccurs="0"/> ref="iodef:IncidentID" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="appid" type="xs:string" default="0"/>
         <xs:attribute name="configid" type="xs:string" default="0"/>
         <xs:attribute name="vendor" type="xs:string"/>
         <xs:attribute name="version" type="xs:string"/> ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  OperatingSystem
    ==  RelatedActivity class                                       ===                                         ==
    ====================================================================
    -->
     <xs:element name="OperatingSystem"> name="RelatedActivity">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:IncidentID" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="vendor" type="xs:string"/>
         <xs:attribute name="version" type="xs:string"/>
         <xs:attribute name="patch" type="xs:string"/> ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Counter  AdditionalData class                                        ===
    ====================================================================
    -->
     <xs:element name="Counter">
       <xs:complexType>
         <xs:attribute ref="iodef:countertype" default="other"/>
         <xs:attribute name="meaning" type="xs:string" use="optional"/>
       </xs:complexType>
     </xs:element> name="AdditionalData" type="iodef:ExtensionType"/>

   <!--
    ====================================================================
    ===  Record  Contact class                                               ===
    ===    - ContactName
    ===    - RegistryHandle
    ===    - PostalAddress
    ===    - Email
    ===    - Telephone
    ===    - Fax
    ===    - TimeZone
    ===    - Contact (recursive)
   ====================================================================
    -->
     <xs:element name="Record"> name="Contact">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:RecordData" ref="iodef:ContactName" minOccurs="0"/>
           <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
           <xs:element ref="iodef:RegistryHandle" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:PostalAddress" minOccurs="0"/>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 67] 62]

Internet-Draft              IODEF Data Model                 August               November 2005


       </xs:complexType>
     </xs:element>
     <xs:element name="RecordData">
       <xs:complexType>
         <xs:sequence>


           <xs:element ref="iodef:DateTime" minOccurs="0"/> ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Description" ref="iodef:Telephone" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Application" ref="iodef:Fax" minOccurs="0"/>
           <xs:element ref="iodef:RecordItem" ref="iodef:TimeZone" minOccurs="0"/>
           <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="role">
           <xs:simpleType>
              <xs:restriction base="xs:NMTOKEN">
                 <xs:enumeration value="creator"/>
                 <xs:enumeration value="admin"/>
                 <xs:enumeration value="tech"/>
                 <xs:enumeration value="irt"/>
                 <xs:enumeration value="cc"/>
              </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="type">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="person"/>
               <xs:enumeration value="organization"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="RecordSource" type="iodef:RecordSourceType"/>
     <xs:complexType name="RecordSourceType" mixed="true">
       <xs:attribute name="recsourcetype" type="xs:string" use="optional"/>
     </xs:complexType>
     <xs:element name="Pattern" type="xs:string"/> name="ContactName" type="iodef:MLStringType" />

     <xs:element name="PatternLocation" type="iodef:PatternLocationType"/> name="RegistryHandle">
       <xs:complexType name="PatternLocationType" mixed="true">
         <xs:attribute name="recdtype" type="xs:string" use="optional"/>
     </xs:complexType>
     <!-- <xs:element name="Count" type="xs:integer"/> -->
     <!--Element Analyzer of IODEF is re-used from IDMEF (4.2.4.1) -->
     <xs:element name="Sensor">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Node" minOccurs="0"/>
           <!-- removed in expectation of Analyser simplification -->
           <!-- <xs:element ref="iodef:Process" minOccurs="0"/> -->
           <xs:element ref="iodef:Process" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute name="analyzerid" type="xs:string" default="0"/>
         <xs:attribute name="manufacturer" type="xs:string"/>
         <xs:attribute name="model" type="xs:string"/>
         <xs:attribute name="version" type="xs:string"/>
         <xs:attribute name="class" type="xs:string"/>
         <xs:attribute name="ostype" type="xs:string"/>
         <xs:attribute name="osversion" type="xs:string"/> name="type">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="internic"/>
               <xs:enumeration value="apnic"/>
               <xs:enumeration value="arin"/>
               <xs:enumeration value="lacnic"/>
               <xs:enumeration value="ripe"/>
               <xs:enumeration value="afrinic"/>
               <xs:enumeration value="local"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>
     <xs:element name="Process">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:name" minOccurs="0"/>
           <xs:element name="arg" type="xs:string" minOccurs="0"/>
           <xs:element name="env" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
     </xs:element>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 68] 63]

Internet-Draft              IODEF Data Model                 August               November 2005


       </xs:complexType>
     </xs:element>


     <xs:element name="RecordItem" type="iodef:AdditionalDataType"/> 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"/>
   <!--
    ====================================================================
    ===  Description  Time-based classes                                          ===
    ====================================================================
    -->
     <xs:element name="DateTime" type="xs:dateTime"/>
     <xs:element name="ReportTime" type="xs:dateTime"/>
     <xs:element name="DetectTime" type="xs:dateTime"/>
     <xs:element name="StartTime" type="xs:dateTime"/>
     <xs:element name="EndTime" type="xs:dateTime"/>
     <xs:element name="TimeZone" type="iodef:TimeZoneType"/>
     <xs:simpleType name="TimeZoneType">
       <xs:restriction base="xs:string">
         <xs:pattern value="[+-][0-9][0-9][0-9][0-9]"/>
       </xs:restriction>
     </xs:simpleType>
     <!--
    ====================================================================
    ===  History class                                               ===
    === (contains attribute "transform" to preserve non-UTF-8 text encoding)    - HistoryItem
    ====================================================================
    -->
     <xs:element name="Description" type="iodef:MultilingTextType"/>
     <xs:complexType name="MultilingTextType" mixed="true">
       <xs:complexContent mixed="true">
         <xs:extension base="iodef:TextAbstractType">
           <xs:attribute ref="iodef:preserve"/> name="History">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:HistoryItem" minOccurs="1" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:transform"/>
         </xs:extension>
       </xs:complexContent> ref="iodef:restriction" default="default"/>
       </xs:complexType>
     <!--
     </xs:element>
     <xs:element name="Text" type="iodef:TextAbstractType"/> -->
     <xs:complexType name="TextAbstractType" mixed="true">
       <xs:annotation>
         <xs:documentation xml:lang="en">Textual description, may use local languages.
         For particular use may be extended with optional attributes "preserve"={0,1} and "transformation"
         </xs:documentation>
       </xs:annotation>
       <xs:complexContent mixed="true">
         <xs:restriction base="xs:anyType"> name="HistoryItem">
       <xs:complexType>
         <xs:sequence>
             <xs:any processContents="lax" minOccurs="0"
           <xs:element ref="iodef:DateTime"/>
           <xs:element ref="iodef:IncidentID" minOccurs="0"/>
           <xs:element ref="iodef:Description" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="lang" type="xs:language"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>
     <!--
    | Values for the Description.preserve attributes
    --> ref="iodef:restriction"/>
         <xs:attribute name="preserve"> name="category" default="other">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="no"/> value="triaged"/>
               <xs:enumeration value="yes"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>
     <xs:attribute name="transform">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN"> value="notification"/>
               <xs:enumeration value="shared-info"/>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 69] 64]

Internet-Draft              IODEF Data Model                 August               November 2005


               <xs:enumeration value="none"/>
           <xs:enumeration value="Base64"/>
           <xs:enumeration value="QP"/>
           <xs:enumeration value="stringprep"/> value="received-info"/>
               <xs:enumeration value="zip"/> value="remediation"/>
               <xs:enumeration value="URI"/> value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
        </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    === Miscellaneous simple classes                                 ===
    ===   - name  Expectation class                                           ===   - url
     <xs:element name="name" type="iodef:MultilingTextType"/>
     <xs:element name="name" type="xs:string"/>
     <xs:element name="name" type="NameidType"/>
     <xs:complexType name="NameidType">
       <xs:complexContent>
         <xs:extension base="iodef:MultilingTextType"/>
       </xs:complexContent>
     </xs:complexType>
    ====================================================================
    -->
     <xs:element name="name" type="iodef:MultilingTextType"/> name="Expectation">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="number" type="xs:string"/> ref="iodef:Description" maxOccurs="unbounded"/>
           <xs:element name="url" type="xs:string"/>
     <!--
    ====================================================================
    === Attribute list declarations.                      ===
    ====================================================================
    -->
     <!--
    | Attributes of the IODEF element.  In general, the fixed value
    | of this attribute will change each time a new version of
    | the DTD is released.
    -->
     <!--
    | Values for the Address.category attribute.
    --> ref="iodef:StartTime" minOccurs="0"/>
           <xs:element ref="iodef:EndTime" minOccurs="0"/>
           <xs:element ref="iodef:Contact" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction" default="default"/>
         <xs:attribute name="addrcat"> ref="iodef:severity"/>
         <xs:attribute name="category">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="asn"/> value="nothing"/>
               <xs:enumeration value="atm"/> value="contact-site"/>
               <xs:enumeration value="e-mail"/> value="contact-me"/>
               <xs:enumeration value="mac"/> value="investigate"/>
               <xs:enumeration value="block-host"/>
               <xs:enumeration value="block-network"/>
               <xs:enumeration value="block-port"/>
               <xs:enumeration value="rate-limit-host"/>
               <xs:enumeration value="rate-limit-network"/>
               <xs:enumeration value="rate-limit-port"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>
     <!--
    ====================================================================
    ===  Method class                                                ===
    ===    - Classification
    ====================================================================
    -->



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 70] 65]

Internet-Draft              IODEF Data Model                 August               November 2005


     <xs:element name="Method">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Classification" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="Classification">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:name"/>
           <xs:element ref="iodef:url" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="origin" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="ipv4-addr"/> value="bugtraqid"/>
               <xs:enumeration value="ipv4-net"/> value="cve"/>
               <xs:enumeration value="ipv4-net-mask"/> value="certcc"/>
               <xs:enumeration value="ipv6-addr"/> value="vendor"/>
               <xs:enumeration value="ipv6-net"/> value="local"/>
               <xs:enumeration value="ipv6-net-mask"/> value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>
     <!--
    | Values for the Impact.completion attribute.
    ====================================================================
    ===  Assessment class                                            ===
    ===    - Impact
    ===    - TimeImpact
    ===    - MonetaryImpact
    ===    - Confidence
    ====================================================================
    -->
     <xs:element name="Assessment">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Impact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:TimeImpact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:MonetaryImpact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Confidence" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>



Danyliw, et al.           Expires May 13, 2006                 [Page 66]

Internet-Draft              IODEF Data Model               November 2005


     </xs:element>

     <xs:element name="Impact">
       <xs:complexType>
         <xs:attribute ref="iodef:severity"/>
         <xs:attribute name="completion">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="failed"/>
               <xs:enumeration value="succeeded"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
     <!--
    | Values for the Contact.role attribute.
    -->
         <xs:attribute name="contactrole"> name="type" use="optional" default="unknown">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="creator"/> value="none"/>
               <xs:enumeration value="admin"/>
               <xs:enumeration value="tech"/> value="dos"/>
               <xs:enumeration value="irt"/> value="file"/>
               <xs:enumeration value="cc"/> value="recon"/>
               <xs:enumeration value="user"/>
               <xs:enumeration value="unknown"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
     <!--
    | Values for the Contact.type attribute.
    -->
         <xs:attribute name="contacttype"> name="lang" type="xs:language"/>
       </xs:complexType>
     </xs:element>

     <xs:element name="TimeImpact">
       <xs:complexType>
         <xs:simpleContent>
            <xs:extension base="xs:float">
              <xs:attribute ref="iodef:severity"/>
              <xs:attribute name="unit" use="required">
                <xs:simpleType>
                  <xs:restriction base="xs:NMTOKEN">
                    <xs:enumeration value="person"/> value="labor"/>
                    <xs:enumeration value="organisation"/> value="elapsed"/>
                    <xs:enumeration value="downtime"/>
                  </xs:restriction>
                </xs:simpleType>
              </xs:attribute>
     <!--
    | Values for the Counter.type attribute.
              <xs:attribute name="metric" use="required">
                <xs:simpleType>
                  <xs:restriction base="xs:NMTOKEN">



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 71] 67]

Internet-Draft              IODEF Data Model                 August               November 2005


    -->
     <xs:attribute name="countertype">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">


                    <xs:enumeration value="packet"/> value="days"/>
                    <xs:enumeration value="session"/> value="hours"/>
                    <xs:enumeration value="event"/> value="minutes"/>
                    <xs:enumeration value="other"/> value="seconds"/>
                  </xs:restriction>
                </xs:simpleType>
              </xs:attribute>
     <!--
    | Values for the RecordItem.type attribute
    -->
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="MonetaryImpact">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:float">
             <xs:attribute name="dtype">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="boolean"/>
           <xs:enumeration value="byte"/>
           <xs:enumeration value="character"/>
           <xs:enumeration value="date-time"/>
           <xs:enumeration value="integer"/>
           <xs:enumeration value="ntpstamp"/>
           <xs:enumeration value="portlist"/>
           <xs:enumeration value="real"/>
           <xs:enumeration value="string"/>
           <xs:enumeration value="file"/>
           <xs:enumeration value="path"/>
           <xs:enumeration value="frame"/>
           <xs:enumeration value="packet"/>
           <xs:enumeration value="ipv4-packet"/>
           <xs:enumeration value="ipv6-packet"/>
           <xs:enumeration value="url"/>
           <xs:enumeration value="xml"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>
     <!--
    | Values for the Expectation.expectcat attributes
    --> ref="iodef:severity"/>
             <xs:attribute name="expectcat"> name="currency" type="xs:string"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="Confidence">
       <xs:complexType>
         <xs:attribute name="rating" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="nothing"/> value="low"/>
               <xs:enumeration value="contact-site"/> value="medium"/>
               <xs:enumeration value="contact-me"/> value="high"/>
               <xs:enumeration value="block"/> value="numeric"/>
               <xs:enumeration value="investigate"/> value="unknown"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>
   <!--
    ====================================================================
    === EventData class                                              ===
    ====================================================================
    -->
     <xs:element name="EventData">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:DetectTime" minOccurs="0"/>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 72] 68]

Internet-Draft              IODEF Data Model                 August               November 2005


           <xs:enumeration value="other"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>


           <xs:element ref="iodef:StartTime" minOccurs="0"/>
           <xs:element ref="iodef:EndTime" minOccurs="0"/>
           <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Assessment" minOccurs="0"/>
           <xs:element ref="iodef:Method" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Flow" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Expectation" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Record" minOccurs="0"/>
           <xs:element ref="iodef:EventData" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction" default="default"/>
       </xs:complexType>
     </xs:element>
   <!--
    | Values for the File.category attribute.
    ====================================================================
    ===  Flow class                                                ===
    ====================================================================
    -->
     <xs:attribute name="filecat">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="current"/>
           <xs:enumeration value="original"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>
     <xs:element name="Flow">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:System" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   <!--
    | Values for the NameIdentifier.format attribute.
    ====================================================================
    ===  System class                                                ===
    ====================================================================
    -->
     <xs:element name="System">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:Node"/>
           <xs:element ref="iodef:Service" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:OperatingSystem" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
         <xs:attribute name="interface" type="xs:string"/>
         <xs:attribute name="format"> name="category">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="emailAddress"/>
           <xs:enumeration value="x509NameQualifier"/>
           <xs:enumeration value="urn"/> value="source"/>
               <xs:enumeration value="local"/> value="target"/>
               <xs:enumeration value="other"/> value="intermediate"/>
             </xs:restriction>



Danyliw, et al.           Expires May 13, 2006                 [Page 69]

Internet-Draft              IODEF Data Model               November 2005


           </xs:simpleType>
         </xs:attribute>
     <!--
    | Values for the History.type attribute.
    -->
         <xs:attribute name="historycat"> name="spoofed" default="unknown">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="triaged"/>
           <xs:enumeration value="notification"/>
           <xs:enumeration value="shared-info"/>
           <xs:enumeration value="received-info"/> value="unknown"/>
               <xs:enumeration value="remediation"/> value="yes"/>
               <xs:enumeration value="other"/> value="no"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

   <!--
    | Values for the Impact.type attribute.
   ====================================================================
   === Node class                                                   ===
   ====================================================================
   -->
     <xs:attribute name="impacttype">



Danyliw, et al.         Expires February 3, 2006               [Page 73]

Internet-Draft              IODEF Data Model                 August 2005
     <xs:element name="Node">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:name" minOccurs="0"/>
           <xs:element ref="iodef:Address" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Location" minOccurs="0"/>
           <xs:element ref="iodef:DateTime" minOccurs="0"/>
           <xs:element ref="iodef:NodeRole" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
     <xs:element name="Address">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:string">
             <xs:attribute name="category">
               <xs:simpleType>
                 <xs:restriction base="xs:NMTOKEN">
                   <xs:enumeration value="none"/> value="asn"/>
                   <xs:enumeration value="admin"/> value="atm"/>
                   <xs:enumeration value="dos"/> value="e-mail"/>
                   <xs:enumeration value="file"/> value="mac"/>
                   <xs:enumeration value="recon"/> value="ipv4-addr"/>
                   <xs:enumeration value="user"/> value="ipv4-net"/>
                   <xs:enumeration value="unknown"/> value="ipv4-net-mask"/>
                   <xs:enumeration value="other"/> value="ipv6-addr"/>
                   <xs:enumeration value="ipv6-net"/>
                   <xs:enumeration value="ipv6-net-mask"/>



Danyliw, et al.           Expires May 13, 2006                 [Page 70]

Internet-Draft              IODEF Data Model               November 2005


                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
   <!--
    | Values for the NodeRole.category attribute.
    -->
             <xs:attribute name="noderolecat"> name="vlan-name" type="xs:string"/>
             <xs:attribute name="vlan-num" type="xs:integer"/>
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="Location" type="xs:string"/>

     <xs:element name="NodeRole">
       <xs:complexType mixed="true">
         <xs:attribute name="category" use="required">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="client"/>
               <xs:enumeration value="server-internal"/>
               <xs:enumeration value="server-public"/>
               <xs:enumeration value="www"/>
               <xs:enumeration value="mail"/>
               <xs:enumeration value="messaging"/>
               <xs:enumeration value="streaming"/>
               <xs:enumeration value="voice"/>
               <xs:enumeration value="file"/>
               <xs:enumeration value="ftp"/>
               <xs:enumeration value="p2p"/>
               <xs:enumeration value="name"/>
               <xs:enumeration value="directory"/>
               <xs:enumeration value="credential"/>
               <xs:enumeration value="print"/>
               <xs:enumeration value="application"/>
               <xs:enumeration value="database"/>
               <xs:enumeration value="infra"/>
               <xs:enumeration value="log"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="lang" type="xs:language"/>
       </xs:complexType>
     </xs:element>
   <!--
    | Values for the Classification.origin attribute.
    ====================================================================
    ===  Service Class                                               ===
    ====================================================================
    -->
     <xs:attribute name="origin">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 74] 71]

Internet-Draft              IODEF Data Model                 August               November 2005


           <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:element name="Service">
       <xs:complexType>
         <xs:sequence>
           <xs:choice>
             <xs:element ref="iodef:port"/>
             <xs:element ref="iodef:portlist"/>
           </xs:choice>
           <xs:element ref="iodef:Application" minOccurs="0"/>
         </xs:sequence>
         <xs:attribute name="ip_version" type="xs:integer" default="4"/>
         <xs:attribute name="ip_protocol" type="xs:integer"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="port" type="xs:integer"/>
     <xs:element name="portlist" type="xs:string"/>

   <!--
    | Values for the Expectation.priority attributes
    ====================================================================
    ===  Application and OperatingSystem class                       ===
    ====================================================================
    -->
     <xs:complexType name="SoftwareType">
       <xs:sequence>
         <xs:element ref="iodef:url" minOccurs="0"/>
       </xs:sequence>
       <xs:attribute name="swid" type="xs:string" default="0"/>
       <xs:attribute name="configid" type="xs:string" default="0"/>
       <xs:attribute name="vendor" type="xs:string"/>
       <xs:attribute name="family" type="xs:string"/>
       <xs:attribute name="name" type="xs:string"/>
       <xs:attribute name="version" type="xs:string"/>
       <xs:attribute name="patch" type="xs:string"/>
     </xs:complexType>


     <xs:element name="Application" type="iodef:SoftwareType" />
     <xs:element name="OperatingSystem" type="iodef:SoftwareType" />
   <!--
    ====================================================================
    ===  Counter class                                              ===
    ====================================================================
    -->
     <xs:element name="Counter">
       <xs:complexType>
         <xs:attribute name="priority"> name="type">
           <xs:simpleType>
             <xs:restriction base="xs:NMTOKEN">
               <xs:enumeration value="low"/> value="packet"/>



Danyliw, et al.           Expires May 13, 2006                 [Page 72]

Internet-Draft              IODEF Data Model               November 2005


               <xs:enumeration value="medium"/> value="session"/>
               <xs:enumeration value="high"/> value="event"/>
               <xs:enumeration value="other"/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="meaning" type="xs:string" use="optional"/>
       </xs:complexType>
     </xs:element>
    <!--
    | Defines purpose of the Incident
    ====================================================================
    ===  Record class                                                ===
    ====================================================================
    -->
     <xs:element name="Record">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:RecordData" maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>
     <xs:element name="RecordData">
       <xs:complexType>
         <xs:sequence>
           <xs:element ref="iodef:DateTime" minOccurs="0"/>
           <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="iodef:Application" minOccurs="0"/>

           <xs:element ref="iodef:RecordPattern" minOccurs="0" maxOccurs="unbounded" />
           <xs:element ref="iodef:RecordItem"  maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute ref="iodef:restriction"/>
       </xs:complexType>
     </xs:element>


     <xs:element name="RecordPattern">
       <xs:complexType>
         <xs:simpleContent>
           <xs:extension base="xs:string">
             <xs:attribute name="purpose"> name="type" use="required">
               <xs:simpleType>
                 <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="traceback"/> base="xs:NMTOKEN">
                   <xs:enumeration value="mitigation"/> value="regex"/>
                   <xs:enumeration value="reporting"/> value="binary"/>
                   <xs:enumeration value="other"/> value="xpath"/>
                 </xs:restriction>



Danyliw, et al.           Expires May 13, 2006                 [Page 73]

Internet-Draft              IODEF Data Model               November 2005


               </xs:simpleType>
             </xs:attribute>
   <!--
    | Values for the Confidence.rating attribute.
    -->
             <xs:attribute name="rating"> 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="low"/>
           <xs:enumeration value="medium"/>
           <xs:enumeration value="high"/>
           <xs:enumeration value="numeric"/> value="line"/>
                   <xs:enumeration value="unknown"/> value="byte"/>
                 </xs:restriction>
               </xs:simpleType>
             </xs:attribute>
             <xs:attribute name="instance" type="xs:integer" use="optional" />
           </xs:extension>
         </xs:simpleContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="RecordItem" type="iodef:ExtensionType"/>
   <!--
    ====================================================================
    === Miscellaneous simple classes                                 ===
    ====================================================================
    -->

     <xs:element name="Description" type="iodef:MLStringType" />

     <xs:element name="name" type="xs:string"/>
     <xs:element name="url" type="xs:string"/>

   <!--
    ====================================================================
    === Complex Data Types                                           ===
    ====================================================================
    -->

    <xs:complexType name="MLStringType">
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute name="lang" type="xs:language"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

     <xs:complexType name="ExtensionType">
       <xs:simpleContent>
       <xs:extension base="xs:string">
         <xs:attribute name="type" use="required">
         <xs:simpleType>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 75] 74]

Internet-Draft              IODEF Data Model                 August               November 2005


   <!--
    | Values for the RegistryHandle.type attribute.
    -->
     <xs:attribute name="registrytype">
       <xs:simpleType>


           <xs:restriction base="xs:NMTOKEN">
             <xs:enumeration value="internic"/> value="boolean"/>
             <xs:enumeration value="apnic"/> value="byte"/>
             <xs:enumeration value="arin"/> value="character"/>
             <xs:enumeration value="lacnic"/> value="date-time"/>
             <xs:enumeration value="integer"/>
             <xs:enumeration value="ripencc"/> value="ntpstamp"/>
             <xs:enumeration value="ti"/> value="portlist"/>
             <xs:enumeration value="local"/> value="real"/>
             <xs:enumeration value="string"/>
             <xs:enumeration value="file"/>
             <xs:enumeration value="path"/>
             <xs:enumeration value="frame"/>
             <xs:enumeration value="packet"/>
             <xs:enumeration value="ipv4-packet"/>
             <xs:enumeration value="ipv6-packet"/>
             <xs:enumeration value="url"/>
             <xs:enumeration value="xml"/>
           </xs:restriction>
         </xs:simpleType>
         </xs:attribute>
         <xs:attribute name="meaning" type="xs:string"/>
         <xs:attribute name="formatid" type="xs:string"/>
         <xs:attribute ref="iodef:restriction"/>
       </xs:extension>
     </xs:simpleContent>

     </xs:complexType>

   <!--
    ====================================================================
    === Global attribute list declarations.                          ===
    ====================================================================
    -->

   <!--
    | Defines restriction @restriction: defines restrictions on access to an element's content
    -->
     <xs:attribute name="restriction">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="default"/>
           <xs:enumeration value="public"/>
           <xs:enumeration value="need-to-know"/>
           <xs:enumeration value="private"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>
   <!--
    | Values for the Impact.severity attribute.
    -->
     <xs:attribute name="severity">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="low"/>
           <xs:enumeration value="medium"/>
           <xs:enumeration value="high"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>
   <!--
    | Values for the System.spoofed attributes
    -->
     <xs:attribute name="spoofed">
       <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="unknown"/>



Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 76] 75]

Internet-Draft              IODEF Data Model                 August               November 2005


           <xs:enumeration value="yes"/>
           <xs:enumeration value="no"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:attribute>


    <!--
     | Values for @severity: conveys the System.category attribute severity or priority of something
     -->
    <xs:attribute name="systemcat"> name="severity">
      <xs:simpleType>
         <xs:restriction base="xs:NMTOKEN">
           <xs:enumeration value="source"/> value="low"/>
           <xs:enumeration value="target"/> value="medium"/>
           <xs:enumeration value="intermediate"/> value="high"/>
         </xs:restriction>
      </xs:simpleType>
    </xs:attribute>

   </xs:schema>





































Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 77] 76]

Internet-Draft              IODEF Data Model                 August               November 2005


9.  Security considerations

   Due to the sensitive nature of some of the data that might be
   represented in the IODEF, the integrity, confidentiality, and non-
   repudiation of these documents in transit SHOULD be ensured.
   Although this protection can be provided by the transport mechanism,
   applying this security to the IODEF document itself is RECOMMENDED.

   When used, the applied protective measures MUST use cryptographic
   techniques.  XML Digital Signatures [14] MUST be used for ensuring
   integrity and non-repudiation, while XML Encryption [15] MUST be used
   to ensure the confidentiality of an IODEF document.  Examples using
   signatures and encryption on an IODEF document can be found in
   Section 7:

   o  IODEF-Document with XML signature (Section 7.2)

   o  IODEF-Document encrypted using XML encryption (Section 7.3)

   o  IODEF-Document encrypted and signed using XML signature &
      encryption (Section 7.4)

   Additional information on applying XML Digital Signatures and XML
   Encryption to an IODEF document can be found in the IODEF
   Implementation Guide [18].


























Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 78] 77]

Internet-Draft              IODEF Data Model                 August               November 2005


10.  IANA considerations

   Must be written
















































Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 79] 78]

Internet-Draft              IODEF Data Model                 August               November 2005


11.  Acknowledgments

   The following groups contributed substantially to this document and
   should be recognized for their efforts.

   o  the Incident Object Description and Exchange Format Working-Group
      of the TERENA task-force (TF-CSIRT)

   o  the eCSIRT.net project










































Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 80] 79]

Internet-Draft              IODEF Data Model                 August               November 2005


12.  References

12.1  Normative References

   [1]   Demchenko, Y., Hiroyuki, H., and G. Keeni, "Requirements for
         Format for Incident Report Exchange", RFC XXX, November 2004.

   [2]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0 (Second Edition)", W3C Recommendation , October 2000,
         <http://www.w3.org/TR/2000/REC-xml-20001006>.

   [3]   World Wide Web Consortium, "Namespaces in XML", W3C
         Recommendation , January 1999,
         <http://www.w3.org/TR/REC-xml-names/>.

   [4]   World Wide Web Consortium, "Extensible Stylesheet Language
         (XSL) Version 1.0", W3C Recommendation , October 2001,
         <http://www.w3.org/TR/xsl/>.

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

   [6]   Alvestrand, H., "Tags for the Identification of Languages",
         RFC 3066, January 2001.

   [7]   Curry, D. and H. Debar, "Intrusion Detection Message Exchange
         Format", RFC XXX, July 2004.

   [8]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [9]   Freed, N., "IANA Charset Registration Procedures", BCP 2278,
         January 1998.

   [10]  Wahl, M., "A Summary of the X.500(96) User Schema for use with
         LDAPv3", RFC 2256, December 1997.

   [11]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [12]  Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

   [13]  International Organization for Standardization, "International
         Standard: Data elements and interchange formats - Information
         interchange - Representation of dates and times", ISO 8601,
         Second Edition, December 2000.




Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 81] 80]

Internet-Draft              IODEF Data Model                 August               November 2005


   [14]  Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup
         Language) XML-Signature Syntax and Processing", RFC 3275,
         March 2002.

   [15]  Imamura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax
         and Processing, W3C Recommendation", December 2002,
         <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.

   [16]  International Organization for Standardization, "International
         Standard: Codes for the representation of currencies and funds,
         ISO 4217:2001", ISO 4217:2001, August 2001.

12.2  Informative References

   [17]  Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling
         Language Reference Model, ISBN 020130998X, Addison-Wesley",
         1998.

   [18]  Danyliw, R., "The IODEF Implementation Guide", RFC XXX, 2003.


Authors' Addresses

   Roman Danyliw
   CERT Coordination Center
   4500 Fifth Ave.
   Pittsburgh, PA  15213
   Pittsburgh
   USA

   Phone: +1 412 268 7090

   Email: rdd@cert.org


   Jan Meijer
   SURFnet bv
   P.O. Box 19035
   Utrecht  NL-3501 DA
   Netherlands

   Phone: +31 302 305 305

   Email: jan.meijer@surfnet.nl










Danyliw, et al.         Expires February 3, 2006               [Page 82]

Internet-Draft              IODEF Data Model                 August 2005


   Yuri Demchenko
   University of Amsterdam
   Netherlands

   Email: demch@chello.nl







Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 83] 81]

Internet-Draft              IODEF Data Model                 August               November 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.





Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 84] 82]

Internet-Draft              IODEF Data Model                 August               November 2005


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Danyliw, et al.           Expires February 3, May 13, 2006                 [Page 85] 83]

----