Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 7970

 Errata 
Proposed STD
Pages: 172
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MILE

The Incident Object Description Exchange Format Version 2

Part 1 of 9, p. 1 to 18
None       Next Section

Obsoletes:    5070    6685


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        R. Danyliw
Request for Comments: 7970                                          CERT
Obsoletes: 5070, 6685                                      November 2016
Category: Standards Track
ISSN: 2070-1721


       The Incident Object Description Exchange Format Version 2

Abstract

   The Incident Object Description Exchange Format (IODEF) defines a
   data representation for security incident reports and indicators
   commonly exchanged by operational security teams for mitigation and
   watch and warning.  This document describes an updated information
   model for the IODEF and provides an associated data model specified
   with the XML schema.  This new information and data model obsoletes
   RFCs 5070 and 6685.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7970.

Top      ToC       Page 2 
Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     1.2.  Notations . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  About the IODEF Data Model  . . . . . . . . . . . . . . .   7
     1.4.  Changes from RFC 5070 . . . . . . . . . . . . . . . . . .   7
   2.  IODEF Data Types  . . . . . . . . . . . . . . . . . . . . . .   9
     2.1.  Integers  . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.2.  Real Numbers  . . . . . . . . . . . . . . . . . . . . . .   9
     2.3.  Characters and Strings  . . . . . . . . . . . . . . . . .   9
     2.4.  Multilingual Strings  . . . . . . . . . . . . . . . . . .   9
     2.5.  Binary Strings  . . . . . . . . . . . . . . . . . . . . .  10
       2.5.1.  Base64 Bytes  . . . . . . . . . . . . . . . . . . . .  10
       2.5.2.  Hexadecimal Bytes . . . . . . . . . . . . . . . . . .  11
     2.6.  Enumerated Types  . . . . . . . . . . . . . . . . . . . .  11
     2.7.  Date-Time String  . . . . . . . . . . . . . . . . . . . .  11
     2.8.  Timezone String . . . . . . . . . . . . . . . . . . . . .  11
     2.9.  Port Lists  . . . . . . . . . . . . . . . . . . . . . . .  11
     2.10. Postal Address  . . . . . . . . . . . . . . . . . . . . .  12
     2.11. Telephone Number  . . . . . . . . . . . . . . . . . . . .  12
     2.12. Email String  . . . . . . . . . . . . . . . . . . . . . .  12
     2.13. Uniform Resource Locator Strings  . . . . . . . . . . . .  12
     2.14. Identifiers and Identifier References . . . . . . . . . .  12
     2.15. Software  . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.15.1.  SoftwareReference Class  . . . . . . . . . . . . . .  14
     2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . .  15
   3.  The IODEF Information Model . . . . . . . . . . . . . . . . .  18
     3.1.  IODEF-Document Class  . . . . . . . . . . . . . . . . . .  18
     3.2.  Incident Class  . . . . . . . . . . . . . . . . . . . . .  20
     3.3.  Common Attributes . . . . . . . . . . . . . . . . . . . .  23
       3.3.1.  restriction Attribute . . . . . . . . . . . . . . . .  23
       3.3.2.  observable-id Attribute . . . . . . . . . . . . . . .  25
     3.4.  IncidentID Class  . . . . . . . . . . . . . . . . . . . .  25
     3.5.  AlternativeID Class . . . . . . . . . . . . . . . . . . .  26
     3.6.  RelatedActivity Class . . . . . . . . . . . . . . . . . .  27
     3.7.  ThreatActor Class . . . . . . . . . . . . . . . . . . . .  28
     3.8.  Campaign Class  . . . . . . . . . . . . . . . . . . . . .  29
     3.9.  Contact Class . . . . . . . . . . . . . . . . . . . . . .  30
       3.9.1.  RegistryHandle Class  . . . . . . . . . . . . . . . .  34
       3.9.2.  PostalAddress Class . . . . . . . . . . . . . . . . .  35
       3.9.3.  Email Class . . . . . . . . . . . . . . . . . . . . .  36
       3.9.4.  Telephone Class . . . . . . . . . . . . . . . . . . .  37
     3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . .  38
       3.10.1.  DetectionPattern Class . . . . . . . . . . . . . . .  40
     3.11. Method Class  . . . . . . . . . . . . . . . . . . . . . .  41
       3.11.1.  Reference Class  . . . . . . . . . . . . . . . . . .  42

Top      ToC       Page 4 
     3.12. Assessment Class  . . . . . . . . . . . . . . . . . . . .  43
       3.12.1.  SystemImpact Class . . . . . . . . . . . . . . . . .  45
       3.12.2.  BusinessImpact Class . . . . . . . . . . . . . . . .  48
       3.12.3.  TimeImpact Class . . . . . . . . . . . . . . . . . .  50
       3.12.4.  MonetaryImpact Class . . . . . . . . . . . . . . . .  52
       3.12.5.  Confidence Class . . . . . . . . . . . . . . . . . .  53
     3.13. History Class . . . . . . . . . . . . . . . . . . . . . .  54
       3.13.1.  HistoryItem Class  . . . . . . . . . . . . . . . . .  54
     3.14. EventData Class . . . . . . . . . . . . . . . . . . . . .  57
       3.14.1.  Relating the Incident and EventData Classes  . . . .  59
       3.14.2.  Recursive Definition of EventData  . . . . . . . . .  59
     3.15. Expectation Class . . . . . . . . . . . . . . . . . . . .  60
     3.16. Flow Class  . . . . . . . . . . . . . . . . . . . . . . .  63
     3.17. System Class  . . . . . . . . . . . . . . . . . . . . . .  64
     3.18. Node Class  . . . . . . . . . . . . . . . . . . . . . . .  67
       3.18.1.  Address Class  . . . . . . . . . . . . . . . . . . .  68
       3.18.2.  NodeRole Class . . . . . . . . . . . . . . . . . . .  69
       3.18.3.  Counter Class  . . . . . . . . . . . . . . . . . . .  73
     3.19. DomainData Class  . . . . . . . . . . . . . . . . . . . .  75
       3.19.1.  Nameservers Class  . . . . . . . . . . . . . . . . .  77
       3.19.2.  DomainContacts Class . . . . . . . . . . . . . . . .  78
     3.20. Service Class . . . . . . . . . . . . . . . . . . . . . .  79
       3.20.1.  ServiceName Class  . . . . . . . . . . . . . . . . .  80
       3.20.2.  ApplicationHeader Class  . . . . . . . . . . . . . .  81
     3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . .  82
     3.22. Record Class  . . . . . . . . . . . . . . . . . . . . . .  83
       3.22.1.  RecordData Class . . . . . . . . . . . . . . . . . .  84
       3.22.2.  RecordPattern Class  . . . . . . . . . . . . . . . .  85
     3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . .  87
       3.23.1.  Key Class  . . . . . . . . . . . . . . . . . . . . .  88
     3.24. CertificateData Class . . . . . . . . . . . . . . . . . .  89
       3.24.1.  Certificate Class  . . . . . . . . . . . . . . . . .  90
     3.25. FileData Class  . . . . . . . . . . . . . . . . . . . . .  90
       3.25.1.  File Class . . . . . . . . . . . . . . . . . . . . .  91
     3.26. HashData Class  . . . . . . . . . . . . . . . . . . . . .  92
       3.26.1.  Hash Class . . . . . . . . . . . . . . . . . . . . .  94
       3.26.2.  FuzzyHash Class  . . . . . . . . . . . . . . . . . .  95
     3.27. SignatureData Class . . . . . . . . . . . . . . . . . . .  95
     3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . .  96
     3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . .  96
       3.29.1.  IndicatorID Class  . . . . . . . . . . . . . . . . .  99
       3.29.2.  AlternativeIndicatorID Class . . . . . . . . . . . . 100
       3.29.3.  Observable Class . . . . . . . . . . . . . . . . . . 101
       3.29.4.  IndicatorExpression Class  . . . . . . . . . . . . . 106
       3.29.5.  Expressions with IndicatorExpression . . . . . . . . 108
       3.29.6.  ObservableReference Class  . . . . . . . . . . . . . 110
       3.29.7.  IndicatorReference Class . . . . . . . . . . . . . . 110
       3.29.8.  AttackPhase Class  . . . . . . . . . . . . . . . . . 111

Top      ToC       Page 5 
   4.  Processing Considerations . . . . . . . . . . . . . . . . . . 112
     4.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . . 112
     4.2.  IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 112
     4.3.  Validation  . . . . . . . . . . . . . . . . . . . . . . . 112
     4.4.  Incompatibilities with v1 . . . . . . . . . . . . . . . . 113
   5.  Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 114
     5.1.  Extending the Enumerated Values of Attributes . . . . . . 114
       5.1.1.  Private Extension of Enumerated Values  . . . . . . . 114
       5.1.2.  Public Extension of Enumerated Values . . . . . . . . 115
     5.2.  Extending Classes . . . . . . . . . . . . . . . . . . . . 115
     5.3.  Deconflicting Private Extensions  . . . . . . . . . . . . 117
   6.  Internationalization Issues . . . . . . . . . . . . . . . . . 118
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . 119
     7.1.  Minimal Example . . . . . . . . . . . . . . . . . . . . . 119
     7.2.  Indicators from a Campaign  . . . . . . . . . . . . . . . 120
   8.  The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 121
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . 161
     9.1.  Security  . . . . . . . . . . . . . . . . . . . . . . . . 161
     9.2.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 162
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163
     10.1.  Namespace and Schema . . . . . . . . . . . . . . . . . . 163
     10.2.  Enumerated Value Registries  . . . . . . . . . . . . . . 163
     10.3.  Expert Review of IODEF-Related XML Registry Entries  . . 166
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 167
     11.1.  Normative References . . . . . . . . . . . . . . . . . . 167
     11.2.  Informative References . . . . . . . . . . . . . . . . . 170
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 171
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 172

1.  Introduction

   Organizations require help from other parties to mitigate malicious
   activity targeting their network and to gain insight into potential
   threats.  This coordination might entail working with an ISP to
   filter attack traffic, contacting a remote site to take down a
   botnet, or sharing watch lists of known malicious indicators in a
   consortium.

   The Incident Object Description Exchange Format (IODEF) is a format
   for representing computer security information commonly exchanged
   between Computer Security Incident Response Teams (CSIRTs) or other
   operational security teams.  It provides an XML representation for
   conveying:

   o  indicators to characterize a threat;

   o  security incident reports to document attacks against an
      organization;

Top      ToC       Page 6 
   o  response activity taken or that could be taken in response to an
      incident; and

   o  metadata so that these various classes of information can be
      exchanged among parties.

   The purpose of the IODEF is to enhance the operational capabilities
   of CSIRTs.  Adoption of the IODEF will improve the ability of a CSIRT
   to resolve security incidents; understand threats; and coordinate
   response activities and proactive mitigations by simplifying
   collaboration and data sharing with its partners.  This structured
   format provided by the IODEF allows for:

   o  machine-to-machine exchange of incident and indicator data;

   o  automated processing of this data whereby allowing more rapid
      execution of appropriate courses of action; and

   o  the development of an ecosystem of interoperable tools enabling
      security operations.

   Sharing and coordinating with other organizations is not strictly a
   technical problem.  There are numerous procedural, cultural, legal,
   and trust-related barriers to overcome.  The IODEF does not attempt
   to address them directly.  However, operational implementations of
   the IODEF will need to consider these challenges.

   Section 1 provides the background for the IODEF.  Sections 3 and 8
   specify the IODEF information and data model, respectively.  The data
   types used in this document are described in Section 2.  Processing
   considerations, extending the specification, internationalization,
   and security issues are covered in Sections 4, 5, 6, and 9,
   respectively.  Examples are listed in Section 7.

1.1.  Terminology

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

1.2.  Notations

   The IODEF is specified as an Extensible Markup Language (XML)
   [W3C.XML] schema [W3C.SCHEMA].  The normative IODEF data model is
   found in the XML schema in Section 8.  To aid in the understanding of
   the data elements, Section 3 also depicts the underlying information
   model using Unified Modeling Language (UML).  This abstract
   presentation of the IODEF is not normative.

Top      ToC       Page 7 
   For clarity in this document, the term "XML document" will be used
   when referring generically to any instance of an XML document.  The
   term "IODEF document" will be used to refer to an XML document
   conforming to the IODEF specification.  The terms "schema" will be
   used to refer to Section 8 of this document.  The terms "data model"
   and "schema" will be used interchangeably.  The terms "class" and
   "element" will be used to reference either the corresponding data
   element in the UML-based information or XML schema-based data models,
   respectively.

1.3.  About the IODEF Data Model

   A number of considerations were made in the design of the IODEF data
   model.

   o  The data model found in this document is an evolution of the one
      previously specified in [RFC5070].  New fields were added to
      represent additional information.  [RFC5070] was developed
      primarily to represent incident reports.  This document builds
      upon it by adding support for indicators and revising it to
      reflect the current challenges faced by CSIRTs.  An attempt was
      made to preserve backward compatibility, but this was not possible
      in all cases.  See Section 4.4.  This document obsoletes
      [RFC5070].

   o  The IODEF is a transport format.  Therefore, the data model may
      not be the optimal archival or in-memory processing format.

   o  The IODEF is intended to be a framework to convey only commonly
      exchanged information.  It ensures that there are mechanisms for
      extensibility to support organization-specific information and
      techniques to reference information kept outside of the data
      model.

   o  Not all commonly exchanged information has a well-defined format
      or taxonomy.  The IODEF attempts to strike a balance between
      enforcing sufficient structure to allow automated processing and
      supporting free-form content that enables maximum flexibility.

   o  The IODEF fits into a broader ecosystem of standards and
      conventions.  An attempt was made to harmonize the data model with
      this context.

1.4.  Changes from RFC 5070

   A detailed list of additions made to the data model in [RFC5070] are
   enumerated in this section.  See Section 4.4 for a list of
   incompatible changes.

Top      ToC       Page 8 
   o  Updated the data types (Section 2) to improve
      internationalization, clarify ambiguity, and ensure consistency in
      extensions.

   o  Added the observable-id attribute (Section 3.3.2) and
      IndicatorData class (Section 3.28) to represent indicators.

   o  Added the private-enum-name and private-enum-id attributes to the
      IODEF-Document class (Section 3.1) to disambiguate private
      extensions.

   o  Updated the Incident class (Section 3.2) to represent additional
      timing and workflow information.

   o  Added the ThreatActor (Section 3.7) and Campaign (Section 3.8)
      classes to represent attack attribution information.

   o  Updated the Contact class (Section 3.9) and its children to
      improve internationalization and represent additional information
      about an entity.

   o  Updated the Method class (Section 3.11) to improve extensibility
      through externally referenced resources.

   o  Added the Discovery class (Section 3.10) to describe how an
      incident was discovered.

   o  Updated the Assessment class (Section 3.12) to enable more
      descriptive characterizations of the impact of an incident.

   o  Updated the HistoryItem (Section 3.13.1) and Expectation
      (Section 3.15) classes to support a reference to a course of
      action.

   o  Updated the EventData class (Section 3.14) with additional
      metadata added to the Incident class.

   o  Updated the System class (Section 3.17) with additional metadata.

   o  Updated the Counter class (Section 3.18.3) to support additional
      rate metrics.

   o  Added DomainData (Section 3.19), EmailData (Section 3.21),
      WindowsRegistryKeysModified (Section 3.23), CertificateData
      (Section 3.24), and FileData (Section 3.25) classes to improve the
      description of an incident and support this data as indicators.

Top      ToC       Page 9 
   o  Added the SignatureData (Section 3.27) and HashData (Section 3.26)
      classes to represent digital signatures and hashes.

   o  Added support for public enumerated attribute extensions using
      IANA registries (Section 5.1.2).

   o  Updated numerous enumerated attributes for completeness.

2.  IODEF Data Types

   The IODEF uses a number of simple and complex types.  This section
   describes these data types.

2.1.  Integers

   An integer is represented in the information model by the INTEGER
   data type.  Integer data MUST be encoded in Base 10.

   The INTEGER data type is implemented in the data model as an
   "xs:integer" type per Section 3.3.13 of [W3C.SCHEMA.DTYPES].

2.2.  Real Numbers

   A real (floating-point) number is represented in the information
   model by the REAL data type.  Real data MUST be encoded in Base 10.

   The REAL data type is implemented in the data model as an "xs:float"
   type per Section 3.2.4 of [W3C.SCHEMA.DTYPES].

2.3.  Characters and Strings

   A single character is represented in the information model by the
   CHARACTER data type.  A string is represented by the STRING data
   type.  Special characters MUST be encoded using entity references.
   See Section 4.1.

   The CHARACTER and STRING data types are implemented in the data model
   as an "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES].

2.4.  Multilingual Strings

   A string that needs to be represented in a human-readable language
   different than the default encoding of the document is represented in
   the information model by the ML_STRING data type.

   The ML_STRING data type is implemented in the data model as the
   "iodef:MLStringType" type.  This type extends the "xs:string" to
   include two attributes.

Top      ToC       Page 10 
   +------------------------+
   | iodef:MLStringType     |
   +------------------------+
   | xs:string              |
   |                        |
   | ENUM xml:lang          |
   | STRING translation-id  |
   +------------------------+

                   Figure 1: The iodef:MLStringType Type

   The content of the class is a character string of type "xs:string"
   whose language MAY be specified by the xml:lang attribute.

   The attributes of the iodef:MLStringType type are:

   xml:lang
      Optional.  ENUM.  A language identifier per Section 2.12 of
      [W3C.XML] whose values and format are described in [RFC5646].  The
      interpretation of this code is described in Section 6.

   translation-id
      Optional.  STRING.  An identifier to relate other instances of
      this class with the same parent as translations of this text.  The
      scope of this identifier is limited to all of the direct, peer
      child classes of a given parent class.

   Using this class enables representing translations of the same text
   in multiple languages.  Each translation is a distinct instance of
   this class with a common parent.  A group of classes each with a
   translated instance of text is related by setting a common identifier
   in the translation-id attribute.  The language of a given class is
   set by the xml:lang attribute.  See Section 6 for more details on
   representing translations of free-form text.

2.5.  Binary Strings

   Binary octets can be represented with two encodings.

2.5.1.  Base64 Bytes

   A binary octet encoded with base64 is represented in the information
   model by the BYTE data type.  A sequence of these octets is of the
   BYTE[] data type.

   The BYTE and BYTE[] data types are implemented in the data model as
   an "xs:base64Binary" type per Section 3.2.16 of [W3C.SCHEMA.DTYPES].

Top      ToC       Page 11 
2.5.2.  Hexadecimal Bytes

   A binary octet encoded as a character tuple consistent of two
   hexadecimal digits is represented in the information model by the
   HEXBIN data type.  A sequence of these octets is of the HEXBIN[] data
   type.

   The HEXBIN and HEXBIN[] data types are implemented in the data model
   as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES].

2.6.  Enumerated Types

   An enumerated type is represented in the information model by the
   ENUM data type.  It is an ordered list of acceptable string values.
   Each value has a representative keyword.  Within the data model, the
   enumerated type keywords are used as attribute values.

   The ENUM data type is implemented in the data model as values of an
   "xs:NMTOKEN" type per Section 3.3.4 of [W3C.SCHEMA.DTYPES].

2.7.  Date-Time String

   A date-time string that describes a particular instant in time is
   represented in the information model by the DATETIME data type.
   Ranges are not supported.

   The DATETIME data type is implemented in the data model as an
   "xs:dateTime" type per Section 3.2.7 of [W3C.SCHEMA.DTYPES].

2.8.  Timezone String

   A timezone offset from UTC is represented in the information model by
   the TIMEZONE data type.  It is formatted according to the following
   regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".

   The TIMEZONE data type is implemented in the data model as an
   "iodef:TimezoneType" type.

2.9.  Port Lists

   A list of network ports is represented in the information model by
   the PORTLIST data type.  A PORTLIST consists of a comma-separated
   list of numbers and ranges (N-M means ports N through M, inclusive).
   It is formatted according to the following regular expression:
   "\d+(\-\d+)?(,\d+(\-\d+)?)*".  For example,
   "2,5-15,30,32,40-50,55-60".

Top      ToC       Page 12 
   The PORTLIST data type is implemented in the data model as an
   "iodef:PortlistType" type.

2.10.  Postal Address

   A postal address is represented in the information model by the
   POSTAL data type.  The format of the POSTAL data type is documented
   in Section 2.23 of [RFC4519] as a free-form multi-line string
   separated by the "$" character.

   The POSTAL data type is implemented in the data model as an
   "iodef:MLStringType" type.

2.11.  Telephone Number

   A telephone number is represented in the information model by the
   PHONE data type.  The format of the PHONE data type is documented in
   [E.164].

   The PHONE data type is implemented in the data model as an
   "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES].

2.12.  Email String

   An email address is represented in the information model by the EMAIL
   data type.  The format of the EMAIL data type is documented in
   Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531].

   The EMAIL data type is implemented in the data model as an
   "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES].

2.13.  Uniform Resource Locator Strings

   A uniform resource locator (URL) is represented in the information
   model by the URL data type.  The format of the URL data type is
   documented in [RFC3986].

   The URL data type is implemented as an "xs:anyURI" type per
   Section 3.2.17 of [W3C.SCHEMA.DTYPES].

2.14.  Identifiers and Identifier References

   An identifier unique to the IODEF document is represented in the
   information model by the ID data type.  A reference to this
   identifier is represented by the IDREF data type.

Top      ToC       Page 13 
   The ID and IDREF data types are implemented in the model as "xs:ID"
   and "xs:IDREF" types per Sections 3.3.8 and 3.3.9 of
   [W3C.SCHEMA.DTYPES].

2.15.  Software

   A particular version of software is represented in the information
   model by the SOFTWARE data type.  This software can be described by
   using a reference, a URL, or with free-form text.

   The SOFTWARE data type is implemented in the data model as the
   "iodef:SoftwareType" type.

   +--------------------+
   | iodef:SoftwareType |
   +--------------------+
   |                    |<>--{0..1}--[ SoftwareReference ]
   |                    |<>--{0..*}--[ URL               ]
   |                    |<>--{0..*}--[ Description       ]
   +--------------------+

                      Figure 2: The SoftwareType Type

   The aggregate classes of the SoftwareType type are:

   SoftwareReference
      Zero or one.  Reference to a software application.  See
      Section 2.15.1.

   URL
      Zero or more.  URL.  A URL to a resource describing the software.

   Description
      Zero or more.  ML_STRING.  A free-form text description of the
      software.

   At least one of these classes MUST be present.

   The iodef:SoftwareType type has no attributes.

Top      ToC       Page 14 
2.15.1.  SoftwareReference Class

   The SoftwareReference class is a reference to a particular version of
   software.

   +----------------------+
   | SoftwareReference    |
   +----------------------+
   | xs:any               |
   |                      |
   | ENUM spec-name       |
   | STRING ext-spec-name |
   | ENUM dtype           |
   | STRING ext-dtype     |
   +----------------------+

                   Figure 3: The SoftwareReference Class

   The element content varies according to the value of the spec-name
   attribute.  It is defined in the data model as "xs:any" per
   [W3C.SCHEMA].

   The attributes of the SoftwareReference class are:

   spec-name
      Required.  ENUM.  Identifies the format and semantics of the
      element body of this class.  Formal standards and specifications
      can be referenced as well as a free-form text description with a
      user-provided data type.  These values are maintained in the
      "SoftwareReference-spec-id" IANA registry per Section 10.2

      1.  custom.  The element content is free-form and of the data type
          specified by the dtype attribute.  If this value is selected,
          then the dtype attribute MUST be set.

      2.  cpe.  The element content describes a Common Platform
          Enumeration (CPE) entry per [NIST.CPE].

      3.  swid.  The element content describes a software identification
          (SWID) tag per [ISO19770].

      4.  ext-value.  A value used to indicate that this attribute is
          extended and the actual value is provided using the
          corresponding ext-* attribute.  See Section 5.1.1.

Top      ToC       Page 15 
   ext-spec-name
      Optional.  STRING.  A means by which to extend the spec-name
      attribute.  See Section 5.1.1.

   dtype
      Optional.  ENUM.  The data type of the element content.  The
      permitted values for this attribute are shown below.  The default
      value is "string".  These values are maintained in the
      "SoftwareReference-dtype" IANA registry per Section 10.2.

      1.  bytes.  The element content is of type HEXBIN.

      2.  integer.  The element content is of type INTEGER.

      3.  real.  The element content is of type REAL.

      4.  string.  The element content is of type STRING.

      5.  xml.  The element content is XML.  See Section 5.2.

      6.  ext-value.  A value used to indicate that this attribute is
          extended and the actual value is provided using the
          corresponding ext-* attribute.  See Section 5.1.1.

   ext-dtype
      Optional.  STRING.  A means by which to extend the dtype
      attribute.  See Section 5.1.1.

2.16.  Extension

   Information not otherwise represented in the IODEF can be added using
   the EXTENSION data type.  This data type is a generic extension
   mechanism.

   The EXTENSION data type is implemented in the data model as the
   "iodef:ExtensionType" type.

   The data type of an EXTENSION is described by the dtype attribute.
   For simple information, atomic data types (e.g., integers, strings)
   are supported.  Their semantics are further described by the meaning
   and formatid attributes.  Encapsulating XML documents conforming to
   another schema is also supported.  A detailed discussion of extending
   the schema can be found in Section 5.  Additional coordination may be
   required to ensure that a recipient of a document using this type can
   parse and process it.

Top      ToC       Page 16 
   +------------------------+
   | iodef:ExtensionType    |
   +------------------------+
   | xs:any                 |
   |                        |
   | STRING name            |
   | ENUM dtype             |
   | STRING ext-dtype       |
   | STRING meaning         |
   | STRING formatid        |
   | ENUM restriction       |
   | STRING ext-restriction |
   | ID observable-id       |
   +------------------------+

                  Figure 4: The iodef:ExtensionType Type

   The element content of this type is the extension being added to the
   data model.  This content is defined in the data model as "xs:any"
   per [W3C.SCHEMA].

   The attributes of the iodef:ExtensionType type are:

   name
      Optional.  STRING.  A free-form name of the field or data element.

   dtype
      Required.  ENUM.  The data type of the element content.  The
      default value is "string".  These values are maintained in the
      "ExtensionType-dtype" IANA registry per Section 10.2.

      1.   boolean.  The element content is of type BOOLEAN.

      2.   byte.  The element content is of type BYTE.

      3.   bytes.  The element content is of type HEXBIN.

      4.   character.  The element content is of type CHARACTER.

      5.   date-time.  The element content is of type DATETIME.

      6.   ntpstamp.  Same as date-time.

      7.   integer.  The element content is of type INTEGER.

      8.   portlist.  The element content is of type PORTLIST.

      9.   real.  The element content is of type REAL.

Top      ToC       Page 17 
      10.  string.  The element content is of type STRING.

      11.  file.  The element content is a base64-encoded binary file
           encoded as a BYTE[] type.

      12.  path.  The element content is a file-system path encoded as a
           STRING type.

      13.  frame.  The element content is a Layer 2 frame encoded as a
           HEXBIN type.

      14.  packet.  The element content is a Layer 3 packet encoded as a
           HEXBIN type.

      15.  ipv4-packet.  The element content is an IPv4 packet encoded
           as a HEXBIN type.

      16.  ipv6-packet.  The element content is an IPv6 packet encoded
           as a HEXBIN type.

      17.  url.  The element content is of type URL.

      18.  csv.  The element content is a comma-separated value (CSV)
           list per Section 2 of [RFC4180] encoded as a STRING type.

      19.  winreg.  The element content is a Microsoft Windows registry
           key encoded as a STRING type.

      20.  xml.  The element content is XML.  See Section 5.2.

      21.  ext-value.  A value used to indicate that this attribute is
           extended and the actual value is provided using the
           corresponding ext-* attribute.  See Section 5.1.1.

   ext-dtype
      Optional.  STRING.  A means by which to extend the dtype
      attribute.  See Section 5.1.1.

   meaning
      Optional.  STRING.  A free-form text description of the element
      content.

   formatid
      Optional.  STRING.  An identifier referencing the format or
      semantics of the element content.

Top      ToC       Page 18 
   restriction
      Optional.  ENUM.  See Section 3.3.1.

   ext-restriction
      Optional.  STRING.  A means by which to extend the restriction
      attribute.  See Section 5.1.1.

   observable-id
      Optional.  ID.  See Section 3.3.2.



(page 18 continued on part 2)

Next Section