view Side-By-Side changes

Network Working Group                                           J.J.                                          J. Meijer
INTERNET-DRAFT
Internet-Draft                                                SURFnet bv
Expires in six months
Expires: September 29, 2003                                   R. Danyliw
                                                CERT Coordination Center
                                                            Y. Demchenko
                                                                  TERENA
                                                            October 2002
                                                              NLnet Labs
                                                          March 31, 2003


  The Incident Object Description and Data Exchange Format Data Model and Extensible Markup Language (XML)
                       Document Type Definition
                   <draft-ietf-inch-iodef-00.txt> XML Implementation
                      draft-ietf-inch-iodef-01.txt

Status of this Memo

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

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

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

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

   Distribution of this memo is unlimited.
   http://www.ietf.org/shadow.html.

   This Internet Draft expires March, Internet-Draft will expire on September 29, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2001). (2003). All Rights Reserved.

Abstract

   The purpose of the Incident Object Description and Data Exchange Format (IODEF) is to define a common
   data format formats for describing and exchanging incident information related to computer security incidents
   typically exchanged between collaborating Computer Security Incident
   Response Teams (CSIRTs).  The specific goals and requirements of the IODEF are
   described in [2]. One of satisfies the design principles requirements
   specified in the IODEF is
   compatibility with the Intrusion Detection Message Exchange Format
   (IDMEF) [3] developed for intrusion detection systems. For this
   reason, IODEF is heavily based on the IDMEF and provides upward
   compatibility with it.



Meijer, et al.            Expires March 2003                    [page 1]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 RFCXXX [1]

   This document Internet-Draft describes a data model for representing commonly
   exchanged incident information
   produced by exported from incident handling
   systems managing security incident
   data, and explains the rationale for using this model. managed by CSIRTs.  An implementation of the data model in



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


   the Extensible Markup Language (XML) is presented, an XML Document
   Type Definition is developed, and examples are provided.
                       

                        
                        TABLE OF CONTENTS

Table of Contents

   1. Conventions Used in This Document................................4
   2.     Introduction ....................................................4
      2.1 IODEF Data MOdel Design principles...........................5
         2.1.1 Problems Addressed by . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1    Terminology  . . . . . . . . . . . . . . . . . . . . . . .   4
   1.2    Overview . . . . . . . . . . . . . . . . . . . . . . . . .   4
   1.3    About the IODEF Data Model ...................5
         2.1.2 . . . . . . . . . . . . . . . .   4
   1.3.1  Issues with Representing Incident Data Model Design Goals ................................6
      2.2 Using XML for . . . . . . . . . .   5
   1.4    About the IODEF .....................................7
      2.3 Relation between IODEF and IDMEF ............................8
   3. Implementation . . . . . . . . . . . . . .   6
   1.5    Related Work . . . . . . . . . . . . . . . . . . . . . . .   6
   2.     Notational Conventions conventions and Formatting Issues ....................8
      3.1 UML Conventions used for Data Model Description .............8
         3.1.1 Relationships...........................................9
         3.1.2 Occurrence Indicators..................................10
      3.2 XML Document Type Definitions ..............................11
      3.3 formatting issues . . . . . . .   8
   2.1    IODEF XML Documents ..............................................11
         3.3.1  . . . . . . . . . . . . . . . . . . .   8
   2.1.1  The Document Prolog ...................................11
            3.3.1.1 XML Declaration ..................................11
            3.3.1.2 IODEF DTD Formal Public Identifier ...............12
            3.3.1.3 IODEF DTD Document Type Declaration ..............12
         3.3.2  . . . . . . . . . . . . . . . . . . .   8
   2.1.2  Character Data Processing in XML and the IODEF ............13
            3.3.2.1 Character Entity References.......................13
            3.3.2.2 Character Code References.........................14
            3.3.2.3 White Space Processing............................14
         3.3.3 . . . . . . . . . .   9
   2.1.3  Languages in XML and the IODEF ............................15
         3.3.4 Inheritance and Aggregation ...........................12
     3.4 . . . . . . . . . . . . . . . . . .  10
   2.2    IODEF Data Types ............................................15
         3.4.1 . . . . . . . . . . . . . . . . . . . . .  11
   2.2.1  Integers ..............................................15
         3.4.2 . . . . . . . . . . . . . . . . . . . . . . . . .  11
   2.2.2  Real Numbers ..........................................15
         3.4.3 . . . . . . . . . . . . . . . . . . . . . . .  11
   2.2.3  Characters and Strings ................................15
         3.4.4 . . . . . . . . . . . . . . . . . .  11
   2.2.4  Bytes .................................................15
         3.4.5  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   2.2.5  Enumerated Types ......................................18
         3.4.6 . . . . . . . . . . . . . . . . . . . . .  12
   2.2.6  Date-Time Strings .....................................18
         3.4.7  . . . . . . . . . . . . . . . . . . . .  12
   2.2.7  NTP Timestamps ........................................20
         3.4.8 . . . . . . . . . . . . . . . . . . . . . .  12
   2.2.8  Port Lists ............................................20
         3.4.9 Unique Identifiers ....................................21
         3.4.10 Personal names........................................22
         3.4.11 Organization name.....................................22
         3.4.12 . . . . . . . . . . . . . . . . . . . . . . . .  12
   2.2.9  Postal address........................................22



Meijer, et al.            Expires March 2003                    [page 2]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         3.4.13 Address . . . . . . . . . . . . . . . . . . . . . .  12
   2.2.10 Person or Organization . . . . . . . . . . . . . . . . . .  13
   2.2.11 Telephone and Fax numbers.............................22
   4. The Numbers  . . . . . . . . . . . . . . . .  13
   2.2.12 Email string . . . . . . . . . . . . . . . . . . . . . . .  13
   2.2.13 Uniform Resource Identifier strings  . . . . . . . . . . .  13
   2.2.14 Unique Identifiers . . . . . . . . . . . . . . . . . . . .  13
   3.     The IODEF Data Model and XML DTD................................23
      4.1 Data Model Overview.........................................23
      4.2 The IODEF-Description Class.................................26
      4.3 The . . . . . . . . . . . . . . . . . . .  14
   3.1    IODEF-Document . . . . . . . . . . . . . . . . . . . . . .  14
   3.2    Incident Class..........................................26
      4.4 The CorrelationIncident Class...............................30
         4.4.1 The EventList Class....................................31
      4.5 The IncidentAlert Class.....................................32
      4.6 The Attack Class............................................33
         4.6.1 The Source Class.......................................35
         4.6.2 The Node Class.........................................38
            4.6.2.1 The Address Class.................................39
            4.6.2.2 The NodeRole Class................................41
         4.6.3 The User Class.........................................43
            4.6.3.1 The UserId Class..................................44
         4.6.4 The Process Class......................................46
         4.6.5 The Service Class......................................47
            4.6.5.1 The WebService Class..............................49
            4.6.5.2 The SNMPService Class.............................50
         4.6.6 The Target Class.......................................51
         4.6.7 The FileList Class.....................................53
            4.6.7.1 The File Class....................................54
            4.6.7.2 The FileAccess Class..............................57
            4.6.7.3 The Linkage Class.................................58
            4.6.7.4 The Inode Class...................................60
         4.6.8 The Description Class..................................62
         4.6.9 The DetectTime Class...................................62
         4.6.10 The class . . . . . . . . . . . . . . . . . . . . . .  14
   3.3    IncidentID class . . . . . . . . . . . . . . . . . . . . .  16
   3.4    AlternativeID class  . . . . . . . . . . . . . . . . . . .  17
   3.5    RelatedActivity class  . . . . . . . . . . . . . . . . . .  18
   3.6    AdditionalData . . . . . . . . . . . . . . . . . . . . . .  19
   3.7    IncidentData . . . . . . . . . . . . . . . . . . . . . . .  20
   3.8    Contact class  . . . . . . . . . . . . . . . . . . . . . .  22
   3.8.1  RegistryHandle class . . . . . . . . . . . . . . . . . . .  25
   3.9    Time classes . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.1  StartTime Class...................................62
         4.6.10 The  . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.2  EndTime Class.....................................63
      4.7 The Method Class............................................63
         4.7.1 The Classification Class...............................64
      4.8 The Attacker Class..........................................65
         4.8.1 The Contact Class......................................67
         4.8.2 The IRTcontact Class...................................68
      4.9 The Victim Class............................................69
      4.10 The Record Class...........................................70
         4.10.1 The RecordData Class..................................71
         4.10.2 The CorrRecord Class..................................72
         4.10.3 The RecordDesc Class..................................73
         4.10.4 The Analyzer Class....................................73
         4.10.5 The RecordItem Class..................................75
      4.11 The AdditionalData Class...................................76
      4.12 The History Class..........................................78
         4.12.1 The HistoryItem class.................................79
         4.12.2 The  . . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.3  DetectTime . . . . . . . . . . . . . . . . . . . . . . . .  26
   3.9.4  ReportTime . . . . . . . . . . . . . . . . . . . . . . . .  27
   3.9.5  DateTime Class....................................80
      4.13 The Assessment Class.......................................80
         4.13.1 The Impact Class......................................81
         4.13.2 The Action Class......................................83
         4.13.3 The Confidence Class..................................84 . . . . . . . . . . . . . . . . . . . . . . . . .  27



Meijer, et al.         Expires September 29, 2003               [Page 2]

Internet-Draft    IODEF Data Model and Implementation         March 2003                    [page 3]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      4.14 The Authority Class........................................85
         4.14.1 The Organization......................................86
   5.


   3.10   Expectation class  . . . . . . . . . . . . . . . . . . . .  27
   3.11   Method class . . . . . . . . . . . . . . . . . . . . . . .  28
   3.11.1 Classification class . . . . . . . . . . . . . . . . . . .  29
   3.12   Assessment class . . . . . . . . . . . . . . . . . . . . .  30
   3.12.1 Impact class . . . . . . . . . . . . . . . . . . . . . . .  31
   3.12.2 TimeImpact class . . . . . . . . . . . . . . . . . . . . .  33
   3.12.3 MonetaryImpact class . . . . . . . . . . . . . . . . . . .  34
   3.12.4 LifeImpact class . . . . . . . . . . . . . . . . . . . . .  35
   3.12.5 Confidence class . . . . . . . . . . . . . . . . . . . . .  36
   3.13   History class  . . . . . . . . . . . . . . . . . . . . . .  38
   3.13.1 HistoryItem class  . . . . . . . . . . . . . . . . . . . .  38
   3.14   EventData class  . . . . . . . . . . . . . . . . . . . . .  40
   3.15   Relating the IncidentData and EventData classes  . . . . .  42
   3.16   Cardinality of EventData . . . . . . . . . . . . . . . . .  43
   3.17   System class . . . . . . . . . . . . . . . . . . . . . . .  44
   3.18   Node class . . . . . . . . . . . . . . . . . . . . . . . .  46
   3.18.1 Address  . . . . . . . . . . . . . . . . . . . . . . . . .  48
   3.18.2 NodeRole class . . . . . . . . . . . . . . . . . . . . . .  48
   3.19   FileList class . . . . . . . . . . . . . . . . . . . . . .  50
   3.20   User . . . . . . . . . . . . . . . . . . . . . . . . . . .  50
   3.21   Process  . . . . . . . . . . . . . . . . . . . . . . . . .  50
   3.22   Service  . . . . . . . . . . . . . . . . . . . . . . . . .  50
   3.23   Record class . . . . . . . . . . . . . . . . . . . . . . .  50
   3.23.1 RecordData class . . . . . . . . . . . . . . . . . . . . .  51
   4.     Extending the IODEF ............................................89
      5.1  . . . . . . . . . . . . . . . . . . .  55
   4.1    Extending the Data Model ...................................88
      5.2 data model . . . . . . . . . . . . . . . . .  55
   4.2    Extending the XML DTD ......................................88
   6. Special  . . . . . . . . . . . . . . . . . .  55
   5.     Processing Considerations .........................................90
      6.1  . . . . . . . . . . . . . . . .  58
   5.1    XML Validity and Well-Formedness ...........................90
      6.2 . . . . . . . . . . . . .  58
   5.2    Unrecognized Data and XML Tags ......................................91
      6.3 Digital Signatures .........................................92 . . . . . . . . . . . . . .  58
   6.     Internationalization issues  . . . . . . . . . . . . . . .  60
   7.     Examples .......................................................92 . . . . . . . . . . . . . . . . . . . . . . . . .  61
   7.1    Code Red detection notification  . . . . . . . . . . . . .  61
   7.2    IODEF-Document with XML signature  . . . . . . . . . . . .  63
   7.3    IODEF-Document encrypted using XML encryption  . . . . . .  63
   7.4    IODEF-Document encrypted and signed using XML signature
          & encryption . . . . . . . . . . . . . . . . . . . . . . .  63
   8.     The IODEF Document Type Definition .............................93 . . . . . . . . . . . .  64
   9. References ....................................................112
   10.     Security Considerations ......................................114
   11. considerations  . . . . . . . . . . . . . . . . .  77
   10.    IANA Considerations ..........................................114
   12. Acknowledgements .............................................114
   13. considerations  . . . . . . . . . . . . . . . . . . .  78
   11.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  79
          Normative References . . . . . . . . . . . . . . . . . . .  80
          Informative References . . . . . . . . . . . . . . . . . .  82
          Authors' Addresses ...........................................114
   14. Full . . . . . . . . . . . . . . . . . . . .  82
          Intellectual Property and Copyright Statement .....................................115 Statements . . . . . .  83






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


1. Conventions Used in This Document 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 RFC 2119 [2].

   Network and Computer Security related RFC2119 [5].

   Definitions for some of the common computer security-related
   terminology used in this
   documents is document can be found in Section 2 of common use, however it contains some specific
   conventions described in [2] and [4].


2. Introduction [1].

1.2 Overview

   The Incident Object Description and Data Exchange Format (IODEF) is intended to be a
   standard format for computer security information exchanged by
   Computer Security Incident Response Teams (CSIRTs) to
   exchange operational (CSIRTs).  The development
   and statistical subsequent deployment of an incident information among
   themselves, their constituency, and their collaborators.  It can
   also provide data format that extends
   beyond a closed communities would improve the basis for operational
   capabilities of the development CSIRTs.

   Assuming widespread adoption of interoperable tools
   and procedures for incident reporting.

   By using the IODEF in their workflow and incident handling system, by the community, an
   organization can potentially benefit from:

   +  a single data schema that can represent information from a
      variety

   o  the increased ease to collaborate with other CSIRTs, on behalf it
      its constituency, to resolve incidents;

   o  increased automation in the processing of subordinate teams or CSIRTs;

   +  a common incident data format that facilities collaboration among
      affected members of data, since the
      commitment of security community  (e.g. users, vendors,
      response teams, law enforcement);



Meijer, et al.            Expires March 2003                    [page 4]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




   +  the simplification analysts to parse free-form textual
      document will be reduced;

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

   o  a common format on which to build inter-operable tools for
      incident handling, such as correlation and
      statistics system systems that process incident reports data
      from different
      CSIRTs.

   The computer security related terminology used in this document is
   described in [1] and [4]. Specific terminology, sites.

   Terminology, notation, and conventions of the data model and XML DTD
   are presented in Sections 3 and 4. 2.  The data model is described in Section 5 with
   examples of its use
   3, and the implementation considerations are covered in Sections 4
   through 6, and 9.  Section 8.  Recognizing the potentially
   diverse user-base implementing the IODEF, 7 provides several examples of IODEF
   documents for representative incidents.  Section 6 discusses 8 formally specifies
   the
   ability to extend XML DTD implementation of the data model.



   2.1

1.3 About the IODEF Data Model Design principles

   The IODEF data model is an object-oriented representation of
   information reported reported, maintained, and maintained exchanged by a CSIRT about a



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


   computer security incident.


      2.1.1 Problems Addressed by the

1.3.1 Issues with Representing Incident Data Model

   The IODEF data model addresses several problems in representing
   incident data:

         +  Incident data

   o  There is inherently heterogeneous. It may encompass
            many functional purposes such as a description of intruder
            behavior or no precise, widely agreed upon definition for an
      incident.  Therefore, the data model does not attempt to imply a
      definition through its implementation.  Rather, a broad
      understanding is assumed that is flexible enough to encompass most
      of the CSIRT community.

   o  Incident data is inherently heterogeneous.  It may encompass many
      functional purposes  such as a description of intruder behavior or
      an analysis process correlating related incidents.  However, even in a single type of incident,
            seemingly disparate information from many sources may need
            to be represented.

            This representation
      An object-oriented model provides extensibility via aggregation
      and sub-classing while preserving the consistency of the model.
      If the data model required modification, it is further complicated by
            the fact extended with new
      classes.  In implementations that incidents may consist do not recognize these
      extensions, the basic subset of varying the data model will still be
      understood.

   o  Incidents have a life-cycle, which causes potentially different
      information or levels of detail to be present depending on their
      stage in the lifecycle. cycle.  For example, newly reported incidents may
      only contain a short description of the involved parties.  On the
      other hand, closed incidents can contain a full description
      complete with the associated evidence and annotation of actions
      taken by the CSIRT.  The data model that represents this
      information must be flexible to accommodate different needs.

            An object-oriented model provides extensible via aggregation

   o  Communication and sub-classing while preserving the consistency of the
            model.  If the data model required modification, it is
            extended with new classes.  In implementations that do not
            recognize these extensions, the basic subset of the data



Meijer, et al.            Expires March 2003                    [page 5]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            model will still be understood.

            In order to address the various types of incidents, the
            IODEF data model creates top-level classes for each of the
            different incident profiles. Just as another other
            extensions coordination are central to the data model, creating new profiles is
            possible through sub-classing or aggregation based on the
            core and supportive classes.

         +  From the purview role of a CSIRT, CSIRT.
      As a result of this activity, incident information can originate
      from a number of sources.  Tracking the all the sources of data is
      key to managing this information.
      The data model defines support classes that accommodate the
      differences between incident reporters. This support includes
      various meta information to represent the reporter's identity as
      well as prescribe a confidence level to the submitted information.

         +  Incidents

   o  Incident data may contain sensitive information. Such information
      should not be exposed to unauthorized parties during
      collaboration.
      The data model allows for a highly granular level of tagging in the individual
      classes to indication restrictions on the usage of the data.
      However, it is the role of the incident handling system
      implementing the data model to honor these labels.


      2.1.2



Meijer, et al.         Expires September 29, 2003               [Page 5]

Internet-Draft    IODEF Data Model Design Goals

         In addition to satisfying the explicit requirements found in
         RFCXXX [2], the IODEF data model is designed with the following
         goals:

         +  The data model is content-driven. This design dictates
            that new representations are introduced only to accommodate
            new types of data, not semantic differences between
            incidents.

         +  Since organizations may define an incident in different
            ways, the data model avoids implicitly relying on a single
            definition of an incident. Rather, it is designed to be
            flexible enough to accomodate a range of understandings in
            what constitutes incident activity.

         +  Where security-related, XML work already exist (e.g., IDMEF
            [3]), the data model will provide support for them.




Meijer, et al.            Expires March 2003                    [page 6]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




   2.2 Using XML for and Implementation         March 2003


1.4 About the IODEF Implementation

   The IODEF implementation is based on uses the Extensible Markup Language (XML). (XML)
   [2].  XML-based applications specifications define their own an XML DTD or Schema and
   register a specific XML namespace [6]. [3]. The IODEF conforms to the
   IETF-defined procedure for registering an application-specific XML
   namespace [9].

      NOTE:

      For clarity in this document, we will use the terms "XML" and "XML
      documents" when speaking in the general case about the Extensible
      Markup Language (XML).  The terms "IODEF description", "IODEF
      markup" and "IODEF  document" will be used to refer to specific
      elements (tags) and attributes of the IODEF DTD.  Furthermore, the
      terms "class" and "subclass" are synonymous to an element in the
      XML DTD.

   The implementation of the IODEF in XML has many benefits:

      +

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

      +

   o  Software tools for processing XML documents are widely available
      in commercial and open source forms.

      +

   o  XML can provide support for full aid in implementing internationalization and localization
      since it is required (and therefore IODEF documents are required)
      to support both the UTF-8 and UTF-16 encodings of ISO/IEC 10646
      (Universal Multiple-Octet Coded Character Set, "UCS") and Unicode.
      XML also provides support for specifying, on a per-element basis,
      the language in which the element's content is written, making the
      IODEF easy to adapt to the local languages in which a CSIRTs
      operates.

      +

   o  XML coupled with XSL, XSL [4], a style language, allows IODEF documents
      to be aggregated, filtered, discarded, and rearranged.

      +

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


   2.3 Relationship between the IODEF and the IDMEF


1.5 Related Work

   The IODEF and the IDMEF [3] [7] are complementary formats.  The latter
   represents data generated by an intrusion detection system.  Such



Meijer, et al.            Expires March 2003                    [page 7]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002
   event data is commonly used by a CSIRT as the basis for an incident
   report or investigation which is represented by the IODEF.



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


   The IODEF data model makes use of certain classes defined in the
   IDMEF, although the semantics of some of these classes has changed.
   Due to their related nature, the data in an IDMEF message can be
   easily represented in an IODEF document.  Through various extension
   mechanisms, it is possible to include IDMEF messages outright in an
   IODEF document.  Alternatively, the similarity in structure of the
   data model makes it possible to decompose the key IDMEF data and
   include it in the corresponding IODEF classes.  However, this
   transformation may not preserve the original semantics of the data.



3.










































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


2. Notational Conventions 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)
   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 briefly introduces these notations, describes the XML notations and conventions used in this
   memo and explains particular issues related to using them to describe
   the IODEF data model and syntax.  For readers unfamiliar with these notations,
   [3]
   notations [19] and [10] [7] will provide a comprehensive reference.


   3.1 Unified Modeling Language conventions used for IODEF Data Model
       description

2.1.1 The IODEF data model is described using the Unified Modeling
      Language (UML) [10]. UML provides a simple framework to represent
      entities and their relationships. UML defines entities as classes.
      In this Document Prolog

   The "prolog" of an XML document, we have identified several classes that part that precedes anything
   else, consists of the XML declaration and their
      associated attributes.  The symbols used in this the document to
      represent classes and attributes are shown in Figure 3.1.


      +-------------+
      | Class Name  |     <----- Name of class
      +-------------+
      | Attribute 1 |     <----- Name type
   declaration.

2.1.1.1 XML Declaration

   Every IODEF document starts with an XML declaration. The XML
   declaration specifies the version of first attribute
      | ...         |
      | Attribute N |     <----- Name XML being used, and optionally
   the character encoding being used (see Section 2.1.2).

   The XML declaration looks like:

   <?xml version="1.0" ?>

   IODEF documents exchanged between applications MUST begin with an XML
   declaration and MUST specify the XML version in use. Specification of nth attribute
      +-------------+
   the encoding in use is REQUIRED if UTF-8 encoding is not used.

2.1.1.2 IODEF DTD Formal Public Identifier

   The formal public identifier (FPI) for the IODEF Document Type
   Definition described in this document is:

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

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

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



Meijer, et al.         Expires March September 29, 2003                    [page               [Page 8]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




      Figure 3.1 - Symbols representing classes

Internet-Draft    IODEF Data Model and attributes

      Note that the associated attributes Implementation         March 2003


2.1.1.3 IODEF DTD Document Type Declaration

   The document type declaration for a class may not appear in
      all diagrams an XML document referencing the
   IODEF DTD will be specified in which the class is used.


      3.1.1 Relationships

         The following ways:

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

    The last component of the UML relationship types:
         inheritance and aggregation.

         Inheritance denotes a superclass/subclass document type of relationship
         where the subclass inherits all declaration is the attributes, operations, and
         relationships FPI
   specified in Section 2.1.1.2.

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

    The last component of the superclass.  Subclasses may have
         additional attributes or operations document type declaration is a URI that apply only
   points to a copy of the
         subclass, and not Document Type Definition.

2.1.2 Character Data Processing in the IODEF

   A document's XML declaration specifies the character encoding to be
   used in the superclass.

         In this document, inheritance as follows:

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

   where "charset" is denoted by the /_\ symbol. In
         Figure 3.2, we are showing that Book and Magazine are two types name of Publication.  Book inherits all the attributes of
         Publication, plus all of its own attributes (thus, it has four
         attributes in total); character encoding, as does Magazine (giving it three
         attributes in total).

                +-------------+
                | Publication |
                +-------------+
                | publisher   |
                | pubDate     |
                +-------------+
                      /_\
                       |
              +--------+--------+
              |                 |
         +----------+     +----------+
         | Magazine |     |   Book   |
         +----------+     +----------+
         | name     |     | title    |
         |          |     | author   |
         +----------+     +----------+

         Figure 3.2 - Inheritance relationships


         Aggregation is a form of association in which registered
   with the whole is
         related to its parts.  In this case, Internet Assigned Numbers Authority (IANA), see [9].

   The XML standard requires that XML processors support the aggregate class
         contains all of its own attributes UTF-8 and as many
   UTF-16 encodings of the
         attributes associated with its parts as required ISO/IEC 10646 (UCS) and



Meijer, et al.            Expires March 2003                    [page 9]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         specified by Unicode, making all XML
   applications (and therefore, all IODEF-compliant applications)
   compatible with these common character encodings.

   While XML supports other character encodings (e.g., UTF-7, UTF-32),
   implementers should carefully consider the occurrence indicators (see Section 3.1.2).

         In this document, portability implications
   of using character encodings other than UTF-8 and UTF-16.

   Consistent with the symbol <> XML standard, if no encoding is used to indicate
         aggregation. It specified for an
   IODEF document, UTF-8 is placed at the end of the association line
         closest to assumed.  IODEF documents encoded in UTF-16
   MUST begin with the aggregate (whole) class.  In Figure 4.3, we
         are showing that a Book is made up of pieces called Preface,
         Chapter, Appendix, Bibliography, and Index.


         +----------+
         |   Book   |
         +----------+       0..1 +--------------+
         | title    |<>----------| Preface      |
         | author   |            +--------------+
         |          |       1..* +--------------+
         |          |<>----------| Chapter      |
         |          |            +--------------+
         |          |       0..* +--------------+
         |          |<>----------| Byte Order Mark described by ISO/IEC 10646 Annex
   E and Unicode Appendix     |
         |          |            +--------------+
         |          |       0..1 +--------------+
         |          |<>----------| Bibliography |
         |          |            +--------------+
         |          |            +--------------+
         |          |<>----------| Index        |
         |          |            +--------------+
         +----------+

         Figure 3.3 - Aggregation relationships


      3.1.2 Occurrence Indicators

         Occurrence indicators show B (the "ZERO WIDTH NO-BREAK SPACE" character,
   #xFEFF).

2.1.2.1 Character Entity References

   Within XML documents, certain characters have special meanings in
   some contexts.  To include the number actual character itself in one of objects within
   these contexts, a class
         that are linked to one another by special escape sequence, called an aggregation relationship.
         They are placed at the end of the association line closest entity
   reference, must be used.

   The characters that sometimes need to
         the part they refer to.  Occurrence indicators, as used in this
         document, are:

            n   exactly "n" (left blank if n=1)
         0..*   (in XML, *) zero or more
         1..*   (in XML, +) one or more
         0..1   (in XML, ?) zero or one
         n..m   between "n" be escaped, and "m" inclusive

         In Figure 3.3, the Book:

         +   may have no Preface or one Preface;
         +   must have at least one Chapter, but may have more; their entity



Meijer, et al.         Expires September 29, 2003               [Page 9]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 10]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         +   may have


   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 number possibility of Appendixes; misinterpretation.

2.1.2.2 Character Code References

   Any character defined by the ISO/IEC 10646 and
         +   must have exactly one Index.


   3.2 XML Document Type Definitions Unicode standards may
   be included in an XML Document Type Definitions (DTDs) are used to declare the
      syntax or markup for document by the IODEF.

      The different pieces use of information the XML document will
      contain are elements, the characteristics of that information
      are the attributes, and the relationship between the information
      is the content model.

      Section 8 of this document contains the complete IODEF DTD.


   3.3 XML Documents

      This section describes a number of XML document formatting rules;
      these rules apply to IODEF documents as well.


      3.3.1 The Document Prolog

         The "prolog" of an XML document, that part that precedes
         anything else, consists of character reference. A
   character reference is started with the XML declaration characters '&' and the document
         type declaration.


         3.3.1.1 XML Declaration

            Every XML document (and therefore every IODEF document)
            starts '#', and
   ended with an XML declaration.  The XML declaration
            specifies the version of XML being used; it may also specify character ';'.  Between these characters, the
   character encoding being used.

            The XML declaration looks like:

            <?xml version="1.0" ?> code for the character inserted.

   If a the character encoding code is specified, the declaration looks
            like:

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

            where "charset" preceded by an 'x' it is the name of the character encoding interpreted in use
            (see Section 3.3.2).  If no encoding
   hexadecimal (base 16), otherwise, it is specified, UTF-8 interpreted in decimal (base
   10).  For instance, the ampersand (&) is
            assumed.  IODEF documents being exchanged between



Meijer, et al.            Expires March 2003                   [page 11]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            IODEF-compliant applications MUST begin with an XML
            declaration, encoded as &#38; or &#x0026;
   and MUST specify the XML version less-than sign (<) is encoded as &#60; or &#x003C;.

   Any one-, two-, or four-byte character specified in use.
            Specification of the encoding ISO/IEC 10646
   and Unicode standards can be included in use is RECOMMENDED.

            IODEF-compliant applications MAY choose to omit a document using this
   technique.

2.1.2.3 White Space Processing

   All IODEF elements support the XML
            declaration internally "xml:space" attribute. If "xml:space"
   is set to conserve space, adding it only
            when "preserve," the message IODEF processing application MUST treat all
   white space in the element's content as significant.  If "xml:space"
   is sent to another destination (e.g., a web
            browser).  This practice "default," the application is NOT RECOMMENDED unless free to do whatever it can be
            accomplished without loss of each message's version and
            encoding information.


         3.3.1.2 normally
   would with white space in the element's content.

2.1.3 Languages in the IODEF DTD Formal Public Identifier

   All IODEF tags support the "xml:lang" attribute thereby allowing each
   element to identify the language in which its content is.  The formal public identifier (FPI) valid
   language code for the IODEF Document
            Type Definition "xml:lang" attribute are described in this document is:

            "-//IETF//DTD RFCxxxx RFC 3066
   [6].




Meijer, et al.         Expires September 29, 2003              [Page 10]

Internet-Draft    IODEF v0.0//EN"

            NOTE: The "RFCxxxx" text Data Model and Implementation         March 2003


   IODEF messages SHOULD specify the language in which their contents
   are encoded. In general, the FPI value will language can be replaced specified with the actual RFC number, if this document is published as
            an RFC.

            This FPI MUST be used
   "xml:lang" attribute in the document type declaration
            within top-level element and letting all other
   elements "inherit" that definition.

   If no language is specified in an XML document referencing the IODEF DTD defined by
            this document, as shown in the following section.


         3.3.1.3 English SHOULD be
   assumed.

2.2 IODEF DTD Document Type Declaration

            The document type declaration for an XML document
            referencing Data Types

2.2.1 Integers

   Integer attributes are represented by the IODEF DTD will usually INTEGER data type. Integer
   data MUST be specified encoded in Base 10 or Base 16.

   Base 10 integer encoding uses the
            following ways:

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

            The last component of digits '0' through '9' and an
   optional sign ('+' or '-').  For example, "123", "-456".

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

2.2.2 Real Numbers

   Real (floating-point) attributes are represented by the previous section.

            <!DOCTYPE IODEF-Description SYSTEM
               "/some/path/to/the/IODEF-Description.dtd">

            The last component REAL data
   type.  Real data MUST be encoded in Base 10.

   Real encoding is that of the document type declaration is POSIX "strtod" library function: an
   optional sign ('+' or '-') followed by a URI
            that points to non-empty string of decimal
   digits, optionally containing a copy 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 Document Type Definition.

            In order STRING data type.

   Character and string data have no special formatting requirements,
   other than the need to be valid occasionally use character references (see
   Section 7.1), an XML document must
            contain a document type declaration.  However, this
            requirement imposes a significant overhead on an 2.1.2.1 and Section 2.1.2.2) to represent special characters.





Meijer, et al.         Expires March September 29, 2003                   [page 12]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            IODEF-compliant application in bandwidth consumption and
            computation for the DTD may need to be downloaded              [Page 11]

Internet-Draft    IODEF Data Model and parsed
            before use Implementation         March 2003


2.2.4 Bytes

   Binary data is represented 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.
            However, 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.


      3.3.2 Character Data Processing in XML and IODEF

         A document's XML declaration specifies
         the character encoding to be used in the document, as follows:

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

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

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

         While XML supports other character encodings (e.g., UTF-7,
         UTF-32), for portability reasons, IODEF documents SHOULD NOT be
         encoded in character encodings other than UTF-8 and UTF-16.

         Consistent with the XML standard, if no encoding is specified
         for an IODEF document, UTF-8 is assumed.  Likewise, 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).


         3.3.2.1 Character Entity References




Meijer, et al.            Expires March 2003                   [page 13]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            Within XML documents, certain characters have special
            meanings in some contexts.  To include the actual character
            itself in one of these contexts, a special escape sequence,
            called an entity reference, must be used.

            The characters that sometimes need to be escaped, and their
            entity references, are:

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

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


         3.3.2.2 Character Code References

            Any character defined by the ISO/IEC 10646 and Unicode
            standards may be included in an XML document by the use of a
            character reference. A character reference is started with
            the characters '&' and '#', and ended with the character
            ';'.  Between these characters, the character code for the
            character inserted.

            If the character code is preceded by an 'x' it is
            interpreted in hexadecimal (base 16), otherwise, it is
            interpreted in decimal (base 10).  For instance, the
            ampersand (&) is encoded as &#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.


         3.3.2.3 White Space Processing

            All IODEF elements support the "xml:space" attribute.

            If "xml:space" is set to "preserve," the IODEF 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



Meijer, et al.            Expires March 2003                   [page 14]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            in the element's content.


      3.3.3 Languages in XML and IODEF

         All IODEF tags support the "xml:lang" attribute whereby
         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 [12].

         IODEF documents 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
         SHALL be assumed.



      3.3.4 Inheritance and Aggregation

         XML DTDs do not support inheritance as used by the IODEF data
         model. This limitation does not present a major problem in
         practice because aggregation relationships can be used instead
         with little loss of functionality.

         As a note of interest, XML Schemas, recently approved by the
         W3C, will provide support for inheritance, stronger data typing
         and other useful features [7]. Future versions of the IODEF
         will probably use XML Schemas instead of DTDs. It was
         recognized that in the initial stage of the design of a new
         application, an XML DTD was useful since it provides a better
         human readable format for document and element descriptions.
         However, with further the development of applications and
         integration into IH systems a more detailed definition of data
         types and elements relations as provided by XML Schemas may be
         required.


   3.4 IODEF Data Types

            XML DTDs do not support data types such as integer, real,
            string, and so on (more on this later). However, they do
            require some indication of the type(s) of content that an
            element will contain.  There are several types available,
            but only two are used in the IODEF:




Meijer, et al.            Expires March 2003                   [page 15]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            PCDATA
            An XML processor will find only text (parsed character data)
            in this element, no tags or entity references (see Section
            3.2.4). This is the content type for all but one of the
            elements at the bottom of the IODEF document tree.

            ANY
            The element may contain anything -- text, other tags, entity
            references, etc.  This is the content type for the
            AdditionalData element (see Section 4.2.4.5).

            In the case where declaring the data is essential, future
            implementations of the IODEF should use an XML Schema
            definition instead of currently used XML DTD.


            There are a variety of attribute content types defined, but
            only two are used in the IODEF:

            CDATA

            An attribute of this type contains character data (text).
            Tags and entity references (see Section 4.2.4) are not
            processed.

            [values]
            An attribute may also be declared with a list of acceptable
            values; this functions somewhat like an enumerated type.
            For example:

            <!ATTLIST Person
               gender     "unknown | male | female"   "unknown"
            >

            The gender attribute may have one of three values; if a
            Person tag appears without a gender attribute, the XML
            processor will behave as though it did have one, with value
            "unknown."



      Within an XML IODEF description, all data will be expressed as
      "text" (as opposed to "binary"), since XML is a text formatting
      language. We provide typing information for the attributes of the
      classes in the data model however, to convey to the reader the
      type of data the model expects for each attribute.

      Each data type in the model has specific formatting requirements
      in an XML IODEF description. These requirements are set forth in



Meijer, et al.            Expires March 2003                   [page 16]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      this section.


      3.4.1 Integers

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

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

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


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


      3.4.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 Sections 4.3.2.1 and 4.3.2.2) to represent
         special characters.

      3.4.4 Bytes

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

         Binary data MUST be encoded in its entirety using character



Meijer, et al.            Expires March 2003                   [page 17]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         code references (see Section 4.3.2.2).


      3.4.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 rank (number) and a representing keyword.

         Within an IODEF document, the enumerated type keywords are used
         as attribute values, and the ranks are ignored.  However, those
         IODEF-compliant applications that choose to represent these
         values internally in a numeric format MUST use the rank values
         identified in this memo.


      3.4.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 [13], as show below.

         1. Dates MUST be formatted as follows:

            YYYY-MM-DD

         where YYYY is the four- digit year, MM is the two-digit month
         (01-12), and DD is the two- digit day (01-31).  (Section
         5.2.1.1, "Complete representation -- Extended format" of [13])

         2. Times MUST be formatted as follows:

            hh:mm:ss

         where hh is the two-digit hour (00-24), mm is the two-digit
         minute (00-59), and ss is the two-digit second (00-60).
         (Section 5.3.1.1, "Complete representation -- Extended
         format." of [13])

         Note that midnight has two representations, 00:00:00 and
         24:00:00.  Both representations MUST be supported by
         IODEF-compliant applications, however, the 00:00:00
         representation SHOULD be used whenever possible.

         Note also that this format accounts for leap seconds.  Positive
         leap seconds are inserted between 23:59:59Z and 24:00:00Z and



Meijer, et al.            Expires March 2003                   [page 18]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         are represented as 23:59:60Z.  Negative leap seconds are
         achieved by the omission of 23:59:59Z.  IODEF-compliant
         applications MUST support leap seconds.

         3. Times MAY be formatted to include a decimal fraction of
            seconds, as follows:

            hh:mm:ss.ss     or
            hh:mm:ss,ss

         As many digits as necessary may follow the decimal sign (at
         least one digit must follow the decimal sign).  Decimal
         fractions of hours and minutes are not supported.  (Section
         5.3.1.3, "Representation of decimal fractions." of [13])

         IODEF-compliant applications MUST support the use of both
         decimal signs ('.'  and ',').

         Note that the number of digits in the fraction part does not
         imply anything about accuracy -- i.e., "00.100000", "00,1000"
         and "00.1" are all equivalent.

         4. Times MUST be formatted to include (a) an indication that
            the time is in Coordinated Universal Time (UTC), or (b) an
            indication of the difference between the specified time and
            Coordinated Universal Time.

         a. Times in UTC MUST be formatted by appending the letter 'Z'
            to the time string as follows:

            hh:mm:ssZ
            hh:mm:ss.ssZ
            hh:mm:ss,ssZ

            (Section 5.3.3, "Coordinated Universal Time (UTC) -- Extended
             format" of [13])

         b. If the time is ahead of or equal to UTC, a '+' sign is
            appended to the time string; if the time is behind UTC, a
            '-' sign is appended.  Following the sign, the number of
            hours and minutes representing the different from UTC is
            appended, as follows:

            hh:mm:ss+hh:mm
            hh:mm:ss-hh:mm
            hh:mm:ss.ss+hh:mm
            hh:mm:ss.ss-hh:mm
            hh:mm:ss,ss+hh:mm
            hh:mm:ss,ss-hh:mm



Meijer, et al.            Expires March 2003                   [page 19]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




         The difference from UTC MUST be specified in both hours and
         minutes, even if the minutes component is 0.  A "difference" of
         "+00:00" is equivalent to UTC.  (Section 5.3.4.2, "Local time
         and the difference with Coordinated Universal Time -- Extended
         Format" of [13])

         5. Date-time strings are created by joining the date and time
            strings with the letter 'T', as shown below:

            YYYY-MM-DDThh:mm:ssZ
            YYYY-MM-DDThh:mm:ss.ssZ
            YYYY-MM-DDThh:mm:ss,ssZ
            YYYY-MM-DDThh:mm:ss+hh:mm
            YYYY-MM-DDThh:mm:ss-hh:mm
            YYYY-MM-DDThh:mm:ss.ss+hh:mm
            YYYY-MM-DDThh:mm:ss.ss-hh:mm
            YYYY-MM-DDThh:mm:ss,ss+hh:mm
            YYYY-MM-DDThh:mm:ss,ss-hh:mm

         (Section 5.4.1, "Complete representation -- Extended format" of
         [13])

         In summary, IODEF date-time strings MUST adhere to one of the
         nine templates identified in Paragraph 5, above.


      3.4.7 NTP Timestamps

         NTP timestamps are represented by the NTPSTAMP data type, and
         are described in detail in [14] and [15].  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.

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


      3.4.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".




Meijer, et al.            Expires March 2003                   [page 20]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




      3.4.9 Unique Identifiers

         There are several types of unique identifiers used in this
         specification. All types are represented by the STRING data
         type.

         These identifiers are implemented as attributes in the relevant
         XML elements, and must have unique values as follows:

         1. If specified, the attribute of the Authority class (Section
         5.2.6.8) OrganizationID MUST have a value that is globally
         unique. It may be a combination of the Registry name and unique
         CSIRT ID in this Registry. FIRST or industry associations
         normally maintain registries.

         The default value is "unknown", which indicates that the
         authority or CISRT does not have unique identifiers.

         2. The Incident, Attacker, Evidence, Victim, Source, Target,
         Node, User, Process, Service, Address, and UserID classes (see
         correspondent sections) are provided with "ident" attribute,
         which if specified, MUST have a value that is unique across all
         IODEF Descriptions created by the particular CSIRT or
         Authority.

         The "ident" attribute value MUST be unique for each particular
         combination of data identifying an object, not for each object.
         Objects may have more than one ident value associated with
         them. For example, an identification of a host by name would
         have one value, while an identification of that host by address
         would have another value, and an identification of that host by
         both name and address would have still another value.
         Furthermore, different analyzers may produce different values
         for the same information.

         The "ident" attribute by itself provides a unique identifier
         only among all the "ident" values created/stored by a
         particular CSIRT or IHS. But when combined with the unique
         "OrganizationID" value for the CSIRT, there is no requirement
         for global uniqueness.  The default value is "0", which
         indicates that the CSIRT/IHS cannot generate unique
         identifiers.

         The specification of methods for creating the unique values
         contained in these attributes is outside the scope of this
         document.

      3.4.10 Personal names



Meijer, et al.            Expires March 2003                   [page 21]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




         The format for personal names is the same as in LDAP.
         Personal names will likely be obtained from the different
         directories used by a CSIRT.

         The suggested personal name formats are as follows:

         Name Surname

         Or

         Surname, Name

         It is also possible to use a personal handle from a registry
         database (e.g., RIPE NCC, InterNIC). In this case, the
         element's attribute will indicate the type of personal name
         used and indirectly point to the referenced registry.

      3.4.11 Organization names

         Organization name can be in the form of a full name, short
         name or identification code retrieved from official Registries.

         It is possible to use an organization handle (or organization
         role from a registry (e.g., RIPE NCC, InterNIC).  In this
         case, the element's attribute will indicate the type of
         organization name.

      3.4.12 Postal addresses

         The format of postal address data is the same as in LDAP
         Postal addresses will likely be obtained directly from an
         incident report or from the different directories used by
         the CSIRT.

         Building, Street, Zip-code, City, Country

         Or

         Post Office Box, Zip-code, City, Country

      3.4.13 Telephone and Fax numbers

         Telephone and fax numbers are expressed in the format
         recommended by ITU guidelines.

         + (international code) (local code) (tel. Number)





Meijer, et al.            Expires March 2003                   [page 22]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




4. The IODEF Data Model and XML DTD

   In this section, the individual components of the IODEF data model
   are explained in details.  UML diagrams of the model are provided to
   illustrate the relationship between components.  Likewise, relevant
   sections of the XML DTD are presented to describe how the model is
   translated into XML.


   4.1 Data Model Overview

      The relationship between the principal components of the data
      model is shown in Figure 5.1 (cardinality and attributes are
      omitted).

      IODEF-Description is the top-level container class for all IODEF
      documents. Recognizing that incidents might require different
      types of data, sub-classes of this root class called incident
      descriptions are defined.  There are presently two types of
      descriptions defined: the Incident class to describe an incident
      and the IncidentAlert class to allow seamless support for IODEF
      alerts.

      It is important to note that the data model does not define the
      events that constitute an incident. The notion of an incident is
      very site-specific.  For example, a port scan may be identified by
      one CSIRT as a single incident with multiple victims.  Another
      CSIRT might separate this activity as multiple incidents each from
      a single source to a single victim. Regardless, once the creator
      of the report has determined a logical grouping of events that
      constitute an incident, the data model dictates how that
      description should be formatted.


                     +---------------------+
                     |  IODEF-Description  |
                     +---------------------+
                               /_\
                                |
           +--------------------+---------------------+
           |                                          |
           |                                  +-------+--------+
           |                                  | IncidentAlert  |
           |                                  +----------------+
           |
      +----------+   +------------+   +----------------+   +----------+
      | Incident |<>-|   Attack   |<>-| Source         |<>-| Node     |
      +----------+   +------------+   +----------------+   +----------+



Meijer, et al.            Expires March 2003                   [page 23]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| User     |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Process  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Service  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Program  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| os       |
      |          |   |            |   +----------------+   +----------+
      |          |   |            |   +----------------+   +----------+
      |          |   |            |<>-| Target         |<>-| Node     |
      |          |   |            |   +----------------+   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| User     |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Process  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Service  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| Program  |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| os       |
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |   +----------+
      |          |   |            |   |                |<>-| FileList |
      |          |   |            |   +----------------+   +----------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Description    |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| DetectTime     |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| StartTime      |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| EndTime        |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+



Meijer, et al.            Expires March 2003                   [page 24]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      |          |<>-| Method     |<>-| Classification |
      |          |   +------------+   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Description    |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| Attacker   |<>-| Contact        |
      |          |   +------------+   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Location       |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| IRTcontact     |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| Victim     |<>-| Contact        |
      |          |   +------------+   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Location       |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| IRTcontact     |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| Record     |<>-| RecordData     |
      |          |   +------------+   +----------------+
      |          |   +----------------+
      |          |<>-| AdditionalData |
      |          |   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| History    |<>-| HistoryItem    |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| Assessment |<>-| Impact         |
      |          |   +------------+   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Action         |
      |          |   |            |   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Convidence     |
      |          |   +------------+   +----------------+
      |          |   +------------+   +----------------+
      |          |<>-| Authority  |<>-| Organization   |
      |          |   +------------+   +----------------+
      |          |   |            |   +----------------+
      |          |   |            |<>-| Contact        |
      +----------+   +------------+   +----------------+

      Figure 4.1  Data model overview



Meijer, et al.            Expires March 2003                   [page 25]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




      The individual classes are described in the following sections.


   4.2 The IODEF-Description Class

      IODEF-Description is the root container class of the IODEF data
      model.  There are currently two main types (subclasses) of IODEF-
      Description: Incident and IncidentAlert. A third Experimental
      class is also included temporarily for testing.

      Since DTDs do not support subclassing (see Section 4.3.4), the
      inheritance relationship between the IODEF-Description and the
      Incident and IncidentAlert subclasses shown in Figure 5.1 has been
      replaced with an aggregate relationship.

      NOTE: The use of aggregation to implement an inheritance
      relationship is done throughout the data model.


      The IODEF-Description class is declared in the IODEF DTD as
      follows:

      <!ENTITY % attlist.IODEF                  "
         version               CDATA                 #FIXED    '0.0'
      ">
      <!ELEMENT IODEF-Description                   (
         (Incident | IncidentAlert)*
      )>
      <!ATTLIST IODEF-Description
         %attlist.IODEF;
      >

      The IODEF-Description class has a single attribute:

        version

      The version of the IODEF-Description specification (this
      document) to which the document conforms. Applications
      specifying a value for this attribute MUST use the value "0.0".


   4.3 The Incident Class

      For a given incident, the CSIRT will create an instance of the
      Incident class. The information used to populate this class will
      come from the reporting infrastructure that the CSIRT already has
      in place. Thus, direct reports from their constituency, IDS alert
      messages, or collaboration with other CSIRTS could serve as



Meijer, et al.            Expires March 2003                   [page 26]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      potential input.

      An Incident description is composed of several aggregate classes,
      as shown in Figure 4.2. The aggregate classes themselves are
      described in Sections 4.2.4.1 - 4.2.4.10.


      +-------------------+
      | Incident          |
      +-------------------+
      | STRING incidentID |   1..* +----------------+   +-------------+
      | ENUM purpose      |<>------|   Attack       |<>-| Source      |
      | ENUM restriction  |        +----------------+   +-------------+
      |                   |        |                |   +-------------+
      |                   |        |                |<>-| Target      |
      |                   |        |                |   +-------------+
      |                   |        |                |   +-------------+
      |                   |        |                |<>-| Description |
      |                   |        |                |   +-------------+
      |                   |        |                |   +-------------+
      |                   |        |                |<>-| DetectTime  |
      |                   |        |                |   +-------------+
      |                   |        |                |   +-------------+
      |                   |        |                |<>-| StartTime   |
      |                   |        |                |   +-------------+
      |                   |        |                |   +-------------+
      |                   |        |                |<>-| EndTime     |
      |                   |        +----------------+   +-------------+
      |                   |   0..* +----------------+
      |                   |<>------| Attacker       |
      |                   |        +----------------+
      |                   |   0..* +----------------+
      |                   |<>------| Victim         |
      |                   |        +----------------+
      |                   |   0..* +----------------+
      |                   |<>------| Method         |
      |                   |        +----------------+
      |                   |   0..1 +----------------+
      |                   |<>------| Record         |
      |                   |        +----------------+
      |                   |   0..1 +----------------+
      |                   |<>------| AdditionalData |
      |                   |        +----------------+
      |                   |   0..1 +----------------+
      |                   |<>------| History        |
      |                   |        +----------------+
      |                   |   0..1 +----------------+
      |                   |<>------| Assessment     |
      |                   |        +----------------+



Meijer, et al.            Expires March 2003                   [page 27]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      |                   |        +----------------+
      |                   |<>------| Authority      |
      +-------------------+        +----------------+
                /_\
                 |
                 |
      +----------+----------+
      | CorrelationIncident |
      +---------------------+

      Figure 4.2 The Incident Class


      The aggregate classes that constitute Incident are:

      Attack
         One or more. The security event(s) that compose the incident.

      Attacker
         Zero or more.  The system(s) from which the Attack originated.

      Victim
         Zero or more.  The system(s) at which the Attack was targeted.

      Method
         Zero or more. The actions taken by the Attacker in the
         incident.

      Evidence
         Zero or one.  Container for the EvidenceData.

      Authority
         Exactly one. The CSIRT or authority that created the incident.

      History
         Zero or one. A log of the actions taken by the CSIRT(s) in the
         course of investigating the incident.

      AdditionalData
         Zero or more.  Additional information about the incident
         included by CSIRT that cannot be readily expressed in the
         data model.


      The Incident class is represented in the XML DTD as follows:

      <!ENTITY % attvals.purpose "
         ( unknown | report | handling | communication |
           statistics | experimental )



Meijer, et al.            Expires March 2003                   [page 28]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      ">
      <!ENTITY % attvals.restriction "
            ( default | public | internal |
              restricted )
      ">
      <!ELEMENT Incident (
         Attack+, Attacker*, Victim*, Method*, Evidence?,
         CorrelationIncident?, Authority, History?, AdditionalData*)>
      <!ATTLIST Incident
         incidentID            CDATA                   '0'
         purpose               %attvals.purpose;       'experimental'
         restriction           %attvals.restriction;   'default'
      >

      The Incident class has three attributes:

      IncidentID
         Required. A unique identifier for the Incident (see Section
         3.4.9).

      purpose
         Optional. The purpose of the incident being reported to the
         CSIRT.

      Rank   Keyword            Description
      ----   -------            -----------
        0    unknown           Purpose of the incident is unknown
        1    report            Incident report
        2    handling          Incident is being handled
        3    communication     Incident is being sent to another team
        4    statistics        Incident was reported for statistical
                               purposes
        5    experimental      Experimental

      restriction
         Optional. Sets a restriction on the usage of the data in
         element.

      Rank   Keyword            Description
      ----   -------            -----------
        0    default            Restriction level is defined by
                                external policy applied to overall
                                CSIRT process
        1    public             No restriction is applied to element
        2    internal           Data is for company's (or
                                constituency) internal use
        3    restricted         Use strictly for Incident managers at
                                CSIRT




Meijer, et al.            Expires March 2003                   [page 29]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




   4.4 The CorrelationIncident Class

      The CorrelationIncident class represents information related to
      the correlation of current incident. It is intended as a way by
      which to logically group previously reported incidents as related.

      The CorrelationIncident class is composed of three aggregate
      classes, as shown in Figure 4.3.


      +---------------------+
      | CorrelationIncident |
      +---------------------+
      | ENUM restriction    |   0..1 +----------------+
      |                     |<>------| IncidentID     |
      |                     |        +----------------+
      |                     |   0..* +----------------+
      |                     |<>------| EvidenceDataID |
      |                     |        +----------------+
      |                     |   0..* +----------------+
      |                     |<>------| EventList      |
      +---------------------+        +----------------+

      Figure 4.3 - The CorrelationIncident Class


      The aggregate classes that constitute CorrelationIncident are:

      IncidentID
         Zero or one. STRING.  Identifier of current Incident. If not
         included into CorrelationIncident class, this value may be
         derived from the top class Incident attribute.

      EvidenceDataID
         Zero or more.  Evidence data that are linked to current
         Incident.

      EventList
         One or more.  Lists all events which are investigated together,
         or have another common denominator.

      This is represented in the XML DTD as follows:

      <!ELEMENT CorrelationIncident (
         IncidentID?, EventList*, EvidenceDataID*
      )>

      <!ATTLIST CorrelationIncident



Meijer, et al.            Expires March 2003                   [page 30]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         restriction           %attvals.restriction;   'default'
      >

      The CorrelationIncident class has one attribute:

      restriction
         Optional. Sets a restriction on the usage of the data in
         element.

         
      4.4.1  The EventList Class

         The EventList class contains information about events which are
         treated as correlated with respect to current incident.

         +---------------------+
         | CorrelationIncident |
         +---------------------+
                     /_\
                      |
         +--------------+
         | EventList    |
         +--------------+       0..1 +----------------+
         |              |<>----------| IncidentID     |
         |              |            +----------------+
         |              |       0..* +----------------+
         |              |<>----------| EvidenceDataID |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| DateTime       |
         |              |            +----------------+
         +--------------+

         Figure 4.27  The EventList Class

         The aggregate classes that constitute EventList are:

         IncidentID
            Zero or one.  Identification number of the Incident.

         EvidenceDataID
            Zero or more.  Identification number of the EvidenceData
            element related to referenced event or IncidentID.

         DateTime
            Zero or one.  Date and time when the event occured.

         EventList is represented in the XML DTD as follows:




Meijer, et al.            Expires March 2003                   [page 31]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         <!ELEMENT EventList                           (
            IncidentID?, EvidenceDataID?, DateTime?)>
         <!ATTLIST EventList
            ident                 ID                      #IMPLIED
         >

         The EventList class has one attributes:

         ident
            Optional. A unique identifier for the EventList element
            (see Section 3.4.9).



   4.5 IncidentAlert Class

      The IncidentAlert class is used as a container for IDMEF Alert
      messages.

      +-------------------+
      | IncidentAlert     |
      +-------------------+
      | STRING incidentID |        +----------------+
      | ENUM purpose      |<>------| Authority      |
      | ENUM restriction  |        +----------------+
      |                   |   0..1 +----------------+
      |                   |<>------| History        |
      |                   |        +----------------+
      |                   |   0..* +----------------+ 
      |                   |<>------| AdditionalData |
      +-------------------+        +----------------+

      Figure 4.4 The IncidentAlert Class

      The aggregate classes that constitute IncidentAlert are:

      Authority
        Exactly one. The CSIRT or authority that created the incident.

      History
         Zero or one. A log of the actions taken by the CSIRT(s) in
         course of investigating the incident.

      AdditionalData
         Zero or more.  A container for the IDMEF Alert message.


      This is represented in the XML DTD as follows:




Meijer, et al.            Expires March 2003                   [page 32]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      <!ELEMENT IncidentAlert (
         Authority, History?, AdditionalData*)>
      <!ATTLIST Incident
         IncidentID            ID                      #IMPLIED
         purpose               %attvals.purpose;       'unknown'
         restriction           %attvals.restriction;   'default'
      >


      The IncidentAlert class has three attributes:

      IncidentID
         Optional. A unique identifier for the alert, see Section 3.4.9.

      purpose
         Optional. The purpose of the incident being reported to the
         CSIRT.

      restriction
         Optional. Sets a restriction on the usage of the data in
         element.


   4.6.  The Attack Class

      The Attack class contains information about the security events
      that constitute the incident.

         +------------------+   0..* +---------------+   +----------+
         |   Attack         |<>------| Source        |<>-| Node     |
         +------------------+        +---------------+   +----------+
         | STRING ident     |        |               |   +----------+
         |                  |        |               |<>-| User     |
         | ENUM restriction |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| process  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| service  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| program  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| os       |
         |                  |        +---------------+   +----------+
         |                  |   0..* +---------------+   +----------+
         |                  |<>------| Target        |<>-| Node     |
         |                  |        +---------------+   +----------+



Meijer, et al.            Expires March 2003                   [page 33]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         |                  |        |               |   +----------+
         |                  |        |               |<>-| User     |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| process  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| service  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| program  |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| os       |
         |                  |        |               |   +----------+
         |                  |        |               |   +----------+
         |                  |        |               |<>-| FileList |
         |                  |        +---------------+   +----------+
         |                  |   0..* +---------------+
         |                  |<>------| Description   |
         |                  |        +---------------+
         |                  |   0..1 +---------------+
         |                  |<>------| DetectTime    |
         |                  |        +---------------+
         |                  |   0..1 +---------------+
         |                  |<>------| StartTime     |
         |                  |        +---------------+
         |                  |   0..1 +---------------+
         |                  |<>------| EndTime       |
         +------------------+        +---------------+

         Figure 4.6  The Attack Class


         The aggregate classes that constitute Attack are:

         Source
            Zero or more.  The source(s) of the event(s) causing the
            incident.

         Target
            Zero or more.  The target(s) of the event(s) in the
            incident.

         Description
            Zero or more.  A free-form textual description by the CSIRT
            or report of the incident events.

         DetectTime



Meijer, et al.            Expires March 2003                   [page 34]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            Zero or one.  The time when the incident activity was first
            detected by the reporter. In the case of more than one
            event, the time the first event was detected. In some
            circumstances, this time may not be the same as the
            RegistrationTime used in the History class.

         StartTime
            Zero or one.  The start time of the incident activity.

         EndTime
            Zero or one.  The end time of the incident activity.


         This is represented in the XML DTD as follows:

         <!ELEMENT Attack   (
            Source*, Target*, Description*,
            DetectTime?, StartTime?, EndTime?)>

         <!ATTLIST Attack
            %attlist.global;
            restriction   %attvals.restriction;   'default'
            ident         CDATA                   #IMPLIED
         >

         The Attack class has two attributes:

         ident
            Optional. A unique identifier for this Attack class (see
            Section 3.4.9).

         restriction
            Optional. Sets a restriction on the usage of the data in
            element.


      4.6.1 The Source Class

         The Source class contains information about the possible
         source(s) of the incident event(s). An event may have more than
         one source (e.g., in a distributed denial of service attack).
         For the purpose of compatibility, the Source class has been
         reused from the IDMEF. Hence, the Source class from an IDMEF
         message can be included unmodified into the IODEF-Description
         class with the same semantics.  Likewise, the data in an
         IDMEF-originating Source class could be decomposed between the
         IODEF Source and Attack classes.

         The definition of the Source class in the IODEF data model is a



Meijer, et al.            Expires March 2003                   [page 35]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         superset of the IDMEF definition.  Two new classes have been
         added: os and program.

         The Source class is composed of four aggregate classes, as
         shown in Figure 4.7.

         +------------------+
         |      Source      |
         +------------------+       0..1 +---------+
         | STRING ident     |<>----------|  Node   |
         | ENUM spoofed     |            +---------+
         | STRING interface |       0..1 +---------+
         |                  |<>----------|  User   |
         |                  |            +---------+
         |                  |       0..1 +---------+
         |                  |<>----------| Process |
         |                  |            +---------+
         |                  |       0..1 +---------+
         |                  |<>----------| Service |
         |                  |            +---------+
         |                  |       0..1 +---------+
         |                  |<>----------| os      |
         |                  |            +---------+
         |                  |       0..1 +---------+
         |                  |<>----------| Program |
         |                  |            +---------+
         +------------------+

         Figure 4.7  The Source Class


         The aggregate classes that constitute Source are:

         Node
            Zero or one.  Information about the host or device that
            appears to be causing the events (network address, network
            name, etc.).

         User
            Zero or one.  Information about the user that appears to be
            causing the event(s).

         Process
            Zero or one.  Information about the process that appears to
            be causing the event(s).

         Service
            Zero or one.  Information about the network service involved
            in the event(s).



Meijer, et al.            Expires March 2003                   [page 36]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




         os
            Zero or one.  The operation system running on the Node from
            which the Attack originated.

         program

            Zero or one.  The program that caused the Attack, that is
            running in the Process.


         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.yesno   "
            ( unknown | yes | no )
         ">
         <!ELEMENT Source   (
            Node?, User?, Process?, Service?, os?, program?
         )>
         <!ATTLIST Source
            ident       CDATA             '0'
            spoofed     %attvals.yesno;   'unknown'
            interface   CDATA             #IMPLIED
         >

         The Source class has three attributes:

         ident
            Optional.  A unique identifier for this Source class (see
            Section 3.4.9).

         spoofed
            Optional.  An indication of confidence as to whether this is
            the true Attack source.  The permitted values for this
            attribute are shown below.  The default value is "unknown".

         Rank   Keyword   Description
         ----   -------   -----------
           0    unknown   Accuracy of source information unknown
           1    yes       Source is believed to be a decoy
           2    no        Source is believed to be "real"

         interface
            Optional.  Specifies the interface on which the source of
            the event(s) was detected.



      4.6.2 The Node Class



Meijer, et al.            Expires March 2003                   [page 37]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




         The Node class is used to identify hosts and other network
         devices (routers, switches, etc.).

         The Node class is composed of five aggregate classes, as shown
         in Figure 4.16.

         +---------------+
         |     Node      |
         +---------------+       0..1 +----------+
         | STRING ident  |<>----------| Location |
         | ENUM category |            +----------+
         |               |       0..1 +----------+
         |               |<>----------| name     |
         |               |            +----------+
         |               |       0..* +----------+
         |               |<>----------| Address  |
         |               |            +----------+
         |               |       0..1 +----------+
         |               |<>----------| DateTime |
         |               |            +----------+
         |               |       0..* +----------+
         |               |<>----------| NodeRole |
         |               |            +----------+
         +---------------+

         Figure 4.16  The Node Class

         The aggregate classes that constitute Node are:

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

         name
            Zero or one.  STRING.  The name of the equipment.  This
            information MUST be provided if no Address information is
            given.

         Address
            Zero or more.  The network or hardware address of the
            equipment.  Unless a name (above) is provided, at least one
            address must be specified.

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




Meijer, et al.            Expires March 2003                   [page 38]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         NodeRole
            Zero or more.  The intended role of the node.

         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.nodecat                "
            ( unknown | ads | afs | coda | dfs | dns | hosts |
              kerberos | nds | nis | nisplus | nt | wfw )
         ">
         <!ELEMENT Node                            (
            location?, (name | Address), Address*, DateTime?, NodeRole*
         )>
         <!ATTLIST Node
            ident                 CDATA                   '0'
            category              %attvals.nodecat;       'unknown'
         >

         The Node class has two attributes:

         ident
            Optional.  A unique identifier for the node, see Section
            3.4.9.

         category
            Optional.  The "domain" from which the name information
            obtained, if relevant.  The permitted values for this
            attribute are shown below.  The default value is "unknown".

         Rank   Keyword    Description
         ----   -------    -----------
           0    unknown    Domain unknown or not relevant
           1    ads        Windows 2000 Advanced Directory Services
           2    afs        Andrew File System (Transarc)
           3    coda       Coda Distributed File System
           4    dfs        Distributed File System (IBM)
           5    dns        Domain Name System
           6    hosts      Local hosts file
           7    kerberos   Kerberos realm
           8    nds        Novell Directory Services
           9    nis        Network Information Services (Sun)
          10    nisplus    Network Information Services Plus (Sun)
          11    nt         Windows NT domain
          12    wfw        Windows for Workgroups


         4.6.2.1 The Address Class

            The Address class represents a network, hardware, or
            application address.



Meijer, et al.            Expires March 2003                   [page 39]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




            The Address class is composed of two aggregate classes, as
            shown in Figure 4.17.


            +------------------+
            |     Address      |
            +------------------+            +---------+
            | STRING ident     |<>----------| address |
            | ENUM category    |            +---------+
            | STRING vlan-name |       0..1 +---------+
            | INTEGER vlan-num |<>----------| netmask |
            |                  |            +---------+
            +------------------+

            Figure 4.17  The Address Class

            The aggregate classes that constitute Address are:

            address
               Exactly one.  STRING.  The address whose format is
               governed by the category attribute.

            netmask
               Zero or one.  STRING.  The network mask for the address,
               if appropriate.

            This is represented in the XML DTD as follows:

            <!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 )
            ">
            <!ELEMENT Address                         (
               address, netmask?
            )>
            <!ATTLIST Address
               ident                 CDATA               '0'
               category              %attvals.addrcat;   'unknown'
               vlan-name             CDATA               #IMPLIED
               vlan-num              CDATA               #IMPLIED
            >

            The Address class has four attributes:

            ident
               Optional.  A unique identifier for the address (see
               Section 3.4.9).



Meijer, et al.            Expires March 2003                   [page 40]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




            category
               Optional.  The type of address represented.  The
               permitted values for this attribute are shown below.  The
               default value is "unknown".

               Rank   Keyword            Description
               ----   -------            -----------
                 0    unknown         Address type unknown
                 1    atm             Asynchronous Transfer Mode network
                                      address
                 2    e-mail          Electronic mail address (RFC 822)
                 3    lotus-notes     Lotus Notes e-mail address
                 4    mac             Media Access Control (MAC) address
                 5    sna             IBM Shared Network Architecture
                                      (SNA) address
                 6    vm              IBM VM ("PROFS") e-mail address
                 7    ipv4-addr       IPv4 host address in
                                      dotted-decimal notation (a.b.c.d)
                 8    ipv4-addr-hex   IPv4 host address in hexadecimal
                                      notation
                 9    ipv4-net        IPv4 network address in
                                      dotted-decimal notation, slash,
                                      significant bits (a.b.c.d/nn)
                10    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)
                11    ipv6-addr       IPv6 host address
                12    ipv6-addr-hex   IPv6 host address in hexadecimal
                                      notation
                13    ipv6-net        IPv6 network address, slash,
                                      significant bits
                14    ipv6-net-mask   IPv6 network address, slash,
                                      network mask

               vlan-name
                  Optional.  The name of the Virtual LAN to which the
                  address belongs.

               vlan-num
                  Optional.  The number of the Virtual LAN to which the
                  address belongs.


            4.6.2.2 The NodeRole Class

               The NodeRole class is used to represent the intended role
               of a particular node.



Meijer, et al.            Expires March 2003                   [page 41]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




               The NodeRole class is composed of a single attribute
               represented in the XML DTD as follows:

               <!ENTITY % attvals.noderolecat                "
                  ( unknown | client | server-internal | server-public |
                    www | mail | messaging | streaming | voice | file |
                    ftp | p2p | name | directory | credential | print |
                    application | database | infra | log )
               ">
               <!ELEMENT NodeRole ()>
               <!ATTLIST NodeRole
                  category   %attvals.noderolecat;   'unknown'
               >

               The NodeRole class has one attribute:

               category

                  Optional. The intended role this Node is to fulfill.
                  The permitted values for this attribute are shown
                  below.  The default value is "unknown".

               Rank   Keyword          Description
               ----   -------          -----------
                 0    unknown          Unknown role
                 1    client           Client computer
                 2    server-internal  Server with internal services
                 3    server-public    Server with public services
                 4    www              WWW server
                 5    mail             Mail server
                 6    messaging        Messaging server (e.g. NNTP, IRC,
                                       instant)
                 7    streaming        Streaming-media server
                 8    voice            Voice server (e.g. SIP, H.323)
                 9    file             File server (e.g. SMB, CVS, AFS)
                10    ftp              FTP server
                11    p2p              Peer-to-peer server (e.g.
                                       Napster)
                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)
                16    print            Print server
                17    application      Application server
                18    database         Database server
                19    infra            Infrastructure server (e.g.
                                       router, firewall, DHCP)



Meijer, et al.            Expires March 2003                   [page 42]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



                20    log              Log server (e.g. syslog)



      4.6.3 The User Class

         The User class describes a user account on a system.  It is
         primarily used as a "container" class for the UserId aggregate
         class, as shown in Figure 4.18.

         More than one UserId can be used within the User class to
         indicate attempts to transition from one user to another, or to
         provide complete information about a user's (or process')
         privileges.

         +---------------+
         |     User      |
         +---------------+       1..* +--------+
         | STRING ident  |<>----------| UserId |
         | ENUM category |            +--------+
         +---------------+

         Figure 4.18  The User Class

         The aggregate class contained in User is:

         UserId
            One or more.  The user.

         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.usercat                "
            ( unknown | application | os-device )
         ">
         <!ELEMENT User                            (
            UserId+
         )>
         <!ATTLIST User
            ident                 CDATA                   '0'
            category              %attvals.usercat;       'unknown'
         >

         The User class has two attributes:

         ident
            Optional.  A unique identifier for the user (see Section
            3.4.9).

         category



Meijer, et al.            Expires March 2003                   [page 43]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            Optional.  The type of user represented.  The permitted
            values for this attribute are shown below.  The default
            value is "unknown".

         Rank   Keyword       Description
         ----   -------       -----------
           0    unknown       User type unknown
           1    application   An application user
           2    os-device     An operating system or device user


         4.6.3.1 The UserId Class

            The UserId class describes a specific user account on a
            system.

            The UserId class is composed of two aggregate classes, as
            shown in Figure 4.19.

            +--------------+
            |    UserId    |
            +--------------+       0..1 +--------+
            | STRING ident |<>----------|  name  |
            | ENUM type    |            +--------+
            |              |       0..1 +--------+
            |              |<>----------| number |
            |              |            +--------+
            +--------------+

            Figure 4.19  The UserId Class


            The aggregate classes that constitute UserId are:

            name
               Zero or one.  STRING.  A user or group name.

            number
               Zero or one.  INTEGER.  A user or group number.

            This is represented in the XML DTD as follows:

            <!ENTITY % attvals.idtype                 "
               ( current-user | original-user | target-user |
                 user-privs | current-group | group-privs | other-privs)
            ">
            <!ELEMENT UserId                          (
               name | number | (name, number)
            )>



Meijer, et al.            Expires March 2003                   [page 44]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            <!ATTLIST UserID
               ident   CDATA                   '0'
               type    %attvals.idtype;        'original-user'
            >

            The UserId class has two attributes:

            ident
               Optional.  A unique identifier for the user id (see
               Section 3.4.9).

            type
               Optional.  The type of user information represented.  The
               permitted values for this attribute are shown below.  The
               default value is "original-user".

            Rank   Keyword        Description
            ----   -------        -----------
              0    current-user   The current user id being used by the
                                  user or process.  On Unix systems,
                                  this would be the "real" user id.
              1    original-user  The actual identity of the user or
                                  process being reported on.  On those
                                  systems that (a) do some type of
                                  auditing and (b) support extracting a
                                  user id from the "audit id" token,
                                  that value should be used.  On those
                                  systems that do not support this, and
                                  where the user has logged into the
                                  system, the "login id" should be used.
              2    target-user    The user id the user or process is
                                  attempting to become.  For example,
                                  on Unix systems when the
                                  user attempts to use "su," "rlogin,"
                                  "telnet," etc.
              3    user-privs     Another user id the user or process
                                  has the ability to use.  On Unix
                                  systems, this would be the "effective"
                                  user id.  Multiple UserId elements of
                                  this type may be used to specify a
                                  list of privileges.
              4    current-group  The current group id (if applicable)
                                  being used by the user or process.  On
                                  Unix systems, this would be the "real"
                                  group id.
              5    group-privs    Another group id the group or process
                                  has the ability to use.  On Unix
                                  systems, this would be the "effective"
                                  group id.  On BSD-derived Unix



Meijer, et al.            Expires March 2003                   [page 45]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



                                  systems, multiple UserId elements of
                                  this type would be used to include all
                                  the group ids on the "group list."
              6    other-privs    Not used in a user, group, or process
                                  context, only used in the file
                                  context.  The file permissions
                                  assigned to users who do not match
                                  either the user or group permissions
                                  on the file.  On Unix systems, this
                                  would be the "world" permissions.



      4.6.4 The Process Class

         The Process class describes a process being executed on a system.

         The Process class is composed of five aggregate classes, as
         shown in Figure 4.20.

         +--------------+
         |    Process   |
         +--------------+            +------+
         | STRING ident |<>----------| name |
         |              |            +------+
         |              |       0..1 +------+
         |              |<>----------| pid  |
         |              |            +------+
         |              |       0..1 +------+
         |              |<>----------| path |
         |              |            +------+
         |              |       0..* +------+
         |              |<>----------| arg  |
         |              |            +------+
         |              |       0..* +------+
         |              |<>----------| env  |
         |              |            +------+
         +--------------+

         Figure 4.20  The Process Class

         The aggregate classes that constitute Process are:

         name
            Exactly one.  STRING.  The filename of the program being
            executed.  This is a short name; path and argument
            information are provided elsewhere.

         pid



Meijer, et al.            Expires March 2003                   [page 46]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            Zero or one.  INTEGER.  The process identifier of the
            process.

         path
            Zero or one.  STRING.  The full path of the program being
            executed.

         arg
            Zero or more.  STRING.  A command-line argument to the
            program.  Multiple arguments may BYTE (and BYTE[]) data type.

   Binary data MUST be specified (they are
            assumed to have occurred encoded in the same order they its entirety using character code
   references (see ).

2.2.5 Enumerated Types

   Enumerated types are
            provided) with multiple uses of arg.

         env
            Zero or more.  STRING.  An environment string associated
            with represented by the process; generally ENUM data type, and consist
   of the format "VARIABLE=value".
            Multiple environment strings may be specified with multiple
            uses an ordered list of env.

         This is represented in the XML DTD as follows:

         <!ELEMENT Process                         (
            name, pid?, path?, arg*, env*
         )>
         <!ATTLIST Process
            ident                 CDATA                   '0'
         >

         The Process class acceptable values.  Each value has one attribute:

         ident
            Optional.  A unique identifier for the process (see Section
            3.4.9).


      4.6.5 The Service Class

         The Service class describes a network service. It can identify
         services by name, port, and protocol.

         When Service occurs as
   representative keyword.  Within an aggregate class of Source, it is
         understood that the service is one from which activity of
         interest is originating; and that the service is "attached" to IODEF document, the Node, Process, and User information also contained in
         Source.  Likewise, when Service occurs enumerated
   type keywords are used as an aggregate class of
         Target, it is understood that attribute values

2.2.6 Date-Time Strings

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

   Date-time strings are formatted according to which
         activity a subset of interest is being directed; and that the service is
         "attached" to ISO
   8601:2000 [15] documented in RFC 3339 [14].

2.2.7 NTP Timestamps

   NTP timestamps are represented by the Node, Process, NTPSTAMP data type, and User information also
         contained are
   described in Target.



Meijer, et al.            Expires March 2003                   [page 47]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 detail in RFC 1305 [10] and RFC 2030 [11].  An NTP
   timestamp is a 64-bit unsigned fixed-point number.  The Service class integer part
   is composed of four aggregate classes, as
         shown in Figure 4.21.

         +--------------+
         |   Service    |
         +--------------+       0..1 +----------+
         | STRING ident |<>----------|   name   |
         |              |            +----------+
         |              |       0..1 +----------+
         |              |<>----------|   port   |
         |              |            +----------+
         |              |       0..1 +----------+
         |              |<>----------| portlist |
         |              |            +----------+
         |              |       0..1 +----------+
         |              |<>----------| protocol |
         |              |            +----------+
         +--------------+
                /_\
                 |
                 +------------+
                              |
             +-------------+  |  +-------------+
             | SNMPService |--+--| WebService  |
             +-------------+     +-------------+

         Figure 4.21 - The Service Class

         The aggregate classes that constitute Service are:

         name
            Zero or one.  STRING.  The name of the service.  Whenever
            possible, first 32 bits, and the name from fraction part is in the IANA 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 well-known network ports
            SHOULD be used.

         port
            Zero or one.  INTEGER.  The port number being used.

         portlist

            Zero or one.  PORTLIST.  A are represented by the PORTLIST data type,
   and consist of a comma-separated list of port numbers being used;
            see Section 3.4.8 for formatting rules.

         protocol
            Zero or one.  STRING.  The protocol being used.

         A Service MUST be specified as either (a) a name, (b) a port,
         (c) a name (individual
   integers) and ranges (N-M means ports N through M, inclusive). Any
   combination of numbers and ranges may be used in a port, or (d) a portlist. single list. For
   example, "5-25,37,42,43,53,69-119,123-514".

2.2.9 Postal Address

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



Meijer, et al.         Expires September 29, 2003              [Page 12]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 48]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         optional


2.2.10 Person or Organization

   The name of an individual or organization is represented by the NAME
   data type. The format of the NAME data type is documented in all cases, but no other combinations are permitted.

         Because DTDs do not support subclassing (see Section 4.3.4),
         the inheritance relationship between Service
   5.4 of RFC 2256 [12].

2.2.11 Telephone and Fax Numbers

   A telephone number is represented by the
         SNMPService and WebService subclasses shown PHONE data type. The format
   of the PHONE data type is documented in Figure 5.17 has
         been replaced with an aggregate relationship. Service Section 5.21 of RFC 2256
   [12].

2.2.12 Email string

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

2.2.13 Uniform Resource Identifier strings

   A uniform resource identifier (URI) is represented by the XML DTD as follows:

         <!ELEMENT Service                         (
            ((name | port | (name, port)) | portlist), protocol?,
              SNMPService?, WebService?
         )>
         <!ATTLIST Service
            ident                 CDATA                   '0'
         > URI data
   type. The Service class has one attribute:

         ident
            Optional. format of the URI data type is documented in RFC 2396 [8].

2.2.14 Unique Identifiers

   A unique identifier for in the service, see Section
            3.4.9.


         4.6.5.1 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 WebService Class
   UID and GUID data types are constructed from alphanumeric strings.























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


3. The WebService class augments IODEF Data Model

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

3.1 IODEF-Document

   The WebService IODEF-Document class is composed of four aggregate classes,
            as shown the top level class in Figure 4.22.

            +-------------+
            |   Service   |
            +-------------+
                  /_\
                   |
            +-------------+
            | WebService  |
            +-------------+            +-------------+
            |             |<>----------|  url        |
            |             |            +-------------+
            |             |       0..1 +-------------+
            |             |<>----------|  cgi        |
            |             |            +-------------+
            |             |       0..1 +-------------+
            |             |<>----------| http-method |
            |             |            +-------------+
            | the IODEF data
   model and the DTD.  All IODEF documents are instances of the
   IODEF-Documents class.


   +-----------------+
   |       0..* +-------------+ IODEF-Document  |             |<>----------|  arg
   +-----------------+
   |



Meijer, et al.            Expires March 2003                   [page 49]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 STRING version  |<>--{1..*}--[ Incident ]
   |                 |            +-------------+
            +-------------+
   +-----------------+

                     Figure 4.22  The WebService Class 2: IODEF-Document class

   The aggregate classes class that constitute WebService are:

            url
               Exactly one.  STRING. constitutes IODEF-Document is:

   Incident
      One.  The URL in Incident class contains all the request.

            cgi
               Zero or one.  STRING. incident-related
      information.

   The CGI script in the request,
               without arguments.

            http-method
               Zero or one. IODEF-Document class has one attribute:

   version
      Required.  STRING.  The HTTP method (PUT, GET) used in version of the request.

            arg
               Zero or more.  STRING.  The arguments IODEF specification to
      which the CGI script.

            This is represented in the XML DTD as follows:

            <!ELEMENT WebService                      (
               url, cgi?, http-method?, arg*
            )>


         4.6.5.2 The SNMPService Class IODEF document conforms.  The SNMPService class augments the Service value of this attribute
      MUST be 1.0


3.2 Incident class with
            additional information related

   Every incident reported to SNMP traffic.

            The SNMPService class or handled by a CSIRT is composed represented by an
   instance of three aggregate
            classes, as shown in Figure 4.23.

            +-------------+
            |   Service   |
            +-------------+
                  /_\
                   |
            +-------------+
            | SNMPService |
            +-------------+       0..1 +-----------+
            |             |<>----------|    oid the Incident class. This class provides a standardized
   representation for commonly exchanged incident data and associates a
   unique identifier with the described activity.








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


   +-------------------+
   | Incident          |
   +-------------------+
   |            +-----------+ ENUM purpose      |<>----------[ IncidentID      ]
   | ENUM restriction  |       0..1 +-----------+
   |             |<>----------| community                   |<>--{0..1}--[ AlternativeIDs  ]
   |                   |
   |            +-----------+



Meijer, et al.            Expires March 2003                   [page 50]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002                   |<>----------[ IncidentData    ]
   |                   |       0..1 +-----------+
   |             |<>----------|  command                   |<>--{0..1}--[ RelatedActivity ]
   |                   |
   |            +-----------+
            +-------------+                   |<>--{0..*}--[ AdditionalData  ]
   +-------------------+

                      Figure 4.23  The SNMPService Class 3: the Incident class

   The aggregate classes that constitute SNMPService Incident are:

            oid

   IncidentID
      One.  The incident tracking number or unique identifier assigned
      to this incident by the party that generated the document.

   AlternativeIDs
      Zero or one.  STRING.  The object identifier  A list of incident tracking numbers used by other
      CSIRTs to refer to same activity as described in the
               request.

            community document.

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

   IncidentData
      Zero or more.  The object's community string.

            command event(s) that constitute the incident about
      which the IODEF-Document conveys information.

   AdditionalData
      Zero or one.  STRING. more.  Extension area for data that cannot be represented
      anywhere else.

   The command sent to Incident class has two attributes:

   purpose
      Required.  ENUM.  The purpose of the SNMP
               server (GET, SET.  etc.). IODEF document.  This
      attribute is represented in the XML DTD defined as follows:

            <!ELEMENT SNMPService                     (
               oid?, community?, command?
            )>



      4.6.6 an enumerated list:

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

      2.  statistics. The Target class contains information about IODEF-Document was sent to be included in a



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


          data-repository for statistical purposes;

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

      4.  other. The IODEF-Document was sent for purposes specified in
          the possible
         target(s) of AdditionalData element.

   restriction
      Optional.  ENUM.  This attribute indicates the incident event(s).  An event may have more
         than one target (e.g., in disclosure
      guidelines to which the case sender expects the recipient of a port sweep).

         For the purpose
      IODEF-Document to adhere. However, it is the choice of compatibility, the Target class has been
         reused from
      recipient of the IDMEF. Hence, document to honor this guideline.

      The value of this attribute is logically inherited by the Target class from an IDMEF
         message can be included unmodified into children
      of this class.  That is to say, the IODEF-Description
         class with disclosure rules applied to
      this class, also apply to its children.

      It is possible to set a granular disclosure policy, since many of
      the same semantics.  Likewise, high-level classes have a restriction attribute.  Therefore, a
      child can override the data in an
         IDMEF-originating Source class could guidelines of a parent class, be decomposed between it to
      tighten or relax the
         IODEF Target disclosure rules (i.e., a child has a weaker
      policy than an ancestor; or an ancestor has a weak policy, and Attack classes. the
      children selectively apply more rigid controls).  The definition implicit
      value of the Target restriction attribute for a class that did not
      specify one can be found in the IODEF data model closest ancestor that did specify
      a value.

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

      1.  public.  There is no restriction level applied to the IDMEF definition.  Two new classes have been
         added: os and program.
          information;

      2.  need-to-know.  The Target class is composed of four aggregate classes, as
         shown information may be shared with other
          parties that are involved in Figure 4.8.





Meijer, et al.            Expires March 2003                   [page 51]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         +------------------+
         |      Target      |
         +------------------+       0..1 +----------+
         | STRING ident     |<>----------| Node     |
         | ENUM spoofed     |            +----------+
         | STRING interface |       0..1 +----------+
         |                  |<>----------| User     |
         |                  |            +----------+
         |                  |       0..1 +----------+
         |                  |<>----------| Process  |
         |                  |            +----------+
         |                  |       0..1 +----------+
         |                  |<>----------| Service  |
         |                  |            +----------+
         |                  |       0..1 +----------+
         |                  |<>----------| FileList |
         |                  |            +----------+
         |                  |       0..1 +----------+
         |                  |<>----------| os       |
         |                  |            +----------+
         |                  |       0..1 +----------+
         |                  |<>----------| Program  |
         |                  |            +----------+
         +------------------+

         Figure 4.8 the incident (e.g., multiple
          victim sites can be informed of each other);

      3.  private.  The Target Class information may not be shared.

      4.  default.  The aggregate classes that constitute Target are:

         Node
            Zero or one.  Information about the host or device at which
            the event(s) (network address, network name, etc.) is being
            directed.

         User
            Zero or one.  Information about the user at which the
            event(s) is being directed.

         Process
            Zero or one.  Information about the process at which the
            event(s) is being directed.

         Service
            Zero or one.  Information about information can be shared according to an
          information disclosure policy pre-arranged by the network service involved
            in
          communicating parties.



3.3 IncidentID class

   The IncidentID class represents the event(s).

         FileList
            Zero incident tracking number or one.  Information about file(s) involved in the



Meijer, et al.         Expires September 29, 2003              [Page 16]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 52]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            event(s).

         os
            Zero or one. The operation system running on the targeted
            Node.

         program
            Zero


   identifier used by a CSIRT or one.  The program running as reporter to uniquely identify (in their
   organization) the Process, which was
            targeted activity characterized in this IODEF-Document.

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

                     Figure 4: the Attack.


         This IncidentID class

   The element content represents an incident tracking number (UID) that
   is represented unique in the XML DTD as follows:

         <!ENTITY % attvals.yesno   "
            ( unknown | yes | no )
         ">
         <!ELEMENT Target   (
            Node?, User?, Process?, Service?, FileList?, os?, program?
         )>
         <!ATTLIST Target
            ident       CDATA             '0'
            decoy       %attvals.yesno;   'unknown'
            interface   CDATA             #IMPLIED
         > context of the CSIRT.

   The Target IncidentID class has three attributes:

         ident
            Optional.  A unique one attribute:

   name
      Required.  GUID.  An identifier for this Target class (see
            Section 3.4.9).

         spoofed
            Optional.  An indication of confidence as to whether this is the true Attack target. CSIRT that created the
      IODEF-Document.


3.4 AlternativeID class

   The permitted values for AlternativeID class references the incident tracking numbers or
   unique identifiers used by other entities (e.g., CSIRTs) to refer to
   activity identical to that characterized in this
            attribute IODEF-Document.
   Thus, tracking numbers listed as an AlternativeID are shown below.  The default value is "unknown".

            Rank   Keyword   Description
            ----   -------   -----------
              0    unknown   Accuracy of target information unknown
              1    yes       Target is believed to be the same events
   detected by another CSIRT, but seem from a decoy
              2    no        Target is believed to different perspective.  It
   follows, the incident tracking numbers of the organization that
   generated the IODEF-Document should never be "real"

         interface
            Optional.  Specifies considered an
   AlternativeID.

   If the interface on which incident is not the event(s)
            against identical activity, but is related (e.g.,
   same methodology or intruder), then its incident tracking number
   should instead be represented in the Target were detected.


      4.6.7 The FileList Class RelatedActivity (Section 3.5)
   class.













Meijer, et al.         Expires March September 29, 2003                   [page 53]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         The FileList class describes files              [Page 17]

Internet-Draft    IODEF Data Model and other file-like objects
         on targets.  It is primarily used as a "container" Implementation         March 2003


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


                   Figure 5: the AlternativeID class

   The aggregate classes that constitute AlternativeID are:

   IncidentID
      One or more.  Unique identifiers assigned by another entity for
      the File aggregate class, as shown identical activity characterized in Figure 5.33. For the
         purpose IODEF-Document.

   The AlternativeID class has one attribute:

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


3.5 RelatedActivity class

   The RelatedActivity class references the incident tracking numbers or
   unique identifiers of compatibility incidents that are related to the FileList Class is reused from one described
   in the
         IDMEF.


         +--------------+
         |   FileList IODEF document.  These references may to local incident
   tracking numbers, as well as, to those of other CSIRTs.

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


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

                    Figure 4.33  The FileList Class 6: RelatedActivity class

   The aggregate class contained in FileList is:

         File classes that constitute RelatedActivity are:

   IncidentID
      One or more.  Information about an individual file, as
            indicated  Unique identifiers assigned by its "category" the CSIRT.

   The RelatedActivity class has one attribute:



Meijer, et al.         Expires September 29, 2003              [Page 18]

Internet-Draft    IODEF Data Model and "fstype" attributes (see
            Section 4.8.13.1). Implementation         March 2003


   restriction
      Optional.  ENUM.  This is represented attribute has been defined in the XML DTD as follows:

         <!ELEMENT FileList                        (
            File+
         )>


         4.6.7.1 The File Class Section 3.2.


3.6 AdditionalData

   The File AdditionalData class provides specific serves as an extension mechanism for
   information about a file or
            other file-like object that has been created, deleted, or
            modified on the target.  More than one File can be used
            within not otherwise represented in the FileList class data model. For
   relatively simple information, atomic data (integers, strings, etc.)
   types are provided with a mechanism to provide information about more
            than one file. annotate their meaning.  The description
   class can provide either also be used to extend the file
            settings prior 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 event or data model and the file settings at 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 time 'meaning' attribute.  Since these description are outside the
   scope of the event, as specified specification, some additional coordination may be
   required to ensure that a recipient of a document using the "category" attribute.

            The File class is composed
   AdditionalData classes can make sense of ten aggregate classes, as
            shown in Figure 4.34.


            +--------------+
            |     File     |
            +--------------+            +-------------+
            |              |<>----------|    name     |
            |              |            +-------------+



Meijer, et al.            Expires March 2003                   [page 54]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            |              |            +-------------+
            |              |<>----------|    path     |
            |              |            +-------------+
            |              |       0..1 +-------------+
            |              |<>----------| create-time |
            |              |            +-------------+
            |              |       0..1 +-------------+
            |              |<>----------| modify-time |
            |              |            +-------------+
            |              |       0..1 +-------------+
            |              |<>----------| access-time |
            |              |            +-------------+
            |              |       0..1 +-------------+
            |              |<>----------|  data-size  |
            |              |            +-------------+
            |              |       0..1 +-------------+
            |              |<>----------|  disk-size  |
            |              |            +-------------+
            |              |       0..* +-------------+
            |              |<>----------| FileAccess  |
            |              |            +-------------+ the custom extensions.


   +------------------+
   | AdditionalData   |       0..* +-------------+
   +------------------+
   |              |<>----------|   Linkage ANY              |
   |                  |            +-------------+
   | ENUM restriction |       0..1 +-------------+
   |              |<>----------|    Inode ENUM type        |
   | STRING meaning   |            +-------------+
            +--------------+
   +------------------+

                   Figure 4.34  The File Class

            The aggregate classes that make up File are:

            name
               Exactly one.  STRING.  The name of the file to which the
               alert applies, not including the path to the file.

            path

               Exactly one.  STRING.  The full path to the file,
               including 7: the name. AdditionalData class

   The path name should be represented AdditionalData class has three attributes:

   restriction
      Optional.  ENUM.  This attribute has been defined in as "universal" a manner as possible, to facilitate
               processing Section 3.2.

   type
      Required.  ENUM.  The data type of the alert.

               For Windows systems, the path should be specified using
               the Universal Naming Convention (UNC) element content. The
      permitted values for remote files,
               and using this attribute are shown below. The default
      value is "string".

      1.   boolean.  The element contains a drive letter for local files (e.g.,
               "C:\boot.ini").  For Unix systems, paths on network file
               systems should use the name of boolean value, i.e., the mounted resource
           strings "true" or "false"




Meijer, et al.         Expires September 29, 2003              [Page 19]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 55]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



               instead of the local mount point (e.g.,
               "fileserver:/usr/local/bin/foo").


      2.   byte.  The mount point can be
               provided using the <Linkage> element.

            create-time
               Zero or one.  DATETIME.  Time the file was created.  Note
               that this element content is *not* the Unix "st_ctime" file attribute
               (which a single 8-bit byte (see
           Section 2.2.4);

      3.   character.  The element content is not file creation time). a single character (see
           Section 2.2.3);

      4.   date-time.  The Unix "st_ctime"
               attribute element content is contained in a date-time string (see
           Section 2.2.6);

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

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

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

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

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

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

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

            modify-time
               Zero or one.  DATETIME.  Time


3.7 IncidentData

   The IncidentData class summarizes the file was last modified.

            access-time
               Zero or one.  DATETIME.  Time details of the file was last accessed.

            data-size
               Zero or one.  INTEGER.  The size incident
   activity and a CSIRT's handling of the data, information, as well as,
   groups the security events that constitute the incident.

   Many of the aggregated classes of IncidentData are also found in bytes.
               Typically what
   EventData, albeit with different occurrence indicators.  However, the
   semantics of these classes is meant when referring to file size.  On
               Unix UFS file systems, this value corresponds to
               stat.st_size.  On Windows NTFS, this value corres- ponds
               to VDL.

            disk-size
               Zero or one.  INTEGER. quite different.  The physical space on disk
               consumed by classes of
   IncidentData reflect information relevant across the file, in bytes.  On Unix UFS file
               systems, this value corresponds to 512 * stat.st_blocks.
               On Windows NTFS, this value corresponds entire incident,
   while the classes of EventData provide information only relevant to EOF.

            FileAccess
               Zero or more.  Access permissions on
   the file.

            Linkage
               Zero given event or more.  File system objects to which this file is
               linked (other references for node being described.  The relationship
   between the file).

            Inode
               Zero or one.  Inode information for this file (relevant
               to Unix).

            This IncidentData and EventData classes is represented in complementary. The
   latter provides summary information, while the XML DTD as follows:

            <!ENTITY % attvals.filecat           "
               ( current | original )
            ">
            <!ELEMENT File                               (
               name, path, create-time?, modify-time?, access-time?,
               data-size?, disk-size?, FileAccess*, Linkage*, Inode?
            )> former provides more
   specific details.  For example, the overall impact of the incident
   (represented in IncidentData) might be denial of service, but it
   might be worth mentioning that there were specific machines
   (represented in EventData) which also suffered a root compromise. In



Meijer, et al.         Expires September 29, 2003              [Page 20]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 56]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            <!ATTLIST File
               ident                 CDATA                   '0'
               category              %attvals.filecat;       #REQUIRED
               fstype                CDATA                   #REQUIRED
               %attlist.global;
            >

            The File class has three attributes:

            ident
               Optional.  A unique identifier for this file, see Section
               3.4.9.

            category
               Required.  The context for the information being
               provided.  The permitted values are shown below.  There
               is no default value.

               Rank   Keyword     Description
               ----   -------     -----------
                 0     current    The file information is from after the
                                  reported change
                 1     original   The file information is from before
                                  the reported change

            fstype Required.  The type of file system


   another example, an organizational contact can be provided in
   IncidentData class, while more specific contacts for the file resides
            on.  The name should individual
   hosts can be specified using a standard
            abbreviation, e.g., "ufs", "nfs", "afs", "ntfs", "fat16",
            "fat32", "pcfs", "joliet", "cdfs", etc.  This attribute
            governs how path names and other attributes are interpreted.


         4.6.7.2 The FileAccess Class

            The FileAccess class represents in the access permissions on a
            file. The representation is intended to EventData class.

   IncidentData also ensures that certain mandatory information will be usefule across
            operating systems.

            The FileAccess class is composed of two aggregate classes,
            as shown
   present in Figure 4.35.

            +--------------+ the data model.


   +------------------+
   |  FileAccess IncidentData     |
            +--------------+            +------------+
   +------------------+
   |              |<>----------|   UserId ENUM restriction |<>--{0..*}--[ Description    ]
   |                  |
   |            +------------+                  |<>--{1..*}--[ Assessment     ]
   |                  |       1..* +------------+
   |              |<>----------| permission                  |<>--{0..*}--[ Method         ]
   |                  |
   |                  |<>--{0..1}--[ DetectTime     ]
   |                  |
   |                  |<>--{0..1}--[ StartTime      ]
   |                  |
   |                  |<>--{0..1}--[ EndTime        ]
   |                  |
   |                  |<>----------[ ReportTime     ]
   |                  |
   |                  |<>--{1..*}--[ Contact        ]
   |                  |
   |            +------------+                  |<>--{0..*}--[ Expectation    ]
   |                  |
   |                  |<>--{0..1}--[ History        ]
   |                  |
   |                  |<>--{0..*}--[ EventData      ]
   |                  |
   |                  |<>--{0..*}--[ AdditionalData ]
   +------------------+

                    Figure 8: the IncidentData class

   The aggregate classes that constitute IncidentData are:

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

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




Meijer, et al.         Expires September 29, 2003              [Page 21]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 57]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



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

            Figure 4.35


   Method
      Zero or more.  The FileAccess Class techniques (e.g., tools, vulnerabilities) used
      by the intruder.

   DetectTime
      Zero or one.  The aggregate classes that make up FileAccess are:

            UserId
               Exactly time the incident activity was first detected.

   StartTime
      Zero or one.  The user (or group) time the incident activity started.

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

   ReportTime
      One.  The time the incident activity was reported.

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

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

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

   EventData
      Zero or more.  Details on the Data on the (security) events that
      lead to which these
               permissions apply.  The value of the "type" attribute
               must be "user-privs", "group-privs", or "other-privs" as
               appropriate.  Other values for "type" MUST NOT be used in
               this context.

            permission
               One incident.

   AdditionalData
      Zero or more.  STRING.  Level of access allowed.
               Recommended values are "noAccess", "read", "write",
               "execute", "delete", "executeAs", "changePermissions",
               and "takeOwnership".  The "changePermissions" and
               "takeOwnership" strings represent those concepts in
               Windows.  On Unix, the owner of  An area to extend the file always has
               "changePermissions" access, even if no other access is
               allowed for data model with information
      that user.  "Full Control" in Windows is can not be represented by enumerating the permissions it contains. elsewhere.

   The "executeAs" string represents the set-user-id and
               set-group-id features in Unix. IncidentData class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is represented defined in the XML DTD as follows:

            <!ELEMENT FileAccess                      (
               UserId, permission+
            )>


         4.6.7.3 The Linkage Class Section 3.2.


3.8 Contact class

   The Linkage Contact class represents file system connections between
            the file described describes contact information for organizations and
   personnel involved in the <File> element incident.  This class encapsulates naming
   the involved party, specifying contact information to reach them, and other objects
   identifying their role in the file system.  For example, if the <File> element is a
            symbolic link or shortcut, then incident.



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


   People and organizations are treated interchangeably as contacts; one
   can be associated with the <Linkage> element should
            contain other using the name recursive definition of
   the object class. The 'type' attribute determines the link points to.  Further type of contact
   information can be provided about the object in the
            <Linkage> element with another <File> element, if
            appropriate. being provided.

   The Linkage recursive definition of this class (the Contact class is composed
   aggregated into the Contact class) provides a way to relate
   information without requiring the explicit use of three aggregate classes, as
            shown identifiers in Figure 4.36.

            +--------------+ the
   classes.  When grouping people into organizations it is RECOMMENDED
   to nest the persons instances into an organization instance of this
   class.


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



Meijer, et al.            Expires March 2003                   [page 58]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            +--------------+            +------+
   |              |<>----------| name                  |<>--{0..*}--[ RegistryHandle ]
   |                  |
   |            +------+                  |<>--{0..1}--[ PostalAddress  ]
   |                  |            +------+
   |              |<>----------| path                  |<>--{0..*}--[ Email          ]
   |                  |
   |                  |<>--{0..*}--[ Telephone      ]
   |                  |            +------+
   |                  |<>--{0..1}--[ Fax            ]
   |            +------+                  |              |<>----------| File
   |                  |<>--{0..1}--[ Timezone       ]
   |                  |            +------+
            +--------------+
   |                  |<>--{0..*}--[ Contact        ]
   +------------------+

                      Figure 4.36  The Linkage Class 9: the Contact class

   The aggregate classes that make up Linkage constitute the Contact class are:

   name
               Exactly
      Zero or one.  STRING.  NAME.  The name of the file system object
               not including the path.

            path
               Exactly one.  STRING.  The full path to the file system
               object, including the name. contact.  The path name should contact may
      either be
               represented in as "universal" an organization or a manner as possible, to
               facilitate processing of person.  The type attribute
      dictates the alert.

            File
               Exactly semantics (organization or person).

   Description
      Zero or one.  A <File> element may be used in place  STRING.  Free-form description of the <name> and <path> elements if additional information
               about this contact.
      In the file is to be included.

            The case of a person, this is represented in often the XML DTD as follows:

            <!ENTITY % attvals.linkcat               "
               ( hard-link | mount-point | reparse-point | shortcut |
                 stream | symbolic-link )
            ">
            <!ELEMENT Linkage                        (
               (name, path) | File
            )>
            <!ATTLIST Linkage
               category             %attvals.linkcat;       #REQUIRED
            >

            The Linkage class has one attribute:

            category
               The type organizational title of object that
      the link describes.  The
               permitted values are shown below.  There is no default
               value. individual.



Meijer, et al.         Expires September 29, 2003              [Page 23]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 59]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




            Rank   Keyword         Description
            ----   -------         -----------
              0    hard-link


   RegistryHandle
      Zero or many.  The <name> element represents another handle name for this file.  This information
                                   may in a registry.  Care must be more easily obtainable on NTFS
                                   file systems than others.
              1    mount-point     An alias taken
      to ensure that a handle is meaningful to the recipient.
      Intra-organizational handles are of not much use for
      extra-organizational communication.

   PostalAddress
      Zero or one.  POSTAL.  The postal address of the directory specified
                                   by contact formatted
      according to Section 2.2.9.

   Email
      Zero or many.  EMAIL.  The email address of the parent's <name> and <path>
                                   elements.
              2    reparse-point   Applies only contact formatted
      according to Windows; excludes
                                   symbolic links and mount points,
                                   which are specific types Section 2.2.12.

   Telephone
      Zero or many.  PHONE.  The telephone number of reparse
                                   points.
              3    shortcut the contact
      formatted according to .

   Fax
      Zero or one.  PHONE.  The file represented by a Windows
                                   "shortcut."  A shortcut is
                                   distinguished from a symbolic link
                                   because facsimile telephone number of the difference
      contact formatted according to .

   Timezone
      Zero or one.  STRING. The timezone in their
                                   contents, which may be of importance
                                   to the manager.
              4    stream contact resides.

   Contact
      Zero or many.  Recursive definition of Contact, allowing for
      grouping of data.  An Alternate Data Stream (ADS) in
                                   Windows; a fork on MacOS.  Separate
                                   file system entity that example of this is considered an extension of the main <File>.
              5    symbolic-link organization with
      multiple contact persons.

   The <name> element represents Contact class has three attributes:

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

   role
      Required.  ENUM.  Indicates the
                                   file to which role the link points.


         4.6.7.4 The Inode Class

            The Inode class Contact fulfills.   This
      attribute is used to represent defined as an enumerated list:

      1.  creator.  The entity that generate the additional
            information contained in IODEF document.

      2.  admin.  An administrative contact for a Unix file system i-node. host or network.

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

      4.  irt.  The Inode class is composed of six aggregate classes, as
            shown CSIRT involved in Figure 4.37.

            +--------------+
            |    Inode     |
            +--------------+            +----------------+
            |              |<>----------|   change-time  |
            |              |            +----------------+
            |              |            +----------------+
            |              |<>----------|     number     |
            |              |            +----------------+
            |              |            +----------------+
            |              |<>----------|  major-device  |
            |              |            +----------------+
            |              |            +----------------+
            |              |<>----------|  minor-device  | handling the incident.

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



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


          handling of the incident.

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

      1.  person.

      2.  organization.


3.8.1 RegistryHandle class

   The RegistryHandle class represents a handle to an Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            |              |            +----------------+
            |              |            +----------------+
            |              |<>----------| c-major-device | registry
   or community-specific database.  A handle consists of a name
   specified in the element content, and the database to which it
   belongs specified in the type attribute.


   +------------------+
   | RegistryHandle   |            +----------------+
   +------------------+
   | STRING           |            +----------------+
   |              |<>----------| c-minor-device                  |
   | ENUM type        |            +----------------+
            +--------------+
   +------------------+

                  Figure 4.37  The Inode Class

            The aggregate classes that make up Inode are:

            change-time
               Zero or one.  DATETIME.  The time of the last inode
               change, given by the st_ctime element of "struct stat".

            number
               Zero or one.  INTEGER. 10: The inode number.

            major-device
               Zero or one.  INTEGER. RegistryHandle class

   The major device number of the
               device the file resides on.

            minor-device
               Zero or one.  INTEGER. RegistryHandle class has one attribute:

   type
      Required.  ENUM.  The minor device number of the
               device database to which the file resides on.

            c-major-device
               Zero or one.  INTEGER. handle belongs.   The major device of the file
               itself, if it
      default value is a character special device.

            c-minor-device
               Zero or one.  INTEGER. 'local'.  The minor device of the file
               itself, if it is a character special device.

            Note that <number>, <major-device>, and <minor-device> must
            be given together, and the <c-major-device> 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
            <c-minor-device> must be given together.

            This is represented in the XML DTD as follows:

            <!ELEMENT Inode                          (
               change-time?, (number, major-device, minor-device)?,
               (c-major-device, c-minor-device)?
            )> Caribbean IP Address
          Registry

      5.  ripe.  Reseaux IP Europeens

      6.  ti.  TERNEA Trusted Introducer




Meijer, et al.         Expires September 29, 2003              [Page 25]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 61]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      4.6.8 The Description Class


      7.  local.  A database local to the CSIRT.


3.9 Time classes

   The Description class is a general-purpose class data model uses for any
         natural language free-form text.

         Using the XML language attribute, it is reasonable different classes to include
         text in represent a number of different languages in different instances
         of the Description class. For details on declaring language
         attribute see section 3.3.3.

         <!ELEMENT Description xml:lang="langcode">

      4.6.9 The DetectTime Class

         The time when the incident activity was first detected by the
         reporter.

         It timestamp.
   Their definition is represented in the XML DTD as follows:

         <!ELEMENT DetectTime            (#PCDATA) >
         <!ATTLIST DetectTime
            ntpstamp              CDATA                   #REQUIRED
         > identical, but each is named differently to
   convey a semantic difference.

   The DATETIME format of the <DetectTime> element content of each class is
         described in a timestamp formated according
   to the DATETIME data type (see Section 3.4.6. 2.2.6).


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

                      Figure 11: the Time classes

   The DetectTime class has Time classes have one attribute:

   ntpstamp

            Required.
      Optional.  NTPTIMESTAMP.  The NTP timestamp representing the same date and
            time as
      timestamp in the element content.  The NTPSTAMP format of this
      attribute's value is described in Section 3.4.7.

            If 2.2.7.

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

3.9.1 StartTime

   The StartTime class represents timestamp for the start of an
   activity.

3.9.2 EndTime

   The EndTime class represents the NTP timestamp differ (should "never" happen), for the value
            in end of an
   activity.

3.9.3 DetectTime




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


   The DetectTime class represents the NTP timestamp MUST 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 used.


      4.6.10 inferred from the parent class into which it is
   aggregated.

3.10 Expectation class

   The Expectation class conveys to the recipient of the IODEF document
   the actions the sender is requesting.

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

                    Figure 12: the Expectation class

   The aggregate classes that constitute Expectation are:

   Description
      One or many.  STRING.  A free-form description of the desired
      action(s).

   StartTime Class
      Zero or one.  The start time of at which the incident activity.

         It action should be performed.  A
      timestamp that is represented earlier than the ReportTime specified in the XML DTD
      IncidentData class denotes that the expectation should be
      fulfilled as follows:

         <!ELEMENT StartTime            (#PCDATA) > soon as possible.  The DATETIME format absence of the <StartTime> this element content is leaves
      the execution of the expectation to the discretion of the
      recipient.





Meijer, et al.         Expires September 29, 2003              [Page 27]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 62]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         described in Section 3.4.6.


      4.6.11 The


   EndTime Class
      Zero or one.  The end time of by which the incident activity.

         It action should be completed.
      If the action is represented in not carried out by this time, it should no longer
      be performed.

   Contact
      Zero or one.  The expected actor for the XML DTD as follows:

         <!ELEMENT EndTime            (#PCDATA) > action.  The DATETIME format 'role'
      attribute of the <StartTime> element content Contact MUST be set to "actor".

   The Expectations class has three attributes:

   restriction
      Optional.  ENUM.  This attribute is
         described defined in Section 3.4.6.



   4.7 The 3.2.

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

      1.  low.  Low priority

      2.  medium. Medium priority

      3.  high. High priority

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

      1.  nothing.  No action is requested.  Do nothing with the
          information.

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

      3.  contact-me.  Contact the originator of the document.

      4.  block.  Block or investigate machines listed in the document
          in the recipient's constituency.


3.11 Method Class class

   The Method class provides information about the method methodology used by
   the
      Attacker in intruder to perpetrate the events of the incident.  This class
   can reference well-known vulnerability or exploit databases, as well as allow list the
   intruder tools used in the attack, and provide for a free-form
   description of the activity.

      The Method class is composed of two aggregate classes, as shown in
      Figure 4.9.




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


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

                      Figure 4.9 13: The Method Class class

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

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

   Description
      Zero or more. many.  STRING A free-form text description of the attack.





Meijer, et al.            Expires March 2003                   [page 63]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      This is represented of the
      methodology used in the XML DTD as follows:

      <!ELEMENT Method   (
         Classification*, Description*)>
      <!ATTLIST Method
         ident         ID                      #IMPLIED
         restriction   %attvals.restriction;   'default'
      > incident.

   The Method class has two attributes:

      ident
         Optional. A unique identifier for the element (see Section
         3.4.9). one attribute:

   restriction
      Optional. Sets a restriction on the usage of the data  ENUM.  This attribute is defined in
         element.


      4.7.1 The Section 3.2.


3.11.1 Classification Class class

   The Classification class provides is a way to reference to an external vulnerability, exposure, database of
   computer vulnerabilities, exposures, or virus database.

         The Classification class is composed viruses.  A reference
   consists of two aggregate classes,
         as shown the database name, the entry in Figure 4.24.

         +----------------+ the database, and the URI
   to this entry.

   +------------------+
   | Classification   |
         +----------------+        +---------+
   +------------------+
   | STRING origin  |<>------| ENUM restriction |<>----------[ name ]
   | ENUM origin      |
   |        +---------+
         |                |        +---------+
         |                |<>------|                  |<>----------[ url     |
         |                |        +---------+
         +----------------+  ]
   +------------------+

                  Figure 4.24 14: The Classification Class class

   The aggregate classes that constitute Classification are: Classification:

   name
            Exactly one.
      One.  STRING.  The name of the Vulnerability,
            Exposure or Virus (from one of the origins listed below)
            used by Attacker reference to cause Incident.

         url 
            Exactly one.  STRING.  A URL at which the manager can find database specified
      in the origin attribute.



Meijer, et al.         Expires September 29, 2003              [Page 29]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 64]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


   url
      One.  URI.  A URL to additional information about classified method. The document
            pointed to by the URL may include an in-depth description of the attack, appropriate countermeasures,
      vulnerability or other
            information deemed relevant exposure referenced by the vendor.

         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.origin                 "
            ( unknown | bugtraqid | cve | vendor-specific )
         ">
         <!ELEMENT Classification                  (
            name, url
         )>
         <!ATTLIST Classification
            origin                %attvals.origin;        'unknown'
         > name.

   The Classification class has one two attribute:

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

   origin
      Required.  ENUM.  The source from which the name of the alert
            originates. database to which the reference
      is being made.  The permitted values for this attribute are shown below. The default value is "unknown".

            Rank   Keyword           Description
            ----   -------           -----------
              0    unknown           Origin of the name is not known
              1    bugtraqid         The SecurityFocus.com ("Bugtraq")
                                     vulnerability database identifier
                                     (http://www.securityfocus.com/vdb)
              2    cve               The

      1.  bugtraqid.  Bugtraq

      2.  cve.  Common Vulnerabilities and or Exposures (CVE) name
                                     (http://www.cve.mitre.org/)
              3    vendor-specific

      3.  certcc.  CERT Coordination Center Vulnerability Catalog

      4.  vendor.  A vendor-specific name (and hence,
                                     URL); this can product vendor whose name should be used to provide
                                     product-specific information


   4.8 The Attacker Class

      The Attacker class augments information found specified in
          the Source name class
      with further details related to the entity(ies)/person(s)
      identified as

      5.  local.  A local database.

      6.  other.


3.12 Assessment class

   The Assessment class describes the source(s) technical and non-technical
   repercussions of the incident activity.

      NOTE: Information found in

   Note: The IODEF definition of the Attacker Assessment class might be derived
      based on address and network information found in reuses the Source
      class.  However, particular algorithm or procedure is defined by
      Incident Handling System IDMEF
   definition (see Section 4.2.4.5 of [7]), but also extends it.

















Meijer, et al.         Expires September 29, 2003              [Page 30]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 65]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


         +------------------+
         | Attacker Assessment       |
         +------------------+
         | STRING ident     |   0..1 +---------------+
      | ENUM restriction |<>------| Contact       | |<>--{0..*}--[ Impact         ]
         |                  |        +---------------+
         |                  |<>--{0..*}--[ TimeImpact     ]
         |   0..1 +---------------+                  |                  |<>------| IRTcontact
         |                  |<>--{0..*}--[ MonetaryImpact ]
         |                  |        +---------------+
         |                  |<>--{0..*}--[ LifeImpact     ]
         |   0..1 +---------------+                  |                  |<>------| Location
         |                  |<>--{0..1}--[ Confidence     ]
         +------------------+        +---------------+

                      Figure 4.10  The Attacker Class 15: Assessment class

   The aggregate classes that constitute Attacker Assessment are:

      Contact
         Zero or one. Contact information for the entity/person
         identified as an Attacker.

      Location

   Impact
      Zero or one. Location of Attacker's node or system. This is a
         general definition many.  Technical impact of location that may depend on network
         structure or company's geographical distribution.

      IRTcontact
         Zero or one. Contact information for the CSIRT or Network
         Security manager serving the NodeÆs network.


      Attacker is represented in the XML DTD as follows:

      <!ELEMENT Attacker   (
         Contact?, Location?, IRTcontact?)>
      <!ATTLIST Attacker
         ident         ID                      #IMPLIED
         restriction   %attvals.restriction;   'default'
      >

      The Attacker class has two attributes:

      ident
         Optional. A unique identifier for the Attacker, see Section
         4.4.9.

      restriction



Meijer, et al.            Expires March 2003                   [page 66]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         Optional. Sets a restriction activity on the usage of the data in
         element.

      
      
      4.8.1 The Contact Class

         The Contact Class contains contact information for a person or
         role in a CSIRT handling an incident.


         +--------------+
         |   Authority  |
         +--------------+
                /_\
                 |
         +--------------+
         | Contact      |
         +--------------+       0..1 +----------------+
         | STRING ident |<>----------| PersonName     |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| PostalAddress  |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| ContactHandle  |
         |              |            +----------------+
         +--------------+

         Figure 4.29  Contact Class


         The aggregate classes that constitute Contact class are:

         PersonName computers
      and networks.

   TimeImpact
      Zero or one.  Name many.  Impact of the person responsible for handling
            the current incident.

         ContactHandle activity measured with respect to
      time.

   MonetaryImpact
      Zero or one.  Identification number (or handle) used many.  Impact of the activity measured with respect to
            refer
      money.

   LifeImpact
      Zero or many.  Impact of the activity measured with respect to personal (or role) information in different
            Registries.

         PostalAddress
      human life.

   Confidence
      Zero or one.  Postal Address  An estimate of the person identified by
            PersonName.

         Contact is represented confidence in the XML DTD as follows:




Meijer, et al.            Expires March 2003                   [page 67]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         <!ELEMENT Contact                           (
            PersonName?, ContactHandle?, PersonAddress?)>
         <!ATTLIST Contact
            ident                 ID                      #IMPLIED
         > assessment.

   The Contact Assessment class has one attribute:

         ident

   restriction
      Optional. A unique identifier for the Contact element (see  ENUM.  This attribute is defined in Section 3.4.9).


      4.8.2  The IRTcontact Class 3.2.


3.12.1 Impact class

   The IRTcontact Impact class contains an IRTcontact handle to a public
         registry (e.g., RIPE NCC database [18], Trusted Introducer
         database [19]) that references contact information allows for classifying as well as providing a
   description of the
         CSIRT or network security manager serving technical impact due to the incident activity on
   the computers and networks
         referenced in of an organization.



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


   Attributes allow the Attacker or Victim class.

         This impact to be classified according to the
   consequences on the host and the severity of these consequences. The
   element content is represented in used for the XML DTD as follows:

         <!ENTITY % attvals.originIRT                 "
            ( unknown description.

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

   +------------------+
   | ripencc Impact           | ti
   +------------------+
   | arin STRING           | apnic
   | afnic                  | local )
         ">
         <!ELEMENT IRTcontact   >
         <!ATTLIST IRTcontact
            originIRT   %attvals.originirt;   'unknown'
         >

         IRTcontact
   | ENUM restriction |
   | ENUM severity    |
   | ENUM completion  |
   | ENUM type        |
   +------------------+

                        Figure 16: Impact class

   The element content may be empty, or contain a free-form description
   (STRING) of the technical impact.

   The Impact class has one attribute:

         originIRT
            Required.  The registry which four attributes:

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

   severity
      Optional.  ENUM.  An estimate of the IRTcontact handle
            references. relative severity of the
      activity. The permitted values for this attribute are shown below. The default value  There is "unknown".

         Rank   Keyword   Description
         ----   -------   -----------
           0    unknown   Origin no
      default value.

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   completion
      Optional.  ENUM.  An indication of whether the name creator of the
      IODEF document believes the activity was successful.  The
      permitted values are shown below. There is no default value.

      1.  failed.  The attempt was not known
           1    ripencc   RIPE NCC database
           2    ti        Trusted Introducer database of CSIRTs
           3    arin      ARIN database
           4    apnic     APNIC database
           5    afnic     AFNIC database
           6    local     Name of IRT as it used by Incident object
                          creator successful

      2.  succeeded.  The attempt succeeded



Meijer, et al.         Expires September 29, 2003              [Page 32]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 68]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002





   4.9


   type
      Required.  ENUM.  The Victim Class type of impact in relatively broad
      categories.  The Victim class augments information found 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 Target above categories


3.12.2 TimeImpact class
      with further details related to the entity(ies)/person(s)
      identified as

   The TimeImpact class describes the target(s) non-technical impact of the incident activity.

      NOTE: Information found in the Victim class might be derived based
   activity on address and network information found in the Target class.
      However, particular algorithm or procedure is defined by Incident
      Handling System. an organization as a function of time. Different types of
   time calculations and well as units can be used.


         +------------------+
         | Victim TimeImpact       |
         +------------------+
         | STRING ident     |   0..1 +---------------+
      | ENUM restriction |<>------| Contact       |
      | REAL             |        +---------------+
         |                  |   0..1 +---------------+
         |                  |<>------| IRTcontact ENUM restriction |
         | ENUM severity    |        +---------------+
         | ENUM metric      |   0..1 +---------------+
         |                  |<>------| Location ENUM units       |
         +------------------+        +---------------+

                      Figure 4.11 The Victim Class 17: TimeImpact class

   The aggregate classes that constitute Victim are:

      Contact
         Zero or one. Contact information for element content will be a numeric value (REAL) specifying the entity/person
         identified
   impact as a Victim.

      Location
         Zero or one.  Location of VictimÆs node or system. This is a
         general definition function of location that may depend on network
         structure or companyÆs geographical distribution.

      IRTcontact
         Zero or one. Contact information for the CSIRT or Network
         Security manager serving the NodeÆs network.


      Victim is represented in time.  The attributes represent the XML DTD as follows:

      <!ELEMENT Victim   (
         Contact?, Location?, IRTconact?)>
      <!ATTLIST Victim specific
   units and metric.

   The TimeImpact class has four attributes:




Meijer, et al.         Expires September 29, 2003              [Page 33]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 69]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         ident         ID                      #IMPLIED


   restriction   %attvals.restriction;   'default'
      >

      The Victim class has two attributes:

      ident
      Optional. A unique identifier for the Victim element, see  ENUM.  This attribute has been defined in Section 4.4.9.

      restriction 3.2.

   severity
      Optional. Sets a restriction on  ENUM.  An estimate of the usage relative severity of the data in
         element.  
        



      4.10
      activity. The Record Class permitted values are shown below.  There is no
      default value.

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   metric
      Required.  ENUM.  Defines the metric in which the time is
      expressed.  The Record class contains supportive data that provides a
         record 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 incident activity. the recovery to
          its completion.

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

   units
      Required.  ENUM.  Defines the units in which the metric is
      expressed.  The permitted values are shown below. The default
      value is "hours".

      1.  seconds.  Seconds

      2.  minutes.  Minutes

      3.  hours. Hours

      4.  days.  Days


3.12.3 MonetaryImpact class

   The source MonetaryImpact class describes the financial impact of this the
   activity record
         will be typically data exported from a monitoring tool or on an organization.  For example, this impact may consider
   loss due to the
         results cost of a computer forensics investigation.  The record data
         can consist the investigation or recovery, diminished
   productivity of both data the staff, or a tarnished reputation that will affect



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


   future opportunities.


         +------------------+
         | Record MonetaryImpact   |
         +------------------+
         | STRING ident REAL             |
         |                  |   0..* +-------------+
         | ENUM restriction |<>------| RecordData |
         | ENUM severity    |
         | ENUM metric      |
         | STRING currency  |
         +------------------+        +-------------+

                    Figure 4.12  The Record Class

         The aggregate 18: MonetaryImpact class that constitutes Record is:

         RecordData
            Zero or more.  Container for record data related to the
            current incident.

         Record is represented in

   The element content will be a numeric value (REAL) specifying the XML DTD
   impact as follows:

         <!ELEMENT Record   (
            RecordData*)>

         <!ATTLIST Record
            ident         ID                      #IMPLIED
            restriction   %attvals.restriction;   'default'
         >



Meijer, et al.            Expires March 2003                   [page 70]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 a function of money.  The Record attributes represent the specific
   currency and metric.

   The MonetaryImpact class has two four attributes:

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

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

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   currency
      Required.  ENUM.  Defines the currency in
            element.

         ident
            Optional. A unique identifier for which the Record element, see
            Section 4.4.9.


      4.10.1 monetary
      impact is expressed. 	The RecordData Class permitted values are defined in ISO
      4217:2001, Codes for the representation  of currencies and funds
      [18].  There is no default value.


3.12.4 LifeImpact class

   The RecordData LifeImpact class contains textual (e.g., logfiles,
         malicious scripts, list describes the loss of changes if file system, etc.) and
         binary (e.g., disc images) suportive data human life or injury due
   to an incident.




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


         +------------------+
         |   Record         |
         +------------------+
                  /_\ LifeImpact       |
         +------------------+
         | RecordData INTEGER          |
         +------------------+       0..* +--------------+
         | STRING ident     |<>----------| CorrRecord                  |
         | ENUM restriction |            +--------------+
         |                  |       0..1 +--------------+
         |                  |<>----------| RecordDesc   |
         |                  |            +--------------+
         |                  |       0..1 +--------------+
         |                  |<>----------| RecordItem ENUM severity    |
         | ENUM metric      |            +--------------+
         +------------------+

                      Figure 4.25  The RecordData Class 19: LifeImpact class

   The aggregate classes that constitute RecordData are:

         CorrRecord
            Zero or more.  RecordData element content will be a numeric value (INTEGER) specifying the
   impact as a function of human life.  The attributes represent the Record
   specific metric.

   The LifeImpact class that contains
            Record data correlated with current Record data.

         RecordDesc
            Zero or one. Description has three attributes:

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

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

      1.  low.  Low severity

      2.  medium. Medium severity

      3.  high. High severity

   metric
      Required.  ENUM.  Defines the metric in which the
            RecordItem class.

         RecordItem LifeImpact is
      expressed.  The permitted values are shown below.  There is no
      default value.

      1.  Deaths

      2.  Injuries


3.12.5 Confidence class

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



Meijer, et al.         Expires September 29, 2003              [Page 36]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 71]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            Zero or one. Container for a particular piece


   Note: The IODEF definition of record
            data.

         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.restriction             "
            ( default Confidence class reuses the IDMEF
   definition (see Section 4.2.6.3 of [7]), but also extends it and
   alters the semantics.

   The Confidence class has been reused from the IDMEF [7], it has been
   extended and has been altered.


         +------------------+
         | public Confidence       | internal
         +------------------+
         |
              restricted )
         ">
         <!ELEMENT RecordData                  (
            CorrRecord*, RecordDesc?, RecordItem?
         )>
         <!ATTLIST RecordData
            ident CDATA                       #IMPLIED REAL             |
         |                  |
         | ENUM restriction %attvals.restriction; #IMPLIED
         > |
         | ENUM rating      |
         +------------------+

                      Figure 20: Confidence class

   The RecordData element content may be empty if the rating attribute is not set
   to "numeric".  Otherwise, a confidence value (REAL) must be provided.

   The Confidence class has two attributes:

         ident
            Optional.  A unique identifier for this RecordData (see
            Section 3.4.9).

   restriction
      Optional. Sets a restriction on the usage of the data in
            element.


      4.10.2 The CorrRecord Class

         The CorrRecord class references the ID of other related
         RecordData for correlation.  ENUM.  This is represented attribute has been defined in Section 3.2.

   rating
      Required.  ENUM.  Indicates the XML DTD as follows:

         <!ELEMENT CorrRecord   (
            CorrRecordID
         )>
         <!ATTLIST CorrRecord
            IncidentID   ID   #IMPLIED
         >

         The CorrRecord class confidence the CSIRT has one attribute:

         IncidentID
            Optional.  The type of data included in the element content. its
      assessment. The permitted values for this attribute are shown below.  The default
      value is "string". "numeric."

      1.  low

      2.  medium

      3.  high

      4.  numeric.  The CSIRT has provided a probability value
          indicating its confidence in its assessment.

      5.  unknown

   This element SHOULD only be used when the CSIRT can produce
   meaningful information.  When only a rough estimate is possible
   "low", "medium", or "high" SHOULD be used as the rating value.

   When a reasonable probability estimate is possible "numeric" SHOULD



Meijer, et al.         Expires September 29, 2003              [Page 37]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 72]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      4.10.3


   be used as the rating value and include a numeric confidence value in
   the element content. This numeric value is a floating point number
   between 0.0 and 1.0, inclusive.

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

3.13 History class

   The RecordDesc Class History class is a log or diary of the significant events that
   occurred or actions performed by the involved parties (e.g., initial
   reporter, investigating CSIRT, or involved system administrators)
   during the course of handling the incident.

   The RecordDesc class contains meta-information about supportive
         data level of detail maintained in this log is left up to the ReportItem class.

         +----------------+
         | RecordDesc     |
         +----------------+       0..1 +----------------+
         |                |------------| DetectTime     |
         |                |            +----------------+
         |                |       0..1 +----------------+
         |                |<>----------| Analyzer       |
         |                |            +----------------+
         |
   discretion of those handling the incident.


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

                      Figure 4.26 21: The RecordDesc Class History class

   The aggregate classes class that constitute RecordDesc History are:

         DetectTime
            Zero

   HistoryItem
      One or one. Timestamp of the supportive data.  This data
            MUST be present if it is not already represented many.  Entries in the
            EvidenceItem class.

         Analyzer
            Zero or one.  The facility used to gather the supportive
            data.  The analyzer SHOULD define the name history log of the format,
            facility, tool, or device used to generate the supportive
            data if it is not self-describing (e.g. xml).  Likewise, the
            analyzer SHOULD define the Node which detected the
            supportive data or from which it was extracted if this
            information is not represented elsewhere.

         Description
            Zero or one. Free-form text to make comments on significant events or annotate
      actions performed by the supportive data. involved parties.

   The History class has one attribute:

   restriction
      Optional.  ENUM.  This attribute is represented defined in the XML DTD as follows:

         <!ELEMENT RecordDesc                 (
            DetectTime?, Analyzer?, description?
         )>


      4.10.4 The Analyzer Class



Meijer, et al.            Expires March 2003                   [page 73]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




         The Analyzer Section 3.2.


3.13.1 HistoryItem class identifies the facility used to gather the
         evidence or tool generated Incident Alert. In case when Initial
         Incident registration is produced from the IDMEF message the
         Analyzer description may be taken from the IDMEF message where
         the Analyzer Class is mandatory and only one.

   The analyzer SHOULD define the name of the format, facility,
         tool, or device used to generate the evidence if it HistoryItem class is not
         self-describing (e.g. xml). Likewise, the analyzer SHOULD
         define the Node which detected a particular entry in the evidence History (Section
   3.13) log that documents a particular significant action or from which it
         was extracted if this information is not represented elsewhere.

         For event
   that occurred in the purpose course of compatibility the Analyzer Class is reused
         from handling the IDMEF.

         The Analyzer class is composed current incident.  This
   details of two aggregate classes, as
         shown the entry in Figure 4.38.


         +---------------------+
         |      Analyzer       |
         +---------------------+       0..1 +---------+
         | STRING analyzerid   |<>----------|  Node   |
         | STRING manufacturer |            +---------+
         | STRING model this log are a free-form description, but
   each can also be categorized.



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


   +------------------+
   |       0..1 +---------+ HistoryItem      | STRING version      |<>----------| Process
   +------------------+
   | ENUM restriction |<>--{0..1}--[ IncidentID  ]
   | STRING class ENUM type        |            +---------+
   | STRING ostype                  |<>----------[ DateTime    ]
   |                  | STRING osversion
   |
         +---------------------+                  |<>--{1..*}--[ Description ]
   +------------------+

                      Figure 4.38  The Analyzer Class 22: HistoryItem class

   The aggregate classes that make up Analyzer constitute HistoryItem are:

         Node

   IncidentID
      Zero or one.  Information about One.  In history logs created by multiple parties, the host or device on
      IncidentID provides a way specify which CSIRT created the analyzer resides (network address, network name, etc.).

         Process
            Zero
      particular entry and reference this organizations local incident
      tracking number for this activity.  When a single organization is
      maintaining the history log, this class can be ignored.

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

   Description
      One or one.  Information about many.  STRING.  A free-form textual description of the process
      action or event to be document in the history log.

   The HistoryItem class has two attributes:

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

   type
      Optional.  ENUM.  Classifies the type of activity or event being
      document in this history log entry.  The particular details of the
      entry are a free-form description documented in which the
            analyzer is executing.

         This Description
      class.  Possible values are an enumerated list whose default value
      is represented "other":

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

      2.  notification.  Notification to an involved party in the XML DTD as follows:

         <!ELEMENT Analyzer                        (
            Node?, Process?
         )>
          incident was sent (e.g., a CSIRT sending a message to the
          attacking site).




Meijer, et al.         Expires September 29, 2003              [Page 39]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 74]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         <!ATTLIST Analyzer
            analyzerid            CDATA                   '0'
            manufacturer        CDATA                   #IMPLIED
            model               CDATA                   #IMPLIED
            version             CDATA                   #IMPLIED
            class               CDATA                   #IMPLIED
            ostype              CDATA                   #IMPLIED
            osversion           CDATA                   #IMPLIED
         >


      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 Analyzer class incident has seven attributes:

         analyzerid
            Optional. The attribute been resolved; a short
          description may be taken from the IDMEF message
            generated by Analyzer/IDS. For details see [IDMEF].

         manufacturer
            Optional. included.

      6.  other.


3.14 EventData class

   The manufacturer of EventData class describes the analyzer software and/or
            hardware.

         model
            Optional.  The model name/number events of the analyzer software
            and/or hardware.

         version
            Optional.  The version number incident surrounding
   a particular set of hosts or networks.  This description includes the analyzer software
            and/or hardware.

         class
            Optional.  The class
   systems from which the activity originated and those targeted, an
   assessment of analyzer software and/or hardware.

         ostype
            Optional.  Operating system name.  On POSIX systems, this is the value returned in utsname.sysname techniques used by the uname() system
            call, or intruder, the output impact of the "uname -s" command.

         osversion
            Optional.  Operating system version.  On POSIX systems, this
            is the value returned in utsname.release by the uname()
            system call, or
   activity on the output organization, a list of the "uname -r" command.

         The "manufacturer", "model", "version", incident handling tasks
   performed, and "class" attributes'
         contents are vendor-specific, but may be used together to
         identify different types of analyzers.


      4.10.5 The RecordItem Class

         The RecordItem class is a container for the arbitrary and any forensic evidence discovered.































Meijer, et al.         Expires March 2003                   [page 75]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         supportive data.

         This is represented in the XML DTD as follows:

         <!ENTITY % attvals.dtype   "
            ( boolean September 29, 2003              [Page 40]

Internet-Draft    IODEF Data Model and Implementation         March 2003


   +------------------+
   | byte EventData        | character
   +------------------+
   | string ENUM restriction |<>--{0..*}--[ Description    ]
   | binary                  | xml
   |
              file                  |<>--{0..1}--[ Assessment     ]
   | path                  | url )
         ">
         <!ELEMENT RecordItem   ANY >
         <!ATTLIST RecordItem
            dtype   %attvals.dtype;   'string'
         >
   |                  |<>--{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 RecordItem EventData class has one attribute:

         dtype
            Required.  The type of data included in the element content.
            The permitted values for this attribute are shown below.

   The default value is "string".

         Rank   Keyword aggregate classes that constitute EventData are:

   Description
         ----   -------   -----------
           0    boolean   The element contains a boolean value, i.e.,
                          the strings "true"
      Zero or "false"
           1    byte      The element content is a single 8-bit byte
                          (see Section 3.4.4)
           2    character The element content is a single character
                          (see Section 3.4.3)
           3    integer   The element content is an integer (see
                          Section 3.4.1)
           4    string    The element content is a string (see Section
                          3.4.3)
           5    binary    The element content is base-64 encoded
                          binary data.
           6    xml       The element content is XML-tagged data
                          (see Section 5.2)
           7    file      The element contains a name more.  STRING.  A free-form textual description of file that
                          may be stored on any media, this
                          information should be necessary for CSIRT
           8    path      The element content is a path to a file
                          location on IHS system
           9    url       The element content is a URL to the data



   4.11 The AdditionalData Class
      event.

   System
      Zero or more.  The AdditionalData class is used to provide information that
      cannot be represented systems (nodes, networks) involved in the event
      as either sources, targets or intermediaries.

   Method
      Zero or more.  The methods by which the event was staged.
      Information about tools used and vulnerabilities exploited.

   Record
      Zero or one.  Support data model.  AdditionalData can be (e.g., log files) that provides
      information on the events.




Meijer, et al.         Expires September 29, 2003              [Page 41]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 76]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      used to provide atomic data (integers, strings, etc.)


   StartTime
      Zero or one.  The time the event started.

   EndTime
      Zero or one.  The time the event ended.

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

   Contact
      Zero or more.  The different parties involved in cases
      where only small amounts the incident

   Assessment
      Zero or one.  Indicates the impact of additional information needed to be
      represented.  However, the class incident on the target
      and the actions taken.

   AdditionalData
      Zero or one.  Anything that can also not be used to extend put in one of the other
      elements

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

   The EventData class has one attribute:

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


3.15 Relating the IncidentData and EventData classes

   At first glance, the DTD to support proprietary IODEF extensions or
      for encapsulating external XML document such as IDMEF messages.
      Detailed instructions for extending duplication in the data model aggregate classes of
   IncidentData and EventData are obvious.  However, the DTD semantics of
   these classes are
      provided in Section 5.

      The AdditionalData element is declared in quite different.  IncidentData provides summary
   information about the XML DTD as follows:

      <!ENTITY % attvals.adtype   "
         ( boolean | byte | character | date-time | integer |
           ntpstamp | portlist | real | string | xml )
      ">
      <!ELEMENT AdditionalData   ANY >
      <!ATTLIST AdditionalData
         type    %attvals.adtype;   'string'
         local   CDATA              #IMPLIED
      >

      The AdditionalData entire incident, while EventData provides
   information about a subset of the incident.

   For example, note that the Assessment class is aggregated in both
   classes. Consider a case where IncidentData:Assessment:MonetaryImpact
   has two attributes:

      type
         Required.  The type been assigned a value of data included x.  Now, consider a value of y (where y
   < x) being assigned to a given MonetaryImpact class that is
   aggregated in the element content. EventData class.  The permitted semantics of these two values for this attribute are shown below.  The
         default value
   is "string".

         Rank   Keyword     Description
         ----   -------     -----------
           0    boolean     The element contains a boolean value, i.e., some monetary loss.  In the strings "true" or "false"
           1    byte        The element content case of the figure in the IncidentData
   class, this loss is a single 8-bit byte
                            (see Section 3.4.4)
           2    character incident-wide.  The element content figure in EventData is a single character
                            (see Section 3.4.3)
           3    date-time   The element content is
   subset of this overall loss, and allows one to associate a date-time string
                            (see Section 3.4.6)
           4    integer     The element content is an integer (see
                            Section 3.4.1)
           5    ntpstamp    The element content is an NTP timestamp
                            (see Section 3.4.7)
           6    portlist    The element content is particular
   loss with a list given subset of ports
                            (see Section 3.4.8)
           7    real        The element content is a real number
                            (see Section 3.4.2)
           8    string      The element content is events that constitute the incident.  It
   effectively provides a string (see
                            Section 3.4.3)
           9    xml         The element content is XML-tagged data
                            (see Section 5.2) breakdown (or more specific description) of



Meijer, et al.         Expires September 29, 2003              [Page 42]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 77]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




      local
         Optional.  A string describing


   the meaning overall loss previously specified in the IncidentData class.

3.16 Cardinality of EventData

   The recursive definition of this class (the EventData class is
   aggregated into the element
         content if used by CSIRT for EventData class) provides a purpose not described in this
         document. These values will be vendor/implementation dependent.
         The method for ensuring that managers understand way to related
   information without requiring the string is
         outside explicit use of unique attribute
   identifiers in the scope of this specification.



   4.12 classes. The History Class depth of an element in the XML tree
   is used to related information.

   The History EventData class contains can be thought of as a log container describing the
   properties of an event in an incident.  These properties include: the significant events that
      occurred or actions performed by
   hosts involved, impact of the involved parties (e.g.,
      initial reporter, investigating CSIRT, or involved system
      administrators) during incident activity on the course hosts,
   forensic logs, etc.  One groups (via an instance of handling the incident.

      The level EventData
   class) hosts (i.e., System class) around these common properties.

   A child EventData class (and all its siblings) logically "inherits"
   the aggregated classes of detail maintained in this log is left up a parent EventData class.  However, the
   presence of sibling EventData classes (it "never" makes sense to have
   only one EventData child in an EventData class) means that there are
   some disjoin properties of the
      discretion event.  These children of those handling the incident.  

      The History class
      +------------------+
      | History          |
      +------------------+
      |                  |   0..* +-------------+
      | ENUM restriction |<>------| HistoryItem |
      +------------------+        +-------------+
 
      Figure 4.15 The History class
 
      The aggregate parent
   EventData class that constitutes History is:
 
      HistoryItem
         Zero or more.   Describes represent these differences, while still retaining a particular event or action related
   way to represent the current incident.
 
      History is represented in common properties (i.e., the XML DTD as follows:
 
      <!ELEMENT History                         (
          HistoryData* )>
 
      <!ATTLIST History
          restriction           %attvals.restriction;   'default'
        >
 
      The History parent-child
   relationship).

   For example, an EventData class has one attribute:
 
      restriction



Meijer, et al.            Expires March 2003                   [page 78]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         Optional.  Sets a restriction on the usage might be used to describe two
   machines involved in an incident.  This description can be achieved
   using multiple instances of the data in System class.  It happens that the
         element

      4.12.1 The HistoryItem class
   technical contact (i.e., Contact class) for these two machines is
   identical, but the impact (i.e., Assessment class) is different.  The HistoryItem class documents
   problem lies in representing two hosts with a particular significant action
         or common contact, but
   different impacts without duplicating any information.  This event that occurred in the course of handling
   can be represent with the current
         incident.  

         +--------------------+ following design represented in Figure 24.


















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


   +------------------+
   | HistoryItem EventData        |
         +--------------------+
   +------------------+
   | STRING IncidentID                  |<>----[ Contact    ]
   |       0..1 +-------------+                  | STRING AuthorityID |<>----------| DateTime
   |                  |<>----[ EventData  ]<>----[ System     ]
   | ENUM restriction                  |            +-------------+      [            ]<>----[ Assessment ]
   |                  | ENUM type
   |       0..1 +-------------+                  |<>----[ EventData  ]<>----[ System     ]
   |                    |<>----------| Description                  |
         +--------------------+            +-------------+      [            ]<>----[ Assessment ]
   +------------------+

              Figure 4.xx  HistoryItem class
 
         The aggregate classes that constitute HistoryItem are:
 
         DateTime
            Zero or one.  A timestamp of when the action or event
            occurred.
 
         Description
            Zero or one.  A description of the action or event.
 
         HistoryDataItem is represented 24: Recursion in the XML DTD as follows:
 
         <!ELEMENT HistoryDataItem       (
             DateTime?, Description?)>
         <!ATTLIST HistoryDataItem
             IncidentID          PCDATA                  #IMPLIED
             AuthorityID         PCDATA                  #REQUIRED
             restriction         %attvals.restriction;   #IMPLIED
             type                %attvals.history;       #IMPLIED
          > EventData class


3.17 System class

   The HistoryDataItem System class has four attributes:
 
         IncidentID
            Optional.  Identifies the incident ID associated with this
            history entry.  

         AuthorityID
            Required.  Identifies the the entity that made this history



Meijer, et al.            Expires March 2003                   [page 79]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



            entry.  

         restriction
            Optional.  Sets a restriction on the usage of the data in
            element.

         type
            Required.  Categorizes the type of event or action taken
            when handling the incident.  

            Rank   Keyword            Description
            ----   -------            -----------
              0    unknown            An uncategorized history entry
              1    triaged            This incident has been received
                                      and processed by a given incident
                                      handling system
              2    acked-reporter     Acknowledgment of incident 
                                      information was sent to a reporter
              3    notification       Based on represents the incident data, 
                                      notification of their involvement
                                      was sent to an entity
              4    request-info       A request for further information
                                      from an involved party was made
              5    got-info           Additional information about this
                                      incident was either received or
                                      produced
              6    remediation        The incident has been resolved; a
                                      short description may be included
              7    shared-info        Information about this incident
                                      was shared with another party


      4.12.2 The DateTime Class technical information for a given
   computer or network involved in the incident.

   The supportive systems represented by this class are categorized according to mark up date and time information.

         It is represented
   the role they played in the XML DTD as follows:

         <!ELEMENT DateTime            (#PCDATA) > incident via through the category
   attribute.  The DATETIME format value of this category attribute dictates the <DateTime> element content is
         described
   semantics of the aggregated classes in Section 3.4.6.


   4.13 The Assessment Class the System class.

   The Assessment meaning of the Node, User, Process, and Service class is used to provide depend on
   the CSIRT's assessment value of
      an event - its impact, actions taken in response, and confidence.
      For the purpose category attribute of compatibility the Assessment Class System class.  If the
   System class category attribute is reused 'source', then the described
   aggregated classes denote the machine, user, process, or service from
   which the activity is originating.  With a category attribute value
   of 'target' or 'intermediary', then the described machine, user,
   process, or service is the one targeted in the activity.



















Meijer, et al.         Expires September 29, 2003              [Page 44]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 80]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      from the IDMEF.

      The Assessment class is composed of three aggregate classes, as
      shown in Figure 4.13.


   +------------------+
   |   Assessment System           |
   +------------------+       0..1 +------------+
   | ENUM restriction |<>----------|   Impact   |
      |                  |            +------------+ |<>----------[ Node     ]
   | ENUM category    |       0..* +------------+
   |                  |<>----------|   Action STRING interface |<>--{0..*}--[ User     ]
   | ENUM spoofed     |
   |            +------------+                  |<>--{0..*}--[ Process  ]
   |                  |       0..1 +------------+
   |                  |<>----------| Confidence                  |<>--{0..*}--[ Service  ]
   |                  |
   |            +------------+                  |<>--{0..1}--[ FileList ]
   +------------------+

                      Figure 4.13 - The Assessment Class 25: the System class

   The aggregate classes that make up Assessment constitute System are:

      Impact

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

   User
      Zero or one. more. The CSIRT's assessment of application or operating system user running on
      the impact specified host that was involved in the incident.

   Process
      Zero or more.  The process targeted or the source of the event attack on
      the target(s).

      Action specified host,

   Service
      Zero or more. one.  The action(s) taken by network service targeted on the CSIRT host specified
      in response to
        the event.

      Confidence
         A measurement of Node.

   FileList
      Zero or one.  Information about the confidence files on the CSIRT has host involved in its evaluation
         of
      the event. incident.

   The System class has four attribute:

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

   category
      Required.  ENUM.  Classifies the XML DTD as follows:

      <!ELEMENT Assessment                     (
         Impact?, Action*, Confidence?
      )>
      <!ATTLIST Assessment
         restriction           %attvals.restriction;   'default'
         %attlist.global;
      >


      4.13.1 role the System played in the
      incident activity.  The Impact Class possible values are:

      1.  source.  The Impact class is used to provide the CSIRT's assessment of System was the impact source of the event on the target(s).  It is represented in attack




Meijer, et al.         Expires September 29, 2003              [Page 45]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 81]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         the XML DTD as follows:

         <!ENTITY % attvals.severity             "
            ( low | medium | high )
         ">
         <!ENTITY % attvals.completion           "
            ( failed | succeeded )
         ">
         <!ENTITY % attvals.impacttype           "
            ( admin | dos | file | recon | user | other )
         ">
         <!ELEMENT Impact     (#PCDATA | EMPTY)* >
         <!ATTLIST Impact
            severity            %attvals.severity;      #IMPLIED
            completion          %attvals.completion;    #IMPLIED
            type                %attvals.impacttype;    'other'
            %attlist.global;
         >


      2.  target.  The Impact class has three attributes:

         severity
            An estimate of System was the relative severity target of the event. attack

      3.  intermediate.  The
            permitted values are shown below.  There is no default
            value.

            Rank   Keyword   Description
            ----   -------   -----------
              0    low       Low severity
              1    medium    Medium severity
              2    high      High severity

         completion
            An indication of whether System was an intermediate machine used in
          the CSIRT believes attack.

   interface
      Optional.  STRING.  Specifies the attempt that interface on which the event describes was successful or not.  The permitted
            values are shown below.  There is no default value.

            Rank   Keyword     Description
            ----   -------     -----------
              0    failed      The attempt was not successful
              1    succeeded   The attempt succeeded

         type
            The type of attempt represented by event(s)
      on this System originated.

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

            Rank   Keyword   Description
            ----   -------   -----------
      "unknown".

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

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

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


3.18 Node class

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

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

















Meijer, et al.         Expires September 29, 2003              [Page 46]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 82]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



              0    admin     Administrative privileges were
                             attempted


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

                       Figure 26: The Node class

   The aggregate classes that constitute Node are:

   Location
      Zero or obtained
              1    dos       A denial one.  STRING. The physical location of service was attempted or
                             completed
              2    file      An action on a file was attempted the equipment.

   name
      Zero or
                             completed
              3    recon     A reconnaissance probe was attempted one.  STRING. The name of the equipment (e.g., fully
      qualified domain name).  This information MUST be provided if no
      Address information is given.

   Address
      Zero or completed
              4    user      User privileges were attempted more.  The network or
                             obtained
              5    other     Anything not in hardware address of the equipment.
      Unless a name is provided, at least one of the above
                             categories

         All three attributes are optional.  The element itself may address must be
         empty, specified.

   DateTime
      Zero or may contain a textual description one.  A timestamp of when the impact, if resolution between the CSIRT is able to provide additional details.


      4.13.2 The Action Class name
      and address was performed.  This information SHOULD be provided if
      both an Address and name are given.

   NodeRole
      Zero or more.  The Action class is used to describe any actions taken by the
         CSIRT owning current Incident Object in course intended purpose of its handling
         or investigating.  It is represented in the XML DTD as follows:

         <!ENTITY % attvals.actioncat             "
            ( block-installed | notification-sent | taken-offline |
              other )
         ">
         <!ELEMENT Action     (#PCDATA | EMPTY)* >
         <!ATTLIST Action
            category             %attvals.actioncat;     'other'
            %attlist.global;
         >

         Action equipment.

   The Node class has one attribute:

   category
      Optional.  ENUM.  The type of action taken by CSIRT or automatic
            Intrusion detection tools. 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 "other."

            Rank   Keyword            Description
            ----   -------            -----------
              0    block-installed    A block of some sort was installed
                                      to prevent an attack from reaching
                                      its destination.
      "unknown".

      1.   unknown.  Domain unknown or not relevant




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


      2.   ads.  Windows 2000 Advanced Directory Services

      3.   afs.  Andrew File System (Transarc)

      4.   coda.  Coda Distributed File System

      5.   dfs.  Distributed File System (IBM)

      6.   dns.  Domain Name System

      7.   hosts.  Local hosts file

      8.   kerberos.  Kerberos realm

      9.   nds.  Novell Directory Services

      10.  nis.  Network Information Services (Sun)

      11.  nisplus.  Network Information Services Plus (Sun)

      12.  nt.  Windows NT domain

      13.  wfw.  Windows for Workgroups


3.18.1 Address

   The block could
                                      be Address class represents a port block, address block,
                                      etc., or disabling network, hardware, and application
   address.  This class is reused outright from the IDMEF specification,
   see Section 4.2.7.1.1 of [7].

3.18.2 NodeRole class

   The NodeRole class describes (based on a user account.
              1    notification-sent  A notification message of some pre-defined list) the
   function performed by a particular host.
















Meijer, et al.         Expires September 29, 2003              [Page 48]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 83]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



                                      sort was sent out-of-band (via
                                      pager, e-mail, etc.).  Does not
                                      include the transmission of this
                                      alert.
              2    taken-offline      A system, computer, or user was
                                      taken offline, as when the
                                      computer is shut down or a user
                                      is logged off.
              3    other              Anything not in one of the above
                                      categories.


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

                     Figure 27: The NodeRole class

   The element itself may be empty, or may contain a textual
         description of the action, if the description of the taken
         actions needs to content should be expressed empty in free language.


      4.13.3 The Confidence Class

         The Confidence class is used to represent the CSIRT's best
         estimate of all cases other than when the validity of its Incident Assessment.  It
   category attribute is
         represented in the XML DTD as follows:

         <!ENTITY % attvals.rating                "
            ( low | medium | high | numeric )
         ">
         <!ELEMENT Confidence (#PCDATA | EMPTY)* >
         <!ATTLIST Confidence
            rating               %attvals.rating;        'numeric'
            %attlist.global;
         > set to "other".

   The Confidence NodeRole class has one attribute:

         rating
            The CSIRT's rating of its assessment validity.  The
            permitted values are shown below.  The default attributes:

   category
      Required.  Functionality provided by a node.  If a value of
      "other" is
            "numeric."

            Rank   Keyword            Description
            ----   -------            -----------
              0    low                The CSIRT/triage has little
                                      confidence in its validity
              1    medium             The CSIRT/triage has average
                                      confidence in its validity
              2    high               The CSIRT/triage has high
                                      confidence specified, a description SHOULD be provided in its validity
              3    numeric the
      element's content.  The CSIRT/triage has provided
                                      a posterior probability default value
                                      indicating its confidence in is "other".

      1.   client.  Client computer

      2.   server-internal.  Server with internal services

      3.   server-public.  Server with public services

      4.   www.  WWW server

      5.   mail.  Mail server

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

      7.   streaming.  Streaming-media server

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

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

      10.  ftp.  FTP server

      11.  p2p.  Peer-to-peer node

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

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

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



Meijer, et al.         Expires September 29, 2003              [Page 49]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 84]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



                                      its validity


      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 element should be used only when class is reused outright from
   the CSIRT/triage can
         produce meaningful information.  Systems that can output only a
         rough heuristic should use "low", "medium", IDMEF specification, see Section 4.2.7.5 of [7].

3.20 User

   The User class describes an application or "high" as the
         rating value.  In this case, operating system user
   account involved in an incident.  This class is reused outright from
   the element content should be
         omitted.

         Systems capable IDMEF specification, see Section 4.2.7.2 of producing reasonable probability estimates
         should use "numeric" as the rating value and include [7].

3.21 Process

   The Process class describes a numeric
         confidence value in the element content. This numeric value
         should reflect running program on a posterior probability (the probability that an
         attack has occurred given host
   involved in an incident.  This class is reused outright from the data seen by the detection system
         and the model used by the system). It
   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 floating point
         number between 0.0 and 1.0, inclusive. record of
   the incident activity.  The number source of digits
         should this data will typically be limited to those representable the
   output of monitoring tools (e.g., IDMEF messages generated by an IDS,
   connection logs from a single precision
         floating point value, and may be represented as described in
         Section 3.4.2.

         NOTE:

         It should be noted that different types of Incident handling
         Systems may compute confidence values in different ways and web server) that in many cases, confidence values from different CSIRTs
         should not be compared (for example, if were used to uncover the CSIRTs use
         different methods of computing or representing confidence, or
         are of different types or configurations).  Care
   malicious activity.  These logs should be
         taken when implementing systems that process confidence values
         (such provide evidence as event correlators) not to make comparisons or
         assumptions why a
   reporter to CSIRT believes an incident has occurred.






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


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

                        Figure 28: Record class

   The aggregate class that cannot be supported constitutes Record is:

   RecordData
      One or more.  Log or audit data generated by the system's knowledge a particular type of the environment in which it is working.


   4.14
      sensor.

   The Authority Class Record class has one attributes:

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


3.23.1 RecordData class

   The Authority RecordData class names groups log or audit data from a given sensor
   (e.g., IDS, firewall log) and provides contact information for the
      CSIRT who created and is handling a way to annotate the incident. output.


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

                    Figure 4.14 29: The Authority Class RecordData class

   The aggregate classes that constitutes RecordData is:

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

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



Meijer, et al.         Expires September 29, 2003              [Page 51]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 85]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




      The aggregate classes that constitute Authority are:

      Organization
         Exactly one.  Name or organization handling


      convey the current
         incident.

      Contact significance of the provided RecordItem data.

   Analyzer
      Zero or one.  Contact information for the Organization handling  Information about the incident.


      Authority is represented in sensor used to generate the XML DTD as follows:

      <!ELEMENT Authority   (
         Organization, Contact? )>
      <!ATTLIST Authority
         ident         ID                      #IMPLIED
         restriction   %attvals.restriction;   'default'
      >
      RecordItem data.

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

   The Authority RecordData class has two one attributes:

      ident

   restriction
      Optional. A unique identifier for the Authority element (see  ENUM.  This attribute has been defined in Section 3.4.9).



      4.14.1 3.2.


3.23.1.1 Analyzer class

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

3.23.1.2 RecordItem class

   The RecordItem class provides a mandatory subordinate element way to incorporate relevant logs,
   audit trails, or forensic data to support the conclusions made during
   the course of analyzing the
         mandatory Authority 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.


         +--------------+
         |   Authority  |
         +--------------+
                /_\
                 |
         +--------------+
         | Organization |
         +--------------+       0..1 +----------------+
         | STRING ident |<>----------| OrganizationID |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| OrgName        |
         |              |            +----------------+  This class is very similar to the
   AdditionalData class (Section 3.6) in that it is essentially an
   extension class that can support proprietary representations of
   security event data, not all of which is necessarily in XML.















Meijer, et al.         Expires September 29, 2003              [Page 52]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 86]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         |              |       0..1 +----------------+
         |              |<>----------| PostalAddress  |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| Email          |
         |              |            +----------------+
         |              |       0..1 +----------------+
         |              |<>----------| Telephone      |


   +------------------+
   | RecordItem       |            +----------------+
   +------------------+
   | ANY              |       0..1 +----------------+
   |              |<>----------| Fax                  |
   | ENUM type        |            +----------------+
         +--------------+
   +------------------+

                    Figure 4.28  Organization Class 30: The aggregate classes that constitute the Organization RecordItem class
         are:

         OrganizationID
            Zero or one.

   The identification number of the Organization. Recorditem class has one attribute:

   type
      Required.  The ID can be derived from known registries such as RIPE
            NCC, TI, etc.

         OrgName
            Zero or one.  Name type of the organization as it used data included in
            official post address.

         PostalAddress
            Zero or one.  Postal Address of the organization.

         Email
            Zero or one.  Email address of the organization.

         Telephone
            Zero or one.  Telephone number of 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 organization.

         Fax
            Zero
           strings "true" or one.  Fax "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 of the organization.

         At (see xref
           target="dt_real_numbers" />);

      9.   string.  The element content is a minimum, the Organization class MUST have either string (see Section 2.2.3);

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

      11.  path.  The element content is a an
         OrgName or OrganizationID.

         Organization filesystem path;

      12.  url.  The element content is represented in the XML DTD as follows:

         <!ELEMENT Organization                           (
            (OrganizationID? | OrgName?), PostalAddress?,
            Email?, Telephone?, Fax? )> a URL (see Section 2.2.13;)



Meijer, et al.         Expires September 29, 2003              [Page 53]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 87]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



         <!ATTLIST Organization
            ident                 ID                      #IMPLIED
         >


      13.  xml.  The Organization class has one attributes:

         ident
            Optional. A unique identifier for the Organization element content is XML-tagged data (see Section 3.4.9).




5. 4).


















































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


4. Extending the IODEF

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


   5.1 specification or
   published separately.

4.1 Extending the Data Model data model

   There are two mechanisms for extending the IODEF data model:
   inheritance and aggregation (see Section 3.1.1).

      + 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 5.2) 4.2) which set limits on where
   extensions to the data model may be made.


   5.2

4.2 Extending the XML DTD

   There are two ways to extend the IODEF XML DTD:

   1.  The AdditionalData class (see Section 4.2.4.5) allows 3.6) and RecordItem (see Section
       3.23.1.2) classes allow implementers to include arbitrary
       "atomic" data items
         (integers, strings, etc.) in an Incident or IncidentAlert
         class. data. (e.g., integers, strings).  This approach SHOULD
       be used whenever possible.



Meijer, et al.            Expires March 2003                   [page 88]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002

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

      To extend

   The following guidelines MUST be followed when extending the IODEF
   DTD with a new another DTD "module," these guidelines
      MUST be followed: in the extension classes:


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

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



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


       that entity:

    <!DOCTYPE IODEF-Description IODEF-Document SYSTEM
            "/path/to/IODEF-Description.dtd" "/path/to/IODEF-Document.dtd"
             [ <!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">
            %x-extension;
                        % 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-Description IODEF-Document SYSTEM
            "/path/to/IODEF-Description.dtd" "/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:



Meijer, et al.            Expires March 2003                   [page 89]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002

   <!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 whose "type" attribute is "xml".  For example:

        <IODEF-Description








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


   <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-Description>



6.  Special
   </IODEF-Document>





































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


5. Processing Considerations

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


   6.1

5.1 XML Validity and Well-Formedness

      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 of the IODEF
      document rsee Section 3.3.1). Such

   The IODEF documents will MUST be



Meijer, et al.            Expires March 2003                   [page 90]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      well-formed well-formed, and valid as defined in [5].

      Other IODEF when  possible and
   practical the documents will SHOULD also be specified valid.

   It is expected that do IODEF-compliant applications will normally not
   include the
      document prolog (e.g., entries in an IODEF-format database). Such IODEF documents DTD in their communications.  Instead, the DTD will
   be well-formed but not valid.

      Generally, well-formedness implies that a document has a single
      element that contains everything else (e.g., "<Book>"), and that
      all the other elements nest nicely within each other without any
      overlapping (e.g., a "chapter" does not start referenced in the middle document type declaration section of
      another "chapter").

      Validity further implies that not only is the IODEF
   document
      well-formed, but it also follows specific rules (contained in the
      Document Type Definition) about which elements are "legal" (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
      document, how those elements nest within other elements, DTD may
   need to be downloaded and so parsed before use by the XML parser.

   Implementers MAY decide to have entities who regularly exchange IODEF
   message agree out-of-band on
      (e.g., a "chapter" does not begin in the middle of a "title").  A particular document cannot type definition
   they will be valid unless it references a DTD.

      XML processors are required using to parse any well-formed document,
      valid exchange messages (the standard one as defined
   here, or not. one with extensions), and then omit it from IODEF documents.
   The purpose of validation method for negotiating this agreement is to make outside the processing scope of the document (what's done with the data after it's parsed)
      easier.  Without validation, a document may contain elements in
      nonsense order, elements "invented" by the author that the
      processing application doesn't understand, and so on.

     IODEF documents MUST be well-formed.  IODEF documents SHOULD
   this document.

   NOTE: Care must be
     valid whenever both possible and practical.


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

5.2 Unrecognized Data and XML Tags

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

   o  Unrecognized tags may be either:

      +  Recognized as "legitimate" (a valid document), but the
         application does not know used in one of the semantic meaning extension classes (i.e.,
      AdditionalData or RecordItem);

   o  Unrecognized tags outside of the element's
         content; extension classes; or

      +  Not recognized at all.

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



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


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

      Special issue is related to inheritance relation between tag.















































Meijer, et al.         Expires September 29, 2003              [Page 59]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 91]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



      Incident/Attacker related classes IDMEF


6. Internationalization issues

   Internationalization and IODEF, e.g. IODEF
      message may be simply wrap up into IDMEF container for the
      IncidentAlert class.

      In particular case localization is of relations between IODEF and IDMEF, specific concern to the IODEF
      may
   IODEF.  It is only through collaboration, often across language
   barriers, that certain incidents be treated as IDMEF extension applying inheritance resolved.

   XML already supports different character encodings.  This flexibility
   will allow information encoded in the IODEF to
      incorporate Alert/IDMEF data structure into Attack Class be in most written
   languages. Furthermore, XML also provides the xml:lang attribute
   through which the type of IODEF.

      When Incident description is produced language being used in a given element can
   be specified.  By including this attribute in the %attlist.global
   entity found in all elements, users of IDMEF message, the IODEF may can use directly related different
   languages in the same document.

   The data classes from IDMEF. In this context it
      is recommended model ensures that IHS understands both format - IODEF and IDMEF.
      This may be achieved by mapping part the cardinality of IDMEF classes (XML tags)
      related the Description class
   is always one-to-many with its parent.  One of the intents for this
   design was to Attack allow the same description into IODEF classes. This is to be
      not difficult task because repeated in another
   instance of initial approach to match IODEF and
      IDMEF XML namespaces. Otherwise IODEF parser will still be able to
      parser well- formed IDMEF document and recognize important XML
      tags, which meaning the Description class, but in a different language.
   Parsers of the IODEF is inherited from IDMEF.


   6.3 Digital Signatures

      The joint IETF/W3C XML Signature Working Group is currently
      working document, could extract only the elements with
   the relevant language.

   Supporting different languages allows CSIRTs to specify XML digital signature processing rules and
      syntax [16].  XML Signatures provide integrity, message
      authentication, and/or signer authentication services for localize the IODEF.
   However, it does not aid data interchange if the recipient of
      any type, whether located within a
   document does not understand the XML underlying language.  In order to
   ensure that includes the
      signature or elsewhere.

      The IODEF requirements [2] recommend that recipient can at least crudely approximate the
   contents of the document, the data model relies on enumerated
   attributes that are standardized to convey meaning (e.g.,
   %attlist.purpose).























Meijer, et al.         Expires September 29, 2003              [Page 60]

Internet-Draft    IODEF should support
      content confidentiality, integrity, authentication Data Model and non-
      repudiation. Implementation         March 2003


7. Examples

   These requirements examples provide an idea of what IODEF-Documents can look like.
   It must be achieved by the inclusion
      of digital signatures within an stressed that as IODEF document. Additional
      security considerations may be applied to the communications
      methods is a data-exchange-format, it does
   not specify detailed rules on which elements and protocols used for IODEF documents exchange.

      Specifications for the attributes to use
   under all imaginable circumstances.

7.1 Code Red detection notification

   The following message is a typical example of digital signatures within IODEF
      documents are outside the scope of this document.  If such
      functionality an incident where one
   host is infected with a worm.  The initial report is needed, sent in by
   email, the use of subsequently shown IODEF-Document illustrates the
   communication between the XML Signature standard is
      RECOMMENDED.



7. Experimental implementation responsible CSIRT and examples

   There its constituent.  The
   constituent is an ongoing effort among a few European CSIRTs contact for the CSIRT and responsible for
   coordinating the required actions at his site.


   From e-citizen@hisdomain.de
   Date: 13 Sep 2001 23:19:24 -0000
   From: e-citizen@hisdomain.de
   To: cert-for-ourdomain.pl@ourdomain.pl
   Subject: 10.1.1.2 - Code Red Virus detected

   Automated message,
   you don't have to reply to implement
   IODEF in their daily incident handling work [17]. The results this
   project should email.

   Your system with the IP number 10.1.1.2 seems to be available in late 2001.

   This section provides examples of infected
   with the Code Red virus.

   For more information see http://www.incidents.org/react/code_redII.php

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

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

       Figure 35: Code Red detection notification: initial report



   <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 September 29, 2003              [Page 61]

Internet-Draft    IODEF encoded Incident data.  The Data Model and Implementation         March 2003


         <IncidentData>
            <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>
            <Contact role="creator" role="irt" type="organization">
               <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>
            <EventData>
               <System category="source">
                  <Node>
                     <Address category="ipv4-addr">10.1.1.2</Address>
                  </Node>
               </System>
               <System category="target">
                  <Service>
                     <port>80</port>
                  </Service>
               </System>
               <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>



Meijer, et al.         Expires September 29, 2003              [Page 62]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 92]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   examples are provided for illustrative purposes only


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


       Figure 36: Code Red detection notification: CSIRT response


7.2 IODEF-Document with XML signature

7.3 IODEF-Document encrypted using XML encryption

7.4 IODEF-Document encrypted and do not
   necessarily represent the only (or even the "best") way to encode
   these particular incidents. signed using XML signature & encryption



































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


8. The IODEF Document Type Definition

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

   <!--
   ********************************************************************
   ********************************************************************
   *** Incident Object Description and Exchange Format XML DTD      ***
   ***               Version 00, October 2002                       ***
   ***                                                              ***
   ********************************************************************
   ********************************************************************
   -->
   <!--
   ====================================================================
   === SECTION 1. Imported Names                                    ===
   ====================================================================
   -->
   <!--
    | Media type, as per [RFC2045]
    -->
   <!ENTITY % ContentType "CDATA">
   <!--
    | comma-separated list of media types, as per [RFC2045]
    -->
   <!ENTITY % ContentTypes "CDATA">
   <!--
    | Character encoding, as per [RFC2045]
     -->
   <!ENTITY % Charset "CDATA">
   <!--
    | A space separated list of character encodings, as per [RFC2045]
    -->
   <!ENTITY % Charsets "CDATA">
   <!--
    | Language code, as per [RFC1766]
    -->
   <!ENTITY % LanguageCode "NMTOKEN">
   <!--
    | A single character from [ISO10646]
    -->
   <!ENTITY % Character "CDATA"> Definition


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



Meijer, et al.            Expires
    ********************************************************************
    ********************************************************************
    *** IncidentData Exchange Format XML DTD                         ***
    ***               Version 01, March 2003                   [page 93]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



    | Date and time information. ISO date format                         ***
    ********************************************************************
    ********************************************************************
    -->
   <!ENTITY % Datetime "CDATA">
   <!--
    ====================================================================
    === SECTION 2. 1. 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.
    -->
   <!ENTITY % attlist.iodef "
         version             CDATA                   #FIXED    '0.05'
   ">
   <!--
    | Attributes of all elements.  These are the "XML" attributes
    | that every element should have.  Space handling, name space, and
    | language.
    -->
   <!ENTITY % attlist.global "
      xmlns:iodef         CDATA                   #FIXED
          'urn:iana:xml:ns:iodef'
       xmlns               CDATA                   #FIXED
           'urn:iana:xml:ns:iodef'
       xml:space           (default | preserve)    'default'
       xml:lang    %LanguageCode;          #IMPLIED    '0.10'
      ">
   <!--
    ====================================================================
    === SECTION 3. 2. Attribute value declarations.  Enumerated values  ===
    ===            for the many element-specific attribute lists.    ===
    ====================================================================
    -->
   <!--
    | Values for the Address.category attribute.
    -->
   <!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 )
    ">
   <!--
    | Values for the AdditionalData.type attribute.
    -->
   <!ENTITY % attvals.adtype "
      ( boolean | byte | character | date-time | integer | ntpstamp |
        portlist | real | string | xml )



Meijer, et al.            Expires March 2003                   [page 94]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



    ">
   <!--
    | Values for the Data.type attribute used in EvidenceItem.
    -->
   <!ENTITY % attvals.dtype "
       ( boolean | byte | character | string | binary | xml |
         file | path | url )
     ">
   <!--
    | Values for Defines purpose of the Id.type attribute. Incident
    -->
   <!ENTITY % attvals.idtype attvals.purpose "
         ( current-user | original-user | target-user handling | user-privs statistics |
        current-group warning | group-privs other )
      ">
   <!--
    | Values for the Impact.completion attribute. Defines restriction on access to an element's content
    -->
   <!ENTITY % attvals.completion attvals.restriction "
         ( failed default | succeeded )
     ">
   <!-- public | Values for the File.category attribute.
    -->
   <!ENTITY % attvals.filecat "
       ( current need-to-know | original private )
      ">
   <!--
    | Values for the Impact.type attribute. Expectation.category attributes
    -->
   <!ENTITY % attvals.impacttype attvals.expectations "
         ( admin | dos nothing | file contact-site | recon contact-me | user block | other )



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


      ">
   <!--
    | Values for the Linkage.category AdditionalData.type attribute.
    -->
   <!ENTITY % attvals.linkcat attvals.adtype "
         ( hard-link boolean | mount-point byte | reparse-point character | shortcut date-time | stream integer |
         symbolic-link
           ntpstamp | portlist | real | string | xml )
       ">
   <!--
    | Values for the Confidence.rating attribute. RecordItem.type attribute
    -->
   <!ENTITY % attvals.rating attvals.dtype "
         ( low boolean | medium byte | high character | numeric date-time | integer |
           ntpstamp | portlist | real | string | file | path | url |
   	xml )
        ">
   <!--
    | Values for the Impact.severity History.type attribute.
    -->



Meijer, et al.            Expires March 2003                   [page 95]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002
   <!ENTITY % attvals.severity attvals.historycat "
          ( low triaged | medium notification | high shared-info | received-info |
            remediation | other )
         ">
   <!--
    | Values for the Node.category Address.category attribute.
    -->
   <!ENTITY % attvals.nodecat attvals.addrcat "
         ( unknown | ads atm | afs e-mail | coda lotus-notes | dfs mac | dns sna | kerberos vm | nds
           ipv4-addr |
        nis ipv4-addr-hex | nisplus ipv4-net | nt ipv4-net-mask | wfw
           ipv6-addr | ipv6-addr-hex | ipv6-net | ipv6-net-mask )
       ">
   <!--
    | Values for the NodeRole.category Id.type attribute.
    -->
   <!ENTITY % attvals.noderolecat attvals.idtype "
         ( unknown | client | server-internal | server-public | www | mail |
       messaging | streaming | voice | file | ftp | p2p | name |
   directory |
       credential current-user | print original-user | application target-user | database user-privs | infra
           current-group | log group-privs )
       ">
   <!--
    | Values for the Classification.origin Impact.completion attribute.
    -->
   <!ENTITY % attvals.origin attvals.completion "
          ( unknown | bugtraqid failed | cve succeeded )
        ">
   <!--
    | vendor-specific Values for the File.category attribute.
    -->
   <!ENTITY % attvals.filecat "



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


          ( current | irt-local original )
        ">
   <!--
    | Values for the IRTcontact.originIRT attribute Impact.type attribute.
    -->
   <!ENTITY % attvals.originIRT attvals.impacttype "
          ( unknown none | ripencc admin | ti dos | arin file | apnic recon | afnic user | local unknown |
            other )
        ">
   <!--
    | Defines purpose of Values for the IODEF Object Linkage.category attribute.
    -->
   <!ENTITY % attvals.purpose attvals.linkcat "
          ( unknown hard-link | report mount-point | handling reparse-point | communication shortcut | statistics
            stream |
        experimental symbolic-link )
        ">
   <!--
    | Defines restriction on access to an element's content Values for the RegistryHandle.type attribute.
    -->
   <!ENTITY % attvals.restriction attvals.registrytype "
      (default
      ( internic | public apnic | internal arin | lacnic | ripe | ti | restricted local )
    ">
   <!--
    | Values for the User.category Confidence.rating attribute.
    -->
   <!ENTITY % attvals.usercat attvals.rating "
          ( unknown low | application medium | os-device high | numeric | unknown )
        ">



Meijer, et al.            Expires March 2003                   [page 96]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002
   <!--
    | Values for yes/no attributes such as Source.spoofed and
    | Target.decoy. the Impact.severity attribute.
    -->
   <!ENTITY % attvals.yesno attvals.severity "
          ( unknown low | yes medium | no high )
        ">
   <!--
   ====================================================================
   ==  Section 4.2 The IODEF-Description class                       ==
   ====================================================================
   -->
   <!ELEMENT IODEF-Description ((Incident | IncidentAlert)*)>
   <!ATTLIST IODEF-Description
           %attlist.iodef;
           %attlist.global;
   >

   <!--
   ====================================================================
   ==  Section 4.3 The Incident class                                ==
   ====================================================================
   -->

   <!ELEMENT Incident (Attack+, Attacker*, Victim*, Method*, Evidence?,
    CorrelationIncident?, Authority, History?, AdditionalData*)>
   <!ATTLIST Incident
           incidentID CDATA #IMPLIED
           restriction %attvals.restriction; #IMPLIED
           purpose %attvals.purpose; #REQUIRED
           %attlist.global;
   >
   
   <!--
   ====================================================================
   ==  Section 4.4 The CorrelationIncident class                     ==
   ====================================================================
   -->
   <!ELEMENT CorrelationIncident (EventList, IncidentID,
   EvidenceDataID)>
   <!ATTLIST CorrelationIncident
           restriction %attvals.restriction; #IMPLIED
           %attlist.global;
   >
   
   <!--
   ====================================================================
   ==  Section 4.4.1 The EventList class                             ==
   ====================================================================



Meijer, et al.            Expires March 2003                   [page 97]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   -->
   <!ELEMENT EventList ((IncidentID?, EvidenceDataID*, datetime?)*)>
   <!ATTLIST EventList
           %attlist.global;
   >

   <!--
   ====================================================================
   ==  Section 4.5 The IncidentAlert class                           ==
   ====================================================================
   -->
   <!ELEMENT IncidentAlert (History?, Authority, AdditionalData+)>
   <!ATTLIST IncidentAlert
           incidentID CDATA #IMPLIED
           %attlist.global;
           restriction %attvals.restriction; #IMPLIED
   >

   <!--
   ====================================================================
   ===  Section 4.6 The Attack class                                ===
   ====================================================================
   -->
   <!ELEMENT Attack (Target*, Source*, Description*, DetectTime?,
   StartTime?, EndTime?)>
   <!ATTLIST Attack
           ident CDATA "0"
           restriction %attvals.restriction; #IMPLIED
           %attlist.global;
   >
   <!--
   ====================================================================
   ===  Section 4.6.1 The Source class                              ===
   ====================================================================
   -->
   <!-- Elements Target and Source of IODEF are re-used from IDMEF-->
   <!ELEMENT Source (Node?, User?, Process?, Service?, program?, os?)>
   <!ATTLIST Source
           ident CDATA "0"
           spoofed %attvals.yesno; "unknown"
           interface CDATA #IMPLIED
           %attlist.global;
   >
   
   <!--
   ====================================================================
   ===  Section 4.6.2 The Node class                                ===
   ====================================================================
   -->



Meijer, et al.            Expires March 2003                   [page 98]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   
   <!ELEMENT Node (((name | Address), Address*), datetime?, name?,
   Address*, Location?, NodeRole*)>
   <!ATTLIST Node
           ident CDATA "0"
           category %attvals.nodecat; "unknown"
           %attlist.global;
   >

   <!--
   ====================================================================
   ===  Section 4.6.2.1 The Address class                           ===
   ====================================================================
   -->
   <!ELEMENT Address (address, netmask?)>
   <!ATTLIST Address
           ident CDATA "0"
           category %attvals.addrcat; "unknown"
           vlan-name CDATA #IMPLIED
           vlan-num CDATA #IMPLIED
           %attlist.global;
   >

   <!--
   ====================================================================
   ===  Section 4.6.2.2 The NodeRole class                          ===
   ====================================================================
    | Values for the Node.category attribute.
    -->
   <!ELEMENT NodeRole EMPTY>
   <!ATTLIST NodeRole
           category %attvals.noderolecat; "unknown"
   >
   <!ENTITY % attvals.nodecat "
         ( unknown | ads | afs | coda | dfs | dns | hosts |
           kerberos | nds | nis | nisplus | nt | wfw )
       ">
   <!--
   ====================================================================
   ===  Section 4.6.3 The User class                                ===
   ====================================================================
    | Values for the NodeRole.category attribute.
    -->
   <!ELEMENT User (UserId+)>
   <!ATTLIST User
           ident CDATA "0"
           category %attvals.usercat; "unknown"
           %attlist.global;
   >
   
   <!--
   ====================================================================
   ===  Section 4.6.3.1 The UserId class                            ===
   ====================================================================
   <!ENTITY % attvals.noderolecat "
        ( client | server-internal | server-public | www | mail |
          messaging | streaming | voice | file | ftp | p2p | name |
          directory | credential | print | application | database |



Meijer, et al.         Expires September 29, 2003              [Page 66]

Internet-Draft    IODEF Data Model and Implementation         March 2003                   [page 99]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


          infra | log | other )
       ">
   <!--
    | Values for the Classification.origin attribute.
    -->
   <!ELEMENT UserId (name
   <!ENTITY % attvals.origin "
         ( bugtraqid | number cve | (name, number))>
   <!ATTLIST UserId
           ident CDATA "0"
           type %attvals.idtype; "original-user"
           %attlist.global;
   > certcc | vendor | local | other)
      ">
   <!--
   ====================================================================
   ===  Section 4.6.4 The Process class                             ===
   ====================================================================
    | Values for the User.category attribute.
    -->
   <!ELEMENT Process (name, pid?, path?, arg*, env*)>
   <!ATTLIST Process
           ident CDATA "0"
           %attlist.global;
   >
   <!ENTITY % attvals.usercat "
         ( unknown | application | os-device )
      ">
   <!--
   ====================================================================
   ===  Section 4.6.5 The Service Class                             ===
   ====================================================================
    | Values for the System.spoofed and System.decoy attributes
    -->
   <!ELEMENT Service (((name
   <!ENTITY % attvals.yesno "
         ( unknown | port yes | no )
      ">
   <!--
    | Values for the System.category attribute
    -->
   <!ENTITY % attvals.systemcat "
   	( source | (name, port)) target | portlist),
   protocol?, SNMPService?, WebService?)>
   <!ATTLIST Service
           ident CDATA "0"
           %attlist.global;
   > intermediate )
   	">
   <!--
    ====================================================================
   ===  Section 4.6.5.1 The WebService Class                        ===
    ==  Element definitions                                           ==
    ====================================================================
    -->
   <!--
    ====================================================================
    == IODEF-Document class                                           ==
    ====================================================================
    -->
   <!ELEMENT WebService (url, cgi?, http-method?, arg*)> IODEF-Document (Incident+)>
   <!ATTLIST WebService
           %attlist.global; IODEF-Document
   	%attlist.iodef;
   	xmlns:iodef CDATA             #FIXED  'urn:iana:xml:ns:iodef'
   >
   <!--
    ====================================================================
   ===  Section 4.6.5.2 The SNMPService Class                       ===
    ==  Incident class                                                ==
    ====================================================================
    -->
   <!ELEMENT SNMPService (oid?, community?, command?)>
   <!ATTLIST SNMPService
           %attlist.global; Incident (IncidentID, AlternativeID?, RelatedActivity?,
                       IncidentData, AdditionalData*)>



Meijer, et al.         Expires September 29, 2003              [Page 67]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 100]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


   <!ATTLIST Incident
   	restriction  %attvals.restriction; "private"
   	purpose      %attvals.purpose;     #REQUIRED
   >
   <!--
    ====================================================================
   ===  Section 4.6.6 The Target
    ==  IncidentID class                              ===                                              ==
    ====================================================================
    -->
   <!ELEMENT Target (Node?, User?, Process?, Service?, program?, os?,
   FileList?)> IncidentID (#PCDATA)>
   <!ATTLIST Target
           ident CDATA "0"
           decoy %attvals.yesno; "unknown"
           interface IncidentID
   	name        CDATA                 #IMPLIED
           %attlist.global;
   	restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
   ===  Section 4.6.7 The FileList
    ==  AlternativeID class                            ===                                           ==
    ====================================================================
    -->
   <!--Elements  FileList with respective subelements of IODEF
     are re-used from IDMEF-->
   <!ELEMENT FileList (File+)> AlternativeID (IncidentID+)>
   <!ATTLIST FileList
           %attlist.global; AlternativeID
   	restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ==  RelatedActivity class                                         ==
    ====================================================================
    -->
   <!ELEMENT RelatedActivity (IncidentID+)>
   <!ATTLIST RelatedActivity
   	restriction %attvals.restriction; #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.6.7.1 The File  AdditionalData class                                        ===
    ====================================================================
    -->
   <!ELEMENT File (name, path, create-time?, modify-time?,
                   access-time?, data-size?, disk-size?, FileAccess*,
                   Linkage*, Inode?)> AdditionalData ANY>
   <!ATTLIST File
           ident CDATA "0"
           category %attvals.filecat; AdditionalData
   	restriction %attvals.restriction; #IMPLIED
   	type     %attvals.adtype; #REQUIRED
           fstype
   	meaning  CDATA #REQUIRED
           %attlist.global;            #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.6.7.2 The FileAccess  IncidentData class                                          ===
    ====================================================================
    -->



Meijer, et al.         Expires September 29, 2003              [Page 68]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 101]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


   <!ELEMENT FileAccess (UserId, permission+)> IncidentData (Description*, Contact+, ReportTime,
                           DetectTime?, StartTime?, EndTime?,
                           Expectation*, Method*, Assessment+,
                           EventData*, History?, AdditionalData*)>
   <!ATTLIST FileAccess
           %attlist.global; IncidentData
   	restriction  %attvals.restriction;  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.6.7.3 The Linkage  Contact class                                               ===
    ===    - RegistryHandle
    ===    - PostalAddress
    ===    - Email
    ===    - Telephone
    ===    - Fax
    ====================================================================
    -->
   <!ELEMENT Linkage ((name, path) | File)> Contact (name?, Description*, RegistryHandle*,
                      PostalAddress?, Email*, Telephone*, Fax?,
   		   Contact*)>
   <!ATTLIST Linkage
           category %attvals.linkcat; Contact
   	role        (creator | admin | tech | irt | cc) #REQUIRED
   	type        (person | organization)             #REQUIRED
           %attlist.global;
   	restriction %attvals.restriction;               #IMPLIED
   >

   <!--
   ====================================================================
   ===  Section 4.6.7.4 The Inode class                             ===
   ====================================================================
   -->
   <!ELEMENT Inode (change-time?, (number, major-device,
                    minor-device)?, (c-major-device, c-minor-device)?)> RegistryHandle (#PCDATA)>
   <!ATTLIST RegistryHandle
   	type  %attvals.registrytype;  "local"
   >
   <!ELEMENT PostalAddress (#PCDATA)>
   <!ATTLIST Inode
           %attlist.global; PostalAddress
   	lang  NMTOKEN  #IMPLIED
   >
   <!ELEMENT Email (#PCDATA)>
   <!ELEMENT Telephone (#PCDATA)>
   <!ELEMENT Fax (#PCDATA)>
   <!--
    ====================================================================
    ===  Section 4.6.8 The Description class  Time-based classes                                          ===
   ====================================================================
   -->
   <!ELEMENT Description ANY>
   <!ATTLIST Description
           %attlist.global;
   >

   <!--
   ====================================================================
    ===  Section 4.6.9 The    - DateTime
    ===    - ReportTime
    ===    - DetectTime class
    ===    - StartTime
    ===    - EndTime
    ====================================================================
    -->
   <!ELEMENT DetectTime DateTime (#PCDATA)>
   <!ATTLIST DetectTime
           ntpstamp CDATA #REQUIRED
           %attlist.global;
   > DateTime



Meijer, et al.         Expires September 29, 2003              [Page 69]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 102]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


   	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
   >
   <!ELEMENT EndTime (#PCDATA)>
   <!ATTLIST EndTime
   	ntpstamp  CDATA  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.6.10 The StartTime  History class                                               ===
    ===    - HistoryItem
    ====================================================================
    -->
   <!ELEMENT StartTime (#PCDATA)> History (HistoryItem+)>
   <!ATTLIST StartTime
           %attlist.global; History
   	restriction  %attvals.restriction;  #IMPLIED
   >
   <!ELEMENT HistoryItem (DateTime, IncidentID?, Description+)>
   <!ATTLIST HistoryItem
   	type         %attvals.historycat;   #IMPLIED
   	restriction  %attvals.restriction;  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.6.11 The EndTime  Expectation class                                           ===
    ====================================================================
    -->
   <!ELEMENT EndTime (#PCDATA)> Expectation (Description+, Contact?, StartTime?, EndTime?)>
   <!ATTLIST EndTime
           %attlist.global; Expectation
   	priority    %attvals.severity;      #IMPLIED
   	restriction %attvals.restriction;   #IMPLIED
   	category    %attvals.expectations;  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.7 The  Method class                                                ===
    ===    - Classification



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


    ====================================================================
    -->
   <!ELEMENT Method (Classification*, Description*)>
   <!ATTLIST Method
           %attlist.global;
           ident CDATA "0"
   	restriction  %attvals.restriction;  #IMPLIED
   >

   <!--
   ====================================================================
   ===  Section 4.7.1 The Classification class                      ===
   ====================================================================
   -->
   <!ELEMENT Classification (name, url)>
   <!ATTLIST Classification
   	restriction  %attvals.restriction;  #IMPLIED
   	origin %attvals.origin; "unknown"
           %attlist.global; "other"
   >
   <!--
    ====================================================================
    ===  Section 4.8 The Attacker  Assessment class                                            ===
    ===    - Impact
    ===    - TimeImpact
    ===    - MonetaryImpact
    ===    - LifeImpact
    ===    - Confidence
    ====================================================================
    -->
   <!ELEMENT Attacker (Contact?, Location?, IRTcontact?)>



Meijer, et al.            Expires March 2003                  [page 103]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 Assessment (Impact*, TimeImpact*, MonetaryImpact*,
                         LifeImpact*, Confidence?)>
   <!ATTLIST Attacker
           %attlist.global;
           ident CDATA "0" Assessment
   	restriction  %attvals.restriction;  #IMPLIED
           spoofed %attvals.yesno; "unknown"
   >

   <!--
   ====================================================================
   ===  Section 4.8.1 The Contact class                             ===
   ====================================================================
   -->
   <!ELEMENT Contact (PersonName?, PostalAddress?, ContactHandle?)> Impact (#PCDATA)>
   <!ATTLIST Contact
           %attlist.global; Impact
   	restriction  %attvals.restriction;  #IMPLIED
   	severity   %attvals.severity;       #IMPLIED
   	completion %attvals.completion;     #IMPLIED
   	type       %attvals.impacttype;     "unknown"
   	lang       NMTOKEN                  #IMPLIED
   >
   
   <!--
   ====================================================================
   ===  Section 4.8.2 The IRTContact class                          ===
   ====================================================================
   -->
   <!ENTITY % attvals.originIRT                 "
   	( unknown | ripencc
   <!ELEMENT TimeImpact (#PCDATA)>
   <!ATTLIST TimeImpact
   	restriction  %attvals.restriction;        #IMPLIED
   	severity  %attvals.severity;              #IMPLIED
   	unit   (labor | ti elapsed | arin downtime)       #REQUIRED
   	metric (days | apnic hours | afnic minutes | local )
   ">
   <!ELEMENT IRTcontact   >
   <!ATTLIST IRTcontact
   	originIRT   %attvals.originIRT;
   	'unknown' seconds) "hours"
   >

   <!--
   ====================================================================
   ===  Section 4.9 The Victim class                                ===
   ====================================================================
   -->
   <!ELEMENT Victim (Contact?, Location?, IRTcontact?)> MonetaryImpact (#PCDATA)>
   <!ATTLIST Victim MonetaryImpact
   	restriction  %attvals.restriction;  #IMPLIED
           %attlist.global;
   	severity %attvals.severity;         #IMPLIED
   	currency   CDATA                    #REQUIRED
   >

   <!--
   ====================================================================
   ===  Section 4.10 The Record class                               ===
   ====================================================================
   -->
   <!ELEMENT Record (RecordData)> LifeImpact (#PCDATA)>



Meijer, et al.         Expires September 29, 2003              [Page 71]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 104]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


   <!ATTLIST Record LifeImpact
   	restriction  %attvals.restriction;  #IMPLIED
           %attlist.global;
   	severity %attvals.severity;         #IMPLIED
   	metric (deaths | injuries)          #REQUIRED

   >
   <!ELEMENT Confidence EMPTY>
   <!ATTLIST Confidence
   	rating  %attvals.rating;    #REQUIRED
   >
   <!--
    ====================================================================
    ===  Section 4.10.1 The RecordData EventData class                                              ===
    ====================================================================
    -->
   <!ELEMENT RecordData (CorrRecord*, RecordDesc?, RecordItem?)> EventData (Description*, Contact*, ReportTime?,
                        DetectTime?, StartTime?, EndTime?, Expectation?,
   		     System*, Method*, Assessment?, EventData*,
   		     History?, Record?, AdditionalData*)>
   <!ATTLIST RecordData
           %attlist.global;
           ident CDATA "0" EventData
   	restriction  %attvals.restriction;  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.10.2 The CorrRecord  System class                                                ===
    ====================================================================
    -->
   <!ELEMENT CorrRecord (CorrRecordID)> System (Node, User*, Process*, Service*, FileList?)>
   <!ATTLIST CorrRecord
           IncidentID System
   	category     %attvals.systemcat;    #IMPLIED
   	spoofed      %attvals.yesno;        "unknown"
   	interface    CDATA                  #IMPLIED
   	restriction  %attvals.restriction;  #IMPLIED
   >
   <!--
    ====================================================================
    ===  Section 4.10.3 The RecordDesc  FileList class                                              ===
    ===    - File
    ===        - access-time
    ===        - change-time
    ===        - create-time
    ===        - modify-time
    ===        - c-major-device
    ===        - c-minor-device
    ===        - data-size
    ===        - disk-size
    ====================================================================
    -->



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


   <!ELEMENT RecordDesc (DetectTime?, Analyzer?, Description?)> 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)>
   <!ELEMENT disk-size (#PCDATA)>
   <!ELEMENT major-device (#PCDATA)>
   <!ELEMENT minor-device (#PCDATA)>
   <!ELEMENT Linkage ((name, path) | File)>
   <!ATTLIST RecordDesc
           %attlist.global; Linkage
   	category  %attvals.linkcat;  #REQUIRED
   >
   <!ELEMENT FileAccess (UserId, permission+)>
   <!ELEMENT Inode (change-time?, (number, major-device, minor-device)?,
                    (c-major-device, c-minor-device)?)>

   <!--
    ====================================================================
    ===  Section 4.10.4 The Analyzer  FileList class                                              ===
    ===      - NodeRole
    ===      - Location
    ===      - name
    ====================================================================
    -->
   <!--Element Analyzer of IODEF is re-used from IDMEF-->
   <!ELEMENT Analyzer (Node?, Process?)> Node (((name | Address), Address*), DateTime?,
                   name?, Address*, Location?, NodeRole*)>
   <!ATTLIST Node
   	category %attvals.nodecat; "unknown"
   >
   <!ELEMENT Address (address, netmask?)>
   <!ATTLIST Analyzer
           analyzerid Address
   	ident     CDATA "0"
           manufacturer CDATA #IMPLIED
           model
   	category  %attvals.addrcat; "unknown"
   	vlan-name CDATA #IMPLIED



Meijer, et al.         Expires September 29, 2003              [Page 73]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 105]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



           version CDATA #IMPLIED
           class


   	vlan-num  CDATA #IMPLIED
           ostype CDATA
   >
   <!ELEMENT address (#PCDATA)>
   <!ELEMENT netmask (#PCDATA)>
   <!ELEMENT Location (#PCDATA)>
   <!ATTLIST Location
   	lang  NMTOKEN  #IMPLIED
           osversion CDATA
   >
   <!ELEMENT NodeRole (#PCDATA)>
   <!ATTLIST NodeRole
   	category %attvals.noderolecat; "other"
   	lang  NMTOKEN  #IMPLIED
           %attlist.global;
   >

   <!--
    ====================================================================
    ===  Section 4.10.5 The RecordItem  User class                                                  ===
    ===   - UserID
    ====================================================================
    -->
   <!ELEMENT RecordItem ANY> User (UserId+)>
   <!ATTLIST RecordItem
           dtype %attvals.dtype; "string" User
   	ident     CDATA             "0"
   	category  %attvals.usercat; "unknown"
   >

   <!--
   ====================================================================
   ===  Section 4.11 The AdditionalData class                       ===
   ====================================================================
   -->
   <!ELEMENT AdditionalData ANY> UserId (name | number | (name, number))>
   <!ATTLIST AdditionalData
           type %attvals.adtype; "string"
           %ContentType; UserId
   	ident CDATA #IMPLIED
           %attlist.global; "0"
   	type %attvals.idtype; "original-user"
   >
   <!ELEMENT number (#PCDATA)>

   <!--
    ====================================================================
    ===  Section 4.12 The History  Process class                                               ===
    ====================================================================
    -->
   <!ELEMENT History (HistoryData* )> Process (name, pid?, path?, arg*, env*)>
   <!ATTLIST History
           restriction
           %attvals.restriction;   'default' Process
   	ident CDATA "0"
   >
   <!ELEMENT env (#PCDATA)>
   <!ELEMENT pid (#PCDATA)>

   <!--
    ====================================================================
    ===  Section 4.12.1 The HistoryItem class  Service Class                                               ===
   ====================================================================
   -->
   <!ELEMENT HistoryDataItem ( DateTime?, Description?)>
   <!ATTLIST HistoryDataItem
           IncidentID PCDATA #IMPLIED
           AuthorityID PCDATA #REQUIRED
    ===    - port



Meijer, et al.         Expires September 29, 2003              [Page 74]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 106]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



           restriction %attvals.restriction; #IMPLIED
           type %attvals.history; #IMPLIED
   >

   <!--
   ====================================================================
   ===  Section 4.12.2 The DateTime class


    ===
   ====================================================================
   -->
   <!ELEMENT DateTime (#PCDATA)>
   <!ATTLIST DateTime
           %DateTime;
           timestamp $DateTime;  #IMPLIED
           %attlist.global;
   >
   
   <!--
   ====================================================================    - portlist
    ===  Section 4.13 The Assessment class    - protocol
    ===
   ====================================================================
   -->
   <!ELEMENT Assessment (Impact?, Action*, Confidence?)>
   <!ATTLIST Assessment
           restriction %attvals.restriction; #IMPLIED
           %attlist.global;
   >

   <!--
   ====================================================================    - SNMPService
    ===  Section 4.13.1 The Impact class    - WebService
    ===
   ====================================================================
   -->
   <!ELEMENT Impact EMPTY>
   <!ATTLIST Impact
           severity %attvals.severity; #IMPLIED
           completion %attvals.completion; #IMPLIED
           type %attvals.impacttype; "other"
           %attlist.global;
   >

   <!--
   ====================================================================        - url, cgi, arg, http-method
    ===  Section 4.13.2 The Action class    - SNMPService
    ===        - oid, community, command
    ====================================================================
    -->
   <!ENTITY % attvals.actioncat "( block-installed
   <!ELEMENT Service (((name |
           notification-sent port | taken-offline (name, port)) | other )
   ">
   <!ELEMENT Action (#PCDATA)>



Meijer, et al.            Expires March 2003                  [page 107]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002 portlist),
                      protocol?, SNMPService?, WebService?)>
   <!ATTLIST Action
           %attlist.global; Service
   	ident CDATA "0"
   >
   <!ELEMENT port (#PCDATA)>
   <!ELEMENT portlist (#PCDATA)>
   <!ELEMENT protocol (#PCDATA)>
   <!--
   ====================================================================
   ===  Section 4.13.3 The Confidence class                         ===
   ====================================================================
    ====== Web Service ======
    -->
   <!ELEMENT Confidence EMPTY>
   <!ATTLIST Confidence
           rating %attvals.rating; "numeric"
           %attlist.global;
   > WebService (url, cgi?, http-method?, arg*)>
   <!ELEMENT cgi (#PCDATA)>
   <!ELEMENT arg (#PCDATA)>
   <!ELEMENT http-method (#PCDATA)>
   <!--
   ====================================================================
   ===  Section 4.14 The Authority class                            ===
   ====================================================================
    ====== SNMPService ======
    -->
   <!ELEMENT Authority (Organization, Contact*)>
   <!ATTLIST Authority
           restriction %attvals.restriction; #IMPLIED
           %attlist.global;
   > SNMPService (oid?, community?, command?)>
   <!ELEMENT oid (#PCDATA)>
   <!ELEMENT community (#PCDATA)>
   <!ELEMENT command (#PCDATA)>
   <!--
    ====================================================================
    ===  Section 4.14.1 The Organization  Record class                                                ===
   ====================================================================
   -->
   <!ELEMENT Organization (OrganizationID?, OrgName?, PostalAddress?,
   Email?, Telephone?, Fax?)>
   <!ATTLIST Organization
           %attlist.global;
   >
   
   <!--
   ====================================================================
    === Simple elements with sub-elements or attributes.    - RecordData
    ===    - Analyzer
    ===    - RecordItem
    ====================================================================
    -->
   <!ELEMENT ContactHandle (#PCDATA)> Record (RecordData+)>
   <!ATTLIST ContactHandle
           originIRT %attvals.originIRT; #REQUIRED
           %attlist.global; Record
   	restriction %attvals.restriction; #IMPLIED
   >
   <!ELEMENT PersonName (#PCDATA)> RecordData (Description*, DateTime?, Analyzer?,
             RecordItem?)>
   <!ATTLIST PersonName RecordData
   	ident       CDATA                 "0"
   	restriction %attvals.restriction; #IMPLIED



Meijer, et al.         Expires September 29, 2003              [Page 75]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 108]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



           nametype CDATA #IMPLIED
           %attlist.global;
   >
   <!ELEMENT PostalAddress (#PCDATA)>
   <!ATTLIST PostalAddress
           %attlist.global;
   >

   <!ELEMENT Email (#PCDATA)>
   <!ATTLIST Email
           %attlist.global;
   >
   <!ELEMENT Telephone (#PCDATA)>
   <!ATTLIST Telephone
           %attlist.global;
   >
   <!ELEMENT Fax (#PCDATA)>
   <!ATTLIST Fax
           %attlist.global;


   >
   <!--Element Description may contain arbitrary description in
   any/local language used by CSIRT (or IODEF object owner).
   Language should be indicated in the xml:lang attribute of the
   %attlist.global;
   Use Analyzer of different charsets/encodings for the same language should
   considered.--> IODEF is re-used from IDMEF-->
   <!ELEMENT Action (#PCDATA)> Analyzer (Node?, Process?)>
   <!ATTLIST Action
           %attlist.global; Analyzer
   	analyzerid    CDATA  "0"
   	manufacturer  CDATA  #IMPLIED
   	model         CDATA  #IMPLIED
   	version       CDATA  #IMPLIED
   	class         CDATA  #IMPLIED
   	ostype        CDATA  #IMPLIED
   	osversion     CDATA  #IMPLIED
   >
   <!ELEMENT Description RecordItem ANY>
   <!ATTLIST Description
           %attlist.global; RecordItem
   	dtype  %attvals.dtype;  #REQUIRED
   >
   <!--
    ====================================================================
    === SECTION 10. Simple elements with no sub-elements or Miscellaneous simple classes                                 ===
    ===   - Description
    ===   - name
    ===             attributes.   - path
    ===   - url
    ====================================================================
    -->
   <!ELEMENT IncidentID (#PCDATA)> Description ANY>
   <!ATTLIST IncidentID
           %attlist.global; Description
   	lang  NMTOKEN  #IMPLIED
   >
   <!ELEMENT attackID name (#PCDATA)>
   <!ATTLIST attackID
           %attlist.global; name
   	lang  NMTOKEN  #IMPLIED
   >
   <!ELEMENT AuthorityID path (#PCDATA)>
   <!ELEMENT url (#PCDATA)>
















Meijer, et al.         Expires September 29, 2003              [Page 76]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 109]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   <!ATTLIST AuthorityID
           %attlist.global;
   >
   <!ELEMENT MessageID (#PCDATA)>
   <!ATTLIST MessageID
           %attlist.global;
   >
   <!ELEMENT EvidenceDataID (#PCDATA)>
   <!ATTLIST EvidenceDataID
           %attlist.global;
   >
   <!ELEMENT CorrEvidenceID (#PCDATA)>
   <!ATTLIST CorrEvidenceID
           %attlist.global;
   >
   <!ELEMENT OrganizationID (#PCDATA)>
   <!ATTLIST OrganizationID
           %attlist.global;
   >
   <!ELEMENT access-time (#PCDATA)>
   <!ATTLIST access-time
           %attlist.global;
   >
   <!ELEMENT change-time (#PCDATA)>
   <!ATTLIST change-time
           %attlist.global;
   >
   <!ELEMENT create-time (#PCDATA)>
   <!ATTLIST create-time
           %attlist.global;
   >
   <!ELEMENT modify-time (#PCDATA)>
   <!ATTLIST modify-time
           %attlist.global;
   >
   <!ELEMENT c-major-device (#PCDATA)>
   <!ATTLIST c-major-device
           %attlist.global;
   >
   <!ELEMENT c-minor-device (#PCDATA)>
   <!ATTLIST c-minor-device
           %attlist.global;
   >
   <!ELEMENT data-size (#PCDATA)>
   <!ATTLIST data-size
           %attlist.global;
   >
   <!ELEMENT disk-size (#PCDATA)>
   <!ATTLIST disk-size


9. Security considerations

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

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

   o  IODEF-Document with XML signature (Section 7.2)

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

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

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

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

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















Meijer, et al.         Expires March September 29, 2003                  [page 110]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



           %attlist.global;
   >
   <!ELEMENT major-device (#PCDATA)>
   <!ATTLIST major-device
           %attlist.global;
   >
   <!ELEMENT minor-device (#PCDATA)>
   <!ATTLIST minor-device
           %attlist.global;
   >
   <!ELEMENT permission (#PCDATA)>
   <!ATTLIST permission
           %attlist.global;
   >
   <!ELEMENT cgi (#PCDATA)>
   <!ATTLIST cgi
           %attlist.global;
   >
   <!ELEMENT command (#PCDATA)>
   <!ATTLIST command
           %attlist.global;
   >
   <!ELEMENT env (#PCDATA)>
   <!ATTLIST env
           %attlist.global;
   >
   <!ELEMENT netmask (#PCDATA)>
   <!ATTLIST netmask
           %attlist.global;
   >
   <!ELEMENT community (#PCDATA)>
   <!ATTLIST community
           %attlist.global;
   >
   <!ELEMENT Location (#PCDATA)>
   <!ATTLIST Location
           %attlist.global;
   >
   <!ELEMENT http-method (#PCDATA)>
   <!ATTLIST http-method
           %attlist.global;
   >
   <!ELEMENT name (#PCDATA)>
   <!ATTLIST name
           %attlist.global;
   >
   <!ELEMENT number (#PCDATA)>
   <!ATTLIST number
           %attlist.global;



Meijer, et al.            Expires              [Page 77]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 111]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   >
   <!ELEMENT url (#PCDATA)>
   <!ATTLIST url
           %attlist.global;
   >
   <!ELEMENT os (#PCDATA)>
   <!ATTLIST os
           %attlist.global;
   >
   <!ELEMENT arg (#PCDATA)>
   <!ATTLIST arg
           %attlist.global;
   >
   <!ELEMENT oid (#PCDATA)>
   <!ATTLIST oid
           %attlist.global;
   >
   <!ELEMENT path (#PCDATA)>
   <!ATTLIST path
           %attlist.global;
   >
   <!ELEMENT pid (#PCDATA)>
   <!ATTLIST pid
           %attlist.global;
   >
   <!ELEMENT port (#PCDATA)>
   <!ATTLIST port
           %attlist.global;
   >
   <!ELEMENT portlist (#PCDATA)>
   <!ATTLIST portlist
           %attlist.global;
   >
   <!ELEMENT program (#PCDATA)>
   <!ATTLIST program
           %attlist.global;
   >
   <!ELEMENT protocol (#PCDATA)>
   <!ATTLIST protocol
           %attlist.global;
   >
   <!ELEMENT size (#PCDATA)>
   <!ATTLIST size
           %attlist.global;
   >



9. References


10. IANA considerations


















































Meijer, et al.         Expires September 29, 2003              [Page 78]

Internet-Draft    IODEF Data Model and Implementation         March 2003                  [page 112]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002




   [1]  Bradner, S., "Key words for use in RFCs


11. Acknowledgments

   The following groups contributed substantially to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997

   [2]  Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's 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 Requirements",
        RFC 3067, February 2001

   [3]  Intrusion Detection Message Exchange Format Extensible Markup
        Language (XML) Document Type Definition by D. Curry - September
        2001 - http://www.ietf.org/internet-drafts/draft-ietf-idwg-
        idmef-xml-06.txt - work in progress.

   [4]  Taxonomy Working-Group
      of the Computer Security TERENA task-force (TF-CSIRT)

   o  the eCSIRT.net project









































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


Normative References

   [1]   Demchenko, Y., Hiroyuki, H. and G. Keeni, "Requirements for
         Format for Incident related terminology
        - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/
        i-taxonomy_terms.html

   [5] Report Exchange", RFC XXX, September 2003.

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

   [6] 2000, <http://www.w3.org/TR/
         2000/REC-xml-20001006>.

   [3]   World Wide Web Consortium (W3C), Consortium, "Namespaces in XML," W3C
        Recommendation, 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/
         >.

   [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 14, 1999. http://www.w3.org/TR/1999/
        REC-xml-names-19990114.

   [7]  XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001.
        http://www.w3.org/TR/xmlschema-0/

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

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

   [9]  Mealling, M., "The IANA XML Registry," draft-mealling-iana-
        xmlns-registry-00.txt, November 17, 2000, work in progress.
   [10] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified
        Modeling Language Reference Model," ISBN 020130998X,
        Addison-Wesley, 1998.

   [11]   Freed, N., "IANA Charset Registration Procedures," Procedures", BCP 19, RFC 2278,
         January 1998.

   [12] Alvestrand, H., "Tags

   [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 the Identification
         IPv4, IPv6 and OSI", RFC 2030, October 1996.

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

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

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

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



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


         interchange - Representation of dates and times," times", ISO 8601,
         Second Edition, December 15, 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 September 29, 2003                  [page 113]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002



   [14] Mills, D., "Network Time Protocol (Version 3) Specification,
        Implementation,              [Page 81]

Internet-Draft    IODEF Data Model and Analysis," RFC 1305, Implementation         March 1992.

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

   [16] Eastlake, D., Reagle, 2003


Informative References

   [19]  Rumbaugh, J., Jacobson, I. and D. Solo, "XML-Signature Syntax
        and Processing," draft-ietf-xmldsig-core-11.txt, November 1,
        2000, work in progress.

   [17] Incident Object Description G. Booch, "The Unified Modeling
         Language Reference Model, ISBN 020130998X, Addison-Wesley",
         1998.

   [20]  Helme, A. and Exchange Format Working Group -
        http://www.terena.nl/task-forces/tf-csirt/iodef/

   [18] RIPE NCC Database - http://www.ripe.net/ripe/wg/db/

   [19] Trusted Introducer Service - http://www.ti.terena.nl/



10. Security Considerations





11. IANA Considerations





12. Acknowledgements

   This R. Danyliw, "The IODEF Implementation Guide,
         document was built on the work done to be created by the Incident Object
   Description and Exchange Format Working-Group of the TERENA
   task-force TF-CSIRT.
   


13. INCH WG", 2003.


Authors' Addresses: Addresses

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

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




Meijer, et al.            Expires March 2003                  [page 114]

Internet Draft         draft-ietf-inch-iodef-00.txt             Apr 2002


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

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


   Yuri Demchenko
  TERENA
  Singel 468 D
  1017 AW Amsterdam
  The
   NLnet Labs
   Netherlands
  Phone: +31 205 304 488
  Email: demch@terena.nl



14.

   EMail: demch@chello.nl














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


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

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


Full Copyright Statement

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

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

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

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



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


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." PURPOSE.


Acknowledgement

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











































Meijer, et al.         Expires September 29, 2003              [Page 84]

----