view Side-By-Side changes

NetworkINCH Working Group                                             J. Meijer
Internet-Draft
Draft-ietf-inch-iodef-03.txt                                  SURFnet bv
Expires: March 29, 2004 May 10, 2005                                         R. Danyliw
                                                CERT Coordination Center
                                                            Y. Demchenko
                                                              NLnet Labs
                                                      September 29, 2003
                                                        November 9, 2004



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


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed, or
   will be disclosed, and any of which I become aware will be disclosed,
   in accordance with RFC 3668.


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.


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


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


   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.
   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 March 29, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved. May 10, 2005.


Abstract


   The purpose of the Incident Data Object Description Exchange Format
   (IODEF) is to define a data formats representation that provides a framework
   for sharing information related to computer security incidents
   typically commonly exchanged between collaborating by Computer Security
   Incident Response Teams (CSIRTs). (CSIRTs) about computer security incidents.
   The IODEF satisfies the requirements specified in  RFCXXX [1]


   This Internet-Draft describes a data model for representing commonly
   exchanged incident




Meijer, et al.            Expires May 10, 2005                  [Page 1]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   information exported from incident handling systems managed by
   CSIRTs.  An implementation of the data model in



Meijer, et al.           Expires March 29, 2004                 [Page 1]

Internet-Draft    IODEF Data Model and Implementation     September 2003 the Extensible Markup
   Language (XML) is presented, an XML Document Type Definition is
   developed, and examples are provided.


Table of Contents


   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1  Terminology  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3  About the IODEF Data Model . . . . . . . . . . . . . . . .   4
   1.3.1  Issues with Representing Incident Data
     1.4  About the IODEF Implementation . . . . . . . . . . . . . .   5
   1.4
     1.5  About the IODEF Implementation Transport Protocol . . . . . . . . . . . . . . .   6
   1.5
     1.6  Related Work . . . . . . . . . . . . . . . . . . . . . . .   6
   2.     Notational conventions and formatting issues   Formatting Issues  . . . . . . . . . . . . . . . . . . . . .   8
     2.1  IODEF XML Documents  . . . . . . . . . . . . . . . . . . .   8
       2.1.1  The Document Prolog  . . . . . . . . . . . . . . . . . . .   8
       2.1.2  Character Data  White Space Processing in the IODEF . . . . . . . . . . . . . . . .   9
       2.1.3  Languages in the IODEF . . . . . . . . . . . . . . . . . .  10   9
     2.2  IODEF Data Types . . . . . . . . . . . . . . . . . . . . .  11   9
       2.2.1  Integers . . . . . . . . . . . . . . . . . . . . . . . . .  11  10
       2.2.2  Real Numbers . . . . . . . . . . . . . . . . . . . . . . .  11  10
       2.2.3  Characters and Strings . . . . . . . . . . . . . . . . . .  11  10
       2.2.4  Bytes  . . . . . . . . . . . . . . . . . . . . . . . . . .  12  10
       2.2.5  Enumerated Types . . . . . . . . . . . . . . . . . . . . .  12  10
       2.2.6  Date-Time Strings  . . . . . . . . . . . . . . . . . . . .  12  11
       2.2.7  NTP Timestamps  Port Lists . . . . . . . . . . . . . . . . . . . . . .  12  11
       2.2.8  Port Lists . . . .  Postal Address . . . . . . . . . . . . . . . . . . . .  12  11
       2.2.9  Postal Address . . . . . .  Person or Organization . . . . . . . . . . . . . . . .  12  11
       2.2.10 Person or Organization . . . . .   Telephone and Fax Numbers  . . . . . . . . . . . . .  13  11
       2.2.11 Telephone and Fax Numbers  . . . .   Email string . . . . . . . . . . . .  13
   2.2.12 Email string . . . . . . . .  11
       2.2.12   Uniform Resource Identifier strings  . . . . . . . .  11
       2.2.13   Timezone string  . . . . . . .  13
   2.2.13 Uniform Resource Identifier strings . . . . . . . . . . .  13  12
       2.2.14   Unique Identifiers . . . . . . . . . . . . . . . . . . . .  13  12
   3.   The IODEF Data Model . . . . . . . . . . . . . . . . . . .  14 .  13
     3.1  IODEF-Document class . . . . . . . . . . . . . . . . . . .  14  13
     3.2  Incident class . . . . . . . . . . . . . . . . . . . . . .  14  13
     3.3  IncidentID class . . . . . . . . . . . . . . . . . . . . .  17  16
     3.4  AlternativeID class  . . . . . . . . . . . . . . . . . . .  17
     3.5  RelatedActivity class  . . . . . . . . . . . . . . . . . .  18
     3.6  AdditionalData . . . . . . . . . . . . . . . . . . . . . .  19  18
     3.7    IncidentData . . . . . . . . . . . . . . . . . . . . . . .  20
   3.8  Contact class  . . . . . . . . . . . . . . . . . . . . . .  22
   3.8.1  20
       3.7.1  RegistryHandle class . . . . . . . . . . . . . . . . . . .  25
   3.9  22
     3.8  Time classes . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.1  23
       3.8.1  StartTime  . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.2  23
       3.8.2  EndTime  . . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.3  23
       3.8.3  DetectTime . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.4  23
       3.8.4  ReportTime . . . . . . . . . . . . . . . . . . . . . . . .  27
   3.9.5  DateTime . . . . . . . . . . . . . . . . . . . . . . . . .  27  23




Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 2]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   3.10   Expectation class      November 2004



       3.8.5  DateTime . . . . . . . . . . . . . . . . . . . .  27
   3.11   Method class . . .  23
     3.9  Expectation class  . . . . . . . . . . . . . . . . . . . .  28
   3.11.1 Classification  23
     3.10   Method class . . . . . . . . . . . . . . . . . . .  29
   3.12   Assessment class . . . . .  25
       3.10.1   Classification class . . . . . . . . . . . . . . . .  30
   3.12.1 Impact  26
     3.11   Assessment class . . . . . . . . . . . . . . . . . . . . . . .  31
   3.12.2 TimeImpact  27
       3.11.1   Impact class . . . . . . . . . . . . . . . . . . . . .  33
   3.12.3 MonetaryImpact  28
       3.11.2   TimeImpact class . . . . . . . . . . . . . . . . . . .  34
   3.12.4 LifeImpact  28
       3.11.3   MonetaryImpact class . . . . . . . . . . . . . . . . . . . . .  35
   3.12.5  29
       3.11.4   Confidence class . . . . . . . . . . . . . . . . . . . . .  36
   3.13  30
     3.12   History class  . . . . . . . . . . . . . . . . . . . . . .  38
   3.13.1  30
       3.12.1   HistoryItem class  . . . . . . . . . . . . . . . . . . . .  38
   3.14  31
     3.13   EventData class  . . . . . . . . . . . . . . . . . . . . .  40
   3.15  33
       3.13.1   Relating the IncidentData Incident and EventData classes  . . . . .  42
   3.16  34
       3.13.2   Cardinality of EventData . . . . . . . . . . . . . .  35
     3.14   Flow class . . .  43
   3.17   System class . . . . . . . . . . . . . . . . . . . .  36
     3.15   System class . . . .  44
   3.18   Node class . . . . . . . . . . . . . . . . . .  36
     3.16   Node class . . . . . .  46
   3.18.1 Address . . . . . . . . . . . . . . . . .  38
       3.16.1   Counter class  . . . . . . . .  48
   3.18.2 NodeRole class . . . . . . . . . . .  40
       3.16.2   Address  . . . . . . . . . . .  48
   3.19   FileList class . . . . . . . . . . .  40
       3.16.3   NodeRole class . . . . . . . . . . .  50
   3.20   User . . . . . . . .  42
     3.17   Process class  . . . . . . . . . . . . . . . . . . .  50
   3.21   Process . .  43
     3.18   Service class  . . . . . . . . . . . . . . . . . . . . .  43
     3.19   Record class . .  50
   3.22   Service . . . . . . . . . . . . . . . . . . . .  44
       3.19.1   RecordData class . . . . .  50
   3.23   Record class . . . . . . . . . . . . .  45
       3.19.2   Analyzer class . . . . . . . . . . . . .  50
   3.23.1 RecordData class . . . . . .  46
       3.19.3   RecordItem class . . . . . . . . . . . . . . .  51 . . .  46
   4.   Extending the IODEF  . . . . . . . . . . . . . . . . . . .  55 .  48
     4.1  Extending the data model . . . . . . . . . . . . . . . . .  55  48
     4.2  Extending the XML DTD  . . . . . . . . . . . . . . . . . .  55  48
   5.   Processing Considerations  . . . . . . . . . . . . . . . .  58
   5.1    XML Validity and Well-Formedness .  51
   6.   Internationalization issues  . . . . . . . . . . . .  58
   5.2    Unrecognized Data and XML Tags . . . . . . . . . . . . . .  58
   6.     Internationalization issues  . . . . . . . . . . . . . . .  60  52
   7.   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  61 .  53
     7.1  Code Red detection notification  . . . . . . . . . . . . .  61  53
     7.2  IODEF-Document with XML signature  . . . . . . . . . . . .  63  55
     7.3  IODEF-Document encrypted using XML encryption  . . . . . .  63  55
     7.4  IODEF-Document encrypted and signed using XML signature
          & encryption . . . . . . . . . . . . . . . . . . . . . . .  63  55
   8.   The IODEF Document Type Definition . . . . . . . . . . . .  64 .  56
   9.   Security considerations  . . . . . . . . . . . . . . . . .  78 .  67
   10.  IANA considerations  . . . . . . . . . . . . . . . . . . .  79 .  68
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  80 .  69
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  70
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  81  70
   12.2   Informative References . . . . . . . . . . . . . . . . . .  83  71
        Authors' Addresses . . . . . . . . . . . . . . . . . . . .  83 .  71
        Intellectual Property and Copyright Statements . . . . . .  84 .  72






Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 3]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



1.  Introduction


1.1  Terminology


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


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


1.2  Overview


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


   The development
   and subsequent deployment overriding purpose of an incident data format that extends
   beyond a closed communities would improve the IODEF is to expand and enhance the
   operational capabilities of the CSIRTs.

   Assuming widespread  Community adoption of the IODEF by the community,
   provides an
   organization can potentially benefit from:

   o  the increased ease to collaborate with other CSIRTs, on behalf it
      its constituency, improved ability to resolve incidents; incidents by simplifying
   collaboration and data sharing.  This structured format provided by
   the IODEF allows for:


   o  increased automation in the processing of incident data, since the
      commitment
      resources of security analysts to parse free-form textual
      document
      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 inter-operable interoperable tools for incident
      handling, such as correlation systems that process data from
      different sites.


   Terminology, notation, and conventions of the data model and XML DTD
   are presented in Sections 2.  The data model is described in Section
   3, and the implementation considerations are covered in Sections 4
   through 6, and 9. 6.  Section 7 provides several examples of IODEF
   documents for representative incidents. documents.
   Section 8 formally specifies the XML DTD 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 an object-oriented a data representation of that provides a
   framework for sharing information reported, maintained, and commonly exchanged by a CSIRT CSIRTs about a




Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 4]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



   computer security incident.

1.3.1 Issues with Representing Incident Data incidents.  A number of considerations were made in
   the design of the data model.


   o  The IODEF intent of the data model addresses several problems in representing 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 data: report generation, this model is sufficiently
      complex that it will be unwieldy to create and process without
      software.


   o  There  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.  Therefore,
      incident, the data model does not attempt to imply a
      definition dictate one through
      its implementation.  Rather, a broad understanding is assumed that
      is flexible enough to encompass most of the CSIRT community.


   o  Incident data is inherently heterogeneous.  It may encompass many
      functional purposes  such as a description of intruder behavior or  Describing an analysis process correlating related incidents.
      An object-oriented model provides extensibility via aggregation
      and sub-classing while preserving the consistency of the incident for all definitions would require an
      incredibly complex data model.
      If  Therefore, the IODEF data model required modification,
      only intends to be a framework to convey commonly exchanged
      incident information.  However, it is extended with new
      classes.  In implementations ensures that do not recognize these
      extensions, the basic subset there are ample
      mechanisms for extensibility to support organization-specific
      information, and techniques to reference information kept outside
      of the explicit data model will still be
      understood. model.


   o  Incidents have a life-cycle, which causes potentially different
      information or levels of life-cycle that dictates the exact type,
      quantity, and detail to of the data that will be present depending on their
      stage in the cycle.  For example, at a given
      time (e.g., newly reported incidents may only contain a short description of the involved parties.  On the
      other hand, most
      rudimentary details, but closed incidents can may contain a full description
      complete with the associated evidence and annotation of actions
      taken by the CSIRT. detailed
      analysis).  The data model that represents deals with this
      information must be flexible to accommodate different needs. situation.


   o  Communication and coordination are central to the role of a CSIRT.
      As a result of this activity, incident information can originate
      from a number of sources.  Tracking the all
      Hence, tracking the sources source of all data is
      key to managing this information.
      The data model defines support classes that accommodate the
      differences between incident reporters. This support includes
      various meta information central to represent handling the reporter's identity as
      well as prescribe a confidence level to
      incident.  Therefore, the submitted information.

   o  Incident data may contain sensitive information. Such model provides ways to explicitly
      bind information
      should not be exposed to unauthorized parties during
      collaboration.
      The data model allows for a granular tagging source, and accommodates differences in the individual
      classes to indication restrictions on the usage of the data.
      However, it is the role
      types of parties involved in the incident handling system
      implementing the (e.g., varying levels of
      confidence in information, different data model to honor these labels.



Meijer, et al.           Expires March 29, 2004                 [Page 5]

Internet-Draft    IODEF Data Model and Implementation     September 2003 sharing arrangements).



1.4  About the IODEF Implementation


   The IODEF implementation uses the Extensible Markup Language (XML)
   [2].  XML-based specifications define
   [2], specifies an XML DTD or Schema Document Type Definition (DTD), and
   register a specific XML namespace [3]. The IODEF conforms to the
   IETF-defined procedure for registering registers
   an application-specific XML namespace [9]. [3].


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




Meijer, et al.            Expires May 10, 2005                  [Page 5]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   will be used when speaking in the general case about 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 DTD.  Furthermore,  Finally, the terms "class" and "subclass" are synonymous to will be
   used as synonyms for an element in the XML DTD. element.


   The implementation of choice to implement the IODEF in XML has many benefits: was made because it
   provides:


   o  XML provides  all the necessary features to define and extend a specific markup
      language for describing security incidents. It also defines
      a standard way to extend this language, either for later revisions
      ("standard" extensions), or for organizational-specific use
      ("non-standard" extensions). incidents;


   o  Software tools  a well understood technique for processing XML documents are widely available
      in commercial supporting internationalization
      and open source forms. localization;


   o  XML can  a base of related technologies such as XSL [4], XPATH, and XML-SIG
      that the aid in implementing internationalization and localization
      since it is required (and therefore IODEF documents are required)
      to support both the UTF-8 manipulation and UTF-16 encodings use of ISO/IEC 10646
      (Universal Multiple-Octet Coded Character Set, "UCS") the incident data; and Unicode.


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


   While XML also provides support for specifying, on a per-element basis,
      the useful implementation language in which the element's content for IODEF, this
   implementation also dictates several limitations.


   o  XML is written, 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 easy to adapt
      for other purposes.  Due to the local languages in which a CSIRTs
      operates.

   o overhead of the parser, XML coupled with XSL [4], a style language, allows IODEF documents
      to be aggregated, filtered, discarded, is not
      an optimal in-memory representation.  Furthermore, storing,
      searching, and rearranged.

   o retrieving native XML documents is free (no license, license fees or royalties).


1.5 Related Work

   The IODEF problematic on a
      large scale dictating that this format is also a poor choice as a
      storage and archive format.



1.5  About the IDMEF [7] are complementary formats. Transport Protocol


   Currently, there is no transport protocol specified for exchanging
   IODEF documents.  The latter
   represents data generated by working group has realized that this omission
   is an intrusion detection system.  Such
   event data inpediment to interoperability, and is commonly working on identifying
   candidate protocols.  It is likely that SOAP will be used by a CSIRT as the basis for an incident
   report or investigation which is represented by
   messaging envelope, and HTTP will be the IODEF. underlying transport.


1.6  Related Work


   The IODEF is only one of several security relevant data




Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 6]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   The IODEF data model makes use of certain classes defined in the
   IDMEF, although      November 2004



   representations being standardized.  Specifically, the semantics of some complementary
   nature of these classes has changed.
   Due to their related nature, the data in an IDMEF message can be
   easily Intrusion Detection Message Exchange Format [7] bears
   mention given that many incidents represented in an IODEF document.  Through various extension
   mechanisms, it is possible to include IDMEF messages outright in an the IODEF document.  Alternatively, may have
   first been discovered through the similarity in structure use of intrusion detection system
   output formatted according to the IDMEF.  Given this relationship,
   the IODEF data model makes it possible to decompose use of certain classes defined in the key
   IDMEF data and
   include it in the corresponding IODEF classes.  However, this
   transformation may not preserve the original semantics of the data. model.













































Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 7]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



2. Notational conventions and formatting issues  Formatting Issues


2.1  IODEF XML Documents


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


   This section describes the XML notations and conventions used in this
   memo
   document and explains particular issues related to using them to
   describe the IODEF data model and syntax.  For readers unfamiliar
   with these notations [19] [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 starts MUST begin with an XML declaration. The XML
   declaration specifies declaration, and MUST
   specify the version of XML being version used.  If UTF-8 encoded is not used, and optionally the
   character encoding being used (see Section 2.1.2). MUST also be explicitly specified.


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


   <?xml version="1.0" ?>

   IODEF documents exchanged between applications MUST begin with an


   When a character encoding is specified, the XML declaration and MUST specify will read
   like the XML version in use. Specification following:


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


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


   Consistent with the XML standard, if UTF-8 no encoding is not used. 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 DTD Formal Public Identifier


   The formal public identifier (FPI) for the IODEF Document Type




Meijer, et al.            Expires May 10, 2005                  [Page 8]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   Definition described in this document is:


        "-//IETF//DTD RFCxxxx IODEF v0.0//EN"


   NOTE: The "RFCxxxx" text in the FPI value will be replaced with the
   actual RFC number when this document is published as an RFC.


   This FPI MUST be used in the document type declaration within an XML
   document referencing the IODEF DTD defined by this document, as shown in Section 2.1.1.3.



Meijer, et al.           Expires March 29, 2004                 [Page 8]

Internet-Draft    IODEF Data Model and Implementation     September 2003


2.1.1.3  IODEF DTD Document Type Declaration


   The document type declaration for an XML document referencing the
   IODEF DTD will MUST be specified in either by referencing the following ways: FPI (see
   Section 2.1.1.2) as follows:


    <!DOCTYPE IODEF-Document PUBLIC "-//IETF//DTD RFCxxxx IODEF v0.0//EN">

    The last component of the document type declaration is the FPI
   specified in Section 2.1.1.2.

    <!DOCTYPE IODEF-Document SYSTEM "/path/to/IODEF-Document.dtd">

    The last component of the document type declaration is


    or by providing a URI that
   points to references a copy of the Document Type Definition. DTD as follows:


    <!DOCTYPE IODEF-Document SYSTEM "/path/to/IODEF-Document.dtd">



2.1.2 Character Data  White Space Processing in the


   All IODEF

   A document's XML declaration specifies elements support the character encoding "xml:space" attribute.  If "xml:space"
   is set to be
   used "preserve," the IODEF processing application MUST treat all
   white space in the document, element's content as follows:

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

   where "charset" significant.  If "xml:space"
   is set to "default," the name application is free to decide on the
   handling of the character encoding, as registered
   with whitepace.


2.1.3  Languages in the Internet Assigned Numbers Authority (IANA), see [9].

   The XML standard requires IODEF


   For the IODEF elements that XML processors support free-form text, the UTF-8 and
   UTF-16 encodings of ISO/IEC 10646 (UCS) and Unicode, making all XML
   applications (and therefore, all IODEF-compliant applications)
   compatible with these common character encodings.

   While XML supports other character encodings (e.g., UTF-7, UTF-32),
   implementers should carefully consider "xml:lang"
   attribute can be used to identify the portability implications language of using character encodings other than UTF-8 and UTF-16.

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

2.1.2.1 Character Entity References

   Within XML documents, certain characters have special meanings in
   some contexts.  To include
   RFC 3066 [6].


   IODEF messages SHOULD specify the actual character itself language in one of
   these contexts, a special escape sequence, called an entity
   reference, must which their contents
   are encoded.  In general, the language can be used.

   The characters specified with the
   "xml:lang" attribute in the top-level element and letting all other
   elements "inherit" that sometimes need to definition.


   If no language is specified, English SHOULD be escaped, and their entity assumed.


2.2  IODEF Data Types


   The IODEF data model defines a number of data types.




Meijer, et al.            Expires March 29, 2004 May 10, 2005                  [Page 9]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   references, are:

               Character        Entity Reference
               ---------------------------------
               &                 &amp;
               <                 &lt;
               >                 &gt;
               "                 &quot;
               '                 &apos;

                                Figure 1

   It is RECOMMENDED that IODEF-compliant applications use the entity
   reference form whenever writing these characters in data, to avoid
   any possibility of misinterpretation.

2.1.2.2 Character Code References

   Any character defined      November 2004



2.2.1  Integers


   Integer attributes are represented by the ISO/IEC 10646 and Unicode standards may INTEGER data type.  Integer
   data MUST be included encoded in an XML document by the use of a character reference. A
   character reference is started with Base 10 or Base 16.


   Base 10 integer encoding uses the characters '&' and '#', and
   ended with the character ';'.  Between these characters, the
   character code for the character inserted.

   If the character code is preceded by an 'x' it is interpreted in
   hexadecimal (base 16), otherwise, it is interpreted in decimal (base
   10).  For instance, the ampersand (&) is encoded as &#38; or &#x0026;
   and the less-than sign (<) is encoded as &#60; or &#x003C;.

   Any one-, two-, or four-byte character specified in the ISO/IEC 10646
   and Unicode standards can be included in a document using this
   technique.

2.1.2.3 White Space Processing

   All IODEF elements support the "xml:space" attribute. If "xml:space"
   is set to "preserve," the IODEF processing application MUST treat all
   white space in the element's content as significant.  If "xml:space"
   is "default," the application is free to do whatever it normally
   would with white space in the element's content.

2.1.3 Languages in the IODEF

   All IODEF tags support the "xml:lang" attribute thereby allowing each
   element to identify the language in which its content is.  The valid
   language code for the "xml:lang" attribute are described in RFC 3066
   [6].




Meijer, et al.           Expires March 29, 2004                [Page 10]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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

   If no language is specified in an IODEF document, English SHOULD be
   assumed.

2.2 IODEF Data Types

2.2.1 Integers

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

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


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


2.2.2  Real Numbers


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


   Real encoding is that of the POSIX "strtod" library function: an
   optional sign ('+' or '-') followed by a non-empty string of decimal
   digits, optionally containing a radix character, then an optional
   exponent part.  An exponent part consists of an 'e' or 'E', followed
   by an optional sign, followed by one or more decimal digits.  For
   example, "123.45e02", "-567,89e-03".


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


2.2.3  Characters and Strings


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


   Character and string data have no special formatting requirements,
   other than the need to occasionally use character references (see
   Section 2.1.2.1 and Section 2.1.2.2) to
   represent special characters.





Meijer, et al.           Expires March 29, 2004                [Page 11]

Internet-Draft    IODEF Data Model and Implementation     September 2003


2.2.4  Bytes


   Binary data is represented by the BYTE (and BYTE[]) data type.


   Binary data MUST be encoded in its entirety using character code
   references (see ).


2.2.5  Enumerated Types


   Enumerated types are represented by the ENUM data type, and consist
   of an ordered list of acceptable values.  Each value has a




Meijer, et al.            Expires May 10, 2005                 [Page 10]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   representative keyword.  Within an IODEF document, DTD, the enumerated type
   keywords are used as attribute values values.


2.2.6  Date-Time Strings


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


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


2.2.7 NTP Timestamps

   NTP timestamps are represented by the NTPSTAMP data type, and are
   described in detail in RFC 1305 [10] and RFC 2030 [11].  An NTP
   timestamp is a 64-bit unsigned fixed-point number.  The integer part
   is in the first 32 bits, and the fraction part is in the last 32
   bits.

   IODEF documents MUST encode NTP timestamps as two 32-bit hexadecimal
   values, separated by a period ('.'). For example,
   "0x12345678.0x87654321".

2.2.8  Port Lists


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

2.2.9


2.2.8  Postal Address


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



Meijer, et al.           Expires March 29, 2004                [Page 12]

Internet-Draft    IODEF Data Model and Implementation     September 2003


2.2.10 [10].


2.2.9  Person or Organization


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

2.2.11 [10].


2.2.10  Telephone and Fax Numbers


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

2.2.12
   [10].


2.2.11  Email string


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

2.2.13 [11]


2.2.12  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].





Meijer, et al.            Expires May 10, 2005                 [Page 11]



Internet-Draft    IODEF Data Model and Implementation      November 2004



2.2.13  Timezone string


   A timezone is represented by the TIMEZONE data type.  Its format is
   yet to be specified.


2.2.14  Unique Identifiers


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









































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 13] 12]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



3.  The IODEF Data Model


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


3.1  IODEF-Document class


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



   +-----------------+
   | IODEF-Document  |
   +-----------------+
   | STRING version  |<>--{1..*}--[ Incident ]
   |                 |
   +-----------------+


                     Figure 2: 1: IODEF-Document class


   The aggregate class that constitutes IODEF-Document is:


   Incident
      One.
      One or more.  The Incident class contains all the incident-related
      information. information related to a single incident.


   The IODEF-Document class has one attribute:


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



3.2  Incident class

   In each exchange of


   Every incident related data this data 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.











Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 14] 13]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



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


                      Figure 3: 2: the Incident class


   The aggregate classes that constitute Incident are:


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


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


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

   IncidentData


   Description
      Zero or more.  The event(s) that constitute the incident about
      which  STRING.  A free-form textual description of the IODEF-Document conveys information.

   AdditionalData
      incident.


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


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






Meijer, et al.            Expires May 10, 2005                 [Page 14]



Internet-Draft    IODEF Data Model and Implementation      November 2004



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


   StartTime
      Zero or one.  The time the incident started.


   EndTime
      Zero or one.  The time the incident ended.


   ReportTime
      One.  The time the incident was reported.


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


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


   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 attributes:


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


      1.  handling.  The IODEF-Document document was sent for incident-handling
          purposes;


      2.  statistics.  The IODEF-Document document was sent to be included in a



Meijer, et al.           Expires March 29, 2004                [Page 15]

Internet-Draft    IODEF Data Model and Implementation     September 2003
          data-repository for statistical purposes;


      3.  warning.  The IODEF-Document document was sent as a warning;


      4.  other.  The IODEF-Document document was sent for purposes specified in the
          Expectation element.




Meijer, et al.            Expires May 10, 2005                 [Page 15]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   restriction
      Optional.  ENUM.  This attribute indicates the disclosure
      guidelines to which the sender expects the recipient of the
      IODEF-Document to adhere. However,  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
      tighten 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:


      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 used, no default is specified.


      1.  public.  There is are no restriction level applied to 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.





Meijer, et al.           Expires March 29, 2004                [Page 16]

Internet-Draft    IODEF Data Model and Implementation     September 2003




3.3  IncidentID class


   The IncidentID class represents an incident tracking number (UID)
   that is unique in the context of the CSIRT and identifies the
   activity characterized in an IODEF-Document.





Meijer, et al.            Expires May 10, 2005                 [Page 16]



Internet-Draft    IODEF Data Model and Implementation      November 2004



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


                     Figure 4: 3: the IncidentID class


   The IncidentID class has one attribute:


   name
      Required.  GUID.  An identifier for the CSIRT that created the
      IODEF-Document.

   An implementation strategy for the GUID name attribute would be to
   use global or regional CSIRT registries such as FIRST or the European
   Trusted Introducer.



3.4  AlternativeID class


   The AlternativeID class references lists the incident tracking numbers or
   unique identifiers used by
   other entities (e.g., CSIRTs) CSIRTs to refer to activity identical to that characterized described in this IODEF-Document. IODEF document.
   Thus, a tracking numbers number listed as an AlternativeID are references the
   same events incident detected by another CSIRT, but seem from a different perspective.  It
   follows, the CSIRT.  The incident tracking
   numbers of the organization CSIRT that generated the IODEF-Document IODEF document should never
   be considered an AlternativeID.

   If the incident is not the identical activity, but is related (e.g.,
   same methodology or intruder), then its incident tracking number
   should instead be represented in the RelatedActivity (Section 3.5)
   class.










Meijer, et al.           Expires March 29, 2004                [Page 17]

Internet-Draft    IODEF Data Model and Implementation     September 2003



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



                   Figure 5: 4: the AlternativeID class


   The aggregate classes class that constitute constitutes AlternativeID are: is:


   IncidentID
      One or more.  Unique identifiers assigned by  The incident tracking number of another entity for
      the identical activity characterized in the IODEF-Document. CSIRT.


   The AlternativeID class has one attribute:


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






Meijer, et al.            Expires May 10, 2005                 [Page 17]



Internet-Draft    IODEF Data Model and Implementation      November 2004



3.5  RelatedActivity class


   The RelatedActivity class references lists the incident tracking numbers or
   unique identifiers 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 6: 5: RelatedActivity class


   The aggregate classes class that constitute constitutes RelatedActivity are: is:


   IncidentID
      One or more.  Unique identifiers assigned by the CSIRT.  The incident tracking number of a related incident.


   The RelatedActivity class has one attribute:



Meijer, et al.           Expires March 29, 2004                [Page 18]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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



3.6  AdditionalData


   The AdditionalData class serves as an extension mechanism for
   information not otherwise represented in the data model.  For
   relatively simple information, atomic data (integers, strings, etc.) types (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 DTD to
   support proprietary extensions by encapsulating entire XML documents
   conforming to another DTD (e.g., IDMEF).  A detailed discussion for
   extending the data model and the DTD can be found in Section 4.


   Unlike XML, which is self-describing, atomic data must typically be documented
   to convey its meaning.  This information is described in the
   'meaning' attribute.  Since these description are outside the scope
   of the specification, some additional coordination may be required to
   ensure that a recipient of a document using the AdditionalData
   classes can make sense of the custom extensions.




Meijer, et al.            Expires May 10, 2005                 [Page 18]



Internet-Draft    IODEF Data Model and Implementation      November 2004



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


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




Meijer, et al.           Expires March 29, 2004                [Page 19]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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


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


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


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


      6.   ntpstamp.  The element content is a NTP timestamp (see
           Section 2.2.7);

      7.  portlist.  The element content is a port list (see Section
           2.2.8);

      8.
          2.2.7);


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

      9.


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

      10.


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






Meijer, et al.            Expires May 10, 2005                 [Page 19]



Internet-Draft    IODEF Data Model and Implementation      November 2004



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



3.7 IncidentData  Contact class


   The IncidentData Contact class summarizes describes contact information for organizations and
   personnel involved in the details incident.  This class allows for the naming
   of the incident
   activity and a CSIRT's handling of involved party, specifying contact information for them, and
   identifying their role in the information, incident.


   People and organizations are treated interchangeably as well as,
   groups contacts; one
   can be associated with the security events that constitute other using the incident.

   Many recursive definition of
   the class (the Contact class is aggregated classes of IncidentData are also found in
   EventData, albeit with different occurrence indicators.  However, into the
   semantics of these classes is quite different. Contact class).
   The classes of
   IncidentData reflect information relevant across the entire incident,
   while 'type' attribute disambiguates the classes type of EventData provide contact information only relevant to
   the given event or system node
   being described.  The relationship
   between the IncidentData and EventData classes is complementary. The
   latter provides summary information, while the former provided.


   This recursive definition provides more
   specific details.  For example, the overall impact of a way to relate information
   without requiring the incident
   (represented in IncidentData) might be denial explicit use of service, but it
   might be worth mentioning that there were specific machines
   (represented identifiers in EventData) which also suffered a root compromise. In



Meijer, et al.           Expires March 29, 2004                [Page 20]

Internet-Draft    IODEF Data Model and Implementation     September 2003


   another the classes.
   For example, an organizational seperate contact can be provided in
   IncidentData class, while more specific contacts information for two individuals from
   the individual
   hosts can be in the EventData class.

   IncidentData also ensures that certain mandatory information will be
   present in same organization would not require duplicating the data model. organization
   information.



   +------------------+
   | IncidentData Contact          |
   +------------------+
   | ENUM restriction |<>--{0..*}--[ Description |<>--{0..1}--[ name           ]
   |                  |
   |                  |<>--{1..*}--[ Assessment ENUM role        |<>--{0..*}--[ Description    ]
   |                  |
   | ENUM type        |<>--{0..*}--[ Method RegistryHandle ]
   |                  |
   |                  |<>--{0..1}--[ DetectTime PostalAddress  ]
   |                  |
   |                  |<>--{0..1}--[ StartTime                  |<>--{0..*}--[ Email          ]
   |                  |
   |                  |<>--{0..1}--[ EndTime                  |<>--{0..*}--[ Telephone      ]
   |                  |
   |                  |<>----------[ ReportTime                  |<>--{0..1}--[ Fax            ]
   |                  |
   |                  |<>--{1..*}--[ Contact                  |<>--{0..1}--[ Timezone       ]
   |                  |
   |                  |<>--{0..*}--[ Expectation    ]
   |                  |
   |                  |<>--{0..1}--[ History        ]
   |                  |
   |                  |<>--{0..*}--[ EventData      ]
   |                  |
   |                  |<>--{0..*}--[ AdditionalData Contact        ]
   +------------------+


                      Figure 8: 7: the IncidentData Contact class


   The aggregate classes that constitute IncidentData the Contact class are:

   Description


   name
      Zero or more.  STRING.  A free-form textual description one.  NAME.  The name of the
      incident activity

   Assessment
      One contact.  The contact may
      either be an organization or more.  A characterization of the impact a person.  The type attribute
      disambiguates the incident
      activity. semantics.





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 21] 20]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   Method      November 2004



   Description
      Zero or more.  The techniques (e.g., tools, vulnerabilities) used
      by one.  STRING.  Free-form description of the intruder.

   DetectTime this contact.
      In the case of a person, this is often the organizational title of
      the individual.


   RegistryHandle
      Zero or one.  The time the incident activity was first detected.

   StartTime many.  A handle name in a registry.


   PostalAddress
      Zero or one.  POSTAL.  The time postal address of the incident activity started.

   EndTime contact formatted
      according to Section 2.2.8.


   Email
      Zero or one.  The time the incident activity ended.

   ReportTime
      One. many.  EMAIL.  The time the incident activity was reported.

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

   Expectation contact formatted
      according to Section 2.2.11.


   Telephone
      Zero or more.  Expected action to be performed by the recipient many.  PHONE.  The telephone number of the document.

   History contact
      formatted according to Section 2.2.10.


   Fax
      Zero or one.  Documents significant events or actions that
      occurred during the course  PHONE.  The facsimile telephone number of handling the incident.

   EventData
      contact formatted according to Section 2.2.10.


   Timezone
      Zero or more.  Details on the Data on one.  TIMEZONE.  The timezone in which the (security) events that
      lead contact resides
      formatted according to the incident.

   AdditionalData Section 2.2.13.


   Contact
      Zero or more.  An area to extend many.  Recursive definition of Contact allowing for the data model with information
      that can not be represented elsewhere.

   The IncidentData
      grouping of information.


   The Contact class has one attribute: three attributes:


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


3.8 Contact class

   The Contact class describes contact information for organizations and
   personnel involved in


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


      1.  creator.  The entity that generate the involved party, specifying IODEF document.


      2.  admin.  An administrative contact information to reach them, and
   identifying their role for a host or network.


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


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




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 22] 21]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   People and organizations are treated interchangeably as contacts; one
   can      November 2004



      5.  cc.  An entity that is to be associated with the other using kept informed about the recursive definition handling
          of the class. The 'type' attribute determines incident.


   type
      Required.  ENUM.  Indicates the type of contact
   information being provided.

   The recursive definition of this described.
      This attribute is defined as an enumerated list:


      1.  person.


      2.  organization.



3.7.1  RegistryHandle class (the Contact


   The RegistryHandle class is
   aggregated into the Contact class) provides represents a way handle to relate
   information without requiring the explicit use an Internet registry
   or community-specific database.  A handle consists of identifiers a name
   specified in the
   classes.  When grouping people into organizations it is RECOMMENDED element content, and the database to nest which it
   belongs specified in the persons instances into an organization instance of this
   class. type attribute.



   +------------------+
   | Contact RegistryHandle   |
   +------------------+
   | ENUM restriction |<>--{0..1}--[ name           ] STRING           |
   | ENUM role                  |
   | ENUM type        |<>--{0..*}--[ Description    ]
   |        |
   |                  |<>--{0..*}--[
   +------------------+


                   Figure 8: The RegistryHandle ]
   |                  |
   |                  |<>--{0..1}--[ PostalAddress  ]
   |                  |
   |                  |<>--{0..*}--[ Email          ]
   |                  |
   |                  |<>--{0..*}--[ Telephone      ]
   |                  |
   |                  |<>--{0..1}--[ Fax            ]
   |                  |
   |                  |<>--{0..1}--[ Timezone       ]
   |                  |
   |                  |<>--{0..*}--[ Contact        ]
   +------------------+

                      Figure 9: the Contact class


   The aggregate classes that constitute the Contact RegistryHandle class are:

   name
      Zero or one.  NAME. has one attribute:


   type
      Required.  ENUM.  The name of database to which the contact.  The contact may
      either be an organization or a person. handle belongs.  The type attribute
      dictates the semantics (organization or person).

   Description
      Zero or one.  STRING.  Free-form description of the this contact.
      In the case of a person, this
      default value is often the organizational title of 'local'.  The possible values are:


      1.  internic.  Internet Network Information Center


      2.  apnic.  Asia Pacific Network Information Center


      3.  arin.  American Registry for Internet Numbers


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


      5.  ripe.  Reseaux IP Europeens


      6.  local.  A database local to the individual. CSIRT.




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 23] 22]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   RegistryHandle
      Zero or many.      November 2004



3.8  Time classes


   The handle name in a registry.  Care must be taken data model uses five different classes to ensure that represent a handle timestamp.
   Their definition is meaningful identical, but each has a distinct name to the recipient.
      Intra-organizational handles are of not much use for
      extra-organizational communication.

   PostalAddress
      Zero or one.  POSTAL. convey
   a difference in semantics.


   The postal address element content of the contact formatted each class is a timestamp formated according
   to the DATETIME data type (see Section 2.2.9.

   Email
      Zero or many.  EMAIL. 2.2.6).



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


                       Figure 9: the Time classes



3.8.1  StartTime


   The email address of StartTime class represents the contact formatted
      according to Section 2.2.12.

   Telephone
      Zero or many.  PHONE. time the incident began.


3.8.2  EndTime


   The telephone number of EndTime class represents the contact
      formatted according to .

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

   Timezone
      Zero or one.  STRING. incident ended.


3.8.3  DetectTime


   The timezone in which DetectTime class represents the contact resides.

   Contact
      Zero or many.  Recursive definition of Contact, allowing for
      grouping of data.  An example time the first activity of this is an organization with
      multiple contact persons. the
   incident was detected.


3.8.4  ReportTime


   The Contact ReportTime class has three attributes:

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

   role
      Required.  ENUM.  Indicates represents the role time the Contact fulfills. incident was reported.
   This
      attribute is defined as an enumerated list:

      1.  creator.  The entity that generate timestamp SHOULD coincide to the time at which the IODEF document.

      2.  admin.  An administrative contact for
   document is generated.


3.8.5  DateTime


   The DateTime class is a host or network.

      3.  tech.  A technical contact for generic representation of a host or network.

      4.  irt.  The CSIRT involved in handling timestamp.  Its
   semantics should be inferred from the incident.

      5.  cc.  An entity that parent class into which it is
   aggregated.


3.9  Expectation class


   The Expectation class conveys to be kept informed about the recipient of the IODEF document
   the actions the sender is requesting.




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 24] 23]



Internet-Draft    IODEF Data Model and Implementation     September 2003


          handling of the incident.

   type
      Required.  ENUM.  Indicates the type of      November 2004



   +------------------+
   | Expectation      |
   +------------------+
   | ENUM restriction |<>--{1..*}--[ Description ]
   | ENUM priority    |<>--{0..1}--[ StartTime   ]
   | ENUM category    |<>--{0..1}--[ EndTime     ]
   |                  |<>--{0..1}--[ Contact being provided.
      This attribute is defined as an enumerated list:

      1.  person.

      2.  organization.


3.8.1 RegistryHandle     ]
   +------------------+


                    Figure 10: the Expectation class


   The RegistryHandle class represents a handle to an Internet registry aggregate classes that constitute Expectation are:


   Description
      One or community-specific database. many.  STRING.  A handle consists free-form description of a name the desired
      action(s).


   StartTime
      Zero or one.  The time at which the action should be performed.  A
      timestamp that is earlier than the ReportTime specified in the
      Incident class denotes that the expectation should be fulfilled as
      soon as possible.  The absence of this element content, and leaves the database
      execution of the expectation to the discretion of the recipient.


   EndTime
      Zero or one.  The time by which it
   belongs specified in the type attribute.


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

                  Figure 10: action should be completed.
      If the action is not carried out by this time, it should no longer
      be performed.


   Contact
      Zero or one.  The RegistryHandle class expected actor for the action.


   The RegistryHandle Expectations class has one attribute:

   type
      Required. three attributes:


   restriction
      Optional.  ENUM.  The database to which  This attribute is defined in Section 3.2.


   priority
      Optional.  ENUM.  Indicates the handle belongs.   The
      default value desired priority of the action.
      This attribute is 'local'.  The possible values are: an enumerated list with no default value.


      1.  internic.  Internet Network Information Center  low.  Low priority


      2.  apnic.  Asia Pacific Network Information Center  medium.  Medium priority


      3.  arin.  American Registry for Internet Numbers

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

      5.  ripe.  Reseaux IP Europeens

      6.  ti.  TERNEA Trusted Introducer  high.  High priority






Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 25] 24]



Internet-Draft    IODEF Data Model and Implementation     September 2003


      7.  local.  A database local to      November 2004



   category
      Optional.  ENUM.  Classifies the CSIRT.


3.9 Time classes

   The data model uses for different classes to represent a timestamp.
   Their definition type of action requested.  This
      attribute is identical, but each an enumerated list with no default value.


      1.  nothing.  No action is named differently to
   convey a semantic difference.

   The element content requested.  Do nothing with the
          information.


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


      3.  contact-me.  Contact the originator of each class is a timestamp formated according
   to the DATETIME data type (see Section 2.2.6).


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

                      Figure 11: document.


      4.  investigate.  Investigate the Time classes

   The Time classes have one attribute:

   ntpstamp
      Optional.  NTPTIMESTAMP.  The NTP timestamp representing machine(s) listed in the
      timestamp
          document.


      5.  block.  Block traffic from the machine(s) listed in the element content.  The NTPSTAMP format of this
      attribute's value is
          document.


      6.  other.  Perform some custom action described in Section 2.2.7. the
          Description class.



3.10  Method class


   The use of Method class describes the ntpstamp attribute is optional since it is redundant.
   However, it has been maintained methodology used by the intruder to ensure compatibility with
   perpetrate the
   IDMEF [7].  Representing a timestamp in both events of the element content and
   attribute is NOT RECOMMENDED.  However, if both are used, their
   values MUST be identical.

3.9.1 StartTime

   The StartTime incident.  This class represents timestamp for can reference
   well-known vulnerability or exploit databases; the intruder tools
   used in the start attack; and provide a free-form description of an the
   activity.

3.9.2 EndTime


   +------------------+
   | Method           |
   +------------------+
   | ENUM restriction |<>--{0..*}--[ Classification ]
   |                  |
   |                  |<>--{0..*}--[ Description    ]
   +------------------+


                      Figure 11: The EndTime Method class represents the timestamp for the end


   The Method class is composed of an
   activity.

3.9.3 DetectTime two aggregate classes.


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







Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 26] 25]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   The DetectTime class represents the timestamp      November 2004



   Description
      Zero or many.  STRING.  A free-form text description of when an activity was
   first detected.

3.9.4 ReportTime

   The ReportTime class represents the timestamp of when a detected
   activity was reported.

3.9.5 DateTime

   The DateTime class is a generic representation of a timestamp.  Its
   semantics should be inferred from
      methodology used by the parent intruder.


   The Method class into which it has one attribute:


   restriction
      Optional.  ENUM.  This attribute is
   aggregated.

3.10 Expectation defined in Section 3.2.



3.10.1  Classification class


   The Expectation Classification class conveys is a reference to the recipient an external database of
   computer vulnerabilities, exposures, or viruses.  A reference
   consists of the IODEF document database name, the actions entry name in the sender is requesting. database, and
   the URI to this entry.


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


                  Figure 12: the Expectation The Classification class


   The aggregate classes that constitute Expectation are:

   Description
      One or many. Classification:


   name
      One.  STRING.  A free-form description of  The key into the desired
      action(s).

   StartTime database specified in the origin
      attribute.


   url
      Zero or one.  The time at which the action should be performed. One.  URI.  A
      timestamp that is earlier than URL to additional information about the ReportTime specified in
      vulnerability or exposure referenced by the
      IncidentData name.


   The Classification class denotes that the expectation should be
      fulfilled as soon as possible. has two attribute:


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


   origin
      Required.  ENUM.  The absence of this element leaves
      the execution name of the expectation database to which the discretion of the
      recipient.





Meijer, et al.           Expires March 29, 2004 reference
      is being made.  The permitted values are shown below.


      1.  bugtraqid.  Bugtraq


      2.  cve.  Mitre Common Vulnerabilities or Exposures




Meijer, et al.            Expires May 10, 2005                 [Page 27] 26]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   EndTime
      Zero or one.  The time by which the action should be completed.
      If the action is not carried out by this time, it      November 2004



      3.  certcc.  CERT Coordination Center Vulnerability Catalog


      4.  vendor.  A product vendor whose name should no longer
      be performed.

   Contact
      Zero or one.  The expected actor for the action.  The 'role'
      attribute of the Contact MUST be set to "actor".

   The Expectations class has three attributes:

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

   priority
      Optional.  ENUM.  Indicates the desired priority of the action.
      This attribute is an enumerated list with no default value.

      1.  low.  Low priority

      2.  medium. Medium priority

      3.  high. High priority

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

      1.  nothing.  No action 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.  block.  Block or investigate machines listed in the document entry is specified in the recipient's constituency. name
          class.



3.11 Method  Assessment class


   The Method Assessment class provides information about 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, list the
   intruder tools used in reuses the attack, and provide for a free-form
   description IDMEF
   definition (see Section 4.2.4.5 of the activity.




Meijer, et al.           Expires March 29, 2004                [Page 28]

Internet-Draft    IODEF Data Model and Implementation     September 2003 [7]), but also extends it.



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


                      Figure 13: The Method Assessment class


   The Method class is composed of two aggregate classes.

   Classification classes that constitute Assessment are:


   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.  STRING A free-form text description  Impact of the
      methodology used activity measured with respect to
      financial loss.


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





Meijer, et al.            Expires May 10, 2005                 [Page 27]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   The Method Assessment class has one attribute:


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



3.11.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 in IDMEF
   definition (see Section 4.2.6.1 of [7]).


3.11.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 metric      |
         |                  |<>----------[ url  ] ENUM units       |
         +------------------+


                      Figure 14: The Classification TimeImpact class


   The aggregate classes that constitute Classification:

   name
      One.  STRING.  The name of the reference to the database specified
      in the origin attribute. element content will be a numeric value (REAL) specifying a unit
   of time.  The unit and metric attributes will imply the semantics of
   the element content.


   The TimeImpact class has three attributes:


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


      1.  low.  Low severity


      2.  medium.  Medium severity





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 29] 28]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   url
      One.  URI.  A URL to additional information about      November 2004



      3.  high.  High severity


   metric
      Required.  ENUM.  Defines the
      vulnerability or exposure referenced by metric in which the name.

   The Classification class has two attribute:

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

   origin
      Required.  ENUM.
      expressed.  The name permitted values are shown below.  There is no
      default value.


      1.  labor.  Total staff-time to recovery from the activity (e.g.,
          2 employees working 4 hours each would be 8 hours)


      2.  elapsed.  Elapsed time from the beginning of the database recovery to
          its completion.


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


   units
      Required.  ENUM.  Defines the reference units in which the element content
      is being made. expressed.  The permitted values are shown below.  The default
      value is "hours".


      1.  bugtraqid.  Bugtraq  seconds.  Seconds.


      2.  cve.  Common Vulnerabilities or Exposures  minutes.  Minutes.


      3.  certcc.  CERT Coordination Center Vulnerability Catalog  hours.  Hours.


      4.  vendor.  A product vendor whose name should be specified in
          the name class

      5.  local.  A local database.

      6.  other.


3.12 Assessment  days.  Days.



3.11.3  MonetaryImpact class


   The Assessment MonetaryImpact class describes the technical and non-technical
   repercussions financial impact of the incident activity.

   Note: The IODEF definition
   activity on an organization.  For example, this impact may consider
   losses due to the cost of the Assessment class reuses the IDMEF
   definition (see Section 4.2.4.5 investigation or recovery, diminished
   productivity of [7]), but also extends it. the staff, or a tarnished reputation that will affect
   future opportunities.















Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 30] 29]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



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


                    Figure 15: Assessment MonetaryImpact class


   The aggregate classes that constitute Assessment are:

   Impact
      Zero or many.  Technical impact of the activity on the computers
      and networks.

   TimeImpact
      Zero or many.  Impact element content will be a numeric value (REAL) specifying a unit
   of currency described in the activity measured with respect to
      time. currency attribute.


   The MonetaryImpact
      Zero or many.  Impact of the activity measured with respect to
      money.

   LifeImpact
      Zero or many.  Impact of the activity measured with respect to
      human life.

   Confidence
      Zero or one. class has two attributes:


   severity
      Optional.  ENUM.  An estimate of confidence in the assessment. relative severity of the
      activity.  The Assessment class has one attribute:

   restriction
      Optional. 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.  This attribute  Defines the currency in which the monetary
      impact is expressed.  The permitted values are defined in Section 3.2.


3.12.1 Impact ISO
      4217:2001, Codes for the representation  of currencies and funds
      [16].  There is no default value.



3.11.4  Confidence class


   The Impact Confidence class allows for classifying as well as providing represents a
   description best estimate of the technical validity and
   accuracy of the described impact due to (see Section 3.11) of the incident activity on
   the computers and networks of an organization.



Meijer, et al.           Expires March 29, 2004                [Page 31]

Internet-Draft    IODEF Data Model and Implementation     September 2003


   Attributes allow the impact to
   activity.  This estimate can be classified according to the
   consequences on the host and the severity of these consequences. The
   element content is used for the description. expressed as a category, or a numeric
   calculation.


   Note: The IODEF definition of the Impact Confidence class reuses the IDMEF
   definition (see Section 4.2.6.1 4.2.6.3 of [7]), but also extends it [7]).


3.12  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




Meijer, et al.            Expires May 10, 2005                 [Page 30]



Internet-Draft    IODEF Data Model and
   alters Implementation      November 2004



   incident.


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



   +------------------+
   | Impact History          |
   +------------------+
   | STRING           |
   |                  |
   | ENUM restriction |<>--{1..*}--[ HistoryItem ]
   |                  | ENUM severity    |
   | ENUM completion  |
   | ENUM type        |
   +------------------+


                      Figure 16: Impact The History class


   The element content may be empty, class that constitutes History is:


   HistoryItem
      One or contain a free-form description
   (STRING) many.  Entry in the history log of significant events or
      actions performed by the technical impact. involved parties.


   The Impact History class has four attributes: one attribute:


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

   severity
      Optional.  ENUM.  An estimate of the relative severity of the
      activity.



3.12.1  HistoryItem class


   The permitted values are shown below.  There HistoryItem class is no
      default value.

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   completion
      Optional.  ENUM.  An indication of whether an entry in the creator of History (Section 3.12) log
   that documents a particular action or event that occurred in the
      IODEF document believes
   course of handling the activity was successful. incident.  The
      permitted values details of the entry are shown below. There is no default value.

      1.  failed.  The attempt was not successful

      2.  succeeded.  The attempt succeeded a
   free-form description, but each can be categorized with the type
   attribute.


















Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 32] 31]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   type
      Required.  ENUM.  The type of impact in relatively broad
      categories.  The permitted values are shown below.  The default
      value is "unknown."

      1.  admin.  Administrative privileges were attempted or obtained

      2.  dos.  A denial of service was attempted or completed

      3.  file.  An action on a file was attempted or completed

      4.  recon.  A reconnaissance probe was attempted or completed

      5.  user.  User privileges were attempted or obtained

      6.  none.  The activity did not have any (technical) impact

      7.  unknown.  The impact of the activity is unknown

      8.  other.  Anything not in one of the above categories


3.12.2 TimeImpact class

   The TimeImpact class describes the non-technical impact of the
   activity on an organization as a function of time. Different types of
   time calculations and well as units can be used.      November 2004



   +------------------+
   | TimeImpact HistoryItem      |
   +------------------+
   | REAL             |
         |                  |
         | ENUM restriction |
         | ENUM severity    |
         | ENUM metric      | |<>--{0..1}--[ IncidentID  ]
   | ENUM units type        |<>----------[ DateTime    ]
   |                  |<>--{1..*}--[ Description ]
   +------------------+


                      Figure 17: TimeImpact HistoryItem class


   The element content will be aggregate classes that constitute HistoryItem are:


   IncidentID
      Zero or One.  In a numeric value (REAL) specifying history log created by multiple parties, the
   impact as
      IncidentID provides a function of time.  The attributes represent the specific
   units and metric.

   The TimeImpact class has four attributes:




Meijer, et al.           Expires March 29, 2004                [Page 33]

Internet-Draft    IODEF Data Model mechanism to specify which CSIRT created a
      particular entry and Implementation     September 2003


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

   severity
      Optional.  ENUM.  An estimate of references this organization's incident
      tracking number.  When a single organization is maintaining the relative severity
      log, this class can be ignored.


   DateTime
      One.  Timestamp of the
      activity. The permitted values are shown below.  There is no
      default value.

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   metric
      Required.  ENUM.  Defines the metric this entry in which the time is
      expressed.  The permitted values are shown below.  There is no
      default value.

      1.  labor.  Total staff-time to recovery from the activity history log (e.g.,
          2 employees working 4 hours each would be 8 hours)

      2.  elapsed.  Elapsed time from when
      the beginning of action described in the recovery to
          its completion.

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

   units
      Required.  ENUM.  Defines taken).


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


   The HistoryItem class has two attributes:


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


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


      1.  seconds.  Seconds

      2.  minutes.  Minutes

      3.  hours. Hours

      4.  days.  Days


3.12.3 MonetaryImpact class  triaged.  The MonetaryImpact class describes the financial impact of the
   activity on incident data was received and processed by an organization.  For example, this impact may consider
   loss due
          IHS.


      2.  notification.  Notification to an involved party in the cost of
          incident was sent (e.g., a CSIRT sending a message to the investigation or recovery, diminished
   productivity of
          attacking site).


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


      4.  received-info.  Additional information about the staff, or a tarnished reputation that will affect incident was




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 34] 32]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   future opportunities.      November 2004



          received.


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


      6.  other.  A custom entry.



3.13  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.



   +------------------+
   | MonetaryImpact EventData        |
   +------------------+
   | REAL             | ENUM restriction |<>--{0..*}--[ Description    ]
   |                  |<>--{0..1}--[ DetectTime     ]
   |                  |<>--{0..1}--[ StartTime      ]
   | ENUM restriction                  |<>--{0..1}--[ EndTime        ]
   |                  |<>--{0..*}--[ Contact        ]
   | ENUM severity                  |<>--{0..1}--[ Assessment     ]
   |                  |<>--{0..*}--[ Method         ]
   | ENUM metric                  |<>--{0..*}--[ Flow           ]
   |                  |<>--{0..1}--[ Record         ]
   | STRING currency                  |<>--{0..*}--[ EventData      ]
   |                  |<>--{0..*}--[ AdditionalData ]
   +------------------+


                     Figure 18: MonetaryImpact The EventData class


   The element content will be a numeric value (REAL) specifying the
   impact as a function aggregate classes that constitute EventData are:


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


   DetectTime
      Zero or one.  The attributes represent time the specific
   currency event was detected.


   StartTime
      Zero or one.  The time the event started.






Meijer, et al.            Expires May 10, 2005                 [Page 33]



Internet-Draft    IODEF Data Model and metric. Implementation      November 2004



   EndTime
      Zero or one.  The MonetaryImpact class has four attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined time the event ended.


   Contact
      Zero or more.  The different parties involved in Section 3.2.

   severity
      Optional.  ENUM.  An estimate of the relative severity incident


   Assessment
      Zero or one.  The impact 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 incident on the currency in which target and the monetary
      impact is expressed.
      actions taken.


   Method
      Zero or more.  The permitted values are defined in ISO
      4217:2001, Codes for methodology used by the representation intruders.


   Flow
      Zero or more.  A description of currencies and funds
      [18].  There is no default value.


3.12.4 LifeImpact class

   The LifeImpact class describes the loss of human life systems or injury due
   to an incident.




Meijer, et al.           Expires March 29, 2004                [Page 35]

Internet-Draft    IODEF Data Model and Implementation     September 2003


         +------------------+
         | LifeImpact       |
         +------------------+
         | INTEGER          |
         |                  |
         | ENUM restriction |
         | ENUM severity    |
         | ENUM metric      |
         +------------------+

                      Figure 19: LifeImpact class

   The element content will be a numeric value (INTEGER) specifying networks involved.


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


   EventData
      Zero or more.  Recursive definition of human life.  The attributes represent EventData allowing for the
   specific metric.
      grouping of data


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


   The LifeImpact EventData class has three attributes: one attribute:


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

   severity
      Optional.  ENUM.  An estimate of the relative severity of



3.13.1  Relating the
      activity. The permitted values are shown below. Incident and EventData classes


   There is no
      default value.

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   metric
      Required.  ENUM.  Defines the metric substantial overlap in which the LifeImpact is
      expressed.  The permitted values Incident and EventData classes.
   Nevertheless, the semantics of these classes are shown below.  There is no
      default value.

      1.  Deaths

      2.  Injuries


3.12.5 Confidence class

   The Confidence quite different.
   The Incident class represents a best estimate of provides summary information about the validity and
   accuracy of entire
   incident, while the described impact (see Section 3.12) of EventData class provides information about the incident
   activity. This estimate can
   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 expressed as a category, or possible that the overall summarized information about the
   incident conflicts with some individual information in an EventData
   class when there is a numeric
   calculation. substantial composition of various events in
   the an incident.





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 36] 34]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   Note:      November 2004



3.13.2  Cardinality of EventData


   The IODEF definition EventData class can be thought of as a container for the Confidence class reuses
   properties of an event in an incident.  These properties include: the IDMEF
   definition (see Section 4.2.6.3
   hosts involved, impact of [7]), but also extends it and
   alters the semantics. 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 Confidence class has been reused from recursive definition of the IDMEF [7], it has been
   extended and has been altered.


         +------------------+
         | Confidence       |
         +------------------+
         | REAL             |
         |                  |
         | ENUM restriction |
         | ENUM rating      |
         +------------------+

                      Figure 20: Confidence EventData class

   The element content may be empty if (the EventData class
   is aggregated into the rating 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 not set used to "numeric".  Otherwise, a confidence value (REAL) must be provided.

   The Confidence class has two attributes:

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

   rating
      Required.  ENUM.  Indicates group (relate)
   information.


   Nested EventData classes imply that while the confidence child classes share the CSIRT has in its
      assessment. The permitted values are shown below.  The default
      value
   properties of the parent, there is "numeric."

      1.  low

      2.  medium

      3.  high

      4.  numeric.  The CSIRT has provided some properties for which they do
   not agree.  Therefore, in order express these distinct properties,
   the nesting approach was used.  In such a probability value
          indicating its confidence 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 its assessment.

      5.  unknown an incident.  This element SHOULD only description can be used when achieved
   using multiple instances of the CSIRT can produce
   meaningful information.  When only System class.  It happens that there
   is a rough estimate common technical contact (i.e., Contact class) for these two
   machines, but the impact (i.e., Assessment class) on them is possible
   "low", "medium", or "high" SHOULD
   different.  A depiction of the representation for this situation can
   be used as found in Figure 19.



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


              Figure 19: Recursion in the rating value.

   When a reasonable probability estimate is possible "numeric" SHOULD EventData class








Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 37] 35]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   be used as      November 2004



3.14  Flow class


   The Flow class groups the rating value source and include a numeric confidence value target hosts or networks in an
   event.



   +------------------+
   | Flow             |
   +------------------+
   |                  |<>--{1..*}--[ System   ]
   +------------------+


                       Figure 20: the element content. This numeric value is a floating point number
   between 0.0 and 1.0, inclusive.

   Different CSIRTs may compute and represent confidence values in
   different ways.  Care should be taken to take proper notice of the
   exact meaning of Flow class


   The aggregate class that constitutes Flow is:


   System
      One or More.  A host or network involved in the confidence values of different CSIRTs when
   comparing confidence values.

3.13 History incident activity.


   The Flow System class has no attributes.


3.15  System class


   The History System class is represents a log computer or diary of network involved in the significant events that
   occurred or actions performed
   incident.


   The systems represented by this class are categorized according to
   the involved parties (e.g., initial
   reporter, investigating CSIRT, or involved system administrators)
   during role they played in the course of handling incident through the incident. category attribute.
   The level value of detail maintained in this log is left up to category attribute dictates the
   discretion semantics of those handling the incident.
   aggregated classes in the System class.  If the category attribute
   has a value of 'source', then the aggregated classes denote the
   machine and service from which the activity is originating.  With a
   category attribute value of 'target' or 'intermediary', then the
   machine or service is the one targeted in the activity.


















Meijer, et al.            Expires May 10, 2005                 [Page 36]



Internet-Draft    IODEF Data Model and Implementation      November 2004



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


                      Figure 21: The History the System class


   The class aggregate classes that constitute History System are:

   HistoryItem
      One


   Node
      One.  A host or many.  Entries network involved in the history log of significant events incident.


   Service
      Zero or
      actions performed by more.  A network service running on the involved parties. system.


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


   The History System class has one four attribute:


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


3.13.1 HistoryItem class

   The HistoryItem class is a particular entry in


   category
      Required.  ENUM.  Classifies the History (Section
   3.13) log that documents a particular significant action role the host or event
   that occurred network played
      in the course incident.  The possible values are:


      1.  source.  The System was the source of handling the current incident.  This
   details attack.


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


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


   interface
      Optional.  STRING.  Specifies the interface on which the event(s)
      on this log are System originated.  If the Node class specifies a free-form description, but
   each can also be categorized. network
      rather than a host, this attribute has no meaning.


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




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 38] 37]



Internet-Draft    IODEF Data Model and Implementation     September 2003


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

                      Figure 22: HistoryItem class      November 2004



      1.  unknown.  The aggregate classes that constitute HistoryItem are:

   IncidentID
      Zero or One. accuracy of the category attribute value is
          unknown


      2.  yes.  The category attribute value is probably incorrect.  In history logs created by multiple parties,
          the
      IncidentID provides case of a way specify which CSIRT created source, the
      particular entry and reference this organizations local incident
      tracking number for this activity.  When a single organization System is
      maintaining likely a decoy; with a
          target, the history log, this class can System was likely not the intended victim.


      3.  no.  The category attribute value is believed to be ignored.

   DateTime
      One.  Timestamp correct.



3.16  Node class


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


   The base definition of the this entry in class is reused from the history log (e.g., when IDMEF
   specification, see Section 4.2.7.1 of [7].  However, the action described in class has
   been extended by adding the Description was taken).

   Description
      One NodeRole and DateTime classes.



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


                       Figure 22: The Node class


   The aggregate classes that constitute Node are:


   Location
      Zero or many. one.  STRING.  A free-form textual free-from description of the
      action or event to be document in the history log.

   The HistoryItem class has two attributes:

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

   type
      Optional.  ENUM.  Classifies the type physical
      location of activity the equipment.


   name
      Zero or event being
      document in this history log entry. one.  STRING.  The particular details name of the
      entry are a free-form description documented in the Description
      class.  Possible values are an enumerated list whose default value equipment (e.g., fully
      qualified domain name).  This information MUST be provided if no
      Address information is "other":

      1.  triaged. given.


   Address
      Zero or more.  The incident data was received and processed by an
          IHS

      2.  notification.  Notification to an involved party in hardware, network, or application address of
      the
          incident was sent (e.g., Node.  Unless a CSIRT sending a message to the
          attacking site). name is provided, at least one address must be
      specified.





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 39] 38]



Internet-Draft    IODEF Data Model and Implementation     September 2003


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

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

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

      6.  other.


3.14 EventData class

   The EventData class describes the events of the incident surrounding
   a particular set of hosts      November 2004



   DateTime
      Zero 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 one.  A timestamp of when the
   activity on resolution between the organization, a list of incident handling tasks
   performed, and name
      and any forensic evidence discovered.































Meijer, et al.           Expires March 29, 2004                [Page 40]

Internet-Draft    IODEF Data Model address was performed.  This information SHOULD be provided if
      both an Address and Implementation     September 2003


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

                     Figure 23: The EventData class

   The aggregate classes that constitute EventData are:

   Description name are given.


   NodeRole
      Zero or more.  STRING.  A free-form textual description  The intended purpose of the
      event.

   System equipment.


   Counter
      Zero or more.  The systems (nodes, networks) involved in the event
      as either sources, targets or intermediaries.

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


   The methods by Node class has one attribute:


   category
      Optional.  ENUM.  The context in which the event was staged.
      Information about tools used Address and vulnerabilities exploited.

   Record
      Zero name
      classes should be considered, if relevant.  The permitted values
      for this attribute are shown below.  The default value is
      "unknown".


      1.  unknown.  Domain unknown or one.  Support data (e.g., log files) that provides
      information on the events. not relevant


      2.  ads.  Windows 2000 Advanced Directory Services


      3.  afs.  Andrew File System (Transarc)


      4.  coda.  Coda Distributed File System


      5.  dfs.  Distributed File System (IBM)


      6.  dns.  Domain Name System


      7.  hosts.  Local hosts file


      8.  kerberos.  Kerberos realm


      9.  nds.  Novell Directory Services


      10.  nis.  Network Information Services (Sun)


      11.  nisplus.  Network Information Services Plus (Sun)


      12.  nt.  Windows NT domain


      13.  wfw.  Windows for Workgroups







Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 41] 39]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   StartTime
      Zero or one.      November 2004



3.16.1  Counter class


   The time the event started.

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


   The time value of the event ended.

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

   Contact
      Zero or more.  The different parties involved element content, with its units
   represented in the incident

   Assessment
      Zero or one.  Indicates the impact of the incident type attribute.  The complete semantics are
   entirely context dependant based on the target
      and the actions taken.

   AdditionalData
      Zero or one.  Anything that can not be put class in one of which the other
      elements

   Event
      Zero or more.  Recursive definition of Event, allowing for
      grouping of data

   The EventData class has one Counter is
   aggregated.



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


                      Figure 23: the Counter class


   The Counter class has two attribute:

   restriction


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


3.15 Relating the IncidentData and EventData classes

   At first glance, the duplication in the aggregate classes of
   IncidentData and EventData are obvious.  However,  Specifies the semantics units of
   these classes are quite different.  IncidentData provides summary
   information about the entire incident, while EventData provides
   information about a subset element contents.


      1.  packet.  Count of the incident.

   For example, note that the Assessment class is aggregated in both
   classes. Consider a case where IncidentData:Assessment:MonetaryImpact
   has been assigned a value packets.


      2.  session.  Count of x.  Now, consider a value sessions


      3.  event.  Count of y (where y
   < x) being assigned to a given MonetaryImpact class that is
   aggregated in events


      4.  other.  User defined count


   meaning
      Optional.  STRING.  Describes the EventData class.  The semantics of these two values
   is some monetary loss.  In the case of the figure in element content
      if the IncidentData
   class, this loss is incident-wide.  The figure in EventData type attribute is a
   subset of this overall loss, and allows one set to associate a particular
   loss with other.



3.16.2  Address


   The Address class represents a given subset of events that constitute hardware (layer-2), network (layer-3),
   or application (layer-7) address.


   This class was originally derived from the incident.  It
   effectively provides a breakdown (or more specific description) of IDMEF specification [7].






Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 42] 40]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   the overall loss previously specified in      November 2004



   +------------------+
   |     Address      |
   +------------------+
   | ENUM category    |
   | STRING vlan-name |
   | INTEGER vlan-num |
   +------------------+


                      Figure 24: the IncidentData class.

3.16 Cardinality of EventData Address class


   The recursive definition Address class has four attributes:


   category
      Required.  ENUM.  The type of address represented.  The permitted
      values for this class (the EventData class is
   aggregated into the EventData class) provides a way to related
   information without requiring the explicit use of unique attribute
   identifiers are shown below.  The default value is
      "ipv4-addr".


      1.  atm.  Asynchronous Transfer Mode (ATM)


      2.  mac.  Media Access Control (MAC) address


      3.  sna.  IBM Shared Network Architecture (SNA) address


      4.  ipv4-addr.  IPv4 host address in the classes. 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.  vm.  IBM VM ("PROFS") email address


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


      12.  lotus-notes.  Lotus Notes e-mail address








Meijer, et al.            Expires May 10, 2005                 [Page 41]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   vlan-name
      Optional.  STRING.  The depth name of an element in the XML tree
   is used Virtual LAN to related information.

   The EventData class can be thought of as a container describing which the
   properties
      address belongs.


   vlan-num
      Optional.  STRING.  The number of an event in an incident.  These properties include: the
   hosts involved, impact of Virtual LAN to which the incident activity
      address belongs.



3.16.3  NodeRole class


   The NodeRole class describes (based on a pre-defined list) the hosts,
   forensic logs, etc.  One groups (via an instance of the EventData
   class) hosts (i.e., System class) around these common properties.

   A child EventData
   function performed by a particular host.



         +---------------+
         | NodeRole      |
         +---------------+
         | STRING        |
         |               |
         | ENUM category |
         +---------------+


                     Figure 25: The NodeRole class (and


   The element content should be empty in all its siblings) logically "inherits"
   the aggregated classes of a parent EventData class.  However, cases other than when the
   presence of sibling EventData classes (it "never" makes sense
   category attribute is set to have
   only "other".


   The NodeRole class has one EventData child in an EventData class) means that there are
   some disjoin properties attributes:


   category
      Required.  Functionality provided by a node.  If a value of the event.  These children of the parent
   EventData class represent these differences, while still retaining
      "other" is specified, a
   way to represent the common properties (i.e., the parent-child
   relationship).

   For example, an EventData class might be used to describe two
   machines involved in an incident.  This description can SHOULD be achieved
   using multiple instances of the System class.  It happens that the
   technical contact (i.e., Contact class) for these two machines is
   identical, but provided in the impact (i.e., Assessment class) is different.
      element content.  The
   problem lies in representing two hosts default value is "other".


      1.  client.  Client computer


      2.  server-internal.  Server with a common contact, but
   different impacts without duplicating any information.  This event
   can be represent internal services


      3.  server-public.  Server with the following design represented in Figure 24. public services


      4.  www.  WWW server


      5.  mail.  Mail server


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


      7.  streaming.  Streaming-media server




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 43] 42]



Internet-Draft    IODEF Data Model and Implementation     September 2003


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

              Figure 24: Recursion      November 2004



      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 the EventData class this list



3.17 System  Process class


   The System Process class represents the technical information for describes a running program on a given
   computer or network host
   involved in the an incident.

   The systems represented by this  This class are categorized according to
   the role they played in the incident via through is reused outright from the category
   attribute.  The value
   IDMEF specification, see Section 4.2.7.3 of this category attribute dictates the
   semantics [7].


3.18  Service class


   The Service class describes a network service of the aggregated classes in the System class. a host or network.
   The meaning service is identified by specific port or list of ports, along
   with the Node, User, Process, and application listening on that port.


   When Service occurs as an aggregate class depend on
   the value of the category attribute of the System class.  If the a System class category attribute that is 'source', a
   source, then that the described
   aggregated classes denote the machine, user, process, or service is the one from which the activity of
   interest is originating.  With a category attribute value  Conversely, when Service occurs as an
   aggregate class of 'target' or 'intermediary', a System that is a target, then the described machine, user,
   process, or that service is
   the one targeted in to which activity of interest is being directed.


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




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 44] 43]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   +------------------+
   | System           |
   +------------------+
   | ENUM restriction |<>----------[ Node     ]      November 2004



   +--------------------+
   | ENUM category   Service          |
   +--------------------+
   | STRING interface |<>--{0..*}--[ User     ]
   | ENUM spoofed     |
   |                  |<>--{0..*}--[ Process ip_version  |<>--{0..1}--[ port        ]
   |                  |
   |                  |<>--{0..*}--[ Service STRING ip_protocol |<>--{0..1}--[ portlist    ]
   |                  |
   |                    |<>--{0..1}--[ FileList Application ]
   +------------------+
   +--------------------+


                      Figure 25: the System 26: The Service class


   The aggregate classes that constitute System Service are:

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

   User


   port
      Zero or more. The application one.  INTEGER.  A port number.


   portlist
      Zero or operating system user running on
      the specified host that was involved in the incident.

   Process one.  PORTLIST.  A list of port numbers formatted
      according to Section 2.2.7.


   Application
      Zero or more.  The process targeted or the source of the attack on application bound to the specified host,

   Service
      Zero port or one.
      portlist.


   The network service targeted on the host specified
      in Node.

   FileList
      Zero Service class must specify either a port or one.  Information about the files on the host involved in
      the incident. portlist.


   The System Service class has four attribute:

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

   category two attributes:


   ip_version
      Required.  ENUM.  Classifies the role the System played in the
      incident activity.  INTEGER.  The possible values are:

      1.  source. IP version number.


   ip_protocol
      Required.  INTEGER.  The System was IANA protocol number.



3.19  Record class


   The Record class is a container class for log and audit data that
   provides supportive information about the incident.  The source of
   this data will often be the output of monitoring tools (e.g., IDMEF
   messages generated by an IDS, connection logs from a web server) that
   were used to uncover the attack malicious activity.  These logs should
   provide evidence as to why a CSIRT believes an incident has occurred.










Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 45] 44]



Internet-Draft    IODEF Data Model and Implementation     September 2003


      2.  target.      November 2004



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


                        Figure 27: Record class


   The System was the target aggregate class that constitutes Record is:


   RecordData
      One or more.  Log or audit data generated by a particular type of
      sensor.  Seperate instances of the attack

      3.  intermediate.  The System was an intermediate machine RecordData class SHOULD be used in
          the attack.

   interface
      Optional.  STRING.  Specifies the interface on which the event(s)
      on this System originated.

   spoofed
      for each sensor type.


   The Record class has one attributes:


   restriction
      Optional.  ENUM.  An indication of confidence as to whether this
      System was the true target or attacking host.  The permitted
      values for this  This attribute are shown below.  The default value is
      "unknown".

      1.  unknown.  The accuracy of the category information is unknown

      2.  yes.  The category value classifying the host or network as an
          source or target is probably incorrect.  In the case of a
          source, the System is likely a decoy; with a target, the
          System was likely not the intended victim.

      3.  no.  The category value classifying the host or network as a
          source or target is believed to be correct.


3.18 Node has been defined in Section 3.2.



3.19.1  RecordData class


   The Node RecordData class is used to identify a host groups log or network device (e.g.,
   routers, switches).

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

















Meijer, et al.           Expires March 29, 2004                [Page 46]

Internet-Draft    IODEF Data Model a given sensor
   (e.g., IDS, firewall log) and Implementation     September 2003


   +---------------+ provides a way to annotate the output.



   +------------------+
   |     Node RecordData       |
   +---------------+
   +------------------+
   | ENUM category |<>--{0..1}--[ Location ]
   |               |
   | restriction |<>--{0..1}--[ name DateTime    ]
   |               |
   |                  |<>--{0..*}--[ Address Description ]
   |               |
   |                  |<>--{0..1}--[ DateTime Analyzer    ]
   |               |
   |               |<>--{0..*}--[ NodeRole                  |<>--{1..*}--[ RecordItem  ]
   +---------------+
   +------------------+


                    Figure 26: 28: The Node RecordData class


   The aggregate classes that constitute Node are:

   Location constitutes RecordData is:


   DateTime
      Zero or one.  STRING. The physical location  Timestamp of the equipment.

   name RecordItem data.


   Description
      Zero or one. more.  STRING. The name  Free-form textual description of the equipment (e.g., fully
      qualified domain name).  This information MUST be
      provided if no
      Address information is given.

   Address
      Zero or more.  The network or hardware address of RecordItem data.  At minimum, this description should
      convey the equipment.
      Unless a name is provided, at least one address must be specified.

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

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

   The Node class has one attribute:

   category
      Optional.  ENUM.  The context in which the Address and name
      classes should be considered, if relevant. The permitted values
      for this attribute are shown below.  The default value is
      "unknown".

      1.   unknown.  Domain unknown or not relevant RecordItem data.





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 47] 45]



Internet-Draft    IODEF Data Model and Implementation     September 2003


      2.   ads.  Windows 2000 Advanced Directory Services

      3.   afs.  Andrew File System (Transarc)

      4.   coda.  Coda Distributed File System

      5.   dfs.  Distributed File System (IBM)

      6.   dns.  Domain Name System

      7.   hosts.  Local hosts file

      8.   kerberos.  Kerberos realm

      9.   nds.  Novell Directory Services

      10.  nis.  Network Information Services (Sun)

      11.  nisplus.  Network      November 2004



   Analyzer
      Zero or one.  Information Services Plus (Sun)

      12.  nt.  Windows NT domain

      13.  wfw.  Windows for Workgroups


3.18.1 Address about the sensor used to generate the
      RecordItem data.


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


   The Address RecordData class represents a network, hardware, and application
   address. has one attributes:


   restriction
      Optional.  ENUM.  This class is reused outright from the IDMEF specification,
   see attribute has been defined in Section 4.2.7.1.1 of [7].

3.18.2 NodeRole 3.2.



3.19.2  Analyzer class


   The NodeRole Analyzer class describes (based on a pre-defined list) identifies the
   function performed by a sensor (e.g., IDS, firewall, web
   server) used to generate particular host. log or audit data.  The
   definition of the class is reused from the IDMEF specification, see
   Section 4.2.7.3 of [7].  However, in this context, the definition of
   an analyzer is expanded beyond merely an IDS.


3.19.3  RecordItem class


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


   The dtype attribute will dictate the type of log data that will be
   found in this class.  This class is very similar to the
   AdditionalData class (Section 3.6) in that it is an extension
   mechanism that can support proprietary representations of security
   event data, not all of which is necessarily in XML.


















Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 48] 46]



Internet-Draft    IODEF Data Model and Implementation     September 2003


         +---------------+      November 2004



   +------------------+
   | NodeRole RecordItem       |
         +---------------+
   +------------------+
   | STRING ANY              |
   |                  |
   | ENUM category type        |
         +---------------+
   +------------------+


                    Figure 27: 29: The NodeRole RecordItem class


   The element content should be empty in all cases other than when the
   category attribute is set to "other".

   The NodeRole Recorditem class has one attributes:

   category attribute:


   type
      Required.  Functionality provided by a node.  If a value  The type of
      "other" is specified, a description SHOULD be provided data included in the
      element's element content.  The
      permitted values for this attribute are shown below.  The default
      value is "other". "string".


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


      2.   server-internal.  Server with internal services

      3.   server-public.  Server with public services

      4.   www.  WWW server  byte.  The element content is a single 8-bit byte (see Section
           2.2.4);


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


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


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


      6.   messaging.  Messaging server (e.g. NNTP, IRC, IM)  portlist.  The element content is a port list (see Section
           2.2.7);


      7.   streaming.  Streaming-media server  real.  The element content is a real number (see Section
           2.2.2);


      8.   voice.  Voice server (e.g. SIP, H.323)  string.  The element content is a string (see Section 2.2.3);


      9.  file.  File server (e.g. SMB, CVS, AFS)  The element content is a base64 encoded binary file;


      10.  ftp.  FTP server  path.  The element content is a filesystem path;


      11.  p2p.  Peer-to-peer node  url.  The element content is a URL (see Section 2.2.12;)


      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)  xml.  The element content is XML-tagged data (see Section 4).





Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 49] 47]



Internet-Draft    IODEF Data Model and Implementation     September 2003


      15.  print.  Print server

      16.  application.  Application server

      17.  database.  Database server

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

      19.  log.  Logserver

      20.  other.  other role not in this list


3.19 FileList class

   The FileList class describes files and other file-like objects on
   hosts involved in an incident.  This class is reused outright from      November 2004



4.  Extending the IDMEF specification, see Section 4.2.7.5 of [7].

3.20 User

   The User class describes an application or operating system user
   account involved in an incident.  This class is reused outright from
   the IDMEF specification, see Section 4.2.7.2 of [7].

3.21 Process

   The Process class describes a running program on a given host
   involved in an incident.  This class is reused outright from the
   IDMEF specification, see Section 4.2.7.3 of [7].

3.22 Service

   The Service class describes a network service of a host. This class
   is reused outright from the IDMEF specification, see Section 4.2.7.4
   of [7].

3.23 Record class

   The Record class groups log or audit data that provides a record of
   the incident activity.  The source of this data will typically be the
   output of monitoring tools (e.g., IDMEF messages generated by an IDS,
   connection logs from a web server) that were used to uncover the
   malicious activity.  These logs should provide evidence as to why a
   reporter to CSIRT believes an incident has occurred.






Meijer, et al.           Expires March 29, 2004                [Page 50]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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

                        Figure 28: Record class

   The aggregate class that constitutes Record is:

   RecordData
      One or more.  Log or audit data generated by a particular type of
      sensor.

   The Record class has one attributes:

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


3.23.1 RecordData class

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


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

                    Figure 29: The RecordData class

   The aggregate classes that constitutes RecordData is:

   DateTime
      Zero or one.  Timestamp information for the RecordItem data.

   Description
      Zero or more.  STRING. Free-form textual description of the
      provided RecordItem data. At minimum, this description should



Meijer, et al.           Expires March 29, 2004                [Page 51]

Internet-Draft    IODEF Data Model and Implementation     September 2003


      convey the significance of the provided RecordItem data.

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

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

   The RecordData class has one attributes:

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


3.23.1.1 Analyzer class

   The Analyzer class identifies the sensor (e.g., IDS, firewall, web
   server) used to generate particular log or audit data. The definition
   of the class is reused from the IDMEF specification, see Section
   4.2.7.3 of [7].  However, in this context, the definition of an
   analyzer is expanded beyond merely an IDS.

3.23.1.2 RecordItem class

   The RecordItem class provides a way to incorporate relevant logs,
   audit trails, or forensic data to support the conclusions made during
   the course of analyzing the incident.  This data can be directly
   encapsulated as part of this document, or can be referenced whereby
   using this class as merely a pointer to the relevant information.

   The dtype attribute will dictate the type of log data that will be
   found in this class.  This class is very similar to the
   AdditionalData class (Section 3.6) in that it is essentially an
   extension class that can support proprietary representations of
   security event data, not all of which is necessarily in XML.















Meijer, et al.           Expires March 29, 2004                [Page 52]

Internet-Draft    IODEF Data Model and Implementation     September 2003


   +------------------+
   | RecordItem       |
   +------------------+
   | ANY              |
   |                  |
   | ENUM type        |
   +------------------+

                    Figure 30: The RecordItem class

   The Recorditem class has one attribute:

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

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

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

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

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

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

      6.   ntpstamp.  The element content is a NTP timestamp (see
           Section 2.2.7);

      7.   portlist.  The element content is a port list (see Section
           2.2.8);

      8.   real.  The element content is a real number (see xref
           target="dt_real_numbers" />);

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

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

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

      12.  url.  The element content is a URL (see Section 2.2.13;)



Meijer, et al.           Expires March 29, 2004                [Page 53]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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


















































Meijer, et al.           Expires March 29, 2004                [Page 54]

Internet-Draft    IODEF Data Model and Implementation     September 2003


4. Extending the IODEF

   In order to support the changing activity IODEF


   In order to support the changing activity of CSIRTS, the IODEF data
   model and DTD will need to evolve along with them.  To allow new
   features to be added, both the data model and the DTD can be extended
   as described in this section.  As these extensions mature, they can
   then
   be incorporated into future versions of the specification or
   published separately.


4.1  Extending the data model


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


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


   o  Aggregation allows for entirely new, self-contained classes to be
      created and associated with a parent class.


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


4.2  Extending the XML DTD


   There are two ways to extend the IODEF XML DTD:


   1.  The AdditionalData (see Section 3.6) and RecordItem (see Section
       3.23.1.2)
       3.19.3) classes allow implementers to include arbitrary "atomic"
       data.  (e.g., integers, strings).  This approach SHOULD be used
       whenever possible.


   2.  The AdditionalData and RecordItem classes also allow implementers
       to extend the IODEF XML DTD with additional DTDs that describe
       arbitrarily complex data types and relationships.


   The following guidelines MUST be followed when extending the IODEF
   DTD with another DTD in the extension classes:



   1.  The IODEF description MUST include a document type declaration
       (see Section 2.1.1.3);


   2.  The document type declaration MUST define a parameter entity that
       contains the location of the extension DTD, and then reference




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 55] 48]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



       that entity:


    <!DOCTYPE IODEF-Document SYSTEM "/path/to/IODEF-Document.dtd"
             [ <!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">
                        % x-extension;  ]>



       In this example, the "x-extension" parameter entity is defined
       and then referenced, causing the DTD for the extension to be read
       by the XML parser.
       The name of the parameter entity defined for this purpose MUST be
       a string beginning with "x-"; there are no other restrictions on
       the name (other than those imposed on all entity names by XML).
       Multiple extensions may be included by defining multiple entities
       and referencing them.  For example:


    <!DOCTYPE IODEF-Document SYSTEM "/path/to/IODEF-Document.dtd"
             [ <!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">
               <!ENTITY % x-another SYSTEM "/path/to/another.dtd">
                        %x-extension;
                        %x-another;  ]>


   3.  Extension DTDs MUST declare all of their elements and attributes
       in a separate XML namespace.  Extension DTDs MUST NOT declare any
       elements or attributes in the "IODEF" or default namespaces.


       For example, the "test" extension might be declared as follows:


   <!ELEMENT test:test ( test:a, test:b, test:c )>
   <!ATTLIST test:test
      xmlns      CDATA   #IMPLIED
      xmlns:test CDATA   #IMPLIED
   >
   <!ELEMENT test:a (#PCDATA)>
   <!ATTLIST test:a
      test:attr   CDATA   #IMPLIED
   >


   <!ELEMENT test:b (#PCDATA)>
   <!ELEMENT test:c (#PCDATA)>


   4.  Extensions MUST only be included in the AdditionalData class of
       the Incident class or
       RecordItem classes whose "type" attribute is "xml".  For example:









Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 56] 49]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



   <IODEF-Document version="0.0">
      <Incident ident="...">
         ...
         <AdditionalData type="xml">
           <test:test
            xmlns:test="http://www.ietf.org/iodef/test.html"
            xmlns="http://www.ietf.org/iodef/test.html">
            <test:a test:attr="...">...</test:a>
            <test:b>...</test:b>
            <test:c>...</test:c>
           </test:test>
         </AdditionalData>
      </Incident>
   </IODEF-Document>






































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 57] 50]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



5.  Processing Considerations

   This section discusses some of the special considerations that must
   be taken into account by implementers of the IODEF.

5.1 XML Validity and Well-Formedness


   The IODEF documents MUST be well-formed, and when  possible and
   practical the documents practical, SHOULD
   also be valid.


   It is expected that IODEF-compliant applications will normally not
   include the IODEF DTD in their communications.  Instead, the DTD will
   be referenced in the document type declaration section of the IODEF
   document (see Section 2.1.1.3.

   While an XML document SHOULD contain a document type declaration.
   This requirement imposes a significant overhead on an IODEF-compliant
   application in bandwidth consumption and computation for the DTD may
   need to be downloaded and parsed before use by the XML parser.

   Implementers MAY decide to have entities who regularly exchange IODEF
   message agree out-of-band on the particular document type definition
   they will be using to exchange messages (the standard one as defined
   here, or one with extensions), and then omit it from IODEF documents.
   The method for negotiating this agreement is outside the scope of
   this document.

   NOTE: Care must be taken in negotiating any such agreements, as each
   entities will have to keep state on this agreed upon document type
   definition.  The management complexity of these negotiations grows
   more complex as entities make such arrangements with many
   collaborators.

5.2 Unrecognized Data and XML Tags 2.1.1.3).


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


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


   o  Unrecognized tags outside of the extension classes; or


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



Meijer, et al.           Expires March 29, 2004                [Page 58]

Internet-Draft    IODEF Data Model and Implementation     September 2003


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
























Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 59] 51]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



6.  Internationalization issues


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


   The IODEF leverages that certain incidents be resolved. XML already natively supports different character
   encodings.  This flexibility
   will allow allows information encoded in the an IODEF
   document to be in most written languages. Furthermore,  In order to disambiguate the
   explicit language used on a per-element basis, XML also provides the
   xml:lang attribute
   through which attribute.  Using the type of language being used in a given element can
   be specified.  By including this xml:lang attribute in the %attlist.global
   entity found in all elements, users of allows the IODEF can to
   make use different of multiple languages in the same document.


   The intent of the data model ensures was to provide internationalization and
   localization, but not to the detriment of inter-operability.  While
   IODEF does support different languages, the data model also relies
   heavily on standardized enumerated attributes that can crudely
   approximate the cardinality contents of the Description class
   is document.  With this approach, a
   CSIRT should be able to make some sense of an IODEF document it might
   receive that uses a language unfamiliar to its analysts.


   Likewise, the data model was designed so that classes where free-text
   might be used for descriptive purposes always have a one-to-many
   cardinality with its parent.  One parent (i.e., Description class).  The primary
   intent of the intents for this design was to allow the same description to be
   repeated in another instance of the Description class, class but in a different
   language.
   Parsers of the IODEF document, could extract only the elements with
   the relevant language.

   Supporting  This approach allows recipients speaking different
   languages allows CSIRTs to localize the IODEF.
   However, it does not aid data interchange if the recipient of a
   document does not understand the underlying language.  In order to
   ensure that the recipient can at least crudely approximate the
   contents of receive the identical document, but allows the data model relies on enumerated
   attributes that are standardized IODEF
   parser to convey meaning (e.g.,
   %attlist.purpose). select the appropriate language.





















Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 60] 52]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



7.  Examples

   These examples provide an idea of what IODEF-Documents can look like.
   It must be stressed that as IODEF is a data-exchange-format, it does
   not specify detailed rules on which elements and attributes


   This section provides representative examples of incident data
   converted to use
   under all imaginable circumstances. 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 initial original report is
   sent in by
   email, the subsequently shown IODEF-Document illustrates the
   communication between the responsible CSIRT and its constituent.  The
   constituent email is a contact for the CSIRT presented in Figure 34, and responsible for
   coordinating the required actions at his site. corresponding
   equivalent as an IODEF document is shown below.



   From e-citizen@hisdomain.de e-citizen@domain.com
   Date: 13 Sep 2001 23:19:24 -0000
   From: e-citizen@hisdomain.de
   To: cert-for-ourdomain.pl@ourdomain.pl 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.incidents.org/react/code_redII.php http://www.domain.org/react/code_redII.html


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


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


       Figure 35: 34: Code Red detection notification: initial report




   <IODEF-Document version="1.0">
      <Incident restriction="need-to-know" purpose="handling">
         <IncidentID
   name="CERT-FOR-OUR-DOMAIN.PL">CERT-FOR-OUR-DOMAIN.PL#189</IncidentID>



Meijer, et al.           Expires March 29, 2004                [Page 61]

Internet-Draft    IODEF Data Model and Implementation     September 2003


         <IncidentData> name="CERT-DOMAIN.COM">CERT-DOMAIN.COM#189</IncidentID>
         <Description>Host sending out Code Red probes</Description>
            <ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
            <Expectation category="other">
               <Description>Track and clean host</Description>
            </Expectation>
         <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">




Meijer, et al.            Expires May 10, 2005                 [Page 53]



Internet-Draft    IODEF Data Model and Implementation      November 2004



            <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>
            <History>
               <HistoryItem type="notification">
                  <IncidentID
   name="CERT-FOR-OUR-DOMAIN.PL">CERT-FOR-OUR-DOMAIN.PL#189</IncidentID>
                  <Description>Notification sent to
   Constituency-contact@10.1.1.2.pl</Description>
                  <DateTime>2001-09-14T08:19:01+00:00</DateTime>
               </HistoryItem>
            </History>
         <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>
                   <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>






Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 62] 54]



Internet-Draft    IODEF Data Model and Implementation     September 2003


                  </RecordData>
               </Record>
            </EventData>
         </IncidentData>
      </Incident>
   </IODEF-Document>      November 2004



       Figure 36: 35: Code Red detection notification: CSIRT response



7.2  IODEF-Document with XML signature


7.3  IODEF-Document encrypted using XML encryption


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











































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 63] 55]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



8.  The IODEF Document Type Definition



   <?xml version="1.0" encoding="UTF-8"?>
   <!--
    ********************************************************************
    ********************************************************************
    *** IncidentData Incident Object Description Exchange Format XML DTD              ***
    ***               Version 01, September 2003 November 2004                      ***
    ********************************************************************
    ********************************************************************
    -->
   <!ENTITY % attlist.iodef "
            version             CDATA                   #FIXED    '0.20'    '0.30'
         ">
   <!--
    ====================================================================
    ==  Element definitions                                           ==
    ====================================================================
    -->
   <!--
    ====================================================================
    == IODEF-Document class                                           ==
    ====================================================================
    -->
   <!ELEMENT IODEF-Document (Incident+)>
   <!ATTLIST IODEF-Document
        %attlist.iodef;
        xmlns:iodef CDATA #FIXED "urn:iana:xml:ns:iodef"
   >
   <!--
    ====================================================================
    ==  Incident class                                                ==
    ====================================================================
    -->
   <!ELEMENT Incident (IncidentID, AlternativeID?, RelatedActivity?, IncidentData, Description*, Contact+, ReportTime, DetectTime?, StartTime?, EndTime?, Expectation*, Method*, Assessment+, EventData*, History?, AdditionalData*)>
   <!ATTLIST Incident
        restriction %attvals.restriction; "private"
        purpose %attvals.purpose; #REQUIRED
   >
   <!--
    ====================================================================
    ==  IncidentID class                                              ==
    ====================================================================
       -->
   <!ELEMENT IncidentID (#PCDATA)>
   <!ATTLIST IncidentID
        name CDATA #IMPLIED




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 64] 56]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



        restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ==  AlternativeID class                                           ==
    ====================================================================
    -->
   <!ELEMENT AlternativeID (IncidentID+)>
   <!ATTLIST AlternativeID
        restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ==  RelatedActivity class                                         ==
    ====================================================================
    -->
   <!ELEMENT RelatedActivity (IncidentID+)>
   <!ATTLIST RelatedActivity
        restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ===  AdditionalData class                                        ===
    ====================================================================
    -->
   <!ELEMENT AdditionalData ANY>
   <!ATTLIST AdditionalData
        restriction %attvals.restriction; #IMPLIED
        type %attvals.dtype; #REQUIRED
        meaning CDATA #IMPLIED
   >
   <!--
    ====================================================================
    ===  IncidentData class                                          ===
       ====================================================================
       -->
   <!ELEMENT IncidentData (Description*, Contact+, ReportTime, DetectTime?, StartTime?, EndTime?, Expectation*, Method*, Assessment+, EventData*, History?, AdditionalData*)>
   <!ATTLIST IncidentData
   	restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ===  Contact class                                               ===
    ===    - Name
    ===    - RegistryHandle
    ===    - PostalAddress
    ===    - Email
    ===    - Telephone



Meijer, et al.           Expires March 29, 2004                [Page 65]

Internet-Draft    IODEF Data Model and Implementation     September 2003
    ===    - Fax
    ===    - TimeZone Timezone
    ===    - Contact (recursive)
    ====================================================================
    -->
   <!ELEMENT Contact (Name?, Description*, RegistryHandle*, PostalAddress?, Email*, Telephone*, Fax?, TimeZone, Timezone, Contact*)>
   <!ATTLIST Contact
        contactrole (creator | admin | tech | irt | cc) #REQUIRED
        contacttype (person | organization) #REQUIRED




Meijer, et al.            Expires May 10, 2005                 [Page 57]



Internet-Draft    IODEF Data Model and Implementation      November 2004



        restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT RegistryHandle (#PCDATA)>
   <!ATTLIST RegistryHandle
        type %attvals.registrytype; "local"
   >
   <!ELEMENT PostalAddress (#PCDATA)>
   <!ATTLIST PostalAddress
        lang NMTOKEN #IMPLIED
   >
   <!ELEMENT Email (#PCDATA)>
   <!ELEMENT Telephone (#PCDATA)>
   <!ELEMENT Fax (#PCDATA)>
   <!--
    ====================================================================
    ===  Time-based classes                                          ===
    ===    - DateTime
    ===    - ReportTime
    ===    - DetectTime
    ===    - StartTime
    ===    - EndTime
    ====================================================================
    -->
   <!ELEMENT DateTime (#PCDATA)>
   <!ATTLIST DateTime
   	ntpstamp CDATA #IMPLIED
   >
   <!ELEMENT ReportTime (#PCDATA)>
   <!ATTLIST ReportTime
   	ntpstamp CDATA #IMPLIED
   >
   <!ELEMENT DetectTime (#PCDATA)>
   <!ATTLIST DetectTime
   	ntpstamp CDATA #IMPLIED
   >
   <!ELEMENT StartTime (#PCDATA)>
   <!ATTLIST StartTime
   	ntpstamp CDATA #IMPLIED
   >



Meijer, et al.           Expires March 29, 2004                [Page 66]

Internet-Draft    IODEF Data Model and Implementation     September 2003 (#PCDATA)>
   <!ELEMENT EndTime ReportTime (#PCDATA)>
   <!ELEMENT DetectTime (#PCDATA)>
   <!ATTLIST DetectTime
   <!ELEMENT StartTime (#PCDATA)>
   <!ELEMENT EndTime
   	ntpstamp CDATA #IMPLIED
   > (#PCDATA)>


   <!--
    ====================================================================
    ===  History class                                               ===
    ===    - HistoryItem
    ====================================================================
    -->
   <!ELEMENT History (HistoryItem+)>
   <!ATTLIST History
        restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT HistoryItem (DateTime, IncidentID?, Description+)>
   <!ATTLIST HistoryItem
        type %attvals.historycat; #IMPLIED
        restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ===  Expectation class                                           ===




Meijer, et al.            Expires May 10, 2005                 [Page 58]



Internet-Draft    IODEF Data Model and Implementation      November 2004



    ====================================================================
    -->
   <!ELEMENT Expectation (Description+, Contact?, StartTime?, EndTime?)>
   <!ATTLIST Expectation
        priority %attvals.priority; #IMPLIED
        restriction %attvals.restriction; #IMPLIED
        category %attvals.expectcat; #IMPLIED
   >
   <!--
    ====================================================================
    ===  Method class                                                ===
    ===    - Classification
    ====================================================================
    -->
   <!ELEMENT Method (Classification*, Description*)>
   <!ATTLIST Method
        restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT Classification (name, url?)>
   <!ATTLIST Classification
        restriction %attvals.restriction; #IMPLIED
        origin %attvals.origin; "other"
   >
   <!--
    ====================================================================
    ===  Assessment class                                            ===



Meijer, et al.           Expires March 29, 2004                [Page 67]

Internet-Draft    IODEF Data Model and Implementation     September 2003
    ===    - Impact
    ===    - TimeImpact
    ===    - MonetaryImpact
    ===    - LifeImpact
    ===    - Confidence
    ====================================================================
    -->
   <!ELEMENT Assessment (Impact*, TimeImpact*, MonetaryImpact*, LifeImpact*, Confidence?)>
   <!ATTLIST Assessment
        restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT Impact (#PCDATA)>
   <!ATTLIST Impact
   	restriction %attvals.restriction; #IMPLIED
        severity %attvals.severity; #IMPLIED
        completion %attvals.completion; #IMPLIED
        type %attvals.impacttype; "unknown"
        lang NMTOKEN #IMPLIED
   >
   <!ELEMENT TimeImpact (#PCDATA)>
   <!ATTLIST TimeImpact
   	restriction %attvals.restriction; #IMPLIED
        severity %attvals.severity; #IMPLIED
        unit (labor | elapsed | downtime) #REQUIRED




Meijer, et al.            Expires May 10, 2005                 [Page 59]



Internet-Draft    IODEF Data Model and Implementation      November 2004



        metric (days | hours | minutes | seconds) "hours"
   >
   <!ELEMENT MonetaryImpact (#PCDATA)>
   <!ATTLIST MonetaryImpact
   	restriction %attvals.restriction; #IMPLIED
        severity %attvals.severity; #IMPLIED
        currency CDATA #REQUIRED
   >
   <!ELEMENT LifeImpact (#PCDATA)>
   <!ATTLIST LifeImpact
   	restriction %attvals.restriction; #IMPLIED
        severity %attvals.severity; #IMPLIED
        metric (deaths | injuries) #REQUIRED
   >
   <!ELEMENT Confidence EMPTY>
   <!ATTLIST Confidence
        rating %attvals.rating; #REQUIRED
   >
   <!--
   ====================================================================
   === EventData class                                              ===
   ====================================================================
    -->
   <!ELEMENT EventData (Description*, Contact*, ReportTime?, DetectTime?, StartTime?, EndTime?, Expectation?, System*, Method*, Contact*, Assessment?, Method*, Flow*, EventData*, History?, Record?, AdditionalData*)>



Meijer, et al.           Expires March 29, 2004                [Page 68]

Internet-Draft    IODEF Data Model and Implementation     September 2003


   <!ATTLIST EventData
        restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ===  Flow and System class                                       ===
    ===  Note. Represents merged Source and Target classes of IDMF IDMEF
    ===  (sections 4.2.4.3, 4.2.4.4)
    ====================================================================
    -->
   <!ELEMENT Flow (System+)>


   <!ELEMENT System (Node, User*, Process*, Service*, FileList?)> Counter*)>
   <!ATTLIST System
        category %attvals.systemcat; #IMPLIED
        spoofed %attvals.spoofed; "unknown"
        interface CDATA #IMPLIED
        restriction %attvals.restriction; #IMPLIED
   >
   <!--
   ====================================================================
       ===  FileList
   ====== Node class               IDMEF (4.2.7.5)        ===
       ===    - File
       ===        - access-time
       ===        - change-time
       ===        - create-time                                                ===        - modify-time
       ===        - c-major-device
   ===      - c-minor-device Address
   ===      - data-size NodeRole
   ===      - disk-size
       ====================================================================
       -->
   <!ELEMENT FileList (File+)>
   <!ENTITY % attvals.filecat "
             ( current | original )
              ">
   <!ELEMENT File (name, path, create-time?, modify-time?, access-time?, data-size?, disk-size?, FileAccess*, Linkage*, Inode?)>
   <!ATTLIST File
   	ident CDATA "0"
   	category %attvals.filecat; #REQUIRED
   	fstype CDATA #REQUIRED
   >
   <!ELEMENT access-time (#PCDATA)>
   <!ELEMENT change-time (#PCDATA)>
   <!ELEMENT create-time (#PCDATA)>
   <!ELEMENT modify-time (#PCDATA)>
   <!ELEMENT c-major-device (#PCDATA)>
   <!ELEMENT c-minor-device (#PCDATA)>
   <!ELEMENT data-size (#PCDATA)> Location




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 69] 60]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   <!ELEMENT disk-size (#PCDATA)>
   <!ELEMENT major-device (#PCDATA)>
   <!ELEMENT minor-device (#PCDATA)>
   <!ELEMENT Linkage ((name, path) | File)>
   <!ATTLIST Linkage
   	category %attvals.linkcat; #REQUIRED
   >
   <!ELEMENT FileAccess (UserId, permission+)>
   <!ELEMENT Inode (change-time?, (number, major-device, minor-device)?, (c-major-device, c-minor-device)?)>
   <!--
   ====================================================================
   ====== Node class                                        ===
    ===      - Address
    ===      - NodeRole
    ===      - Location      November 2004



   ===      - name
   ===    Note. IODEF Node class is extended IDMEF Node class (4.2.7.1):
   ===        <!ELEMENT Node ( location?, (name | Address), Address* )>
   ====================================================================
   -->
   <!ELEMENT Node (name?, Address*, DateTime?, Location?, NodeRole*)> NodeRole*, Counter*)>
   <!ATTLIST Node
        category %attvals.nodecat; "unknown"
   >
   <!ELEMENT Address (address, netmask?)> (#PCDATA)>
   <!ATTLIST Address
   	ident CDATA "0"
        category %attvals.addrcat; "unknown" "ipv4-addr"
        vlan-name CDATA #IMPLIED
        vlan-num CDATA #IMPLIED
   >
   <!ELEMENT address (#PCDATA)>
   <!ELEMENT netmask (#PCDATA)>
   <!ELEMENT Location (#PCDATA)>
   <!ATTLIST Location
        lang NMTOKEN #IMPLIED
   >
   <!ELEMENT NodeRole (#PCDATA)>
   <!ATTLIST NodeRole
        category %attvals.noderolecat; "other"
        lang NMTOKEN #IMPLIED
   >


   <!--
    ====================================================================
       ===  User class                                                  ===
       ===   - UserID
       ====================================================================
       -->



Meijer, et al.           Expires March 29, 2004                [Page 70]

Internet-Draft    IODEF Data Model and Implementation     September 2003


   <!ELEMENT User (UserId+)>
   <!ATTLIST User
   	ident CDATA "0"
   	category %attvals.usercat; "unknown"
   >
   <!ELEMENT UserId ( (number, name?) | (name, number?))>
   <!ATTLIST UserId
   	ident CDATA "0"
   	type %attvals.idtype; "original-user"
   >
   <!ELEMENT number (#PCDATA)>
   <!--
    ====================================================================
    ===  Process class                                               ===
    ===  IDMEF (4.2.7.3)
    ===   <!ELEMENT Process (name, pid?, path?, arg*, env* )>
    ====================================================================
    ===  Counter class                                               ===
    ====================================================================
    -->
   <!ELEMENT Process (name, pid?, path?, arg*, env*)> Counter (#PCDATA)>
   <!ATTLIST Process
   	ident Counter
        type (packet | session | event | other )  "other"
         meaning CDATA "0" #IMPLIED
   >
   <!ELEMENT env (#PCDATA)>
   <!ELEMENT pid (#PCDATA)>


   <!--
    ====================================================================
    ===  Service Class                                               ===
    ===    - port
    ===    - portlist
    ===    - protocol
    ===    - SNMPService
    ===    - WebService
    ===        - url, cgi, arg, http-method
    ===    - SNMPService
    ===        - oid, community, command
    ===   IDMEF (4.2.7.4)
    ====================================================================
    -->
   <!ELEMENT Service (((name?, port), ((port | portlist), protocol?, SNMPService?, WebService?)> Application?)>
   <!ATTLIST Service
   	ident
         ip_version CDATA "0"
   >
   <!ELEMENT port (#PCDATA)>
   <!ELEMENT portlist (#PCDATA)>
   <!ELEMENT protocol (#PCDATA)>
   <!--
       ====== Web Service ======
       -->  "4"
         ip_protocol CDATA #REQUIRED




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 71] 61]



Internet-Draft    IODEF Data Model and Implementation     September 2003


   <!ELEMENT WebService (url, cgi?, http-method?, arg*)>
   <!ELEMENT cgi (#PCDATA)>
   <!ELEMENT arg (#PCDATA)>
   <!ELEMENT http-method (#PCDATA)>
   <!--
       ====== SNMPService ======
       -->
   <!ELEMENT SNMPService (oid?, community?, command?)>      November 2004



   >


   <!ELEMENT oid port (#PCDATA)>
   <!ELEMENT community portlist (#PCDATA)>


   <!ELEMENT command (#PCDATA)> Application (name, url?)>
   <!ATTLIST Application
         appid    CDATA    "0"
         configid CDATA "0"
         vendor_name CDATA #IMPLIED
         version CDATA  #IMPLIED
   >


   <!--
    ====================================================================
    ===  Record class                                                ===
    ===    - RecordData
    ===    - Analyzer
    ===    - RecordItem
    ====================================================================
    -->
   <!ELEMENT Record (RecordData+)>
   <!ATTLIST Record
        restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT RecordData (Description*, DateTime?, Analyzer?, RecordItem+)>
   <!ATTLIST RecordData
        ident CDATA "0"
        restriction %attvals.restriction; #IMPLIED
   >
   <!--Element Analyzer of IODEF is re-used from IDMEF (4.2.4.1) -->
   <!ELEMENT Analyzer (Node?, Process?)>
   <!ATTLIST Analyzer
        analyzerid CDATA "0"
        manufacturer CDATA #IMPLIED
        model CDATA #IMPLIED
        version CDATA #IMPLIED
        class CDATA #IMPLIED
        ostype CDATA #IMPLIED
        osversion CDATA #IMPLIED
   >
   <!--Element Process of IODEF is re-used from IDMEF (4.2.7.3) -->
   <!ELEMENT Process (name, pid?, path?, arg*, env*)>
   <!ATTLIST Process
        ident CDATA "0"
   >
   <!ELEMENT env (#PCDATA)>
   <!ELEMENT pid (#PCDATA)>




Meijer, et al.            Expires May 10, 2005                 [Page 62]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   <!ELEMENT path (#PCDATA)>


   <!ELEMENT RecordItem ANY>
   <!ATTLIST RecordItem
        dtype %attvals.dtype; #REQUIRED
   >
   <!--
    ====================================================================
    === Simple classes containing multilingual content               ===
    ===   - Description
    ===   - Contact.Name



Meijer, et al.           Expires March 29, 2004                [Page 72]

Internet-Draft    IODEF Data Model and Implementation     September 2003
    ====================================================================
    -->
   <!ELEMENT Description ANY>
   <!ATTLIST Description
        preserve %attvals.preserve; #IMPLIED
        transform %attvals.transform; #IMPLIED
        lang NMTOKEN #IMPLIED
   >
   <!ELEMENT Name ANY>
   <!ATTLIST Name
        preserve %attvals.preserve; #IMPLIED
        transform %attvals.transform; #IMPLIED
        lang NMTOKEN #IMPLIED
   >
   <!--
    ====================================================================
    === Miscellaneous simple classes                                 ===
    ===   - path url
    ===   - url name
    ====================================================================
    -->
   <!ELEMENT name (#PCDATA)>
   <!ATTLIST name
        lang NMTOKEN #IMPLIED
   >
   <!ELEMENT path (#PCDATA)>
   <!ELEMENT url (#PCDATA)>
   <!--
    ====================================================================
    ===  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.
    -->
   <!--




Meijer, et al.            Expires May 10, 2005                 [Page 63]



Internet-Draft    IODEF Data Model and Implementation      November 2004



    ====================================================================
    === SECTION 2. Attribute value declarations.  Enumerated values  ===
    ===            for the many element-specific attribute lists.    ===
    ====================================================================
    -->
   <!--
    | Defines purpose of the Incident
    -->
   <!ENTITY % attvals.purpose "
            ( handling | statistics | warning | other )



Meijer, et al.           Expires March 29, 2004                [Page 73]

Internet-Draft    IODEF Data Model and Implementation     September 2003
         ">
   <!--
    | Defines restriction on access to an element's content
    -->
   <!ENTITY % attvals.restriction "
            ( default | public | need-to-know | private )
         ">
   <!--
    | Values for the Expectation.expectcat attributes
    -->
   <!ENTITY % attvals.expectcat "
            ( nothing | contact-site | contact-me | investigate | block | other )
         ">
   <!--
    | Values for the AdditionalData.type attribute.
    -->
   <!ENTITY % attvals.adtype "
            ( boolean | byte | character | date-time | integer |
              ntpstamp | portlist | real | string | xml )
          ">
   <!--
    | Values for the RecordItem.type attribute
    -->
   <!ENTITY % attvals.dtype "
            ( boolean | byte | character | date-time | integer |
              ntpstamp | portlist | real | string | file | path | url |
        xml )
           ">
   <!--
    | Values for the History.type attribute.
    -->
   <!ENTITY % attvals.historycat "
             ( triaged | notification | shared-info | received-info |
               remediation | other )
            ">
   <!--
    | Values for the Address.category attribute.
    -->




Meijer, et al.            Expires May 10, 2005                 [Page 64]



Internet-Draft    IODEF Data Model and Implementation      November 2004



   <!ENTITY % attvals.addrcat "
            ( unknown | atm | e-mail | lotus-notes | mac | sna | vm |
              ipv4-addr | ipv4-addr-hex | ipv4-net | ipv4-net-mask |
              ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask |
              asn |
              vm | e-mail | lotus-notes )
          ">
   <!--
    | Values for the Id.type attribute.
    -->
   <!ENTITY % attvals.idtype "
            ( current-user | original-user | target-user | user-privs |



Meijer, et al.           Expires March 29, 2004                [Page 74]

Internet-Draft    IODEF Data Model and Implementation     September 2003
              current-group | group-privs )
          ">
   <!--
    | Values for the Impact.completion attribute.
       -->
   <!ENTITY % attvals.completion "
             ( failed | succeeded )
           ">
   <!--
       | Values for the File.category Impact.completion attribute.
    -->
   <!ENTITY % attvals.filecat attvals.completion "
             ( current failed | original succeeded )
           ">
   <!--
    | Values for the Impact.type attribute.
    -->
   <!ENTITY % attvals.impacttype "
             ( none | admin | dos | file | recon | user | unknown |
               other )
           ">
   <!--
    | Values for the Linkage.category attribute.
       -->
   <!ENTITY % attvals.linkcat "
             ( hard-link | mount-point | reparse-point | shortcut |
               stream | symbolic-link )
           ">
   <!--
       | Values for the RegistryHandle.type attribute.
    -->
   <!ENTITY % attvals.registrytype "
         ( internic | apnic | arin | lacnic | ripencc | ti | local )
       ">
   <!--
    | Values for the Confidence.rating attribute.
    -->
   <!ENTITY % attvals.rating "
             ( low | medium | high | numeric | unknown )
           ">
   <!--
    | Values for the Impact.severity attribute.
    -->
   <!ENTITY % attvals.severity "
             ( low | medium | high )
           ">
   <!ENTITY % attvals.priority "
             ( low | medium | high )
           ">




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 75] 65]



Internet-Draft    IODEF Data Model and Implementation     September 2003


           ">      November 2004



   <!--
    | Values for the Node.category attribute.
    -->
   <!ENTITY % attvals.nodecat "
            ( unknown | ads | afs | coda | dfs | dns | hosts |
              kerberos | nds | nis | nisplus | nt | wfw )
          ">
   <!--
    | Values for the NodeRole.category attribute.
    -->
   <!ENTITY % attvals.noderolecat "
           ( client | server-internal | server-public | www | mail |
             messaging | streaming | voice | file | ftp | p2p | name |
             directory | credential | print | application | database |
             infra | log | other )
          ">
   <!--
    | Values for the Classification.origin attribute.
    -->
   <!ENTITY % attvals.origin "
            ( bugtraqid | cve | certcc | vendor | local | other)
         ">
   <!--
    | Values for the User.category attribute.
       -->
   <!ENTITY % attvals.usercat "
            ( unknown | application | os-device )
         ">
   <!--
       | Values for the System.spoofed attribute
    -->
   <!ENTITY % attvals.spoofed "
            ( unknown | yes | no )
         ">
   <!--
    | Values for the System.category attribute
    -->
   <!ENTITY % attvals.systemcat "
        ( source | target | intermediate )
        ">
   <!--
    | Values for the MultilingText.preserve and MultilingText.transform attribute
    -->
   <!ENTITY % attvals.preserve "
        ( yes | no )
        ">
   <!ENTITY % attvals.transform "



Meijer, et al.           Expires March 29, 2004                [Page 76]

Internet-Draft    IODEF Data Model and Implementation     September 2003
        ( none | Base64 | QP | stringprep | zip | URI )
      	">
   <!--
   Full Copyright Statement

      Copyright (C) The Internet Society (2002).  All Rights Reserved.

      This document and translations of it may be copied and furnished to others,
      and derivative works that comment on or otherwise explain it or assist in
      its implementation may be prepared, copied, published and distributed, in
      whole or in part, without restriction of any kind, provided that the above
      copyright notice and this paragraph are included on all such copies and
      derivative works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the Internet
      Society or other Internet organizations, except as needed for the purpose of
      developing Internet standards in which case the procedures for copyrights
      defined in the Internet Standards process must be followed, or as required
      to translate it into languages other than English.

      The limited permissions granted above are perpetual and will not be revoked
      by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on an "AS IS"
      basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
      DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
      ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
      RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE.

      Acknowledgement

      Funding for the RFC Editor function is currently provided by the Internet
      Society.
   --> Base64 | QP | stringprep | zip | URI )
        ">









Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 77] 66]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



9.  Security considerations


   Due to the sensitive nature of some of the data that might be
   represented in the IODEF, the integrity, confidentiality, and
   non-repudiation of these documents in transit SHOULD be ensured.
   Although this protection can be provided by the transport mechanism,
   applying this security to an instance of the IODEF document itself is RECOMMENDED.  However, the specific protective measures applied to an
   IODEF document (be in through XML or the underlying transport
   protocol) should be driven by the requirements of


   When used, the collaborators.

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


   o  IODEF-Document with XML signature (Section 7.2)


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


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

   Information


   Additional information on the implementation-specifics of applying XML Digital Signatures and XML
   Encryption to an IODEF-Document IODEF document can be found in the IODEF
   Implementation Guide [20].

   When using cryptographic techniques the issue of key management
   (whether symmetric or public key cryptography is used) must be
   addressed.

   Overall security measures must be applied to secure the
   IODEF-Document processing environment.  The definition of these
   measures is outside the scope of this memo. [18].



























Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 78] 67]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



10.  IANA considerations



















































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 79] 68]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



11.  Acknowledgments


   The following groups contributed substantially to this document and
   should be recognized for their efforts. This document would not exist
   without their help:


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


   o  the eCSIRT.net project











































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 80] 69]



Internet-Draft    IODEF Data Model and Implementation     September 2003      November 2004



12.  References


12.1  Normative References


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


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


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


   [4]   World Wide Web Consortium, "Extensible Stylesheet Language
         (XSL) Version 1.0", , October 2001, <http://www.w3.org/TR/xsl/
         >.
         <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, January 2003. 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]  Mills, D., "Network Time Protocol (Version 3) Specification,
         Implementation, and Analysis", BCP 2278, March 1992.

   [11]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
         IPv4, IPv6 and OSI", RFC 2030, October 1996.

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

   [13]


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

   [14]


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

   [15]  International Organization for Standardization, "International
         Standard: Data elements and interchange formats -  Information



Meijer, et al.           Expires March 29, 2004                [Page 81]

Internet-Draft    IODEF Data Model and Implementation     September 2003


         interchange - Representation of dates and times", ISO 8601,
         Second Edition, December 2000.

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

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

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





































Meijer, et al.           Expires March 29, 2004                [Page 82]

Internet-Draft    IODEF 2002.


   [13]  International Organization for Standardization, "International
         Standard: Data Model elements and Implementation     September 2003


Informative References

   [19]  Rumbaugh, J., Jacobson, I. interchange formats -  Information
         interchange - Representation of dates and G. Booch, "The Unified Modeling
         Language Reference Model, ISBN 020130998X, Addison-Wesley",
         1998.

   [20]  Helme, A. times", ISO 8601,
         Second Edition, December 2000.


   [14]  Eastlake 3rd, D., Reagle, J. and R. Danyliw, "The IODEF Implementation Guide,
         document to be created by the INCH WG", 2003.


Authors' Addresses

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

   Phone: +31 302 305 305
   EMail: jan.meijer@surfnet.nl


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

   Phone: +1 412 268 7090
   EMail: rdd@cert.org


   Yuri Demchenko
   NLnet Labs
   Netherlands

   EMail: demch@chello.nl D. Solo, "(Extensible Markup




Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 83] 70]



Internet-Draft    IODEF Data Model and Implementation     September 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication      November 2004



         Language) XML-Signature Syntax and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to 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 IETF Executive
   Director. 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


   Jan Meijer
   SURFnet bv
   P.O. Box 19035
   Utrecht  NL-3501 DA
   Netherlands
   Phone: +31 302 305 305
   EMail: jan.meijer@surfnet.nl



   Roman Danyliw
   CERT Coordination Center
   4500 Fifth Ave.
   Pittsburgh, PA  15213
   USA
   Phone: +1 412 268 7090
   EMail: rdd@cert.org



   Yuri Demchenko
   NLnet Labs
   Netherlands
   EMail: demch@chello.nl





Meijer, et al.            Expires May 10, 2005                 [Page 71]



Internet-Draft    IODEF Data Model and Implementation      November 2004



Full Copyright Statement


   Copyright (C) The Internet Society (2003). All Rights Reserved. (2004).  This document and translations of it may be copied and furnished is subject
   to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies rights, licenses and derivative works. However, this
   document itself may not be modified restrictions contained in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, BCP 78, and
   except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by set forth therein, the Internet Society or its successors or assignees. authors retain all their rights.


   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE REPRESENTS
   THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 
   ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
   WARRANTY THAT THE USE OF THE INFORMATION



Meijer, et al.           Expires March 29, 2004                [Page 84]

Internet-Draft    IODEF Data Model and Implementation     September 2003 HEREIN WILL NOT INFRINGE 
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
   FOR A PARTICULAR PURPOSE.


Acknowledgement

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






































Meijer, et al.            Expires March 29, 2004 May 10, 2005                 [Page 85] 72] 
----