RFC 7970
The Incident Object Description Exchange Format Version 2
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 2Abstract
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.
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.
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
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
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 . . . . . . . . . . . . . . . . . . . . . . . . 1721. 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;
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.
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.
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.
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.
+------------------------+ | 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].
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".
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.
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.
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.
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.
+------------------------+ | 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.
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.
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)
