INTERNET DRAFT                                          Yuri Demchenko 
draft-terena-itdwg-iodef-xml-00.txt                      <initial text> 
Category: Informational                                  Roman Danyliw               
                                                         Jan Meijer            
Expires March 2002                                                      
                                                                        
                                                                        
                                                                        
                                                                        
                                                          October, 2001 
    
    
              Incident Object Description and Exchange Format 
              Data Model and Extensible Markup Language (XML) 
                         Document Type Definition 
                   <draft-terena-itdwg-iodef-xml-00.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 obsolete by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/lid-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. 
    
   This Internet Draft expires March, 2002. 
    
   Copyright Notice 
    
   Copyright (C) The Internet Society (2001). All Rights Reserved. 
    
1. Abstracts 
    
   The purpose of the Incident Object Description and Exchange Format 
   is to define a common data format for the description, archiving and 
   exchange of information about incidents between CSIRTs (Computer 
   Security Incident Response Teams) (including alert, incident in 

 
                                                              [Page 1] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   investigation, archiving, statistics, reporting, etc.). The goals 
   and requirements of the IODEF are described in [2]. One of IODEF 
   design principle is compatibility with Intrusion Detection Message 
   Exchange Format (IDMEF) [3] developed for Intrusion Detection 
   Systems. IODEF is heavily based on IDMEF and has upward 
   compatibility with IDMEF. 
    
   This document describes a data model to represent information 
   produced by Incident Handling System used by CSIRT to track security 
   incidents, and explains the rationale for using this model. An 
   implementation of the data model in the Extensible Markup Language 
   (XML) is presented, an XML Document Type Definition is developed, 
   and examples are provided.  
    
 
 
                        TABLE OF CONTENTS 
 
 
Status of This Memo ................................................    
 
1. Abstract ........................................................    
 
2. Conventions Used in This Document ...............................    
 
3. Introduction ....................................................    
  3.1 About the IODEF Data Model .................................    
     3.1.1 Problems Addressed by the Data Model .................    
     3.1.2 Data Model Design Goals ..............................    
  3.2 About the IODEF XML Implementation .........................    
  3.3 Relation between IODEF and IDMEF ... 
 
4. Notational Conventions and Formatting Issues ....................    
4.1 UML Conventions used for Data Model Description ................    
4.2 XML Document Type Definitions ..............................    
   4.2.2 Element Declarations .................................    
   4.2.3 Attribute Declarations ...............................    
   4.2.4 Entity Declarations ..................................    
4.3 XML Documents ..............................................    
   4.3.1 The Document Prolog ..................................    
      4.3.1.1 XML Declaration ................................    
      4.3.1.2 IODEF DTD Formal Public Identifier .............    
      4.3.1.3 IODEF DTD Document Type Declaration ............    
   4.3.2 Character Data Processing in XML and IODEF ...........    
   4.3.3 Languages in XML and IODEF ...........................    
   4.3.4 Inheritance and Aggregation ..........................    
4.4 IODEF Data Types ...........................................    
   4.4.1 Integers .............................................    
   4.4.2 Real Numbers .........................................    
   4.4.3 Characters and Strings ...............................    
   4.4.4 Bytes ................................................    
   4.4.5 Enumerated Types .....................................    
   4.4.6 Date-Time Strings ....................................    
   4.4.7 NTP Timestamps .......................................    
   4.4.8 Port Lists ...........................................    
   4.4.9 Unique Identifiers ...................................    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 2] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 

   4.4.10 Personal name 
   4.4.11 Organisation name 
   4.4.12 Postal address 
   4.4.13 Telephone and Fax numbers 

5. The IODEF Data Model and XML DTD 
5.1 Data Model Overview 
5.2 The IODEF Description Classes 
   5.2.1 The IODEF-Description Class 
   5.2.2 The Incident Class 
      5.2.2.1 The CorrelationIncident Class 
   5.2.3 The IncidentAlert Class 
   5.2.4 The Core Classes 
      5.2.4.1 The Attack Class 
      5.2.4.2 The Source Class 
      5.2.4.3 The Target Class 
      5.2.4.4 The Method Class 
      5.2.4.5 The Attacker Class 
      5.2.4.6 The Victim Class 
      5.2.4.7 The Evidence Class 
      5.2.4.8 The Authority Class 
      5.2.4.9 The History Class 
      5.2.4.10 The AdditionalData Class 
   5.2.5 The Time Classes 
      5.2.5.1 The DetectTime Class 
      5.2.5.2 The StartTime Class 
      5.2.5.3 The EndTime Class 
   5.2.6 The Support Classes 
      5.2.6.1 The Node Class 
         5.2.6.1.1 The Address Class 
      5.2.6.2 The User Class 
         5.2.6.2.1 The UserId Class 
      5.2.6.3 The Process Class 
      5.2.6.4 The Service Class 
         5.2.6.4.1 The WebService Class 
         5.2.6.4.2 The SNMPService Class 
      5.2.6.5 The Classification Class 
      5.2.6.6 The EvidenceData Class 
      5.2.6.7 The EventList Class 
      5.2.6.8 The Organization Class 
      5.2.6.9 The Contact Class 
      5.2.6.10 The Reported Class 
      5.2.6.11 The Received Class 
      5.2.6.12 The ActionList Class 
   5.2.7 The Simple Classes 
      5.2.7.1 The Description Class 
      5.2.7.2 The IRTcontact Class 
      5.2.7.3 The Data Class 
 
6. Extending the IODEF .............................................    
 6.1 Extending the Data Model ...................................    
 6.2 Extending the XML DTD ......................................    
 
7. Special Considerations ..........................................    
 7.1 XML Validity and Well-Formedness ...........................    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 3] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 

 7.2 Unrecognized XML Tags ......................................    
 7.3 Digital Signatures .........................................    
 
8. Examples ........................................................    
 
9. The IODEF Document Type Definition ..............................    
 
10. Security Considerations ........................................    
 
11. References .....................................................    
 
12. Acknowledgements ...............................................    
 
13. Authors' Addresses .............................................    
 
Full Copyright Statement ...........................................    
 
 
 
 

2. Conventions Used in This Document 
 

   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 terminology used in this 
   documents is of common use, however it contains some specific 
   conventions described in [2] and [4]. 
    
    
3. Introduction 
    
    
   Incident Object Description and Exchange Format (IODEF) is intended 
   to be a standard format which allows CSIRTs to exchange operational 
   and statistical information; it may also provide a basis for the 
   development of compatible and inter-operable tools for Incident 
   recording, tracking and exchange. 
 

   First of all, IODEF target for common exchange format between CSIRTs 
   and may be generated when sending message with Incident information 
   to another CSIRT or Incident Handling System (IHS), although 
   internal incident data storage/database may use another 
   (proprietary) format. Using IODEF in their workflow and Incident 
   Handling Systems, CSIRTs can benefit from: 
 

   +  a single organisational database system that could store the 
     information from a variety of subordinate teams/CSIRTs; 
       
   +  simplifies building an incident correlation and statistics system 
     that process Incident reports from different CSIRTs; 
       
   +  a common incident data exchange format would make it easier for 
     different organizations (users, vendors, response teams, law 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 4] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     enforcement) to not only exchange data, but also communicate about 
     it. 
 
   One of IODEF design principle is compatibility with Intrusion 
   Detection Message Exchange Format (IDMEF) [3] developed for 
   Intrusion Detection Systems. IODEF is heavily based on IDMEF and has 
   upward compatibility with IDMEF. IDMEF message may be wrapped up 
   into IDMEF container as to provide Incident alert information. One 
   of specific purpose of this version of the Internet Draft is to 
   provide information for discussion about level and volume of 
   compatibility between IODEF and IDMEF. 
    
   IODEF description intends to be capable to describe other Computer 
   Security Incident related documents, e.g. Incident Evidence and 
   Vulnerability or Virus Alerts. The diversity of IODEF uses should be 
   considered when developing elements and classes definitions. Some 
   example IODEF implementations are discussed in Section 8. 
    
   Computer Security related terminology used in this document is 
   described in [1] and [4]. Specific terminology and notational 
   conventions related to data model and XML DTD presentation in this 
   document are described in sections below. 
    
 
 

3.1 IODEF Data Model Design principles 
  

   The IODEF data model is an object-oriented representation of the 
   Incident description created by CSIRT when such a security event 
   registered by CSIRT.  
 
 

3.1.1 Problems Addressed by the Data Model 
 

   The data model addresses several problems associated with 
   representing Incident description data: 
 

   +  Incident information is inherently heterogeneous. Some Incidents 
     at the initial stage are described with very little information, 
     such as attack/target, victim and time of the event. In process of 
     investigation Incident description is extended with additional 
     data that completes full Incident description, including Evidence 
     data and history of handling process. The data model that 
     represents this information must be flexible to accommodate 
     different needs. 
 

     Subclassing and aggregation provide extensibility while preserving 
     the consistency of the model. An object-oriented model is 
     naturally extensible via aggregation and subclassing. If an 
     implementation or purpose of the data model extends, it is 
     extended with new classes, either by aggregation or subclassing, 
     and implementation that does not understand these extensions will 
     still be able to understand the subset of information that is 
     defined by the data model.  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 5] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 

 

   +  The origin of Incidents may be different. Normally, Incident is 
     created by CSIRT personnel manually, it may also be based on 
     Incident report received from other team, or Intrusion Alert sent 
     by IDS. The initial information is different in different cases.  
      
     The data model defines support classes that accommodate the 
     differences in data sources depending on Incident origination and 
     registration procedure. Particularly, if Incident alert is created 
     from IDMEF message generated by IDS, the data model allows simple 
     wrapping up of IDMEF Alert message combined with information about 
     CSIRT/authority created the object. 
      
   +  The purpose of Incident description may be different. Security 
     event may initiate Incident registration, or Vulnerability 
     investigation, or Evidence Collection, in other cases IODEF 
     Description may be used for carrying aggregated Incident 
     information for multisite incidents or for statistics purposes. 
      
     To meet this problem, IODEF data model should allow creation of 
     top-level classes for different description profiles. The data 
     model defines extensions to the basic schema that allow creating 
     new profiles and description of both simple and complex Incidents, 
     as well as Incident aggregation. Extensions are accomplished 
     through subclassing or association of new classes based on reusing 
     core and supportive classes where possible. 
 

   +  Incident description may contain sensitive information in 
     different elements. This information should not be exposed to non-
     authorised personnel or should not be transferred to another 
     CSIRT. 
      
     The data model and its XML implementation should allow indication 
     of access restriction to different elements/fields of IODEF 
     Description for further filtering by IHS. 
      
     The similar suggestions may apply to local information used (or 
     included into IODEF object) by single CSIRT for internal purposes, 
     that information is not necessary to be transferred to other 
     CSIRTs. 
 
 

3.1.2 Data Model Design Goals 
  

   The data model was designed to provide a standard representation of 
   Incident in an unambiguous fashion, and to permit possible adoption 
   of IODEF description to concrete Incident handling system and 
   procedure/workflow used by CSIRT. 
    
   The design of the data model is content-driven. This means that new 
   objects are introduced to accommodate additional content, not 
   semantic differences between Incidents.  
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 6] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The data model must be unambiguous.  This means that while we allow 
   IODEF descriptions created by different CSIRTs to be different, we 
   must ensure that the same incident described by different CSIRTs 
   (and using different initial information) is identified as one 
   incident with high level of confidence (i.e., the common subset of 
   information reported by both CSIRTs must be identical and inserted 
   in the same placeholders within the Incident data structure). Of 
   course, description may have different level of detalisation and 
   source, target and mediator of Attack may be described from 
   different perspective depending on origination of Attack, but these 
   problems should not prevent Incident handling systems to find right 
   correlation relations between Incidents.  
    
   Incidents may require aggregation when investigated by few teams, or 
   in case when multisite incidents are investigated. This data model 
   provides all necessary definitions and facility for describing 
   Incidents of different complexity, including incidents correlation. 
   However, methods and algorithms for processing of this kind of 
   information relate to the IHS. 
 
 

3.2 Using XML for IODEF Description 
 

   Current IODEF implementation is based on XML. XML as a metalanguage 
   allows the definition of customized markup languages for different 
   types of documents and different applications. XML provides both 
   syntax for declaring document markup and structure (i.e., defining 
   elements and attributes, specifying the order in which they appear, 
   and so on) and a syntax for using that markup in documents. 
    
   Normally, XML-based applications define their own XML DTD and/or XML 
   Schema, which are accomplished with defining and registration of 
   specific XML namespace [6]. There is a procedure defined by IETF for 
   registration application specific XML namespace [9]. 
    
   NOTE.  
   1. For clarity in this document, we will use the terms "XML" and 
   "XML documents" when speaking in the general case, and the terms 
   "IODEF description" and "IODEF markup" and "IODEF document" when 
   speaking specifically about the elements (tags) and attributes that 
   describe IODEF descriptions. 
   2. For convenience in this document, we will use terms "class" and 
   "subclass" when talking about data model, and terms "class" and 
   "element" as equal meaning when talking about XML DTD or XML 
   Document. 
    
   XML-implementation of IODEF has many benefits: 
 

   +  XML (by means of defining XML DTD or XML Schema) provides all 
     necessary features to develop specific markup language for the 
     purpose of describing Security Incidents. It also defines a 
     standard way to extend this language, either for later revisions 
     of this document ("standard" extensions), or for vendor-specific 
     use ("non-standard" extensions). 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 7] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


 
   +  Software tools for processing XML documents are widely available, 
     in both commercial and open source forms. Numerous tools and APIs 
     for parsing and/or validating XML are available in a variety of 
     languages, including Java, C, C++, Tcl, Perl, Python, etc. 
     Widespread access to tools will make adoption of the IODEF by 
     product developers easier, and hopefully, faster.  
  
   +  XML meets IODEF Requirement 4.1, that message formats support 
     full internationalization and localization. The XML standard 
     requires support for both the UTF-8 and UTF-16 encodings of 
     ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set, 
     "UCS") and Unicode, making all XML applications (and therefore all 
     IODEF-compliant applications) compatible with these common 
     character encodings. 
 
     XML also provides support for specifying, on a per-element basis, 
     the language in which the element's content is written, making 
     IODEF easy to adapt to local languages in which CSIRTs and their 
     constituency work. 
 
   +  XML meets IODEF Requirement 4.2, that message formats must 
     support modularity and filtering and aggregation. XML's 
     integration with XSL, a style language, allows messages to be 
     combined, discarded, and rearranged. Simple solution for this 
     purpose may also use attributes applied to each. 
 
   +  XML is free, with no license, no license fees, and no royalties. 
     Developers may also benefit from learning experience from similar 
     XML based solutions in open source domain. 
 
 

3.3 Relation between IODEF and IDMEF 
 

   One of IODEF design principle is compatibility with Intrusion 
   Detection Message Exchange Format (IDMEF) developed for Intrusion 
   Detection Systems [3]. IODEF is heavily based on IDMEF and has 
   upward compatibility with IDMEF that assures inheritance of IDMEF 
   data structure. IODEF re-uses most of class definitions from IDMEF.  
    
   IDMEF message may be simply wrapped up into IDMEF container for 
   IncidentAlert class. When Incident description is produced of IDMEF 
   message, IODEF may directly use related data classes/elements from 
   IDMEF. 
    
   In this context is recommended that IHS understands both format - 
   IODEF and IDMEF. This may be achieved by mapping part of IDMEF 
   classes (XML tags) related to Attack description into IODEF classes. 
   This is to be not difficult task because 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 semantics and meaning in IODEF is 
   inherited from IDMEF. 
 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 8] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 

 

4. Notational Conventions and Formatting Issues 
 

   This document uses three notations: Unified Modeling Language to 
   describe the data model, XML to describe the markup used in IODEF 
   documents, and IODEF markup to represent the documents themselves. 
    
   This section describes these notations in sufficient detail that 
   readers unfamiliar with them can understand the document. Note, 
   however, that these descriptions are not comprehensive; they only 
   cover the components of the notations used by the data model and 
   document format. 
    
   This section also explains several document formatting issues that 
   apply to XML and IODEF documents, including formats for particular 
   data types, special character and whitespace processing, character 
   sets, and languages. 
    
   It is assumed that readers and/or implementers are familiar with 
   basics of UML and XML. 
    
    
4.1 Unified Modeling Language conventions used for IODEF Data Model 
description 
    
   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, we have identified several classes and their 
   associated attributes.  The symbols used in this document to 
   represent classes and attributes are shown in Figure 4.1. 
  

   +-------------+  
   | Class Name  |     <----- Name of class  
   +-------------+  
   | Attribute 1 |     <----- Name of first attribute  
   | ...         |  
   | Attribute N |     <----- Name of nth attribute  
   +-------------+ 
    
   Figure 4.1 - Symbols representing classes and attributes 
    
   Note that attributes for a class may not appear in all diagrams in 
   which the class is used. 
 
 

4.1.1 Relationships 
 

   The IODEF model currently uses only two of the relationship types 
   defined by UML: inheritance and aggregation. 
    
   Inheritance denotes a superclass/subclass type of relationship where 
   the subclass inherits all the attributes, operations, and 
   relationships of the superclass.  This type of relationship is also 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 9] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   called a "is-a" or "kind-of" relationship.  Subclasses may have 
   additional attributes or operations that apply only to the subclass, 
   and not to the superclass. 
    
   In this document, inheritance is denoted by the /_\ symbol. In 
   Figure 4.2 above, we are showing that Book and Magazine are two 
   types of Publication.  Book inherits all the attributes of 
   Publication, plus all of its own attributes (thus, it has four 
   attributes in total); as does Magazine (giving it three attributes 
   in total). 
    
    
           +-------------+  
           | Publication |  
           +-------------+  
           | publisher   |  
           | pubDate     |  
           +-------------+  
                 /_\  
                  |  
         +--------+--------+  
         |                 |  
   +----------+     +----------+  
   | Magazine |     |   Book   |  
   +----------+     +----------+  
   | name     |     | title    |  
   |          |     | author   |  
   +----------+     +----------+ 
     
   Figure 4.2 - Inheritance relationships  
    
    
   Aggregation is a form of association in which the whole is related 
   to its parts.  This type of relationship is also referred to as a 
   "part-of" relationship.  In this case, the aggregate class contains 
   all of its own attributes and as many of the attributes associated 
   with its parts as required and specified by the occurrence 
   indicators (see Section 4.1.2). 
    
   In this document, the symbol <> is used to indicate aggregation. It 
   is placed at the end of the association line closest to the 
   aggregate (whole) class.  In Figure 4.3 above, 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      |  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 10] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |          |            +--------------+  
   |          |       0..* +--------------+  
   |          |<>----------| Appendix     |  
   |          |            +--------------+  
   |          |       0..1 +--------------+  
   |          |<>----------| Bibliography |  
   |          |            +--------------+  
   |          |            +--------------+  
   |          |<>----------| Index        |  
   |          |            +--------------+  
   +----------+ 
    
    Figure 4.3 - Aggregation relationships 
    
    
    
4.1.2 Occurrence Indicators 
    
   Occurrence indicators show the number of objects within a class that 
   are linked to one another by an aggregation relationship.  They are 
   placed at the end of the association line closest to the part they 
   refer to.  Occurrence indicators, as used in this document, are: 
    
      n     exactly "n" (left blank if n=1)  
   0..*     zero or more  
   1..*     one or more  
   0..1     zero or one (i.e., "optional")  
   n..m     between "n" and "m" (inclusive) 
    
   In Figure 4.3 above, the Book: 
    
   +  may have no Preface or one Preface;  
   +  must have at least one Chapter, but may have more;  
   +  may have any number of Appendixes; and  
   +  must have exactly one Index. 
 
 

4.2 XML Document Type Definitions 
 

   XML Document Type Definitions (DTDs) are used to declare the markup 
   for a document.  This includes the different pieces of information 
   the document will contain (the elements), characteristics of that 
   information (the attributes), and the relationship between the 
   pieces (the content model). 
    
   Section 9 of this document contains the complete IODEF DTD. 
    
 

4.2.2 Element Declarations 
    
   Elements are the main part of a document's markup; they define the 
   names of the pieces of the document, and the content model for those 
   pieces. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 11] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!ELEMENT Book (  
       Preface, Chapter, Appendix, Bibliography, Index  
     )> 
    
   In this example, the "Book" element is defined to consist of exactly 
   one Preface, one Chapter, one Appendix, one Bibliography, and one 
   Index.  Furthermore, these parts must appear in this order (e.g., 
   the Index cannot come before the Bibliography). 
    
   The XML document associated with this DTD might look like this: 
    
   <Book>  
     <Preface>  
       ...  
     </Preface>  
     <Chapter>  
       ...  
     </Chapter>  
     <Appendix>  
       ...  
     </Appendix>  
     <Index>  
       ...  
     </Index>  
   </Book> 
    
   NOTE: XML is for the most part a free-format language; the line 
   breaks and indentation used in the examples are for the purpose of 
   improving readability only. 
    
    
4.2.2.1 Occurrence Indicators 
    
   In the example above, Book must contain exactly one of each part -- 
   it cannot have more than one Chapter, the Preface is not optional, 
   and so on.  This is not a very good representation of real-life 
   books. 
    
   XML provides occurrence indicators to make it possible to represent 
   more complex content models.  The occurrence indicators are: 
    
   ?          the content may appear either once or not at all  
   *          the content may appear one or more times or not at all  
   +          the content must appear at least once, and may appear  
              more than once  
   [none]     the content must appear exactly once 
    
   Occurrence indicators allow us to revise our Book content model 
    
   <!ELEMENT Book (  
      Preface?, Chapter+, Appendix*, Bibliography?, Index  
     )> 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 12] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   Now a Book may contain an optional Preface, one or more Chapters, 
   any number of Appendixes, an optional Bibliography, and an Index.  
   The parts must still occur in this order. 
    
    
4.2.2.2 Alternative Content and Grouping 
    
   To allow the creation of arbitrarily complex content models, XML 
   also provides: 
    
   +  alternatives, specified with the '|' character  
   +  parentheses, to permit grouping of elements  
   +  occurrence indicators may also be used on parenthesized groups 
    
   For example: 
    
   <!ELEMENT x (a, (b | c | d), e)* > 
    
   would allow all of the following: 
    
   <x>          <x>          <x>          <x>          <x>  
     <a/>         <a/>         <a/>         <a/>       </x>  
     <b/>         <d/>         <c/>         <b/>  
     <e/>         <e/>         <e/>         <e/>  
   </x>         </x>           <a/>         <a/>  
                               <c/>         <c/>  
                               <e/>         <e/>  
                             </x>           <a/>  
                                            <d/>  
                                            <e/>  
                                          </x> 
    
   The example above also introduces the "<tag/>" notation; this is 
   used in XML to denote empty content.  It is more or less equivalent 
   to "<tag></tag>" (the differences are beyond the scope of this 
   document). 
    
    
4.2.2.3 Element Content 
    
   An XML document has a tree structure.  One element at the top is the 
   parent of all other elements (e.g., Book), there are some number of 
   other elements all with parents and children, and then at the bottom 
   of the tree, there are some number of elements that have no 
   children. These are the elements that contain the document content. 
    
   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: 
    
   PCDATA  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 13] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   An XML processor will find only text (parsed character data) in this 
   element, no tags or entity references (see Section 4.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 5.2.4.5). 
    
   In case if data type declaration will be recognized as essential, 
   future implementation of the IODEF should use XML Schema definition 
   instead of currently used XML DTD. 
    
    
4.2.3 Attribute Declarations 
     
   Attributes allow data to be associated with an element.  The 
   decision to put data in an attribute or a child element is mostly 
   one of style, although consideration should be given to the type and 
   quantity of data as well.  Attributes are, generally, used for 
   small, atomic data and elements are used for large or composite 
   data. 
    
   Attributes are declared with their name, their content type, and 
   their attribute type, as shown below: 
    
   <!ATTLIST Book  
       title          CDATA                  #REQUIRED  
       author         CDATA                  #REQUIRED  
     > 
    
   The declaration above defines two attributes of the Book element, 
   title and author.  Both may contain character data, and both are 
   required.  These might be given as follows in an XML document: 
    
   <Book title="The Cat in the Hat" author="Dr. Seuss"> 
    
    
4.2.3.1 Attribute Types 
    
   There are four attribute types: 
    
   #REQUIRED  
   The attribute is required, and has no default value.  The XML 
   document must specify a value for it. 
    
   #IMPLIED  
   The attribute is optional, and has no default value. 
    
   #FIXED [value]  
   The attribute must always have the default value "[value]."  It is 
   an error to specify the attribute with any other value.  When an XML 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 14] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   processor encounters an omitted attribute, it will behave as though 
   it were present with the declared default value. 
    
   [value]  
   The attribute is optional, and has a default value of "[value]." 
   When an XML processor encounters an omitted attribute, it will 
   behave as though it were present with the default value. 
    
    
4.2.3.2 Attribute Content 
    
   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." 
    
    
4.2.4 Entity Declarations 
    
   Entities allow symbols to be defined that will be replaced with 
   other text when processed.  There are two types of entities, 
   "general" and "parameter."  General entities are for use within XML 
   document content; for example: 
    
   <!ENTITY IODEF "Intrusion Detection Message Exchange Format"> 
    
   Entities are referenced by bracketing them with the characters '&' 
   and ';' -- whenever "&IODEF;" appears in the XML document from the 
   example above, it will be replaced with the text "Intrusion 
   Detection Message Exchange Format".  General entities (and a special 
   case of them called character references) are used extensively in 
   handling special characters (see Sections 4.3.2.1 and 4.3.2.2). 
     
   Parameter entities are for use within DTDs (they are not recognized 
   in document content), and are declared and referenced in a slightly 
   different way.  The declaration includes a '%' symbol before the 
   entity name, and they are referenced by bracketing them with the 
   characters '%' (instead of '&') and ';'.  For example, attributes 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 15] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   that must appear on every element are declared in a parameter 
   entity: 
    
   <!ENTITY % attlist.global     "  
       xmlns           CDATA     #FIXED     'urn:iana:xml:ns:IODEF'  
       xmlns:IODEF     CDATA     #FIXED     'urn:iana:xml:ns:IODEF'  
       xml:space       (default | preserve) 'default'  
       xml:lang        NMTOKEN   #IMPLIED  
     "> 
    
   and then referenced in each attribute list declaration: 
    
   <!ATTLIST IODEF-Description  
       %attlist.global;  
     >  
   <!ATTLIST Alert  
       %attlist.global;  
     > 
    
    
4.3 XML Documents 
    
   This section describes a number of XML document formatting rules; 
   these rules apply to IODEF documents as well. 
    
    
4.3.1 The Document Prolog 
    
   The "prolog" of an XML document, that part that precedes anything 
   else, consists of the XML declaration and the document type 
   declaration. 
    
    
4.3.1.1 XML Declaration 
    
   Every XML document (and therefore every IODEF document) starts with 
   an XML declaration.  The XML declaration specifies the version of 
   XML being used; it may also specify the character encoding being 
   used. 
    
   The XML declaration looks like: 
    
   <?xml version="1.0" ?> 
    
   If a character encoding is specified, the declaration looks like: 
    
   <?xml version="1.0" encoding="charset" ?> 
    
   where "charset" is the name of the character encoding in use (see 
   Section 4.3.2).  If no encoding is specified, UTF-8 is assumed. 
   IODEF documents being exchanged between IODEF-compliant applications 
   MUST begin with an XML declaration, and MUST specify the XML version 
   in use. Specification of the encoding in use is RECOMMENDED. 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 16] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   IODEF-compliant applications MAY choose to omit the XML declaration 
   internally to conserve space, adding it only when the message is 
   sent to another destination (e.g., a web browser).  This practice is 
   NOT RECOMMENDED unless it can be accomplished without loss of each 
   message's version and encoding information. 
    
    
4.3.1.2 IODEF DTD Formal Public Identifier 
    
   The formal public identifier (FPI) for the IODEF Document Type 
   Definition described in this memo is: 
    
   "-//IETF//DTD RFCxxxx IODEF v0.0//EN" 
    
   NOTE: The "RFCxxxx" text in the FPI value will be replaced with the 
   actual RFC number, if this memo 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 memo, as shown in 
   the following section. 
    
    
4.3.1.3 IODEF DTD Document Type Declaration 
    
   The document type declaration for an XML document referencing the 
   IODEF DTD defined by this memo will usually be specified in one of 
   the following ways: 
    
   <!DOCTYPE IODEF-Description PUBLIC  
       "-//IETF//DTD RFCxxxx IODEF v0.0//EN"> 
    
   The last component of the document type declaration is the formal 
   public identifier (FPI) specified in the previous section. 
    
   <!DOCTYPE IODEF-Description SYSTEM  
       "/some/path/to/the/IODEF-Description.dtd"> 
    
   The last component of the document type declaration is a URI that 
   points to a copy of the Document Type Definition. 
    
   In order to be valid (see Section 7.1), an XML document must contain 
   a document type declaration.  However, this represents significant 
   overhead to an IODEF-compliant application, both in the bandwidth it 
   consumes as well as the requirements it places on the XML processor 
   (not only to parse the declaration itself, but also to parse the DTD 
   it references). 
    
   Implementers MAY decide, therefore, to have analyzers and managers 
   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 the document type 
   declaration from IODEF descriptions.  The method for negotiating 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 17] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   this agreement is outside the scope of this document.  Note that 
   great care must be taken in negotiating any such agreements, as the 
   manager may have to accept messages from many different analyzers, 
   each using a DTD with a different set of extensions. 
    
    
4.3.2 Character Data Processing in XML and IODEF 
    
   A document's XML declaration (see Section 4.3.1.1) 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.  The XML standard 
   also permits other character encodings to be used (e.g., UTF-7, UTF-
   8, UTF-32). However, support for these encodings is not guaranteed 
   to be present in all XML applications. 
    
   For portability reasons, IODEF-compliant applications SHOULD NOT 
   use, and IODEF descriptions 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 description, UTF-
   8 is assumed. 
    
   NOTE: The ASCII character set is a subset of the UTF-8 encoding, and 
   therefore may be used to encode IODEF descriptions. 
    
   Per the XML standard, 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). 
    
    
4.3.2.1 Character Entity References 
    
   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;  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 18] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      >                 &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. 
    
4.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. 
    
    
4.3.2.3 White Space Processing 
    
   XML preserves white space by default.  The XML processor passes all 
   white space characters to the application unchanged.  This is much 
   different from HTML (and SGML), in which, although the space/no 
   space distinction is meaningful, the one space/many spaces 
   distinction is not. 
    
   XML allows elements to identify the importance of white space in 
   their content by using the "xml:space" attribute: 
    
   <tag xml:space="action"> 
    
   where "action" is either "default" or "preserve." 
    
   If "action" is "preserve," the application MUST treat all white 
   space in the element's content as significant.  If "action" is 
   "default," the application is free to do whatever it normally would 
   with white space in the element's content. 
    
   The intent declared with the "xml:space" attribute is considered to 
   apply to all attributes and content of the element where it is 
   specified (including sub-elements), unless overridden with an 
   instance of "xml:space" on another element within that content. 
    
   All IODEF elements support the "xml:space" attribute. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 19] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
4.3.3 Languages in XML and IODEF 
    
   XML allows elements to identify the language their content is 
   written in by using the "xml:lang" attribute: 
    
   <tag xml:lang="langcode"> 
    
   where "langcode" is a language tag as described in RFC 3066 [12]. 
    
   The intent declared with the "xml:lang" attribute is considered to 
   apply to all attributes and content of the element where it is 
   specified (including sub-elements), unless overridden with an 
   instance of "xml:lang" on another element within that content. 
    
   IODEF-compliant applications SHOULD specify the language in which 
   their contents are encoded; in general this can be done by 
   specifying the "xml:lang" attribute for the top-level element and 
   letting all other elements "inherit" that definition. 
    
   If no language is specified for an IODEF description, English SHALL 
   be assumed. 
    
   All IODEF tags support the "xml:lang" attribute. 
    
    
4.3.4 Inheritance and Aggregation 
    
   XML DTDs do not support inheritance as used by the IODEF data model 
   (i.e., there is no support for "kind-of" relationships).  This does 
   not present a major problem in practice; aggregation relationships 
   have been used instead to implement these relationships with little 
   loss of functionality. 
    
   As a note of interest, XML Schemas, recently approved by the W3C, 
   will provide support for inheritance, as well as stronger data 
   typing and other useful features [7]. Future versions of the IODEF 
   may probably use XML Schemas instead of DTDs. It was recognized that 
   for initial stage of new application design XML DTD provides better 
   human readable format of document and elements description, however 
   further development of application and its possible integration into 
   Information/Incident management system may require more detailed 
   definition of data types and object/elements relations. 
    
    
4.4 IODEF Data Types 
    
   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. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 20] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   Each data type in the model has specific formatting requirements in 
   an XML IODEF description; these requirements are set forth in this 
   section. 
    
    
4.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". 
    
    
4.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. 
    
    
4.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. 
    
    
4.4.4 Bytes 
    
   Binary data is represented by the BYTE (and BYTE[]) data type. 
    
   Binary data MUST be encoded in its entirety using character code 
   references (see Section 4.3.2.2). 
    
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 21] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


4.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 IODEF XML messages, 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. 
    
    
4.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.  Section references in parentheses 
   refer to sections of the ISO 8601:2000 standard. 
    
   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.") 
    
   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.") 
    
   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 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: 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 22] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      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.") 
    
   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.") 
    
   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 
    
   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.") 
    
   5. Date-time strings are created by joing 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  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 23] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      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.") 
    
   In summary, IODEF date-time strings MUST adhere to one of the nine 
   templates identified in Paragraph 5, above. 
    
    
    
4.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". 
    
    
4.4.8 Port Lists 
    
   Port lists 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". 
    
    
4.4.9 Unique Identifiers 
    
   There are <few> types of unique identifiers used in this 
   specification. All types are represented by STRING data types. 
    
   These identifiers are implemented as attributes on the relevant XML 
   elements, and must have unique values as follows: 
    
   1. The Authority class' (Section 5.2.6.8) "OrganizationID" 
   element/attribute, if specified, MUST have a value that is globally 
   unique, however it may be combined by Registry name and unique CSIRT 
   ID in this Registry. Registries are normally maintained by FIRST or 
   industry communities/associations. 
    
   The default value is "unknown", which indicates that the authority 
   or CISRT doesn’t have unique identifiers. 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 24] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   2. The Incident, Attacker, 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 "OrganisationID" 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. 
    
4.4.10 Personal names 
    
   Format for the Personal name data is used the same as in LDAP. It is 
   supposed that normally personal names are obtained from different 
   Directories used by CSIRTs for their daily work. 
    
   Current suggestion for the personal name formats are a follows: 
    
   Name Surname 
    
   Or 
    
   Surname, Name 
    
   It is possible to use personal handle from the official (IP or DNS) 
   databases: RIPE NCC, InterNIC, etc. In this case element’s attribute 
   will indicate type of personal name presentation and indirectly 
   point on used Registry or database. 
    
    
4.4.11 Organisation names 
    
   Organisation name is presented in form of it full name, short name 
   or identification code retrieved from official Registries.  
    
   It is possible to use organisation handle (or organization role from 
   the official (IP or DNS) databases: RIPE NCC, InterNIC, etc. In this 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 25] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   case element’s attribute will indicate type of personal name 
   presentation and indirectly point on used Registry or database. 
    
    
4.4.12 Postal addresses 
    
   Format for the Postal addresses data is used the same as in LDAP. It 
   is supposed that postal addresses are obtained from the Incident 
   reports or from different Directories used by CSIRTs for their daily 
   work. 
    
   Building, Street, Zip-code, City, Country 
    
   Or 
    
   Post Office Box, Zip-code, City, Country 
    
    
4.4.13 Telephone and Fax numbers 
    
   Telephone and Fax numbers are expressed in format recommended by ITU 
   documents. 
    
   + (international code) (local code) (tel. Number) 
    
    
    
5. 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 
   show how the components are related to each other, and relevant 
   sections of the XML DTD are presented to show how the model is 
   translated into XML. 
    
    
5.1 Data Model Overview 
    
   The relationship between the principal components of the data model 
   is shown in Figure 5.1 (occurrence indicators and attributes are 
   omitted). 
    
   The top-level container class for all IODEF descriptions is IODEF-
   Description; each type of description is a subclass of this top-
   level class.  There are presently two types of Descriptions defined: 
   Incident and IncidentAlert. Within each description, subclasses of 
   the IODEF-description class are used to provide the detailed 
   information included into the description.  
    
   Top class in IODEF Description is Incident that actually contains 
   all information related to event that is treated as Incident. 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 26] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   It is important to note that the data model does not specify how an 
   Incident should be classified or identified.  For example, a port 
   scan may be identified by one CSIRT as a single attack against 
   multiple targets, while another CSIRT might identify it as multiple 
   attacks from a single source. However, once creator of the report 
   has determined the type of Incident/attack it plans to report, the 
   data model dictates how that description should be formatted. 
    
    
                  +---------------------+  
                  |  IODEF-Description  |  
                  +---------------------+  
                            /_\  
                             |  
        +--------------------+---------------------+        
        |                                          |              
        |                                  +-------+--------+  
        |                                  | IncidentAlert  |  
        |                                  +----------------+  
        |                                                           
   +----------+   +------------+   +----------------+   +---------+  
   | Incident |<>-|   Attack   |<>-| Source         |<>-| Process |  
   +----------+   +------------+   +----------------+   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| Service |  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| Program |  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| OS      |  
   |          |   |            |   +----------------+   +---------+  
   |          |   |            |   +----------------+   +---------+  
   |          |   |            |<>-| Target         |<>-| Process |  
   |          |   |            |   +----------------+   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| Service |  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| Program |  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |   +---------+  
   |          |   |            |   |                |<>-| OS      |  
   |          |   |            |   +----------------+   +---------+  
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Name           | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| DetectTime     | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| StartTime      | 
   |          |   |            |   +----------------+ 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 27] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |          |   |            |   +----------------+ 
   |          |   |            |<>-| EndTime        | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Description    |  
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Action         | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |<>-| Attacker   |<>-| Node           | 
   |          |   +------------+   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Location       | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| User           | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |<>-| Victim     |<>-| Node           | 
   |          |   +------------+   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Location       | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| User           | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |<>-| Method     |<>-| Classification | 
   |          |   +------------+   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Description    | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |<>-| Evidence   |<>-| EvidenceData   | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |   | Authority  |<>-| Organisation   | 
   |          |   +------------+   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Contact        | 
   |          |   +------------+   +----------------+ 
   |          |   +------------+   +----------------+ 
   |          |<>-| History    |<>-| Reported       | 
   |          |   +------------+   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| Received       | 
   |          |   |            |   +----------------+ 
   |          |   |            |   +----------------+ 
   |          |   |            |<>-| ActionList     | 
   |          |   +------------+   +----------------+ 
   |          |   +----------------+ 
   |          |<>-| AdditionalData | 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 28] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   +----------+   +----------------+ 
    
   Figure 5.1  Data model overview 
    
   Note. Complete IODEF Data Model in graphical form can be found at 
   [18].  
    
    
    
5.2 The IODEF Description Classes 
 

   The individual classes are described in the following sections. 
 
 

5.2.1 The IODEF-Description Class 
 

   All IODEF descriptions are members of the IODEF-Description class; 
   it is the top-level class of the IODEF data model, as well as the 
   IODEF DTD. There are currently two main types (subclasses) of IODEF-
   Description: Incident and IncidentAlert. Another one Experimental 
   class is included temporary for purpose of pilot/experimental 
   implementation and is not defined in details in this document. 
    
   Because DTDs do not support subclassing (see Section 4.3.4), the  
   inheritance relationship between IODEF-Description and the Incident 
   and IncidentAlert subclasses shown in Figure 5.1 has been replaced 
   with an aggregate relationship.  This is declared in the IODEF DTD 
   as follows: 
    
   <!ENTITY % attlist.IODEF                  "  
       version               CDATA                 #FIXED    '0.0'  
     ">  
   <!ELEMENT IODEF-Description                   (  
       (Incident | IncidentAlert | Experimental)*  
     )>  
   <!ATTLIST IODEF-Description  
       %attlist.IODEF;  
     > 
    
   The IODEF-Description class has a single attribute: 
    
   version  
      The version of the IODEF-Description specification (this 
      document) this message conforms to. Applications specifying a 
      value for this attribute MUST specify the value "0.0". 
 
 

5.2.2 The Incident Class 
     
   Generally, every time CSIRT register/open an Incident, it creates an 
   Incident description. Depending on initial data and information 
   source. Incident description may be created of Incident/Attack 
   report made by humans from CSIRT constituency, IDS Alert message or 
   information about already open Incident received from another CSIRT.  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 29] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   An Incident description is composed of several aggregate classes, as 
   shown in Figure 5.2. The aggregate classes themselves are described 
   in Sections 5.2.4.1 - 5.2.4.10. 
    
    
   +-------------------+ 
   | Incident          | 
   +-------------------+ 
   | STRING incidentID |        +----------------+   +-------------+  
   | ENUM purpose      |<>------|   Attack       |<>-| Source      |  
   | ENUM restriction  |        +----------------+   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| Target      |  
   |                   |        |                |   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| Description |  
   |                   |        |                |   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| Action      |  
   |                   |        |                |   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| DetectTime  |  
   |                   |        |                |   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| StartTime   |  
   |                   |        |                |   +-------------+  
   |                   |        |                |   +-------------+  
   |                   |        |                |<>-| EndTime     |  
   |                   |        +----------------+   +-------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| Attacker       |  
   |                   |        +----------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| Victim         |  
   |                   |        +----------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| Method         |  
   |                   |        +----------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| Evidence       |  
   |                   |        +----------------+  
   |                   |        +----------------+  
   |                   |<>------| Authority      |  
   |                   |        +----------------+  
   |                   |   0..1 +----------------+  
   |                   |<>------| History        |  
   |                   |        +----------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| AdditionalData |  
   +-------------------+        +----------------+  
             /_\  
              |  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 30] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


              |             
   +----------+----------+  
   | CorrelationIncident |  
   +---------------------+  
    
   Figure 5.2 The Incident Class 
    
    
   The aggregate classes that constitute Incident are: 
    
   Attack  
      Exactly one. Container for information about security event that 
   lead to registration of Incident.  
    
   Attacker 
      Zero or more.  The identification of system or network entity 
   which the Attack was originated from. 
    
   Victim 
      Zero or more.  The identification of system or network entity 
   which the Attack targeted to. 
    
   Method 
      Zero or more. The container for information about method or 
   activity used by Attacker that lead to Incident. The element may 
   contain free language description the "name" or classification 
   identifier of Vulnerability, Exposure or other weakness of Victim’s 
   system that lead to attempted or successful Attack. Normally, 
   information put into this class by CSIRT’s triage is derived from 
   known registries of Vulnerabilities, Exposures or Exploits, 
   otherwise it can put it’s own definition of the method.  
    
   Evidence 
      Zero or more.  Container for the EvidenceData. 
    
   Authority 
      Exactly one. Information about CSIRT or other authority created 
   Incident object. 
    
   History 
      Zero or one. Contains records of Incident history including 
   reporting time, exchange history and actions taken by CSIRT(s) in 
   course of investigating incident. In case of Evidence custody, this 
   element may contain chain of custody. 
    
   AdditionalData  
      Zero or more.  Information included by CSIRT that does not fit 
   into the data model.  This may be an atomic piece of data, or a 
   large amount of data provided through an extension to the IODEF (see 
   Section 6). 
    
   Because DTDs do not support subclassing (see Section 4.3.4), the 
   inheritance relationship between Incident and the 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 31] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   CorrelationIncident, subclasses shown in Figure 5.2 has been 
   replaced with an aggregate relationship. 
    
   Incident is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.purpose                 "  
       ( unknown | report | handling | communication |  
        statistics | experimental )  
     ">  
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
   <!ELEMENT Incident                           (  
       Attack*, Attacker*, Victim*, Method*, Evidence*,  
       IncidentCorrelation?, Authority, History?, AdditionalData*)> 
   <!ATTLIST Incident 
       incidentID            ID                      #IMPLIED  
       purpose               %attvals.purpose;       'experimental' 
       restriction           %attvals.restriction;   'default' 
     > 
    
   The Incident class has three attributes: 
    
   IncidentID 
      Required. A unique identifier for the Incdent, see Section 4.4.9. 
    
   purpose 
      Optional. Attribute that indicate the purpose of Incident Object 
    
   Rank   Keyword            Description  
   ----   -------            -----------  
     0    unknown           Purpose of Incident object is unknown 
     1    report            Incident report  
     2    handling          Incident in process of handling 
     3    communication     Incident is being sent to another team 
     4    statistics        For statistics purposes 
     5    experimental      Experimental (default for this version of  
                            XML DTD 
    
   restriction 
      Optional. Indicates restriction level that should be applied to 
   Incident class by Incident Handling System. 
    
   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 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 32] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
    
5.2.2.2 The CorrelationIncident Class 
 

   The CorrelationIncident class carries additional information related 
   to the correlation of current Incident with other Incidents (handled 
   by CSIRT - current Incident owner). It is intended to group one or 
   more registered Incident which are investigated together. 
    
   The CorrelationIncident class is composed of three aggregate 
   classes, as shown in Figure 5.3. 
    
    
   +---------------------+  
   | CorrelationIncident |  
   +---------------------+  
   | ENUM restriction    |   0..1 +----------------+ 
   |                     |<>------| IncidentID     | 
   |                     |        +----------------+ 
   |                     |   0..* +----------------+ 
   |                     |<>------| EventList      | 
   |                     |        +----------------+ 
   |                     |   0..* +----------------+ 
   |                     |<>------| EvidenceDataID | 
   +---------------------+        +----------------+ 
    
   Figure 5.3 - The CorrelationIncident Class 
    
    
   The aggregate classes that constitute CorrelationIncident are: 
    
   EventList  
      One or more.  Lists all events which are investigated together, 
   or have another common denominator. 
    
   EvidenceDataID 
      Zero or more.  Evidence data that are linked to current Incident. 
    
   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.  
    
   This is represented in the XML DTD as follows. 
    
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal | restricted )  
     ">  
    
   <!ELEMENT CorrelationIncident                (  
       IncidentID?, EventList*, EvidenceDataID*  
     )>  
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 33] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!ATTLIST CorrelationIncident  
       restriction           %attvals.restriction;   ‘default’ 
     > 
 

   The CorrelationIncident class has one attribute: 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   CorrelationIncident class by Incident Handling System. 
    
   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 
    
5.2.3 IncidentAlert Class 
 

   IncidentAlert Class is used as a container for the IDMEF Alert 
   message in case when IncidentAlert is originated from IDS report. In 
   this case IDMEF Alert message is placed into AdditionalData element. 
    
    
   +-------------------+  
   | IncidentAlert     |  
   +-------------------+  
   | STRING incidentID |        +----------------+  
   | ENUM purpose      |<>------| Authority      |  
   | ENUM restriction  |        +----------------+  
   |                   |   0..1 +----------------+  
   |                   |<>------| History        |  
   |                   |        +----------------+  
   |                   |   0..* +----------------+  
   |                   |<>------| AdditionalData |  
   +-------------------+        +----------------+  
 

   Figure 5.4 The IncidentAlert Class 
    
   The aggregate classes that constitute IncidentAlert are: 
    
   Authority 
      Exactly one. Information about CSIRT or other authority created 
   IncidentAlert object. 
    
   History 
      Zero or one. Contains records of IncidentAlert history including 
   reporting time, exchange history and actions taken by CSIRT(s) in 
   course of investigating incident. In case of Evidence custody, this 
   element may contain chain of custody. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 34] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   AdditionalData  
      Zero or more.  Container for the IDMEF Alert message.  
    
    
   Incident is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.purpose                 "  
       ( unknown | report | handling | communication |  
        statistics | experimental )  
     ">  
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal | restricted )  
     ">  
    
   <!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 4.4.9. 
    
   purpose 
      Optional. Attribute that indicate the purpose of IncidentAlert 
   Object. 
    
   Rank   Keyword            Description  
   ----   -------            -----------  
     0    unknown           Purpose of IncidentAlert object is unknown 
     1    report            Incident report  
     2    handling          Incident in process of handling 
     3    communication     Incident is being sent to another team 
     4    statistics        For statistics purposes 
     5    experimental      Experimental (default for this version of  
                            XML DTD 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   CorrelationIncident class by Incident Handling System. 
    
   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) 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 35] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


                             internal use 
     3    restricted         Use strictly for Incident managers at 
                             CSIRT 
    
    
5.2.4 The Core Classes 
    
   The core classes - Attack, Source, Target, Attacker, Victim, Method, 
   Evidence, Authority, History, and AdditionalData - are the main 
   parts of Incident and IncidentAlert classes, as shown in Figure 5.5. 
    
   NOTE. IODEF re-uses Source and Target core classes from IDMEF [3].  
    
    
   +---------------+             +----------+     0..* +-------------+ 
   | Incident      |             | Attack   |   +------| Source      | 
   +---------------+             +----------+   |      +-------------+ 
   |               |             |          |   | 0..* +-------------+ 
   |               |<>----+------|          |<>-+------| Target      | 
   |               |      |      |          |   |      +-------------+ 
   |               |      |      +----------+   | 0..* +-------------+ 
   |               |      |                     +------| Description | 
   |               |<>-+  |                     |      +-------------+ 
   |               |   |  | 0..* +----------+   | 0..* +-------------+ 
   |               |   |  +------| Attacker |   +------| Action      | 
   +---------------+   |  |      +----------+   |      +-------------+ 
                       |  | 0..* +----------+   | 0..1 +-------------+ 
                       |  +------| Victim   |   +------| DetectTime  | 
                       |  |      +----------+   |      +-------------+ 
                       |  | 0..* +----------+   | 0..1 +-------------+ 
                       |  +------| Method   |   +------| StartTime   | 
                       |  |      +----------+   |      +-------------+ 
                       |  | 0..* +----------+   | 0..1 +-------------+ 
                       |  +------| Evidence |   +------| EndTime     | 
                       |         +----------+          +-------------+ 
   +---------------+   |                              
   | IncidentAlert |   |                              
   +---------------+   |          +----------------+  
   |               |<>-+----------| Authority      |  
   |               |   |          +----------------+  
   +---------------+   |     0..1 +----------------+  
                       +----------| History        |  
                       |          +----------------+  
                       |     0..* +----------------+  
                       +----------| AdditionalData |  
                                  +----------------+  
    
   Figure 5.5  The IODEF Core Classes 
    
 
 

5.2.2.1 The Attack Class 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 36] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The Attack class contains information about security event that was 
   evaluated as incident.  
    
   +------------------+   0..* +---------------+   +---------+  
   |   Attack         |<>------| Source        |<>-| process |  
   +------------------+        +---------------+   +---------+  
   | STRING ident     |        |               |   +---------+  
   | ENUM impact      |        |               |<>-| service |  
   | ENUM restriction |        |               |   +---------+  
   |                  |        |               |   +---------+  
   |                  |        |               |<>-| program |  
   |                  |        |               |   +---------+  
   |                  |        |               |   +---------+  
   |                  |        |               |<>-| OS      |  
   |                  |        +---------------+   +---------+  
   |                  |   0..* +---------------+   +---------+  
   |                  |<>------| Target        |<>-| process |  
   |                  |        +---------------+   +---------+  
   |                  |        |               |   +---------+  
   |                  |        |               |<>-| service |  
   |                  |        |               |   +---------+  
   |                  |        |               |   +---------+  
   |                  |        |               |<>-| program |  
   |                  |        |               |   +---------+  
   |                  |        |               |   +---------+  
   |                  |        |               |<>-| OS      |  
   |                  |        +---------------+   +---------+  
   |                  |   0..* +---------------+ 
   |                  |<>------| Description   | 
   |                  |        +---------------+ 
   |                  |   0..* +---------------+ 
   |                  |<>------| Action        | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| DetectTime    | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| StartTime     | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| EndTime       | 
   +------------------+        +---------------+ 
    
   Figure 5.6  The Attack Class 
    
    
   The aggregate classes that constitute Attack are: 
    
    
   Source  
      Zero or more.  The source(s) of the event(s) leading up to the 
   Incident. 
     

 
TERENA ITDWG    Informational - Expires January 2002      [Page 37] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   Target  
      Zero or more.  The target(s) of the event(s) leading up to the 
   Incident. 
    
   Description  
      Zero or more.  Free description of attack by CSIRT or reporter. 
   It may also contain the name of Attack given according to existing 
   well-known or documented and used by CSIRT classification of typical 
   Attacks, e.g. DDoS, Trojan horse, etc. 
    
   Action 
      Zero or more.  Action taken by CSIRT in course of Incident.  
    
   DetectTime  
      Zero or one.  The time of the event(s) leading up to Incident 
   registration. In the case of more than one event, the time the first 
   event was detected. In some circumstances, this may not be the same 
   value as RegistrationTime used in the History Class. 
    
   StartTime  
      Zero or one.  The time which is considered as start time of the 
   Attack that lead to Incident registration.  
    
   EndTime  
      Zero or one.  The time which is considered as end time of the 
   Attack that lead to Incident registration.  
    
    
   Attack is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.impact " 
       ( unknown | bad-unknown | not-suspicious | attempted-admin | 
         successful-admin | attempted-dos | successful-dos | 
         attempted-recon | successful-recon-limited | 
         successful-recon-largescale | attempted-user | 
         successful-user ) 
     "> 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
         restricted )  
     ">  
    
   <!ELEMENT Attack                         ( 
       Source*, Target*, Description*, Action*,  
       DetectTime?, StartTime?, EndTime?)> 
    
   <!ATTLIST Attack 
       %attlist.global;  
       restriction           %attvals.restriction;   ‘default’ 
       impact                %attvals.impact;        'unknown'  
       ident                 CDATA                 #IMPLIED 
     > 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 38] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   The Attack class has attributes: 
    
   ident 
      Optional. A unique identifier for the attack, see Section 4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should be applied to 
   the Attack class by Incident Handling System. 
    
   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 
    
   impact  
      Optional.  The evaluated impact of the event(s) leading up to the 
   Incident on the target. The permitted values for this attribute are 
   shown below. The default value is "unknown". 
    
   Rank   Keyword            Description  
   ----   -------            -----------  
     0    unknown            Event's impact is unknown or cannot be  
                             determined  
     1    bad-unknown        Event's impact is unknown or cannot be  
                             determined, but is usually undesirable  
     2    not-suspicious     Event is not suspicious in any way  
     3    attempted-admin    Attempt to obtain administrator (super-  
                             user) privileges  
     4    successful-admin   Successful compromise of administrator  
                             privileges  
     5    attempted-dos      Attempted denial of service  
     6    successful-dos     Successful denial of service  
     7    attempted-recon    Attempted reconnaissance probe  
     8    successful-recon-  Successful reconnaissance probe; limited  
          limited            scope (e.g., one target)  
     9    successful-recon-  Successful reconnaissance probe; large  
          largescale         scope (e.g., many targets)  
    10    attempted-user     Attempt to obtain user-level privileges  
    11    successful-user    Successful compromise of user-level  
                             privileges 
    
    
 

5.2.4.2 The Source Class 
 

   The Source class contains information about the possible source(s) 
   of the event(s) that are treated as an attack. An event may have 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 39] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   more than one source (e.g., in a distributed denial of service 
   attack). 
    
   For the purpose of compatibility, the Source class may be completely 
   re-used from IDMEF. When produced from IDMEF Message, the Source 
   class (or element) can be completely included into IODEF Description 
   with the same names/semantics or decomposed between two IODEF 
   classes/elements Source and Attack which one may include Node and 
   User elements. Two additional elements may be added to the Source 
   class for Attack description in IODEF: os describing Operation 
   System used by attacked Node, and program that believed to launch 
   the Attack.  
    
   The Source class is composed of four aggregate classes, as shown in  
   Figure 5.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 5.7  The Source Class 
    
    
   The aggregate classes that constitute Source are: 
    
   Node  
      Zero or one.  Information about the host or device that is 
   causing the events (network address, network name, etc.). 
    
   User  
      Zero or one.  Information about the user that is causing the 
   event(s). 
    
   Process  


 
TERENA ITDWG    Informational - Expires January 2002      [Page 40] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      Zero or one.  Information about the process that is causing the 
   event(s). 
    
   Service  
      Zero or one.  Information about the network service involved in 
   the event(s). 
    
   os  
      Zero or one.  Operation system at the Node from which Attack was 
   originated. 
    
   program  
      Zero or one.  Program that believed to launch the Attack(s). 
    
    
   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, see Section 
   4.4.9. 
    
   spoofed  
      Optional.  An indication of whether the source is, as far as the 
   analyzer can determine, a decoy.  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.  May be used by a network-based analyzer with multiple 
   interfaces to indicate which interface this source was seen on. 
    
    
5.2.4.3 The Target Class 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 41] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The Target class contains information about the possible target(s) 
   of the event(s) that are treated as an attack.  An event may have 
   more than one target (e.g., in the case of a port sweep). 
    
   For the purpose of compatibility, the Target class may be completely 
   re-used from IDMEF. When produced from IDMEF Message, the Target 
   class (or element) can be completely included into IODEF Description 
   with the same names/semantics or decomposed between two IODEF 
   classes/elements Target and Victim which one may include Node and 
   User elements. Two additional elements may be added to the Target 
   class for Attack description in IODEF: "the os" describing Operation 
   System used by targeted Node, and "the program" that was or became 
   (due to vulnerability or fault) suggested target of the Attack.  
    
    
   The Target class is composed of four aggregate classes, as shown in 
   Figure 5.8. 
    
    
   +------------------+  
   |      Target      |  
   +------------------+       0..1 +---------+  
   | STRING ident     |<>----------|  Node   |  
   | ENUM decoy       |            +---------+  
   | STRING interface |       0..1 +---------+  
   |                  |<>----------|  User   |  
   |                  |            +---------+  
   |                  |       0..1 +---------+  
   |                  |<>----------| Process |  
   |                  |            +---------+  
   |                  |       0..1 +---------+  
   |                  |<>----------| Service |  
   |                  |            +---------+  
   |                  |       0..1 +---------+  
   |                  |<>----------| os      |  
   |                  |            +---------+  
   |                  |       0..1 +---------+  
   |                  |<>----------| Program |  
   |                  |            +---------+  
   +------------------+ 
    
   Figure 5.8  The Target Class 
    
   The aggregate classes that constitute Target are: 
    
   Node  
      Zero or one.  Information about the host or device that is 
   receiving the events (network address, network name, etc.). 
    
   User  
      Zero or one.  Information about the user that is receiving the 
   event(s). 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 42] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   Process  
      Zero or one.  Information about the process that is receiving the 
   event(s). 
    
   Service  
      Zero or one.  Information about the network service involved in 
   the event(s). 
    
   os  
      Zero or one.  Operation system at targeted Node. 
    
   program  
      Zero or one.  Program that was attacked/defeated in current 
   Attack(s). 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.yesno                  "  
       ( unknown | yes | no )  
     ">  
   <!ELEMENT Target                          (  
       Node?, User?, Process?, Service?, os?, program?  
     )>  
   <!ATTLIST Target  
       ident                 CDATA                   '0'  
       decoy                 %attvals.yesno;         'unknown'  
       interface             CDATA                   #IMPLIED  
     > 
    
   The Target class has three attributes: 
    
   ident  
      Optional.  A unique identifier for this target, see Section 
   4.4.9. 
    
   decoy  
      Optional.  An indication of whether the target is, as far as the 
   analyzer can determine, a decoy.  The permitted values for this 
   attribute 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 a decoy  
     2    no                 Target is believed to be "real" 
    
   interface  
      Optional.  May be used by a network-based analyzer with multiple 
   interfaces to indicate which interface this target was seen on. 
    
    
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 43] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


5.2.4.4 The Method Class 
     
   The Method class provides information about method used by Attacker 
   to perform Attack. Method is used as container for two classes: 
   Classification class that may contain name of Vulnerability, 
   Exposure or Virus according to well-known classification or 
   Registry, and Description provided by CSIRT or Incident owner. The 
   Classification class is re-used from IDMEF. 
    
   The Method class is composed of two aggregate classes, as shown in 
   Figure 5.9. 
    
    
   +------------------+  
   | Method           |  
   +------------------+  
   | STRING ident     |   0..* +----------------+ 
   | ENUM restriction |<>------| Classification |  
   |                  |        +----------------+ 
   |                  |   0..* +----------------+ 
   |                  |<>------| Description    | 
   +------------------+        +----------------+ 
    
   Figure 5.9  The Method Class 
    
    
   The aggregate classes that constitute Method are: 
    
   Classification  
      Zero or more.  STRING.  The name of the alert, from one of the 
   origins listed below. 
    
   Description  
      Zero or more.  Free description of attack by CSIRT or reporter, 
   it may use natural language. 
    
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
    
   <!ELEMENT Method                             (  
       Classification*, Description*)> 
   <!ATTLIST Method 
       IncidentID            ID                      #IMPLIED  
       purpose               %attvals.purpose;       'unknown' 
       restriction           %attvals.restriction;   ‘default’ 
     > 
    
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 44] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The Method class has attributes: 
    
   ident 
      Optional. A unique identifier for the element, see Section 4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   Method class by Incident Handling System. 
    
   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 
    
    
5.2.4.5 The Attacker Class 
    
   The Attacker class contains information about node, location, user 
   associated with Attack. It may contain reference information to 
   CSIRT or Network Security manager serving network from where the 
   Attack was originated, this one is provided in form of IRTcontact 
   handle from public registry, e.g. RIPE NCC database [18] or Trusted 
   Introducer database [19]. 
    
   +------------------+  
   | Attacker         |  
   +------------------+  
   | STRING ident     |   0..* +---------------+ 
   | ENUM restriction |<>------| Node          | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| Location      | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| IRTcontact    | 
   |                  |        +---------------+ 
   |                  |   0..* +---------------+ 
   |                  |<>------| User          | 
   +------------------+        +---------------+ 
    
   Figure 5.10  The Attacker Class 
    
   The aggregate classes that constitute Attacker are: 
    
   Node  
      Zero or more. Node from which Attack was originated. 
    
   Location 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 45] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      Zero or one. Location of Attacker’s node or system. This is a 
   general definition of location that may depend on network structure 
   or company’s geographical distribution. 
    
   IRTcontact 
      Zero or one. Provides place for entering IRTcontact handle that 
   references contact information for the CSIRT or Network Security 
   manager serving the network from which Attack was originated. 
    
   User 
      Zero or more.  User of system that associated with Attack 
   origination. User is used mostly as a container for UserID class. 
    
   Attacker is represented in the XML DTD as follows: 
    
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
    
   <!ELEMENT Attacker                           (  
       Node*, Location?, IRTcontact?, User*)> 
   <!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 
      Optional. Indicates restriction level that should applied to 
   element’s date by Incident Handling System. 
    
   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 
    
    
5.2.4.6 The Victim Class 
    
   The Victim class contains information about node, location, user 
   suffered from the Attack. It may contain reference information to 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 46] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   CSIRT or Network Security manager serving network where the Victim 
   is located, this one is provided in form of IRTcontact handle from 
   public registry, e.g. RIPE NCC database [18] or Trusted Introducer 
   database [19]. 
    
    
   +------------------+  
   | Victim           |  
   +------------------+  
   | STRING ident     |   0..* +---------------+ 
   | ENUM restriction |<>------| node          | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| location      | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| IRTcontact    | 
   |                  |        +---------------+ 
   |                  |   0..* +---------------+ 
   |                  |<>------| user          | 
   +------------------+        +---------------+ 
    
   Figure 5.11 The Victim Class 
    
   The aggregate classes that constitute Victim are: 
    
   Node  
      Zero or more.  Node of the Victim suffered from the Attack. 
    
   Location 
      Zero or one.  Location of Victim’s node or system. This is a 
   general definition of location that may depend on network structure 
   or company’s geographical distribution. 
    
   IRTcontact 
      Zero or one. Provides place for entering IRTcontact handle that 
   references contact information for the CSIRT or Network Security 
   manager serving the network from which Attack was originated. 
    
   User 
      Zero or more.  User of system suffered from Attack. User is used 
   mostly as a container for UserID class. 
    
    
   Victim is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
   <!ELEMENT Victim                           (  
       Node*, Location?, IRTconact?, User*)> 
   <!ATTLIST Victim 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 47] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


       ident                 ID                      #IMPLIED  
       restriction           %attvals.restriction;   ‘default’ 
     > 
    
   The Victim class has two attributes: 
    
   ident 
      Optional. A unique identifier for the Victim element, see Section 
   4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   element’s data by Incident Handling System. 
    
   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 
    
    
5.2.4.7 The Evidence Class 
    
   The Evidence class contains evidence information related to current 
   Incident and may consist of multiple "pieces" of Evidence data of 
   different kind, including textual information (logfiles, malicious 
   scripts, list of changes in file system, etc.) and binary (disc 
   images, etc.). 
    
   +------------------+  
   | Evidence         |  
   +------------------+  
   | STRING ident     |   0..* +---------------+ 
   | ENUM restriction |<>------| EvidenceData  | 
   +------------------+        +---------------+ 
    
   Figure 5.12  The Evidence Class 
    
   The aggregate classes that constitute Evidence are: 
    
   EvidenceData  
      Zero or more.  Container for Evidence data related to current 
   Incident. 
    
   Evidence is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 48] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     ">  
   <!ELEMENT Evidence                           (  
       EvidenceData*)> 
   <!ATTLIST Evidence 
       ident                 ID                      #IMPLIED  
       restriction           %attvals.restriction;   ‘default’ 
     > 
    
   The Evidence class has two attributes: 
    
   ident 
      Optional. A unique identifier for the Evidence element, see 
   Section 4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should be applied to 
   element’s data by Incident Handling System. 
    
   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 
    
    
5.2.4.8 The Authority Class 
    
   The Authority Class describes the owner of the Incident object. It 
   contains information about organization and/or contact person 
   created and processed current Incident report. Authority is one of 
   mandatory classes comprising IODEF-Description.  
    
   +------------------+  
   | Authority        |  
   +------------------+  
   | STRING ident     |        +---------------+ 
   |                  |<>------| Organisation  | 
   |                  |        +---------------+ 
   |                  |   0..1 +---------------+ 
   |                  |<>------| Contact       | 
   +------------------+        +---------------+ 
    
   Figure 5.13 The Authority Class 
    
   The aggregate classes that constitute Authority are: 
    
   Organisation  
      Exactly one.  Name or organization owning and handling current 
   incident. 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 49] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   Contact 
      Zero or one.  Contact information for the person or role account 
   representing CSIRT handling current Incident. 
    
    
   Authority is represented in the XML DTD as follows: 
    
   <!ELEMENT Authority                      (  
       Organisation, Contact? )> 
   <!ATTLIST Authority 
       ident                 ID                      #IMPLIED  
     > 
    
   The Authority class has two attributes: 
    
   ident 
      Optional. A unique identifier for the Authority element, see 
   Section 4.4.9. 
    
    
5.2.4.9 The History Class 
    
   History class contains information how and in what sequence current 
   Incident was handled, including: by whom it was reported, from whom 
   and when it was received, and what actions were taken by responsible 
   CSIRT(s) in cause of Incident. 
    
   +------------------+  
   | History          |  
   +------------------+  
   | STRING ident     |   0..1 +---------------+ 
   | ENUM restriction |<>------| Reported      | 
   |                  |        +---------------+ 
   |                  |   0..* +---------------+ 
   |                  |<>------| Received      | 
   |                  |        +---------------+ 
   |                  |   0..* +---------------+ 
   |                  |<>------| ActionList    | 
   +------------------+        +---------------+ 
    
   Figure 5.14  The History Class 
    
    
   The aggregate classes that constitute History are: 
    
   Reported  
      Zero or one.  Information about who and when reported current 
   Incident. 
    
   Received 



 
TERENA ITDWG    Informational - Expires January 2002      [Page 50] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      Zero or more.  Lists all communications that happened during 
   Incident handling in form from whom and when current Incident was 
   received. Multiple Received elements are allowed. 
    
   ActionList 
      Zero or more.  Lists all actions that were taken in course of 
   Incident handling. 
    
   History is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
   <!ELEMENT History                         (  
       Reported?, Received*, ActionList* )> 
   <!ATTLIST History 
       ident                 ID                      #IMPLIED  
       restriction           %attvals.restriction;   ‘default’ 
     > 
    
   The History class has two attributes: 
    
   ident 
      Optional. A unique identifier for the History element, see 
   Section 4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   element’s data by Incident Handling System. 
    
   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 
    
    
5.2.4.10 The AdditionalData Class 
    
   The AdditionalData class is used to provide information that cannot 
   be represented by the data model.  AdditionalData can be used to 
   provide atomic data (integers, strings, etc.) in cases where only 
   small amounts of additional information needed to be sent; it can 
   also be used to extend the data model and the DTD to support 
   proprietary IODEF extensions by CSIRT, for encapsulation of external 
   XML document such as IDMEF message. Detailed instructions for 
   extending the data model and the DTD are provided in Section 6. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 51] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The AdditionalData element is declared in 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 class has two attributes: 
    
   type  
      Required.  The type of data included in the element content. The 
   permitted values for this attribute are shown below.  The default 
   value is "string". 
    
   Rank   Keyword            Description  
   ----   -------            -----------  
     0    boolean            The element contains a boolean value,  
                             i.e., the strings "true" or "false"  
     1    byte               The element content is a single 8-bit  
                             byte (see Section 4.4.4)  
     2    character          The element content is a single  
                             character (see Section 4.4.3)  
     3    date-time          The element content is a date-time  
                             string (see Section 4.4.6)  
     4    integer            The element content is an integer (see  
                             Section 4.4.1)  
     5    ntpstamp           The element content is an NTP timestamp  
                             (see Section 4.4.7)  
     6    portlist           The element content is a list of ports  
                             (see Section 4.4.8)  
     7    real               The element content is a real number  
                             (see Section 4.4.2)  
     8    string             The element content is a string (see  
                             Section 4.4.3)  
     9    xml                The element content is XML-tagged data  
                             (see Section 6.2) 
    
   local  
      Optional.  A string describing the meaning of the element content 
   if used by CSIRT for purpose not described in this document. These 
   values will be vendor/implementation dependent; the method for 
   ensuring that managers understand the strings used by CSIRT/IHS is 
   outside the scope of this specification. 
    
    
   5.2.5 The Time Classes 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 52] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The data model provides four classes for representing time. Three 
   classes DetectTime, StartTime, EndTime are aggregates of the Attack 
   classes. Supportive DateTime class is used for marking up date and 
   time information in aggregate classes EventList, ActionList 
   Reported, and Received. 
    
   Definition of the Time classes in this document are given in the 
   same format as in IDMEF to ensure compatibility. 
    
    
5.2.5.1 The DetectTime Class 
    
   The time of the event(s) leading up to Incident registration. In the 
   case of more than one event, the time the first event was detected. 
   In some circumstances, this may not be the same value as 
   RegistrationTime used in the History Class. 
    
   It is represented in the XML DTD as follows: 
    
   <!ELEMENT DetectTime            (#PCDATA) >  
   <!ATTLIST DetectTime  
       ntpstamp              CDATA                   #REQUIRED  
     > 
     
   The DATETIME format of the <DetectTime> element content is described 
   in Section 4.4.6. 
    
   The DetectTime class has one attribute: 
    
   ntpstamp  
      Required.  The NTP timestamp representing the same date and time 
   as the element content.  The NTPSTAMP format of this attribute's 
   value is described in Section 4.4.7. 
    
   If the date and time represented by the element content and the NTP 
   timestamp differ (should "never" happen), the value in the NTP 
   timestamp MUST be used. 
    
    
5.2.5.2 The StartTime Class 
    
   The time which is considered as start time of the Attack that lead 
   to Incident registration.  
    
   It is represented in the XML DTD as follows: 
    
   <!ELEMENT StartTime            (#PCDATA) >  
    
   The DATETIME format of the <StartTime> element content is described 
   in Section 4.4.6. 
    
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 53] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


5.2.5.3 The EndTime Class 
    
   The time which is considered as end time of the Attack that lead to 
   Incident registration.  
    
   It is represented in the XML DTD as follows: 
    
   <!ELEMENT EndTime            (#PCDATA) >  
    
   The DATETIME format of the <StartTime> element content is described 
   in Section 4.4.6. 
    
    
5.2.5.4 The DateTime Class 
    
   The supportive class to mark up date and time information in 
   aggregate classes EventList, ActionList Reported, and Received. 
    
   It is represented in the XML DTD as follows: 
    
   <!ELEMENT DateTime            (#PCDATA) >  
    
   The DATETIME format of the <DateTime> element content is described 
   in Section 4.4.6. 
    
    
5.2.6 The Support Classes 
    
   The support classes constitute the major parts of the core classes, 
   and are shared between them. 
    
   IODEF re-uses following support classes from IDMEF: Node, Address, 
   User, UserId, Process, Service – as compound classes for the Source 
   and Target classes or for the Attacker and Victim classes; 
   WebService, SMTPService – as used in Service class; Classification – 
   as component of the Method class. 
    
    
5.2.6.1 The Node Class 
    
   The Node class is used to identify hosts and other network devices 
   (routers, switches, etc.). 
    
   The Node class is composed of three aggregate classes, as shown in 
   Figure 5.15. 
    
   +---------------+  
   |     Node      |  
   +---------------+       0..1 +----------+  
   | STRING ident  |<>----------| location |  
   | ENUM category |            +----------+  
   |               |       0..1 +----------+  
   |               |<>----------|   name   |  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 54] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |               |            +----------+  
   |               |       0..* +----------+  
   |               |<>----------|  Address |  
   |               |            +----------+  
   +---------------+          
    
   Figure 5.15  The Node Class 
    
   The aggregate classes that constitute Node are: 
    
   location  
      Zero or one.  STRING.  The 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. 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.nodecat                "  
       ( unknown | ads | afs | coda | dfs | dns | kerberos | nds |  
         nis | nisplus | nt | wfw )  
     ">  
   <!ELEMENT Node                            (  
       location?, (name | Address), Address*  
     )>  
   <!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 4.4.9. 
    
   category  
      Optional.  The "domain" to which the name information belongs, 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)  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 55] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     5    dns                Domain Name System  
     6    kerberos           Kerberos realm  
     7    nds                Novell Directory Services  
     8    nis                Network Information Services (Sun)  
     9    nisplus            Network Information Services Plus (Sun)  
    10    nt                 Windows NT domain  
    11    wfw                Windows for Workgroups 
    
    
5.2.6.1.1 The Address Class 
    
   The Address class is used to represent network, hardware, and 
   application addresses. 
    
   The Address class is composed of two aggregate classes, as shown in 
   Figure 5.16. 
    
    
   +------------------+  
   |     Address      |  
   +------------------+            +---------+  
   | STRING ident     |<>----------| address |  
   | ENUM category    |            +---------+  
   | STRING vlan-name |       0..1 +---------+  
   | INTEGER vlan-num |<>----------| netmask |  
   |                  |            +---------+  
   +------------------+ 
    
         Figure 5.16  The Address Class 
    
   The aggregate classes that constitute Address are: 
    
   address  
      Exactly one.  STRING.  The address information.  The format of 
   this data 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                 ID                      #IMPLIED  
          category              %attvals.addrcat;       'unknown'  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 56] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


          vlan-name             CDATA                   #IMPLIED  
          vlan-num              CDATA                   #IMPLIED  
        > 
    
   The Address class has four attributes: 
    
   ident  
      Optional.  A unique identifier for the address, see Section 
   4.4.9. 
    
   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. 
    
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 57] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


5.2.6.2 The User Class 
    
   The User class is used to describe users.  It is primarily used as a 
   “container" class for the UserId aggregate class, as shown in Figure 
   5.17. 
    
   +---------------+  
   |     User      |  
   +---------------+       1..* +--------+  
   | STRING ident  |<>----------| UserId |  
   | ENUM category |            +--------+  
   +---------------+ 
    
   Figure 5.17  The User Class 
    
   The aggregate class contained in User is: 
    
   UserId  
      One or more.  Identification of a user, as indicated by its type 
   attribute (see Section 5.2.6.2.1). 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.usercat                "  
       ( unknown | application | os-device )  
     ">  
   <!ELEMENT User                            (  
       UserId+  
     )>  
   <!ATTLIST User  
       ident                 ID                      #IMPLIED  
       category              %attvals.usercat;       'unknown'  
     > 
    
   The User class has two attributes: 
    
   ident  
      Optional.  A unique identifier for the user, see Section 4.4.9. 
    
   category  
      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 
    
    
5.2.6.2.1 The UserId Class 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 58] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The UserId class provides specific information about a user.  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. 
    
   The UserId class is composed of two aggregate classes, as shown in 
   Figure 5.18. 
    
   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. 
    
    
    
   +--------------+  
   |    UserId    |  
   +--------------+       0..1 +--------+  
   | STRING ident |<>----------|  name  |  
   | ENUM type    |            +--------+  
   |              |       0..1 +--------+  
   |              |<>----------| number |  
   |              |            +--------+  
   +--------------+ 
    
     Figure 5.18  The UserId Class 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.idtype                 "  
       ( current-user | original-user | target-user | user-privs |  
         current-group | group-privs )  
     ">  
   <!ELEMENT UserId                          (  
       name | number | (name, number)  
     )>  
   <!ATTLIST UserID  
       ident                 ID                      #IMPLIED  
       type                  %attvals.idtype;        'original-user'  
     > 
    
   The UserId class has two attributes: 
    
   ident  
      Optional.  A unique identifier for the user id, see Section 
   4.4.9. 
    
   type  



 
TERENA ITDWG    Informational - Expires January 2002      [Page 59] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      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, in general.  
     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.  This would apply,  
                             on Unix systems for example, 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, in general.  
     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 systems,  
                             multiple UserId elements of this type  
                             would be used to include all the group  
                             ids on the "group list." 
    
    
5.2.6.3 The Process Class 
    
   The Process class is used to describe processes being executed on 
   sources, targets, and analysers. 
    
   The Process class is composed of five aggregate classes, as shown in 
   Figure 5.19. 
    
   +--------------+  
   |    Process   |  
   +--------------+            +------+  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 60] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   | STRING ident |<>----------| name |  
   |              |            +------+  
   |              |       0..1 +------+  
   |              |<>----------| pid  |  
   |              |            +------+  
   |              |       0..1 +------+  
   |              |<>----------| path |  
   |              |            +------+  
   |              |       0..* +------+  
   |              |<>----------| arg  |  
   |              |            +------+  
   |              |       0..* +------+  
   |              |<>----------| env  |  
   |              |            +------+  
   +--------------+ 
    
   Figure 5.19  The Process Class 
    
   The aggregate classes that constitute Process are:  
   name  
      Exactly one.  STRING.  The name of the program being executed. 
   This is a short name; path and argument information are provided 
   elsewhere. 
    
   pid  
      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 be specified (they are assumed to have 
   occurred in the same order they are provided) with multiple uses of 
   arg. 
    
   env  
      Zero or more.  STRING.  An environment string associated with the 
   process; generally of the format "VARIABLE=value".  Multiple 
   environment strings may be specified with multiple uses of env. 
    
   This is represented in the XML DTD as follows: 
    
   <!ELEMENT Process                         (  
       name, pid?, path?, arg*, env*  
     )>  
   <!ATTLIST Process  
       ident                 ID                      #IMPLIED  
     > 
    
   The Process class has one attribute: 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 61] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   ident  
      Optional.  A unique identifier for the process, see Section 
   4.4.9. 
    
    
5.2.6.4 The Service Class 
    
   The Service class describes network services on sources and targets. 
   It can identify services by name, port, and protocol.  When Service 
   occurs as 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 the Node, Process, and User 
   information also contained in Source.  Likewise, when Service occurs 
   as an aggregate class of Target, it is understood that the service 
   is one to which activity of interest is being directed; and that the 
   service is "attached" to the Node, Process, and User information 
   also contained in Target. 
    
   The Service class is composed of four aggregate classes, as shown in 
   Figure 5.20. 
    
   +--------------+  
   |   Service    |  
   +--------------+       0..1 +----------+  
   | STRING ident |<>----------|   name   |  
   |              |            +----------+  
   |              |       0..1 +----------+  
   |              |<>----------|   port   |  
   |              |            +----------+  
   |              |       0..1 +----------+  
   |              |<>----------| portlist |  
   |              |            +----------+  
   |              |       0..1 +----------+  
   |              |<>----------| protocol |  
   |              |            +----------+  
   +--------------+  
          /_\  
           |  
           +------------+  
                        |  
       +-------------+  |  +-------------+  
       | SNMPService |--+--| WebService  |  
       +-------------+     +-------------+ 
    
        Figure 5.20 - The Service Class 
    
   The aggregate classes that constitute Service are: 
    
   name  
      Zero or one.  STRING.  The name of the service.  Whenever 
   possible, the name from the IANA list of well-known ports SHOULD be 
   used. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 62] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   port  
      Zero or one.  INTEGER.  The port number being used. 
    
   portlist  
      Zero or one.  PORTLIST.  A list of port numbers being used; see    
   Section 4.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 and a port, or (d) a portlist.  The protocol is optional 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 and the SNMPService and 
   WebService subclasses shown in Figure 5.17 has been replaced with an 
   aggregate relationship. Service is represented in the XML DTD as 
   follows: 
    
   <!ELEMENT Service                         (  
       ((name | port | (name, port)) | portlist), protocol?,  
       SNMPService?, WebService?  
     )>  
   <!ATTLIST Service  
       ident                 ID                      #IMPLIED  
     > 
    
   The Service class has one attribute: 
    
   ident  
      Optional.  A unique identifier for the service, see Section 
   4.4.9. 
    
    
5.2.6.4.1 The WebService Class 
    
   The WebService class carries additional information related to web 
   traffic. 
    
   The WebService class is composed of four aggregate classes, as shown 
   in Figure 5.21. 
    
   +-------------+  
   |   Service   |  
   +-------------+  
         /_\  
          |  
   +-------------+  
   | WebService  |  
   +-------------+            +------------+  
   |             |<>----------|  url       |  
   |             |            +------------+  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 63] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |             |       0..1 +------------+  
   |             |<>----------|  cgi       |  
   |             |            +------------+  
   |             |       0..1 +------------+  
   |             |<>----------| httpmethod |  
   |             |            +------------+  
   |             |       0..* +------------+  
   |             |<>----------|  arg       |  
   |             |            +------------+  
   +-------------+ 
    
    Figure 5.21 - The WebService Class 
    
   The aggregate classes that constitute WebService are: 
    
   url  
      Exactly one.  STRING.  The URL in the request. 
    
   cgi  
      Zero or one.  STRING.  The CGI script in the request, without 
   arguments. 
     
   httpmethod  
      Zero or one.  STRING.  The HTTP method (PUT, GET) used in the 
   request. 
    
   arg  
      Zero or more.  STRING.  The arguments to the CGI script. 
    
   This is represented in the XML DTD as follows: 
    
   <!ELEMENT WebService                      (  
       url, cgi?, method?, arg*  
     )> 
    
    
5.2.6.4.2 The SNMPService Class 
    
   The SNMPService class carries additional information related to SNMP 
   traffic. 
    
   The SNMPService class is composed of three aggregate classes, as 
   shown in Figure 5.22. 
    
   +-------------+  
   |   Service   |  
   +-------------+  
         /_\  
          |  
   +-------------+  
   | SNMPService |  
   +-------------+       0..1 +-----------+  
   |             |<>----------|    oid    |  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 64] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |             |            +-----------+  
   |             |       0..1 +-----------+  
   |             |<>----------| community |  
   |             |            +-----------+  
   |             |       0..1 +-----------+  
   |             |<>----------|  command  |  
   |             |            +-----------+  
   +-------------+ 
    
   Figure 5.22 - The SNMPService Class 
    
   The aggregate classes that constitute SNMPService are: 
    
   oid  
      Zero or one.  STRING.  The object identifier in the request. 
    
   community  
      Zero or one.  STRING.  The object's community string. 
    
   command  
      Zero or one.  STRING.  The command sent to the SNMP server (GET, 
   SET.  etc.). 
    
   This is represented in the XML DTD as follows: 
    
   <!ELEMENT SNMPService                     (  
       oid?, community?, command?  
     )> 
    
    
5.2.6.5  The Classification Class 
    
   The Classification class provides the "name" of an alert, or other 
   information allowing the manager to determine what it is (for 
   example, to decide whether or not to display the alert on-screen, 
   what color to display it in, etc.). 
    
   The Classification class is composed of two aggregate classes, as 
   shown in Figure 5.23. 
    
   +----------------+ 
   | Classification | 
   +----------------+        +---------+ 
   | STRING origin  |<>------| name    | 
   |                |        +---------+ 
   |                |        +---------+ 
   |                |<>------| url     | 
   |                |        +---------+ 
   +----------------+ 
    
   Figure 5.23  The Classification Class 
    
   The aggregate classes that constitute Classification are: 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 65] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   name 
      Exactly one.  STRING.  The name of the Vulnerability, Exposure or 
   Virus (from one of the origins listed below) used by Attacker to 
   cause Incident. 
    
   url 
      Exactly one.  STRING.  A URL at which the manager can find 
   additional information about classified method. The URL may include 
   an in-depth description of the attack, appropriate countermeasures, 
   or other information deemed relevant 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' 
     > 
    
   The Classification class has one attribute: 
    
   origin 
      Required.  The source from which the name of the alert 
   originates. 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 Common Vulnerabilities and Exposures 
                             (CVE) name (http://www.cve.mitre.org/) 
     3    vendor-specific    A vendor-specific name (and hence, URL); 
                             this can be used to provide product- 
                             specific information 
    
    
5.2.6.6  The EvidenceData Class 
    
   The EvidenceData class contains evidence data of different kind 
   related to current Incident, including textual information 
   (logfiles, malicious scripts, list of changes if file system, etc.) 
   and binary (disc images, etc.). 
    
    
   +------------------+  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 66] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |   Evidence       |  
   +------------------+  
            /_\  
             |  
   +------------------+  
   | EvidenceData     |  
   +------------------+       0..1 +----------------+  
   | STRING ident     |<>----------| IncidentID     |  
   | ENUM restriction |            +----------------+  
   |                  |       0..* +----------------+  
   |                  |<>----------| CorrEvidenceID |  
   |                  |            +----------------+  
   |                  |       0..1 +----------------+  
   |                  |<>----------| External       |  
   |                  |            +----------------+  
   |                  |            +----------------+  
   |                  |<>----------| Data           |  
   |                  |            +----------------+  
   +------------------+ 
    
   Figure 5.24  The EvidenceData Class 
    
   The aggregate classes that constitute Classification are: 
    
   IncidentID 
      Zero or one. A unique identifier for the Incident, the value is 
   equal to IncidentID attribute of Incident class. 
    
   CorrEvidenceID 
      Zero or more. EvidenceID of the Evidence class that contains 
   Evidence data correlated with current Evidence data. 
    
   External 
      Zero or one. Contains link or path to externally stored Evidence 
   data. 
    
   Data 
      Exactly one. Container for the Evidence data. 
    
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  
     ">  
   <!ELEMENT EvidenceData                  ( 
       IncidentID?, CorrEvidence*, External?, Data 
     )> 
   <!ATTLIST EvidenceData 
       origin                %attvals.origin;        'unknown' 
     > 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 67] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   The EvidenceData class has two attributes: 
    
   ident  
      Optional.  A unique identifier for this source, see Section 
   4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   element’s data by Incident Handling System. 
    
   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 
    
    
5.2.6.7  The EventList Class 
    
   The EventList class contains information about events which are 
   treated as correlated in respect to current incident. 
    
   +---------------------+  
   | CorrelationIncident |  
   +---------------------+  
         /_\  
          |  
   +--------------+  
   | EventList    |  
   +--------------+       0..1 +----------------+  
   |              |<>----------| IncidentID     |  
   |              |            +----------------+  
   |              |       0..* +----------------+  
   |              |<>----------| EvidenceDataID |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| DateTime       |  
   |              |            +----------------+  
   +--------------+ 
    
   Figure 5.25  The EventList Class 
    
   The aggregate classes that constitute EventList are: 
    
   IncidentID  
      Zero or one.  Identification number of the Incident. 
    
   EvidenceDataID 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 68] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      Zero or more.  Identification number of the EvidenceData element 
   related to referenced event or IncidentID. 
    
   DateTime 
      Zero or one.  Date and time when described event happened. 
    
   EventList is represented in the XML DTD as follows: 
    
   <!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 4.4.9. 
    
    
5.2.6.8  The Organisation Class 
    
   The Organisation Class contains information about organization 
   owning current Incident Object. Organisation class is a mandatory 
   subordinate element/subclass of another mandatory Authority class. 
   In respect to this Organisation class must contain at least of two 
   subclasses OrgName or OrganisationID. 
    
    
   +--------------+  
   |   Authority  |  
   +--------------+  
          /_\  
           |  
   +--------------+  
   | Organisation |  
   +--------------+       0..1 +----------------+  
   | STRING ident |<>----------| OrganisationID |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| OrgName        |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| OrgAddress     |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| Email          |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| Telephone      |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 69] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |              |<>----------| Fax            |  
   |              |            +----------------+  
   +--------------+ 
    
   Figure 5.26  Organisation Class 
    
    
   The aggregate classes that constitute Organisation class are: 
    
   OrganisationID  
      Zero or one.  Identification number of the organisation owning 
   the Incident object. For the purpose of OrganisationID, organisation 
   handle from known registries, e.g. RIPE NCC, TI, etc., may be used. 
    
   OrgName 
      Zero or one.  Name of the organization as it used in official 
   post address. 
    
   OrgAddress 
      Zero or one.  Address of the organisation. 
    
   Email 
      Zero or one.  Email address of the organisation. 
    
   Telephone 
      Zero or one.  Telephone number of the organisation. 
    
   Fax 
      Zero or one.  Fax number of the organisation. 
    
   Organisation is represented in the XML DTD as follows: 
    
   <!ELEMENT Organisation                           (  
       (OrganisationID? | OrgName?), OrgAddress?,  
            Email?, Telephone?, Fax? )> 
   <!ATTLIST Organisation 
       ident                 ID                      #IMPLIED  
     > 
    
   The EventList class has one attributes: 
    
   ident 
      Optional. A unique identifier for the EventList element, see 
   Section 4.4.9. 
    
    
5.2.6.9  The Contact Class 
    
   The Contact Class contains contact information for the person or 
   role representing CSIRT that handles current Incident. 
    
    
   +--------------+  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 70] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   |   Authority  |  
   +--------------+  
          /_\  
           |  
   +--------------+  
   | Contact      |  
   +--------------+       0..1 +----------------+  
   | STRING ident |<>----------| PersonName     |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| ContactHandle  |  
   |              |            +----------------+  
   +--------------+ 
    
   Figure 5.27  Contact Class 
    
    
   The aggregate classes that constitute Contact class are: 
    
   Name  
      Zero or one.  Name of the person that responsible for handling 
   current Incident. 
    
   ContactHandle 
      Zero or one.  Identification number (or handle) used to refer to 
   personal (or role) information in different Registries.  
    
   Conatct is represented in the XML DTD as follows: 
    
   <!ELEMENT Contact                           (  
       Name?, ContactHandle?)> 
   <!ATTLIST Contact 
       ident                 ID                      #IMPLIED  
     > 
    
   The Contact class has one attributes: 
    
   ident 
      Optional. A unique identifier for the Contact element, see 
   Section 4.4.9. 
    
    
5.2.6.10  The Reported Class 
    
   The Reported class is subordinate class of the History class. It 
   provided information about who and when reported current Incident, 
   particularly identification number of the CSIRT that reported the 
   Incident and time when it was reported. This element contains only 
   AuthorityID from maintained by CSIRT database or from definite 
   public register like RIPE NCC database or Trusted Introducer CSIRT 
   database, assuming that CSIRT normally can accept information only 
   from trusted source. 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 71] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   +--------------+  
   |   History    |  
   +--------------+  
          /_\  
           |  
   +--------------+  
   | Reported     |  
   +--------------+       0..1 +----------------+  
   | STRING ident |<>----------| AuthorityID    |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| IncidentID     |  
   |              |            +----------------+  
   |              |       0..1 +----------------+  
   |              |<>----------| DateTime       |  
   |              |            +----------------+  
   +--------------+ 
    
   Figure 5.28  Reported Class 
    
   The aggregate classes that constitute Reported class are: 
    
   IncidentID  
      Zero or one.  Identification number of the Incident as it 
   reported by the Authority defined by AuthorityID. 
    
   AuthorityID 
      Zero or one.  Identification number of the authority that 
   reported current incident. 
    
   DateTime 
      Zero or one.  Date and time when message was received. 
    
   Reported is represented in the XML DTD as follows: 
    
   <!ELEMENT Reported                           (  
       AuthorityID?, IncidentID?, DateTime?)> 
   <!ATTLIST Reported 
       ident                 ID                      #IMPLIED  
     > 
    
   The Reported class has one attributes: 
    
   ident 
      Optional. A unique identifier for the Reported element, see 
   Section 4.4.9. 
    
    
5.2.6.11  The Received Class 
    
   The Received class contains information about when and from whom the 
   information about current incident was received. In particular case 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 72] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   it may contain reference to message received from another CSIRT 
   about current incident. This element contains only AuthorityID from 
   maintained by CSIRT database or from definite public register like 
   RIPE NCC database or Trusted Introducer CSIRT database, assuming 
   that CSIRT normally can accept information only from trusted source. 
    
    
   +--------------+  
   |   History    |  
   +--------------+  
         /_\  
          |  
   +--------------+  
   | Received     |  
   +--------------+       0..1 +--------------+  
   | STRING ident |<>----------| AuthorityID  |  
   |              |            +--------------+  
   |              |       0..1 +--------------+  
   |              |<>----------| IncidentID   |  
   |              |            +--------------+  
   |              |       0..1 +--------------+  
   |              |<>----------| MessageID    |  
   |              |            +--------------+  
   |              |       0..1 +--------------+  
   |              |<>----------| DateTime     |  
   |              |            +--------------+  
   +--------------+ 
    
   Figure 5.29  Received Class 
    
   The aggregate classes that constitute Received class are: 
    
   IncidentID  
      Zero or one.  Identification number of the Incident as it 
   reported by the Authority defined by AuthorityID. 
    
   MessageID 
      Zero or one.  Identification number of the message. 
    
   AuthorityID 
      Zero or one.  Identification number of the authority that sent 
   referenced message. 
    
   DateTime 
      Zero or one.  Date and time when message was received. 
    
   Received is represented in the XML DTD as follows: 
    
   <!ELEMENT Received                           (  
       IncidentID?, MessageID?, AuthorityID?, DateTime?)> 
   <!ATTLIST Received 
       ident                 ID                      #IMPLIED  
     > 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 73] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
   The Received class has one attributes: 
    
   ident 
      Optional. A unique identifier for the Received element, see 
   Section 4.4.9. 
    
    
5.2.6.12  The ActionList Class 
    
   The ActionList class lists actions undertaken by CSIRTs in course of 
   handling/investigating Incident. 
    
   +------------------+  
   |   History        |  
   +------------------+  
            /_\  
             |  
   +------------------+  
   | ActionList       |  
   +------------------+        0..*+--------------+  
   | ENUM restriction |<>----------| Action       |  
   |                  |            +--------------+  
   |                  |        0..*+--------------+  
   |                  |<>----------| Description  |  
   |                  |            +--------------+  
   |                  |        0..1+--------------+  
   |                  |<>----------| DateTime     |  
   |                  |            +--------------+  
   +------------------+ 
    
   Figure 5.30  ActionList Class 
    
    
   The aggregate classes that constitute ActionList are: 
    
   Action  
      Zero or more.  Action undertaken by CSIRT in course of incident 
   handling. 
    
   Description  
      Zero or more.  Description of action(s) undertaken by CSIRT in 
   course of Incident handling in free language. 
    
   DateTime 
      Zero or one.  Date and time when action or group of actions were 
   undertaken. 
    
   ActionList is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.restriction             "  
       ( default | public | internal |  
        restricted )  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 74] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     ">  
   <!ELEMENT ActionList                           (  
       Action*, Description*, DateTime?)> 
   <!ATTLIST ActionList 
       ident                 ID                      #IMPLIED  
       restriction           %attvals.restriction;   ‘default’ 
     > 
    
   The ActionList class has two attributes: 
    
   ident 
      Optional. A unique identifier for the ActionList element, see 
   Section 4.4.9. 
    
   restriction 
      Optional. Indicates restriction level that should applied to 
   element’s data by Incident Handling System. 
    
   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 
    
    
5.2.7 Simple Classes 
    
   The simple classes don’t have subclasses. The purpose of describing 
   some simple classes in this section is to provide information about 
   attributes used to describe data of these classes. 
    
    
5.2.7.1  The Description Class 
    
   The Description class is used for putting into related element any 
   description in free language that is normally human language. It is 
   reasonable to use for the Description class the possibility given by 
   XML to define language of one particular element. For details on 
   declaring language attribute see section 4.3.3. 
    
   <!ELEMENT Description xml:lang="langcode"> 
    
    
5.2.7.2  The IRTcontact Class 
    
   The IRTcontact class contains IRTcontact handle that references 
   contact information for the CSIRT or Network Security manager 
   serving the network of Attacker or Victim originated from related 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 75] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   public registry, e.g. RIPE NCC database [18], Trusted Introducer 
   database [19] or other known registry. 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.originIRT                 " 
       ( unknown | ripencc | ti | arin | apnic | afnic | local ) 
     "> 
   <!ELEMENT IRTcontact               > 
   <!ATTLIST IRTcontact 
       originIRT            %attvals.originirt;        'unknown' 
     > 
    
   IRTcontact class has one attribute: 
    
   originIRT 
      Required.  The source from which the IRTcontact handle 
   originates. 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    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 
    
    
5.2.7.3 The External Class 
    
   The External class contains file name, link or path to externally 
   stored data. 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.exttype                 " 
       ( file | path | url ) 
     "> 
   <!ELEMENT External                  > 
   <!ATTLIST External 
       exttype             %attvals.exttype;        'file' 
     > 
    
   The External class has one attribute: 
    
   exttype 
      Required. Type pointer to externally saved data. 
    
   Rank   Keyword            Description  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 76] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   ----   -------            -----------  
     0    file               The element contains a name of file that 
                             may be stored on any media, this  
                             information should be necessary for CSIRT 
     1    path               Describe path to file location on IHS  
                             system 
     2    url                URL to location of the data 
    
    
5.2.7.4 The Data Class 
    
   Container for the arbitrary data. 
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.dtype                 "  
       ( boolean | byte | character | string | binary )  
     ">  
   <!ELEMENT Data            ANY >  
   <!ATTLIST Data  
       type                  %attvals.dtype;        'string'  
     > 
    
   The Data 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            Description  
   ----   -------            -----------  
     0    boolean            The element contains a boolean value,  
                             i.e., the strings "true" or "false"  
     1    byte               The element content is a single 8-bit  
                             byte (see Section 4.4.4)  
     2    character          The element content is a single  
                             character (see Section 4.4.3)  
     3    integer            The element content is an integer (see  
                             Section 4.4.1)  
     4    string             The element content is a string (see  
                             Section 4.4.3)  
     5    binary             The element content is binary data. 
    
    
5.2.7.5 The Name Class 
    
   The Name class contains personal name of contact person at 
   organization of Authority (CSIRT owning Incident object).  
    
   This is represented in the XML DTD as follows: 
    
   <!ENTITY % attvals.nametype                 " 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 77] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


       ( dn | internic | ripencc ) 
     "> 
   <!ELEMENT Name                  > 
   <!ATTLIST Name 
       nametype             %attvals.nametype;        'file' 
     > 
    
   Name class has one attribute: 
    
   nametype 
      Required. Type of name or source of name/role handle. 
    
   Rank   Keyword            Description  
   ----   -------            -----------  
     0    dn                 Distinguished name (personal name).  
                             Format as described in section 4.4.10 
     1    internic           Name/role handle from InterNIC database  
     2    ripencc            Name/role handle from RIPE NCC database 
    
    
6. Extending the IODEF 
    
   As IHS working with IODEF and IDS providing initial information 
   about Security events evolve, the IODEF data model and DTD should 
   evolve along with them.  To allow new features to be added as they 
   are developed, 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. 
    
    
6.1 Extending the Data Model 
     
   There are two mechanisms for extending the IODEF data model, 
   inheritance and aggregation: 
 

   + Inheritance denotes a superclass/subclass type of relationship 
     where the subclass inherits all the attributes, operations, and 
     relationships of the superclass.  This type of relationship is 
     also called a "is-a" or "kind-of" relationship.  Subclasses may 
     have additional attributes or operations that apply only to the 
     subclass, and not to the superclass. 
 
   + Aggregation is a form of association in which the whole is related 
     to its parts.  This type of relationship is also referred to as a 
     "part-of" relationship.  In this case, the aggregate class 
     contains all of its own attributes and as many of the attributes 
     associated with its parts as required and specified by occurrence 
     indicators. 
 

   Of the two mechanisms, inheritance is preferred, because it 
   preserves the existing data model structure and also preserves the 
   operations (methods) executed on the classes of the structure. 
    


 
TERENA ITDWG    Informational - Expires January 2002      [Page 78] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   In particular case of relations between IODEF and IDMEF, the IODEF 
   may be treated as IDMEF extension applying inheritance to 
   incorporate Alert/IDMEF data structure into Attack Class of IODEF.  
    
   Note that the rules for extending the XML DTD (see below) set limits 
   on the places where extensions to the data model may be made. 
 
 

6.2 Extending the XML DTD 
 

   There are two ways to extend the IODEF XML DTD: 
    
   1. The AdditionalData class (see Section 5.2.4.5) allows 
   implementers to include arbitrary "atomic" data items (integers, 
   strings, etc.) in an Incident or IncidentAlert description.  This 
   approach SHOULD be used whenever possible.  
    
   2. The AdditionalData class allows implementers to extend the XML 
   DTD with additional DTD "modules" that describe arbitrarily complex 
   data types and relationships.  The example in this section describes 
   this extension method. 
    
   To extend the IODEF DTD with a new DTD "module," the following steps 
   MUST be followed: 
     
   1. The IODEF description MUST include a document type declaration 
   (see Section 4.3.1.3). 
    
   2. The document type declaration MUST define a parameter entity (see 
   Section 4.2.4) that contains the location of the extension DTD, and 
   then reference that entity: 
    
   <!DOCTYPE IODEF-Description SYSTEM "/path/to/IODEF-Description.dtd"  
   [  
   <!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">  
     %x-extension;  
     ]> 
    
   In this example, the "x-extension" parameter entity is defined and 
   then referenced, causing the DTD for the extension to be read by the 
   XML parser. 
    
   The name of the parameter entity defined for this purpose MUST be a 
   string beginning with "x-"; there are no other restrictions on the 
   name (other than those imposed on all entity names by XML). 
    
   Multiple extensions may be included by defining multiple entities 
   and referencing them.  For example: 
    
   <!DOCTYPE IODEF-Description SYSTEM "/path/to/IODEF-Description.dtd"  
   [  
      <!ENTITY % x-extension SYSTEM "/path/to/extension.dtd">  
      <!ENTITY % x-another SYSTEM "/path/to/another.dtd">  
      %x-extension;  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 79] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


      %x-another;  
      ]> 
    
   3. Extension DTDs MUST declare all of their elements and attributes 
   in a separate XML namespace.  Extension DTDs MUST NOT declare any 
   elements or attributes in the "IODEF" or default namespaces. 
    
   For example, the "test" extension might be declared as follows:  
    
   <!ELEMENT test:test (  
       test:a, test:b, test:c  
      )>  
   <!ATTLIST test:test  
       xmlns      CDATA   #IMPLIED  
       xmlns:test CDATA   #IMPLIED  
     > 
   <!ELEMENT test:a (#PCDATA)>  
   <!ATTLIST test:a  
       test:attr   CDATA   #IMPLIED  
     > 
    
   <!ELEMENT test:b (#PCDATA)>  
   <!ELEMENT test:c (#PCDATA)> 
    
   4. Extensions MUST only be included in IODEF Incident description 
   under an <AdditionalData> element whose "type" attribute contains 
   the value "xml".  For example: 
    
   <IODEF-Description 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>  
     </Alert>  
   </IODEF-Description> 
    
    
7. Special Considerations 
    
   This section discusses some of the special considerations that must 
   be taken into account by implementers of the IODEF. 
    
    
7.1 XML Validity and Well-Formedness 
    
   It is expected that IODEF-compliant applications will not normally 
   include the IODEF DTD itself in their communications.  Instead, the 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 80] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   DTD will be referenced in the document type declaration in the IODEF 
   description (see Section 4.3.1). Such IODEF documents will be well-
   formed and valid as defined in [5]. 
    
   Other IODEF documents will be specified that do not include the 
   document prolog (e.g., entries in an IODEF-format database). Such 
   IODEF documents 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 in the middle of 
   another "chapter"). 
     
   Validity further implies that not only is the document well-formed, 
   but it also follows specific rules (contained in the Document Type 
   Definition) about which elements are "legal" in the document, how 
   those elements nest within other elements, and so on (e.g., a 
   "chapter" does not begin in the middle of a "title").  A document 
   cannot be valid unless it references a DTD. 
    
   XML processors are required to be able to parse any well-formed 
   document, valid or not.  The purpose of validation is to make the 
   processing of that 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 be 
   valid whenever both possible and practical. 
    
    
7.2 Unrecognized XML Tags 
    
   On occasion, an IODEF-compliant application may receive a well-
   formed, or even well-formed and valid, IODEF description containing 
   tags that it does not understand.  The tags may be either: 
    
   +  Recognized as "legitimate" (a valid document), but the 
   application does not know the semantic meaning of the element's 
   content; or 
    
   +  Not recognized at all. 
     
   IODEF-compliant applications MUST continue to process IODEF 
   descriptions that contain unknown tags, provided that such messages 
   meet the well-formedness requirement of Section 7.1.  It is up to 
   the individual application to decide how to process (or ignore) any 
   content from the unknown elements(s). 
    
   Special issue is related to inheritance relation between 
   Incident/Attacker related classes IDMEF and IODEF, e.g. IODEF 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 81] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   message may be simply wrap up into IDMEF container for the 
   IncidentAlert class.  
    
   When Incident description is produced of IDMEF message, IODEF may 
   use directly related data classes from IDMEF. In this context it is 
   recommended that IHS understands both format - IODEF and IDMEF. This 
   may be achieved by mapping part of IDMEF classes (XML tags) related 
   to Attack description into IODEF classes. This is to be not 
   difficult task because 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 in IODEF is inherited from IDMEF. 
    
    
    
7.3 Digital Signatures 
    
   The joint IETF/W3C XML Signature Working Group is currently working 
   to specify XML digital signature processing rules and syntax [16]. 
   XML Signatures provide integrity, message authentication, and/or 
   signer authentication services for data of any type, whether located 
   within the XML that includes the signature or elsewhere. 
    
   The IODEF requirements document recommends that IODEF should support 
   content confidentiality, integrity and authentication and non-
   repudiation. This is achieved by inclusion of digital signatures 
   within an IODEF document. Additional security considerations may be 
   applied to communications methods and protocol used for IODEF 
   documents exchange.  
    
   Specifications for the use of digital signatures within IODEF 
   documents are outside the scope of this document.  However, if such 
   functionality is needed/implemented, use of the XML Signature 
   standard is RECOMMENDED. 
    
    
8. Experimental implementation and examples 
    
   There is ongoing project among few CSIRTs in Europe to implement 
   IODEF in their daily incident handling work [17]. Results is 
   believed to be available late 2001 year.  
    
   There may be some other early implementations using IODEF rather as 
   a general concept for defining data structure. Those implementations 
   must not be treated as valid IODEF implementations. 
    
   This section will provide examples of how the IODEF is used to 
   encode Incident data.  The examples will be provided for 
   illustrative purposes only, and will not necessarily represent the 
   only (or even the "best") way to encode these particular alerts).  
    
9. The IODEF Document Type Definition 
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 82] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <?xml version="1.0" encoding="UTF-8"?> 
   <!-- 
   ## Possibility to use different encoding for local languages should 
   be discussed 
   --> 
   <!-- edited with XML Spy v3.5 NT (http://www.xmlspy.com)  
     by Yuri Demchenko (TERENA) --> 
   <!--Incident Object Description and Exchnage Format (IODEF) XML DTD  
   Version 0.01, 9 September 2001 
   The use and extension of the IODEF XML DTD are described in 
   documents  
   RFCxxxx, "Incident Object Description and Exchange Format Data Model  
   and Extensible Markup Language (XML) Document Type Definition"--> 
   <!--Current version of IODEF XML DTD  is based heavily on  
    the IDMEF XML DTD Draft Version 0.4 
    http://www.ietf.org/internet-drafts/draft-ietf-idwg-idmef-xml-
   04.txt--> 
   <!--Current version of the IODEF XML DTD contains also initial  
    suggestions for IODEF extention for Evidence collection and  
    Vulnerability description.--> 
   <!--================== Imported Names 
   ====================================--> 
   <!-- media type, as per [RFC2045] --> 
   <!ENTITY % ContentType "CDATA"> 
   <!-- comma-separated list of media types, as per [RFC2045] --> 
   <!ENTITY % ContentTypes "CDATA"> 
   <!-- a character encoding, as per [RFC2045] --> 
   <!ENTITY % Charset "CDATA"> 
   <!-- a space separated list of character encodings, as per [RFC2045] 
   --> 
   <!ENTITY % Charsets "CDATA"> 
   <!-- a language code, as per [RFC1766] --> 
   <!ENTITY % LanguageCode "NMTOKEN"> 
   <!-- a single character from [ISO10646] --> 
   <!ENTITY % Character "CDATA"> 
   <!-- date and time information. ISO date format --> 
   <!ENTITY % Datetime "CDATA"> 
   <!--===== SECTION 1. Attribute list declarations  
   ===================--> 
   <!--Attributes of the IODEF element.  In general, the fixed values 
     of these attributes will change each time a new version of  
     the DTD is released.--> 
   <!ENTITY % attlist.iodef " 
      version             CDATA                   #FIXED    '0.01' 
   "> 
   <!--Attributes of all elements.  These are the "XML" attributes  
      that every element should have. Name space and language.--> 
   <!-- 
   ## Possibility to use different encoding/charsets for some local 
      languages should be discussed 
   --> 
   <!ENTITY % attlist.global " 
      xmlns:iodef         CDATA                   #FIXED 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 83] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


          'urn:iana:xml:ns:iodef' 
       xmlns               CDATA                   #FIXED 
           'urn:iana:xml:ns:iodef' 
       xml:space           (default | preserve)    'default' 
       xml:lang    %LanguageCode;          #IMPLIED  
   "> 
   <!-- === SECTION 2. Attribute value declarations.   
                Enumerated values for many of the 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 ) 
    "> 
   <!-- 
   | Values for the Confifence attribute. 
   --> 
   <!ENTITY % attvals.confidence " 
      ( unknown | low | medium | strong | sure ) 
    "> 
   <!-- 
   | Values for the Data.type attribute used as agregate of 
   EvidenceData. 
   --> 
   <!ENTITY % attvals.dtype " 
      ( boolean | byte | character | integer | string | binary ) 
    "> 
   <!-- 
   | Values for the External.type attribute. 
       --> 
   <!ENTITY % attvals.extype " 
      ( file | path | url ) 
    "> 
   <!-- 
   | Values for the Id.type attribute. 
       --> 
   <!ENTITY % attvals.idtype " 
      ( current-user | original-user | target-user | user-privs | 
        current-group | group-privs ) 
    "> 
   <!-- 
   | Values for the Attack.impact attribute. 
       --> 
   <!ENTITY % attvals.impact " 
       ( unknown | bad-unknown | not-suspicious | attempted-admin | 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 84] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


         successful-admin | attempted-dos | successful-dos | 
         attempted-recon | successful-recon-limited | 
         successful-recon-largescale | attempted-user | 
         successful-user ) 
    "> 
   <!-- 
   | Values for the PersonName.type attribute. 
   --> 
   <!ENTITY % attvals.nametype " 
      ( dn | internic | ripencc ) 
    "> 
   <!-- 
   | Values for the Node.category attribute. 
       --> 
   <!ENTITY % attvals.nodecat " 
      ( unknown | ads | afs | coda | dfs | dns | kerberos | nds | 
        nis | nisplus | nt | wfw ) 
    "> 
   <!-- 
   | Values for the Classification.origin attribute. 
       --> 
   <!ENTITY % attvals.origin " 
      ( unknown | bugtraqid | cve | vendor-specific | irt-local ) 
   "> 
   <!-- 
   | Values for the IRTcontact.originIRT attribute 
   --> 
   <!ENTITY % attvals.originIRT " 
      ( unknown | ripencc | ti | arin | apnic | afnic | local ) 
   "> 
   <!--Purpose define purpose of the IODEF Object--> 
   <!ENTITY % attvals.purpose " 
      ( report | handling | communication | statistics | experimental ) 
   "> 
   <!--Restriction defines restriction on access to information in 
   IODEF --> 
   <!ENTITY % attvals.restriction " 
      (default | public | internal | restricted ) 
   "> 
   <!-- 
   | Values for the User.category attribute. 
        
   ##  should be extended for the purposes of IODEF 
   --> 
   <!ENTITY % attvals.usercat " 
      ( unknown | application | os-device ) 
   "> 
   <!-- 
   | Values for yes/no attributes such as Source.spoofed and 
   | Target.decoy. 
       --> 
   <!ENTITY % attvals.yesno " 
      ( unknown | yes | no ) 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 85] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   "> 
   <!-- 
    === SECTION 3. Top-level element declarations.   
             The IODEF-Description element and the types of  
             Incidents it may include. 
   --> 
   <!--############################## 
   IODEF-Descrpition is generally used as a container for Incident data  
   and other information. Suggested top-classes are Incident, 
   IncidentAlert. 
    ============================ 
   Possible extension is seen for Vulnerability and Evidence with  
   top-classes VulnerabilityReport and IncidentEvidence. 
   ##############################--> 
   <!ELEMENT IODEF-Description ((Incident | IncidentAlert | 
   VulnerabilityReport | IncidentEvidence)*)> 
   <!ATTLIST IODEF-Description 
     %attlist.iodef; CDATA #FIXED "0.01" 
     %attlist.global;  
   > 
   <!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;  
   > 
   <!--IncidentAlert should be able to reuse/include IDMEF Message 
   together  
   with Authority/IRT--> 
   <!ELEMENT IncidentAlert (History?, Authority, AdditionalData+)> 
   <!ATTLIST IncidentAlert 
     incid CDATA "0" 
     %attlist.global;  
     restriction %attvals.restriction; 
   > 
   <!--####################### 
   Two possible additional Classes of the IODEF-Description include  
   VulnerabilityReport and IncidentEvidence. 
   Vulnerability format should comply with those used for Vulnerability 
   Alert/report e.g. by ISS (), Para-Protect () or Symantecs (): 
   Possible format 
   <!ELEMENT VulnerabilityReport (VulName, Platform?, RiskFactor?,  
             AttackType?, Description*, Authority, Reference*)> 
   ======================================== 
   IncidentEvidence format should satisfy purposes of Evidence 
   preservation  
   and custody tracking/chain: 
   Possible format 
   <!ELEMENT IncidentEvidence (Attack?, Attacker?, Victim?,  
             Evidence+, Authority, AdditionalData*, History?)> 
   #######################--> 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 86] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!--Definition of VulnerabilityReport below is for illustration only 
   and  
   composed of existing elements to keep DTD validity--> 
   <!ELEMENT VulnerabilityReport (Attack?, Method*, Authority, 
   History?, AdditionalData+)> 
   <!ATTLIST VulnerabilityReport 
     restriction %attvals.restriction; 
     %attlist.global;  
   > 
   <!--Definition of IncidentEvidence below is for illustration  
     only and composed of existing elements to keep DTD validity--> 
   <!ELEMENT IncidentEvidence (Attack?, Attacker?, Victim?, Evidence+, 
   Authority, History?, AdditionalData*)> 
   <!ATTLIST IncidentEvidence 
     restriction %attvals.restriction; 
     %attlist.global;  
   > 
   <!--  
    === SECTION 4. Subclasses of the Incident or other top-level  
           elements that provide more data for specific types  
           of incidents. 
   --> 
   <!ELEMENT Attack (Target*, Source*, Description*, Action*, 
   DetectTime?, StartTime?, EndTime?)> 
   <!ATTLIST Attack 
     ident CDATA #IMPLIED 
     impact %attvals.impact; #IMPLIED 
     restriction %attvals.restriction; #IMPLIED 
     %attlist.global;  
   > 
   <!ELEMENT Attacker (Node*, location?, User*, IRTcontact?)> 
   <!ATTLIST Attacker 
     %attlist.global;  
     ident CDATA "" 
     spoofed %attvals.yesno; "unknown" 
   > 
   <!ELEMENT Victim (Node*, location?, User*, IRTcontact?)> 
   <!ATTLIST Victim 
     %attlist.global;  
   > 
   <!ELEMENT Method (Classification*, Description*)> 
   <!ATTLIST Method 
     %attlist.global;  
     ident CDATA #IMPLIED 
     restriction %attvals.restriction; #IMPLIED 
   > 
   <!ELEMENT Evidence (EvidenceData)> 
   <!ATTLIST Evidence 
     restriction %attvals.restriction; 
     ident CDATA #IMPLIED 
     %attlist.global;  
   > 


 
TERENA ITDWG    Informational - Expires January 2002      [Page 87] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!ELEMENT EvidenceData (IncidentID?, CorrEvidenceID*, External?, 
   data)> 
   <!ATTLIST EvidenceData 
     restriction %attvals.restriction; #IMPLIED 
     %attlist.global;  
   > 
   <!ELEMENT CorrelationIncident (EventList, IncidentID, 
   EvidenceDataID)> 
   <!ATTLIST CorrelationIncident 
     %attlist.global;  
   > 
   <!--Authority may include (handle) information identifying 
   Organisation or  
   person derived from well-known registries for IRTs,  
   e.g. FIRST, RIPE NCC, TrustedIntroducer, etc.--> 
   <!ELEMENT Authority (Organisation, Contact*)> 
   <!ATTLIST Authority 
     %attlist.global;  
   > 
   <!ELEMENT History (Reported?, Received*, ActionList*)> 
   <!ATTLIST History 
     %attlist.global;  
     restriction %attvals.restriction; #IMPLIED 
   > 
   <!-- 
    === SECTION 5.  The AdditionalData element. This element allows  
              an alert to include additional information that  
              cannot be encoded elsewhere in the data model. 
    --> 
   <!ELEMENT AdditionalData ANY> 
   <!ATTLIST AdditionalData 
     type %attvals.adtype; "string" 
     %ContentType; CDATA #IMPLIED 
     %attlist.global;  
   > 
   <!-- 
   === SECTION 6. Elements related to identifying entities -  
          Attack, Attacker, Victim, Method and Authority. 
   --> 
   <!--Elements Target and Source of IODEF are re-used from IDMEF--> 
   <!ELEMENT Target (Node?, User?, Process?, Service?, os?, program?)> 
   <!ATTLIST Target 
     ident CDATA "" 
     decoy %attvals.yesno; "unknown" 
     interface CDATA #IMPLIED 
     %attlist.global;  
   > 
   <!ELEMENT Source (Node?, User?, Process?, Service?, os?, program?)> 
   <!ATTLIST Source 
     ident CDATA "" 
     spoofed %attvals.yesno; "unknown" 
     interface CDATA #IMPLIED 
     %attlist.global;  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 88] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   > 
   <!--Elements Classification of IODEF is re-used from IDMEF--> 
   <!ELEMENT Classification (name, url)> 
   <!ATTLIST Classification 
     origin %attvals.origin; "unknown" 
     %attlist.global;  
   > 
   <!ELEMENT Organisation (OrganisationID?, OrgName?, OrgAddress?,  
                Email?, Telephone?, Fax?)> 
   <!ATTLIST Organisation 
     %attlist.global;  
   > 
   <!ELEMENT Contact (PersonName?, ContactHandle?)> 
   <!ATTLIST Contact 
     %attlist.global;  
   > 
   <!-- 
    === SECTION 7. Support elements used for providing detailed  
                   info about entities - addresses, names, etc. 
   --> 
   <!ELEMENT Address (address, netmask?)> 
   <!ATTLIST Address 
     ident CDATA "0" 
     category %attvals.addrcat; "unknown" 
     vlan-name CDATA #IMPLIED 
     vlan-num CDATA #IMPLIED 
     %attlist.global;  
   > 
   <!ELEMENT ActionList ((Action*, Description*, datetime?))> 
   <!ATTLIST ActionList 
     %attlist.global;  
   > 
   <!ELEMENT EventList ((IncidentID?, EvidenceDataID*, datetime?)*)> 
   <!ATTLIST EventList 
     %attlist.global;  
   > 
   <!ELEMENT Received (AuthorityID?, MessageID?, IncidentID?, 
   datetime?)> 
   <!ATTLIST Received 
     %attlist.global;  
   > 
   <!ELEMENT Reported (AuthorityID?, IncidentID?, datetime?)> 
   <!ATTLIST Reported 
     %attlist.global;  
   > 
   <!ELEMENT Node ((name | Address), Address*)> 
   <!ATTLIST Node 
     ident CDATA "0" 
     category %attvals.nodecat; "unknown" 
     %attlist.global;  
   > 
   <!ELEMENT Process (name, pid?, path?, arg*, env*)> 
   <!ATTLIST Process 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 89] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     ident CDATA "0" 
     %attlist.global;  
   > 
   <!ELEMENT Service (((name | port | (name, port)) | portlist), 
   protocol?, SNMPService?, WebService?)> 
   <!ATTLIST Service 
     ident CDATA "0" 
     %attlist.global;  
   > 
   <!ELEMENT SNMPService (oid?, community?, command?)> 
   <!ATTLIST SNMPService 
     %attlist.global;  
   > 
   <!ELEMENT User (UserId+)> 
   <!ATTLIST User 
     ident CDATA "0" 
     category %attvals.usercat; "unknown" 
     %attlist.global;  
   > 
   <!ELEMENT UserId (name | number | (name, number))> 
   <!ATTLIST UserId 
     ident CDATA "0" 
     type %attvals.idtype; "original-user" 
     %attlist.global;  
   > 
   <!--########################### 
   In current version of IODEF simple element method/IDMEF 
    is renamed to httpmethod what it actually is. 
   ###########################--> 
   <!ELEMENT WebService (url, cgi?, httpmethod?, arg*)> 
   <!ATTLIST WebService 
     %attlist.global;  
   > 
   <!-- 
    === SECTION 8. Simple elements with sub-elements or  
                   attributes of a special nature. 
   --> 
   <!ELEMENT DetectTime (#PCDATA)> 
   <!ATTLIST DetectTime 
     ntpstamp CDATA #REQUIRED 
     %attlist.global;  
   > 
   <!ELEMENT StartTime (#PCDATA)> 
   <!ATTLIST StartTime 
     %attlist.global;  
   > 
   <!ELEMENT EndTime (#PCDATA)> 
   <!ATTLIST EndTime 
     %attlist.global;  
   > 
   <!ELEMENT datetime (#PCDATA)> 
   <!ATTLIST datetime 
     %Datetime;  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 90] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


     %attlist.global;  
   > 
   <!ELEMENT IncidentID (#PCDATA)> 
   <!ATTLIST IncidentID 
     %attlist.global;  
   > 
   <!ELEMENT attackID (#PCDATA)> 
   <!ATTLIST attackID 
     %attlist.global;  
   > 
   <!ELEMENT AuthorityID (#PCDATA)> 
   <!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 OrganisationID (#PCDATA)> 
   <!ATTLIST OrganisationID 
     %attlist.global;  
   > 
   <!ELEMENT IRTcontact (#PCDATA)> 
   <!ATTLIST IRTcontact 
     %attlist.global;  
   > 
   <!ELEMENT ContactHandle (#PCDATA)> 
   <!ATTLIST ContactHandle 
     originIRT %attvals.originIRT; #REQUIRED 
     %attlist.global;  
   > 
   <!ELEMENT PersonName (#PCDATA)> 
   <!ATTLIST PersonName 
     nametype CDATA #IMPLIED 
     %attlist.global;  
   > 
   <!ELEMENT OrgName (#PCDATA)> 
   <!ATTLIST OrgName 
     %attlist.global;  
   > 
   <!ELEMENT OrgAddress (#PCDATA)> 
   <!ATTLIST OrgAddress 
     %attlist.global;  
   > 
   <!ELEMENT Email (#PCDATA)> 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 91] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!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 of different charsets/encodings for the same language should 
   discussed.--> 
   <!ELEMENT Description ANY> 
   <!ATTLIST Description 
     %attlist.global;  
   > 
   <!ELEMENT data (#PCDATA)> 
   <!ATTLIST data 
     %ContentType;  
     %attlist.global;  
   > 
   <!ELEMENT External (#PCDATA)> 
   <!ATTLIST External 
     %attlist.global;  
   > 
   <!--  
   === SECTION 9. Simple elements with no sub-elements and  
                  no special attributes. 
   --> 
   <!ELEMENT Action (#PCDATA)> 
   <!ATTLIST Action 
     %attlist.global;  
   > 
   <!ELEMENT address (#PCDATA)> 
   <!ATTLIST address 
     %attlist.global;  
   > 
   <!ELEMENT buffer (#PCDATA)> 
   <!ATTLIST buffer 
     %attlist.global;  
   > 
   <!ELEMENT cgi (#PCDATA)> 
   <!ATTLIST cgi 
     %attlist.global;  
   > 
   <!ELEMENT command (#PCDATA)> 
   <!ATTLIST command 
     %attlist.global;  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 92] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   > 
   <!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;  
   > 
   <!--########################### 
   In current version of IODEF simple element method/IDMEF  
   is renamed to httpmethod what it actually is. 
   ###########################--> 
   <!ELEMENT httpmethod (#PCDATA)> 
   <!ATTLIST httpmethod 
     %attlist.global;  
   > 
   <!ELEMENT name (#PCDATA)> 
   <!ATTLIST name 
     %attlist.global;  
   > 
   <!ELEMENT number (#PCDATA)> 
   <!ATTLIST number 
     %attlist.global;  
   > 
   <!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;  
   > 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 93] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


   <!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;  
   > 
    
    
10. Security Considerations 
    
   This Internet-Draft describes a data format for the exchange of 
   Security Incidents related data between CSIRTs providing response to 
   security events. There are two aspects of security requirements 
   applied to IODEF documents. 
    
   Security requirements regarding confidentiality, integrity, 
   authenticity and non-repudiation of IODEF description content are 
   satisfied by applying encryption or digital signature to IODEF 
   document content. This issues are discussed in section 7.3. However, 
   using digital signature for IODEF as an XML document is outside of 
   this Internet-Draft.  
    
   Another security consideration applies access restriction to all 
   IODEF classes by indicating their access restriction in 
   "restriction" attribute ([2], requirement 4.3). This normally is 
   applicable to top Incident Class and Core classes Attack, Attacker, 
   Victim, Method, Evidence, History. This requirement in some cases 
   may be addresses by applying encryption to particular element or 
   IODEF document in whole. However, this security requirement relies 
   completely on IHS realization. 
    
   In this respect Security considerations directly applicable to the 
   format of this data. There may, however, be security considerations 
   associated with the transport protocol chosen to move this data 
   between communicating entities. 

 
TERENA ITDWG    Informational - Expires January 2002      [Page 94] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
    
11. Acknowledgements 
    
   This document re-uses sufficient part of IDMEF Data Model and XML 
   DTD Version 0.3 of February 14, 2001 [3]. This, in addition to 
   providing better compatibility between two formats what is mandatory 
   IODEF requirement, sufficiently simplified initial drafting of the 
   document. However, this fact doesn’t eliminate authors’ 
   responsibility for content of current document. 
    
   Authors also credit a lot support and contribution received from 
   Incident Taxonomy and Description WG at TERENA Task Force TF-CSIRT 
   seminars (http://www.terena.nl/task-forces/tf-csirt/iodef/). 
    
   Essential contribution at the stage of drafting initial document was 
   received from Wilfried Woeber and Andrei Robachevski in defining 
   IRTContact class which is intended to use IRTContact information 
   from the RIPE NCC databse. 
    
    
    
12. References 
    
   [1]  Bradner, S., "Key words for use in RFCs to Indicate   
        Requirement Levels", BCP 14, RFC 2119, March 1997 
    
   [2]  Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's  
        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-04.txt - work in progress. 
    
   [4]  Taxonomy of the Computer Security Incident related terminology  
        - http://www.terena.nl/task-forces/tf-csirt/i-taxonomy/docs/ 
        i-taxonomy_terms.html 
    
   [5]  World Wide Web Consortium (W3C), "Extensible Markup Language  
        (XML) 1.0 (Second Edition)," W3C Recommendation, October 6,  
        2000.  http://www.w3.org/TR/2000/REC-xml-20001006. 
     
   [6]  World Wide Web Consortium (W3C), "Namespaces in XML," W3C  
        Recommendation, 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/ 
    
   [8]  Berners-Lee, T., Fielding, R.T., and L. Masinter, "Uniform  
        Resource Identifiers (URI): Generic Syntax," RFC 2396, August  

 
TERENA ITDWG    Informational - Expires January 2002      [Page 95] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


        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," BCP 19, RFC  
        2278, January 1998. 
     
   [12] Alvestrand, H., "Tags for the Identification of Languages,"  
        RFC 3066, BCP 47, January 2001. 
     
   [13] International Organization for Standardization (ISO),  
        "International Standard: Data elements and interchange  
        formats - Information interchange - Representation of dates  
        and times," ISO 8601, Second Edition, December 15, 2000. 
     
   [14] Mills, D., "Network Time Protocol (Version 3) Specification,  
        Implementation, and Analysis," RFC 1305, 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, J., and D. Solo, "XML-Signature Syntax  
        and Processing," draft-ietf-xmldsig-core-11.txt, November 1,  
        2000, work in progress. 
    
   [17] Incident Taxonomy and Description Working Group Charter -  
        http://www.terena.nl/task-forces/tf-csirt/iodef/ 
    
   [18] Incident Object Data model -  
        http://www.terena.nl/task-forces/tf-csirt/iodef/docs/ 
    
   [19] RIPE NCC Database – http://www.ripe.net/ 
    
   [20] Trusted Introducer Service - http://www.ti.terena.nl/ 
    
    
13. Authors Address: 
    
   Yuri Demchenko - Initial text 
   demch@terena.nl 
   TERENA 
    
    
    
    
    
    
    

 
TERENA ITDWG    Informational - Expires January 2002      [Page 96] 

INTERNET DRAFT       IODEF Data Model and XML DTD           July, 2001 


    
    
    
    
    
    
    
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2000). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    


















 
TERENA ITDWG    Informational - Expires January 2002      [Page 97]