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.
Danyliw Standards Track [Page 1]
RFC 7970 IODEF Version 2 November 2016
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.
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;
Danyliw Standards Track [Page 5]
RFC 7970 IODEF Version 2 November 2016
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.
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].
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.
Danyliw Standards Track [Page 6]
RFC 7970 IODEF Version 2 November 2016
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.
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.
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.
Danyliw Standards Track [Page 7]
RFC 7970 IODEF Version 2 November 2016
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.
Danyliw Standards Track [Page 8]
RFC 7970 IODEF Version 2 November 2016
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.
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].
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.
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.
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].
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].
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].
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].
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.
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".
Danyliw Standards Track [Page 11]
RFC 7970 IODEF Version 2 November 2016
The PORTLIST data type is implemented in the data model as an "iodef:PortlistType" type.
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.
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].
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].
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.
Danyliw Standards Track [Page 12]
RFC 7970 IODEF Version 2 November 2016
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].
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.
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.
Danyliw Standards Track [Page 14]
RFC 7970 IODEF Version 2 November 2016
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.
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.
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.
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.
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.
The specifics of the IODEF information model are discussed in this section. Each class and its relationships with the other classes is described. When necessary, clarifications are made about translating this information model to the schema in Section 8.
The aggregate classes of the IODEF-Document class are:
Incident One or more. The information related to a single incident. See Section 3.2.
AdditionalData Zero or more. EXTENSION. Mechanism by which to extend the data model.
Danyliw Standards Track [Page 18]
RFC 7970 IODEF Version 2 November 2016
The attributes of the IODEF-Document class are:
version Required. STRING. The IODEF specification version number to which this IODEF document conforms. The value of this attribute MUST be "2.00".
xml:lang Optional. ENUM. A language identifier per Section 2.12 of [W3C.XML] whose values and form are described in [RFC5646]. The interpretation of this code is described in Section 6.
format-id Optional. STRING. A free-form string to convey processing instructions to the recipient of the document. Its semantics must be negotiated out of band.
private-enum-name Optional. STRING. A globally unique identifier for the CSIRT generating the document to deconflict private extensions used in the document. The fully qualified domain name (FQDN) associated with the CSIRT MUST be used as the identifier. See Section 5.3.
private-enum-id Optional. STRING. An organizationally unique identifier for an extension used in the document. If this attribute is set, the private-enum-name MUST also be set. See Section 5.3.
IncidentID One. An incident tracking number assigned to this incident by the CSIRT that generated the IODEF document. See Section 3.4.
AlternativeID Zero or one. The incident tracking numbers used by other CSIRTs to refer to the incident described in the document. See Section 3.5.
RelatedActivity Zero or more. Related activity and attribution of this activity. See Section 3.6.
DetectTime Zero or one. DATETIME. The time the incident was first detected.
Danyliw Standards Track [Page 20]
RFC 7970 IODEF Version 2 November 2016
StartTime Zero or one. DATETIME. The time the incident started.
EndTime Zero or one. DATETIME. The time the incident ended.
RecoveryTime Zero or one. DATETIME. The time the site recovered from the incident.
ReportTime Zero or one. DATETIME. The time the incident was reported.
GenerationTime One. DATETIME. The time the content in this Incident class was generated.
Description Zero or more. ML_STRING. A free-form text description of the incident.
Discovery Zero or more. The means by which this incident was detected. See Section 3.10.
Assessment Zero or more. A characterization of the impact of the incident. See Section 3.12.
Method Zero or more. The techniques used by the threat actor in the incident. See Section 3.11.
Contact One or more. Contact information for the parties involved in the incident. See Section 3.9.
EventData Zero or more. Description of the events comprising the incident. See Section 3.14.
IndicatorData Zero or one. Indicators from the analysis of an incident. See Section 3.28.
History Zero or one. A log of significant events or actions that occurred during the course of handling the incident. See Section 3.13.
Danyliw Standards Track [Page 21]
RFC 7970 IODEF Version 2 November 2016
AdditionalData Zero or more. EXTENSION. Mechanism by which to extend the data model.
The attributes of the Incident class are:
purpose Required. ENUM. The purpose attribute describes the rationale for documenting the information in this class. It is closely related to the Expectation class (Section 3.15). These values are maintained in the "Incident-purpose" IANA registry per Section 10.2. This attribute is defined as an enumerated list:
1. traceback. The incident was sent for trace-back purposes.
2. mitigation. The incident was sent to request aid in mitigating the described activity.
3. reporting. The incident was sent to comply with reporting requirements.
4. watch. The incident was sent to convey indicators that should be monitored.
5. other. The incident was sent for purposes specified in the Expectation class.
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-purpose Optional. STRING. A means by which to extend the purpose attribute. See Section 5.1.1.
status Optional. ENUM. The status attribute conveys the state in a workflow where the incident is currently found. These values are maintained in the "Incident-status" IANA registry per Section 10.2. This attribute is defined as an enumerated list:
1. new. The incident is newly reported, and no action has been taken.
2. in-progress. The incident is under investigation.
3. forwarded. The incident has been forwarded to another party for handling.
Danyliw Standards Track [Page 22]
RFC 7970 IODEF Version 2 November 2016
4. resolved. The investigation into the activity in this incident has concluded.
5. future. The described activity has not yet been detected.
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-status Optional. STRING. A means by which to extend the status attribute. See Section 5.1.1.
xml:lang Optional. ENUM. A language identifier per Section 2.12 of [W3C.XML] whose values and form are described in [RFC5646]. The interpretation of this code is described in Section 6.
restriction Optional. ENUM. See Section 3.3.1. The default value is "private".
ext-restriction Optional. STRING. A means by which to extend the restriction attribute. See Section 5.1.1.
The restriction attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere for the information represented in this class and its children. This guideline provides no security since there are no technical means to ensure that the recipient of the document handles the information as the sender requested.
The value of this attribute is logically inherited by the children of this class. That is to say, the disclosure rules applied to this class also apply to its children.
Danyliw Standards Track [Page 23]
RFC 7970 IODEF Version 2 November 2016
It is possible to set a granular disclosure policy, since all of the high-level classes (i.e., children of the Incident class) have a restriction attribute. Therefore, a child can override the guidelines of a parent class, be it to restrict or relax the disclosure rules (e.g., a child has a weaker policy than an ancestor; or an ancestor has a weak policy, and the children selectively apply more rigid controls). The implicit value of the restriction attribute for a class that did not specify one can be found in the closest ancestor that did specify a value.
This attribute is defined as an enumerated value with a default value of "private". Note that the default value of the restriction attribute is only defined in the context of the Incident class. In other classes where this attribute is used, no default is specified.
These values are maintained in the "Restriction" IANA registry per Section 10.2.
1. public. The information can be freely distributed without restriction.
2. partner. The information may be shared within a closed community of peers, partners, or affected parties, but cannot be openly published.
3. need-to-know. The information may be shared only within the organization with individuals that have a need to know.
4. private. The information may not be shared.
5. default. The information can be shared according to an information disclosure policy pre-arranged by the communicating parties.
6. white. Same as 'public'.
7. green. Same as 'partner'.
8. amber. Same as 'need-to-know'.
9. red. Same as 'private'.
10. 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.
The observable-id attribute tags information in the document as an observable so that it can be referenced later in the description of an indicator. The value of this attribute is a unique identifier in the scope of the document. It is used by the ObservableReference class to enumerate observables when defining an indicator with the IndicatorData class.
The IncidentID class represents a tracking number that is unique in the context of the CSIRT. It serves as an identifier for an incident or a document identifier when sharing indicators. This identifier would serve as an index into a CSIRT's incident handling or knowledge management system.
The combination of the name attribute and the string in the element content MUST be a globally unique identifier describing the activity. Documents generated by a given CSIRT MUST NOT reuse the same value unless they are referencing the same incident.
The content of the class is an incident identifier of type STRING.
The attributes of the IncidentID class are:
name Required. STRING. An identifier describing the CSIRT that created the document. In order to have a globally unique CSIRT name, the fully qualified domain name associated with the CSIRT MUST be used.
Danyliw Standards Track [Page 25]
RFC 7970 IODEF Version 2 November 2016
instance Optional. STRING. An identifier referencing a subset of the named incident.
The AlternativeID class lists the tracking numbers used by CSIRTs, other than the one generating the document, to refer to the identical activity described in the IODEF document. A tracking number listed as an AlternativeID references the same incident detected by another CSIRT. The tracking numbers of the CSIRT that generated the IODEF document must never be considered an AlternativeID.
The RelatedActivity class relates the information described in the rest of the document to previously observed incidents or activity and allows attribution to a specific actor or campaign.
The aggregate classes of the RelatedActivity class are:
IncidentID Zero or more. The tracking number of a related incident. See Section 3.4.
URL Zero or more. URL. A URL to activity related to this incident.
ThreatActor Zero or more. The threat actor to whom the incident activity is attributed. See Section 3.7.
Campaign Zero or more. The campaign of a given threat actor to whom the described activity is attributed. See Section 3.8.
IndicatorID Zero or more. A reference to a related indicator. See Section 3.4.
Confidence Zero or one. An estimate of the confidence in attributing this RelatedActivity to the events described in the document. See Section 3.12.5.
Danyliw Standards Track [Page 27]
RFC 7970 IODEF Version 2 November 2016
Description Zero or more. ML_STRING. A description of how these relationships were derived.
AdditionalData Zero or more. EXTENSION. A mechanism by which to extend the data model.
The RelatedActivity class MUST have at least one instance of any of the following child classes: IncidentID, URL, ThreatActor, Campaign, Description, or AdditionalData.
The Contact class describes contact information for organizations and personnel involved in the incident. This class allows for the naming of the involved party, specifying contact information for them, and identifying their role in the incident.
People and organizations are treated interchangeably as contacts; one can be associated with the other using the recursive definition of the class (the Contact class is aggregated into the Contact class). The type attribute disambiguates the type of contact information being provided.
The recursive definition of Contact provides a way to relate information without requiring the explicit use of identifiers or duplication of data. A complete point of contact is derived by a particular traversal from the root Contact class to the leaf Contact class. Each child Contact class logically inherits contact information from its ancestors.
ContactName Zero or more. ML_STRING. The name of the contact. The contact may either be an organization or a person. The type attribute disambiguates the semantics.
ContactTitle Zero or more. ML_STRING. The title for the individual named in the ContactName.
Description Zero or more. ML_STRING. A free-form text description of the contact.
RegistryHandle Zero or more. A handle name into the registry of the contact. See Section 3.9.1.
PostalAddress Zero or more. The postal address of the contact. See Section 3.9.2.
Email Zero or more. The email address of the contact. See Section 3.9.3.
Telephone Zero or more. The telephone number of the contact. See Section 3.9.4.
Timezone Zero or one. TIMEZONE. The timezone in which the contact resides.
Contact Zero or more. A recursive definition of the Contact class. This definition can be used to group common data pertaining to multiple points of contact and is especially useful when listing multiple contacts at the same organization.
AdditionalData Zero or more. EXTENSION. A mechanism by which to extend the data model.
At least one of the aggregate classes MUST be present in an instance of the Contact class.
Danyliw Standards Track [Page 31]
RFC 7970 IODEF Version 2 November 2016
The attributes of the Contact class are:
role Required. ENUM. Indicates the role the contact fulfills. These values are maintained in the "Contact-role" IANA registry per Section 10.2.
1. creator. The entity that generates the document.
2. reporter. The entity that reported the information.
3. admin. An administrative contact or business owner for an asset or organization.
4. tech. An entity responsible for the day-to-day management of technical issues for an asset or organization.
5. provider. An external hosting provider for an asset.
6. user. An end-user of an asset or part of an organization.
7. billing. An entity responsible for billing issues for an asset or organization.
8. legal. An entity responsible for legal issues related to an asset or organization.
9. irt. An entity responsible for handling security issues for an asset or organization.
10. abuse. An entity responsible for handling abuse originating from an asset or organization.
11. cc. An entity that is to be kept informed about the events related to an asset or organization.
12. cc-irt. A CSIRT or information-sharing organization coordinating activity related to an asset or organization.
13. leo. A law enforcement organization supporting the investigation of activity affecting an asset or organization.
14. vendor. The vendor that produces an asset.
15. vendor-support. A vendor that provides services.
16. victim. A victim in the incident.
Danyliw Standards Track [Page 32]
RFC 7970 IODEF Version 2 November 2016
17. victim-notified. A victim in the incident who has been notified.
18. 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-role Optional. STRING. A means by which to extend the role attribute. See Section 5.1.1.
type Required. ENUM. Indicates the type of contact being described. This attribute is defined as an enumerated list. These values are maintained in the "Contact-type" IANA registry per Section 10.2.
1. person. The information for this contact references an individual.
2. organization. The information for this contact references an organization.
3. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
The content of the class is a handle into a registry of type STRING.
The attributes of the RegistryHandle class are:
registry Required. ENUM. The database to which the handle belongs. These values are maintained in the "RegistryHandle-registry" IANA registry per Section 10.2. The possible values are:
1. internic. Internet Network Information Center
2. apnic. Asia Pacific Network Information Center
3. arin. American Registry for Internet Numbers
4. lacnic. Latin American and Caribbean Internet Addresses Registry
5. ripe. Reseaux IP Europeens
6. afrinic. African Network Information Center
7. local. A database local to the CSIRT
8. 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-registry Optional. STRING. A means by which to extend the registry attribute. See Section 5.1.1.
The aggregate classes of the PostalAddress class are:
PAddress One. POSTAL. A postal address.
Description Zero or more. ML_STRING. A free-form text description of the address.
The attributes of the PostalAddress class are:
type Optional. ENUM. Categorizes the type of address described in the PAddress class. These values are maintained in the "PostalAddress-type" IANA registry per Section 10.2.
1. street. An address describing a physical location.
2. mailing. An address to which correspondence should be sent.
3. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
Description Zero or more. ML_STRING. A free-form text description of the email address.
The attributes of the Email class are:
type Optional. ENUM. Categorizes the type of email address described in the EmailTo class. These values are maintained in the "Email- type" IANA registry per Section 10.2.
1. direct. An email address of an individual.
2. hotline. An email address regularly monitored for operational purposes.
3. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
Description Zero or more. ML_STRING. A free-form text description of the phone number.
The attributes of the Telephone class are:
type Optional. ENUM. Categorizes the type of telephone number described in the TelephoneNumber class. These values are maintained in the "Telephone-type" IANA registry per Section 10.2.
1. wired. A number of a wire-line (land-line) phone.
2. mobile. A number of a mobile phone.
3. fax. A number to a fax machine.
4. hotline. A number to a regularly monitored operational hotline.
5. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
Description Zero or more. ML_STRING. A free-form text description of how this incident was detected.
Contact Zero or more. Contact information for the party that discovered the incident. See Section 3.9.
DetectionPattern Zero or more. Describes an application-specific configuration that detected the incident. See Section 3.10.1.
The attributes of the Discovery class are:
source Optional. ENUM. Categorizes the techniques used to discover the incident. These values are partially derived from Table 3-1 of [NIST800.61rev2]. These values are maintained in the "Discovery- source" IANA registry per Section 10.2.
1. nidps. Network Intrusion Detection or Prevention System.
2. hips. Host-based Intrusion Prevention System.
3. siem. Security Information and Event Management System.
6. incident. The activity was discovered while investigating an unrelated incident.
7. os-log. Operating system logs.
8. application-log. Application logs.
9. device-log. Network device logs.
10. network-flow. Network flow analysis.
11. passive-dns. Passive DNS analysis.
12. investigation. Manual investigation initiated based on notification of a new vulnerability or exploit.
13. audit. Security audit.
14. internal-notification. A party within the organization reported the activity.
15. external-notification. A party outside of the organization reported the activity.
16. leo. A law enforcement organization notified the victim organization.
17. partner. A customer or business partner reported the activity to the victim organization.
18. actor. The threat actor directly or indirectly reported this activity to the victim organization.
19. unknown. Unknown detection approach.
20. 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-source Optional. STRING. A means by which to extend the source attribute. See Section 5.1.1.
The DetectionPattern class describes a configuration or signature that can be used by an Intrusion Detection System (IDS) / Intrusion Prevention System (IPS), SIEM, antivirus, endpoint protection, network analysis, malware analysis, or host forensics tool to identify a particular phenomenon. This class requires the identification of the target application and allows the configuration to be described in either free form or machine-readable form.
The aggregate classes of the DetectionPattern class are:
Application One. SOFTWARE. The application for which the DetectionConfiguration or Description is being provided.
Description Zero or more. ML_STRING. A free-form text description of how to use the information provided in the Application or DetectionConfiguration classes.
DetectionConfiguration Zero or more. STRING. A machine-consumable configuration to find a pattern of activity.
An instance of either the Description or DetectionConfiguration class MUST be present.
The Method class describes the tactics, techniques, procedures, or weakness used by the threat actor in an incident. This class consists of both a list of references describing the attack methods and weaknesses and a free-form text description.
The Reference class is an external reference to relevant information such as a vulnerability, IDS alert, malware sample, advisory, or attack technique.
The aggregate classes of the Assessment class are:
IncidentCategory Zero or more. ML_STRING. A free-form text description categorizing the type of incident.
SystemImpact Zero or more. A technical characterization of the impact of the incident activity on the victim's enterprise. See Section 3.12.1.
BusinessImpact Zero or more. Impact of the incident activity on the business functions of the victim organization. See Section 3.12.2.
TimeImpact Zero or more. A characterization of the victim organization due to the incident activity as a function of time. See Section 3.12.3.
Danyliw Standards Track [Page 43]
RFC 7970 IODEF Version 2 November 2016
MonetaryImpact Zero or more. The financial loss due to the incident activity. See Section 3.12.4.
IntendedImpact Zero or more. The intended outcome to the victim sought by the threat actor. Defined identically to the BusinessImpact defined in Section 3.12.2 but describes intent rather than the realized impact.
Counter Zero or more. A counter with which to summarize the magnitude of the activity. See Section 3.18.3.
MitigatingFactor Zero or more. ML_STRING. A description of a mitigating factor relative to the impact on the victim organization.
Cause Zero or more. ML_STRING. A description of an underlying cause of the impact.
Confidence Zero or one. An estimate of confidence in the impact assessment. See Section 3.12.5.
AdditionalData Zero or more. EXTENSION. A mechanism by which to extend the data model.
At least one instance of the possible five impact classes (i.e., SystemImpact, BusinessImpact, TimeImpact, MonetaryImpact, or IntendedImpact) MUST be present.
The attributes of the Assessment class are:
occurrence Optional. ENUM. Specifies whether the assessment is describing actual or potential outcomes.
1. actual. This assessment describes activity that has occurred.
2. potential. This assessment describes potential activity that might occur.
Description Zero or more. ML_STRING. A free-form text description of the impact to the system.
The attributes of the SystemImpact class are:
severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
Danyliw Standards Track [Page 45]
RFC 7970 IODEF Version 2 November 2016
completion Optional. ENUM. An indication whether the described activity was successful. The permitted values are shown below. There is no default value.
1. failed. The attempted activity was not successful.
2. succeeded. The attempted activity succeeded.
type Required. ENUM. Classifies the impact. The permitted values are shown below. The default value is "unknown". These values are maintained in the "SystemImpact-type" IANA registry per Section 10.2.
1. takeover-account. Control was taken of a given account.
2. takeover-service. Control was taken of a given service.
3. takeover-system. Control was taken of a given system.
4. cps-manipulation. A cyber-physical system was manipulated.
5. cps-damage. A cyber-physical system was damaged.
6. availability-data. Access to particular data was degraded or denied.
7. availability-account. Access to an account was degraded or denied.
8. availability-service. Access to a service was degraded or denied.
9. availability-system. Access to a system was degraded or denied.
10. damaged-system. Hardware on a system was irreparably damaged.
11. damaged-data. Data on a system was deleted.
12. breach-proprietary. Sensitive or proprietary information was accessed or exfiltrated.
13. breach-privacy. Personally identifiable information was accessed or exfiltrated.
Danyliw Standards Track [Page 46]
RFC 7970 IODEF Version 2 November 2016
14. breach-credential. Credential information was accessed or exfiltrated.
15. breach-configuration. System configuration or data inventory was access or exfiltrated.
16. integrity-data. Data on the system was modified.
17. integrity-configuration. Application or system configuration was modified.
18. integrity-hardware. Firmware of a hardware component was modified.
19. traffic-redirection. Network traffic on the system was redirected
20. monitoring-traffic. Network traffic emerging from a host or enclave was monitored.
21. monitoring-host. System activity (e.g., running processes, keystrokes) were monitored.
22. policy. Activity violated the system owner's acceptable use policy.
24. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
The aggregate class of the BusinessImpact class is:
Description Zero or more. ML_STRING. A free-form text description of the impact to the organization.
The attributes of the BusinessImpact class are:
severity Optional. ENUM. Characterizes the severity of the incident on business functions. The permitted values are shown below. They were derived from Table 3-2 of [NIST800.61rev2]. The default value is "unknown". These values are maintained in the "BusinessImpact-severity" IANA registry per Section 10.2.
1. none. No effect to the organization's ability to provide all services to all users.
2. low. Minimal effect as the organization can still provide all critical services to all users but has lost efficiency.
3. medium. The organization has lost the ability to provide a critical service to a subset of system users.
4. high. The organization is no longer able to provide some critical services to any users.
5. unknown. The impact is not known.
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.
Danyliw Standards Track [Page 48]
RFC 7970 IODEF Version 2 November 2016
ext-severity Optional. STRING. A means by which to extend the severity attribute. See Section 5.1.1.
type Required. ENUM. Characterizes the effect this incident had on the business. The permitted values are shown below. The default value is "unknown". These values are maintained in the "BusinessImpact-type" IANA registry per Section 10.2.
1. breach-proprietary. Sensitive or proprietary information was accessed or exfiltrated.
2. breach-privacy. Personally identifiable information was accessed or exfiltrated.
3. breach-credential. Credential information was accessed or exfiltrated.
4. loss-of-integrity. Sensitive or proprietary information was changed or deleted.
5. loss-of-service. Service delivery was disrupted.
6. theft-financial. Money was stolen.
7. theft-service. Services were misappropriated.
8. degraded-reputation. The reputation of the organization's brand was diminished.
9. asset-damage. A cyber-physical system was damaged.
10. asset-manipulation. A cyber-physical system was manipulated.
11. legal. The incident resulted in legal or regulatory action.
12. extortion. The incident resulted in actors extorting the victim organization.
13. unknown. The impact is unknown.
14. 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.
Danyliw Standards Track [Page 49]
RFC 7970 IODEF Version 2 November 2016
ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
The TimeImpact class describes the impact of the incident on an organization as a function of time. It provides a way to convey down time and recovery time.
The content of the class is of type REAL and specifies an amount of time. The duration attribute provides units for this content, and the metric attribute explains what this content is measuring.
The attributes of the TimeImpact class are:
severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
metric Required. ENUM. Defines the meaning of the value in the element content. These values are maintained in the "TimeImpact-metric" IANA registry per Section 10.2.
1. labor. Total staff time to recovery from the activity (e.g., 2 employees working 4 hours each would be 8 hours).
Danyliw Standards Track [Page 50]
RFC 7970 IODEF Version 2 November 2016
2. elapsed. Elapsed time from the beginning of the recovery to its completion (i.e., wall-clock time).
3. downtime. Duration of time for which some provided service(s) was not available.
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-metric Optional. STRING. A means by which to extend the metric attribute. See Section 5.1.1.
duration Optional. ENUM. Defines the unit of time for the value in the element content. The default value is "hour". These values are maintained in the "TimeImpact-duration" IANA registry per Section 10.2.
1. second. The unit of the element content is seconds.
2. minute. The unit of the element content is minutes.
3. hour. The unit of the element content is hours.
4. day. The unit of the element content is days.
5. month. The unit of the element content is months.
6. quarter. The unit of the element content is quarters.
7. year. The unit of the element content is years.
8. 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-duration Optional. STRING. A means by which to extend the duration attribute. See Section 5.1.1.
The MonetaryImpact class describes the financial impact of the activity on an organization. For example, this impact may consider losses due to the cost of the investigation or recovery, diminished productivity of the staff, or a tarnished reputation that will affect future opportunities.
The content of the class is of type REAL and specifies a quantity of money. The currency attribute defines the currency of this value.
The attributes of the MonetaryImpact class are:
severity Optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
1. low. Low severity
2. medium. Medium severity
3. high. High severity
currency Optional. STRING. Defines the currency in which the value in the element content is expressed. The permitted values are defined in "Codes for the representation of currencies" [ISO4217]. There is no default value.
The Confidence class represents an estimate of the validity and accuracy of data expressed in the document. This estimate can be expressed as a category or a numeric calculation.
The content of the class is of type REAL and specifies a numerical assessment in the confidence of the data when the value of the rating attribute is "numeric". Otherwise, this element MUST be empty.
The attributes of the Confidence class are:
rating Required. ENUM. A qualitative assessment of confidence. These values are maintained in the "Confidence-rating" IANA registry per Section 10.2
1. low. Low confidence.
2. medium. Medium confidence.
3. high. High confidence.
4. numeric. The element content contains a number that conveys the confidence of the data. The semantics of this number is outside the scope of this specification.
5. unknown. The confidence rating value is not known.
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-rating Optional. STRING. A means by which to extend the rating attribute. See Section 5.1.1.
The HistoryItem class is an entry in the History (Section 3.13) log that documents a particular action or event that occurred in the course of handling the incident. The details of the entry are a free-form text description, but each can be categorized with the type attribute.
The aggregate classes of the HistoryItem class are:
DateTime One. DATETIME. A timestamp of this entry in the history log.
IncidentID Zero or one. In a history log created by multiple parties, the IncidentID provides a mechanism to specify which CSIRT created a particular entry and references this organization's tracking number. When a single organization is maintaining the log, this class can be ignored. See Section 3.4.
Contact Zero or one. Provides contact information for the entity that performed the action documented in this class. See Section 3.9.
Description Zero or more. ML_STRING. A free-form text description of the action or event.
DefinedCOA Zero or more. STRING. An identifier meaningful to the sender and recipient of this document that references a course of action (COA). This class MUST be present if the action attribute is set to "defined-coa".
AdditionalData Zero or more. EXTENSION. A mechanism by which to extend the data model.
Danyliw Standards Track [Page 55]
RFC 7970 IODEF Version 2 November 2016
The attributes of the HistoryItem class are:
action Required. ENUM. Classifies a performed action or occurrence documented in this history log entry. As activity will likely have been instigated either through a previously conveyed expectation or through an internal investigation, this attribute is identical to the action attribute of the Expectation class. The difference is only one of tense. When an action is in this class, it has been completed. See Section 3.15.
ext-action Optional. STRING. A means by which to extend the action attribute. See Section 5.1.1.
3.14.1. Relating the Incident and EventData Classes
There is substantial overlap in the child classes aggregated in the Incident and EventData classes. Nevertheless, the semantics of these classes are quite different. The Incident class provides summary information about the entire incident, while the EventData class provides information about the individual events comprising the incident. In the common case, the EventData class will provide more specific information for the general description provided in the Incident class. However, in the case where the summarized information in the Incident class conflicts with the detailed information in an EventData class, the more specific EventData class MUST supersede the more generic information provided in the Incident class.
The EventData class is a container for the properties of an event in an incident. These properties include: the hosts involved, impact of the incident activity on the hosts, forensic logs, etc. The recursive definition of EventData allows for the grouping of related information with common properties. This approach eliminates the need for explicit identifiers to relate information or duplicate it. Instead, the relative depth (nesting) of a class is used to group (relate) information.
For example, consider a case where two hosts experience different impacts during an incident. However, these two hosts have common contact information. A depiction of how this situation would be represented can be found in Figure 30. EventData (2) and (3) group each of the two hosts with their unique impact. EventData (1) describes the common Contact class these two hosts share.
The aggregate classes of the Expectation class are:
Description Zero or more. ML_STRING. A free-form text description of the desired action(s).
DefinedCOA Zero or more. STRING. A unique identifier meaningful to the sender and recipient of this document that references a course of action. This class MUST be present if the action attribute is set to "defined-coa".
Danyliw Standards Track [Page 60]
RFC 7970 IODEF Version 2 November 2016
StartTime Zero or one. DATETIME. The time at which the sender would like the action performed. A timestamp that is earlier than the ReportTime specified in the Incident class denotes that the sender would like the action performed as soon as possible. The absence of this element indicates no expectations of when the recipient would like the action performed.
EndTime Zero or one. DATETIME. The time by which the sender expects the recipient to complete the action. If the recipient cannot complete the action before EndTime, the recipient MUST NOT carry out the action. Because of transit delays and clock drift, the sender MUST be prepared for the recipient to have carried out the action, even if it completes past EndTime.
Contact Zero or one. The entity expected to perform the action. See Section 3.9.
The attributes of the Expectation class are:
action Optional. ENUM. Classifies the type of action requested. The default value of "other". These values are maintained in the "Expectation-action" IANA registry per Section 10.2.
1. nothing. No action is requested. Do nothing with the information.
2. contact-source-site. Contact the site(s) identified as the source of the activity.
3. contact-target-site. Contact the site(s) identified as the target of the activity.
4. contact-sender. Contact the originator of the document.
5. investigate. Investigate the system(s) listed in the event.
6. block-host. Block traffic from the machine(s) listed as sources in the event.
7. block-network. Block traffic from the network(s) lists as sources in the event.
8. block-port. Block the port listed as sources in the event.
Danyliw Standards Track [Page 61]
RFC 7970 IODEF Version 2 November 2016
9. rate-limit-host. Rate-limit the traffic from the machine(s) listed as sources in the event.
10. rate-limit-network. Rate-limit the traffic from the network(s) lists as sources in the event.
11. rate-limit-port. Rate-limit the port(s) listed as sources in the event.
12. redirect-traffic. Redirect traffic from the intended recipient for further analysis.
13. honeypot. Redirect traffic from systems listed in the event to a honeypot for further analysis.
14. upgrade-software. Upgrade or patch the software or firmware on an asset listed in the event.
15. rebuild-asset. Reinstall the operating system or applications on an asset listed in the event.
16. harden-asset. Change the configuration of an asset listed in the event to reduce the attack surface.
17. remediate-other. Remediate the activity in a way other than by rate-limiting or blocking.
18. status-triage. Confirm receipt and begin triaging the incident.
19. status-new-info. Notify the sender when new information is received for this incident.
20. watch-and-report. Watch for the described activity or indicators, and notify the sender when seen.
21. training. Train user to identify or mitigate the described threat.
22. defined-coa. Perform a predefined course of action (COA). The COA is named in the DefinedCOA class.
23. other. Perform a custom action described in the Description class.
24. 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.
Danyliw Standards Track [Page 62]
RFC 7970 IODEF Version 2 November 2016
ext-action Optional. STRING. A means by which to extend the action attribute. See Section 5.1.1.
severity Optional. ENUM. Indicates the desired priority of the action. This attribute is an enumerated list with no default value, and the semantics of these relative measures are context dependent.
1. low. Low priority
2. medium. Medium priority
3. high. High priority
restriction Optional. ENUM. See Section 3.3.1. The default value is "default".
ext-restriction Optional. STRING. A means by which to extend the restriction attribute. See Section 5.1.1.
Node One. A host or network involved in the incident. See Section 3.18.
NodeRole Zero or more. The intended purpose of the system. See Section 3.18.2.
Service Zero or more. A network service running on the system. See Section 3.20.
OperatingSystem Zero or more. SOFTWARE. The operating system running on the system.
Counter Zero or more. A counter with which to summarize properties of this host or network. See Section 3.18.3.
AssetID Zero or more. STRING. An asset identifier for the System.
Danyliw Standards Track [Page 64]
RFC 7970 IODEF Version 2 November 2016
Description Zero or more. ML_STRING. A free-form text description of the System.
AdditionalData Zero or more. EXTENSION. A mechanism by which to extend the data model.
The attributes of the System class are:
category Optional. ENUM. Classifies the role the host or network played in the incident. These values are maintained in the "System- category" IANA registry per Section 10.2.
1. source. The System was the source of the event.
2. target. The System was the target of the event.
3. intermediate. The System was an intermediary in the event.
4. sensor. The System was a sensor monitoring the event.
5. infrastructure. The System was an infrastructure node of the IODEF document exchange.
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-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1.1.
interface Optional. STRING. Specifies the interface on which the event(s) on this System originated. If the Node class specifies a network rather than a host, this attribute has no meaning.
spoofed Optional. ENUM. An indication of confidence in whether this System was the true target or attacking host. The permitted values for this attribute are shown below. The default value is "unknown".
1. unknown. The accuracy of the category attribute value is unknown.
Danyliw Standards Track [Page 65]
RFC 7970 IODEF Version 2 November 2016
2. yes. The category attribute value is likely incorrect. In the case of a source, the System is likely a decoy; with a target, the System was likely not the intended victim.
3. no. The category attribute value is believed to be correct.
virtual Optional. ENUM. Indicates whether this System is a virtual or physical device. The default value is "unknown".
1. yes. The System is a virtual device.
2. no. The System is a physical device.
3. unknown. It is not known if the System is virtual.
ownership Optional. ENUM. Describes the ownership of this System relative to the victim in the incident. These values are maintained in the "System-ownership" IANA registry per Section 10.2.
1. organization. Corporate or enterprise owned.
2. personal. Personally owned by an employee or affiliate of the corporation or enterprise.
3. partner. Owned by a partner of the corporation or enterprise.
4. customer. Owned by a customer of the corporation or enterprise.
5. no-relationship. Owned by an entity that has no known relationship with the victim organization.
6. unknown. Ownership is unknown.
7. 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-ownership Optional. STRING. A means by which to extend the ownership attribute. See Section 5.1.1.
DomainData Zero or more. The domain (DNS) information associated with this node. If an Address is not provided, at least one DomainData MUST be specified. See Section 3.19.
Address Zero or more. The hardware, network, or application address of the node. If a DomainData is not provided, at least one Address MUST be specified. See Section 3.18.1.
PostalAddress Zero or one. POSTAL. The postal address of the node.
Location Zero or more. ML_STRING. A free-form text description of the physical location of the node. This description may provide a more detailed description of where at the address specified by the PostalAddress class this node is found (e.g., room number, rack number, or slot number in a chassis).
Danyliw Standards Track [Page 67]
RFC 7970 IODEF Version 2 November 2016
Counter Zero or more. A counter with which to summarize properties of this host or network. See Section 3.18.3.
The content of the class is an address of type STRING whose semantics are determined by the category attribute.
The attributes of the Address class are:
category Required. ENUM. The type of address represented. The default value is "ipv6-addr". These values are maintained in the "Address-category" IANA registry per Section 10.2.
1. asn. Autonomous System Number.
2. atm. Asynchronous Transfer Mode (ATM) address.
3. e-mail. Email address, per the EMAIL data type.
4. ipv4-addr. IPv4 host address in dotted-decimal notation (i.e., a.b.c.d).
6. ipv4-net-masked. A sanitized IPv4 address with significant bits per "ipv4-net" but with the character 'x' replacing any digit(s) in the address or prefix.
7. ipv4-net-mask. IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (i.e., a.b.c.d/w.x.y.z).
9. ipv6-net. IPv6 network address, slash, prefix per Section 2.3 of [RFC4291].
10. ipv6-net-masked. A sanitized IPv6 address and prefix per "ipv6-net" but with the character 'x' replacing any hexadecimal digit(s) in the address or digit(s) in the prefix.
11. mac. Media Access Control (MAC) address (i.e., aa:bb:cc:dd:ee:ff).
12. site-uri. A URL or URI for a resource, per the URL data type.
13. 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-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1.1.
vlan-name Optional. STRING. The name of the Virtual LAN to which the address belongs.
vlan-num Optional. INTEGER. The number of the Virtual LAN to which the address belongs.
54. 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-category Optional. STRING. A means by which to extend the category attribute. See Section 5.1.1.
The Counter class summarizes multiple occurrences of an event or conveys counts or rates of various features.
The complete semantics of this class are context dependent based on the class in which it is aggregated.
+---------------------+ | Counter | +---------------------+ | REAL | | | | ENUM type | | STRING ext-type | | ENUM unit | | STRING ext-unit | | STRING meaning | | ENUM duration | | STRING ext-duration | +---------------------+
Figure 37: The Counter Class
The content of the class is a value of type REAL whose meaning and units are determined by the type and duration attributes, respectively. If the duration attribute is present, the element content is a rate. Otherwise, it is a simple counter.
The attributes of the Counter class are:
type Required. ENUM. Specifies the type of counter specified in the element content. These values are maintained in the "Counter- type" IANA registry per Section 10.2.
1. count. The Counter class value is a counter.
2. peak. The Counter class value is a peak value.
3. average. The Counter class value is an average.
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.
Danyliw Standards Track [Page 73]
RFC 7970 IODEF Version 2 November 2016
ext-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
unit Required. ENUM. Specifies the units of the element content. These values are maintained in the "Counter-unit" IANA registry per Section 10.2.
1. byte. Bytes transferred.
2. mbit. Megabits (Mbits) transferred.
3. packet. Packets.
4. flow. Network flow records.
5. session. Sessions.
6. alert. Notifications generated by another system (e.g., IDS or SIEM system).
7. message. Messages (e.g., mail messages).
8. event. Events.
9. host. Hosts.
10. site. Site.
11. organization. Organizations.
12. 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-unit Optional. STRING. A means by which to extend the unit attribute. See Section 5.1.1.
meaning Optional. STRING. A free-form text description of the metric represented by the Counter.
Danyliw Standards Track [Page 74]
RFC 7970 IODEF Version 2 November 2016
duration Optional. ENUM. If present, the Counter class represents a rate. This attribute specifies a unit of time over which the rate whose units are specified in the unit attribute is being conveyed. This attribute is the denominator of the rate (where the unit attribute specified the nominator). The possible values of this attribute are defined in the duration attribute of Section 3.12.3
ext-duration Optional. STRING. A means by which to extend the duration attribute. See Section 5.1.1.
The aggregate classes of the DomainData class are:
Name One. STRING. The domain name of a system.
DateDomainWasChecked Zero or one. DATETIME. A timestamp of when the domain listed in the Name class was resolved.
RegistrationDate Zero or one. DATETIME. A timestamp of when domain listed in the Name class was registered.
ExpirationDate Zero or one. DATETIME. A timestamp of when the domain listed in the Name class is set to expire.
Danyliw Standards Track [Page 75]
RFC 7970 IODEF Version 2 November 2016
RelatedDNS Zero or more. EXTENSION. Additional DNS records associated with this domain.
Nameservers Zero or more. The nameservers identified for the domain listed in the Name class. See Section 3.19.1.
DomainContacts Zero or one. Contact information for the domain listed in the Name class supplied by the registrar or through a whois query.
The attributes of the DomainData class are:
system-status Required. ENUM. Assesses the domain's involvement in the event. These values are maintained in the "DomainData-system-status" IANA registry per Section 10.2.
1. spoofed. This domain was spoofed.
2. fraudulent. This domain was operated with fraudulent intentions.
3. innocent-hacked. This domain was compromised by a third party.
4. innocent-hijacked. This domain was deliberately hijacked.
5. unknown. No categorization for this domain known.
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-system-status Optional. STRING. A means by which to extend the system-status attribute. See Section 5.1.1.
domain-status Required. ENUM. Categorizes the registry status of the domain at the time the document was generated. These values and their associated descriptions are derived from Section 3.2.2 of [RFC3982]. These values are maintained in the "DomainData-domain-status" IANA registry per Section 10.2.
1. reservedDelegation. The domain is permanently inactive.
Danyliw Standards Track [Page 76]
RFC 7970 IODEF Version 2 November 2016
2. assignedAndActive. The domain is in a normal state.
3. assignedAndInactive. The domain has an assigned registration, but the delegation is inactive.
4. assignedAndOnHold. The domain is in dispute.
5. revoked. The domain is in the process of being purged from the database.
6. transferPending. The domain is pending a change in authority.
7. registryLock. The domain is on hold by the registry.
8. registrarLock. Same as "registryLock".
9. other. The domain has a known status, but it is not one of the redefined enumerated values.
10. unknown. The domain has an unknown status.
11. 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-domain-status Optional. STRING. A means by which to extend the domain-status attribute. See Section 5.1.1.
The DomainContacts class describes the contact information for a given domain provided either by the registrar or through a whois query.
This contact information can be explicitly described through a Contact class, or a reference can be provided to a domain with identical contact information. Either a single SameDomainContact or one or more Contact classes MUST be present.
The aggregate classes of the DomainContacts class are:
SameDomainContact Zero or one. STRING. A domain name already cited in this document or through previous exchange that contains the identical contact information as the domain name in question. The domain contact information associated with this domain should be used instead of an explicit definition with the Contact class.
Contact One or more. Contact information for the domain. See Section 3.9.
The Service class describes a network service. The service is described by a protocol, port, protocol header field, and application providing or using the service.
Portlist Zero or one. PORTLIST. A list of port numbers.
ProtoCode Zero or one. INTEGER. A transport-layer (Layer 4) protocol- specific code field (e.g., ICMP code field).
ProtoType Zero or one. INTEGER. A transport-layer (Layer 4) protocol- specific type field (e.g., ICMP type field).
ProtoField Zero or one. INTEGER. A transport-layer (Layer 4) protocol- specific flag field (e.g., TCP flag field).
ApplicationHeader Zero or one. A protocol header. See Section 3.20.2.
Danyliw Standards Track [Page 79]
RFC 7970 IODEF Version 2 November 2016
EmailData Zero or one. Headers associated with an email message. See Section 3.21.
Application Zero or one. SOFTWARE. The application acting as either the client or the server for the service.
At least one of these classes MUST be present.
When a given System class with category="source" and another with category="target" are aggregated into a single Flow class, and each of these System classes has a Service and Portlist class, an implicit relationship between these Portlists exists. If N ports are listed for a System@category="source", and M ports are listed for System@category="target", the number of ports in N must be equal to M. Likewise, the ports MUST be listed in an identical sequence such that the n-th port in the source corresponds to the n-th port of the target. If N is greater than 1, a given instance of a Flow class MUST only have a single instance of a System@category="source" and System@category="target".
The attributes of the Service class are:
ip-protocol Optional. INTEGER. The IANA-assigned IP protocol number per [IANA.Protocols]. The attribute MUST be set if a Port, Portlist, ProtoCode, ProtoType, or ProtoField class is present.
The ServiceName class identifies an application protocol. It can be described by referencing an IANA-registered protocol, by referencing a URL, or with free-form text.
The aggregate class of the ApplicationHeader class is:
ApplicationHeaderField One or more. EXTENSION. A field name and value in a protocol header. The name attribute MUST be set to the field name. The field value MUST be set in the element content.
EmailTo Zero or more. EMAIL. The value of the "To:" header field (Section 3.6.3 of [RFC5322]) in an email.
EmailFrom Zero or one. EMAIL. The value of the "From:" header field (Section 3.6.2 of [RFC5322]) in an email.
EmailSubject Zero or one. STRING. The value of the "Subject:" header field in an email. See Section 3.6.5 of [RFC5322].
EmailX-Mailer Zero or one. STRING. The value of the "X-Mailer:" header field in an email.
EmailHeaderField Zero or more. EXTENSION. The header name and value of an arbitrary header field of the email message. The name attribute MUST be set to the header name. The header value MUST be set in the element body. The dtype attribute MUST be set to "string".
EmailHeaders Zero or one. STRING. The headers of an email message.
Danyliw Standards Track [Page 82]
RFC 7970 IODEF Version 2 November 2016
EmailBody Zero or one. STRING. The body of an email message.
EmailMessage Zero or one. STRING. The headers and body of an email message.
HashData Zero or more. Hash(es) associated with this email message. See Section 3.26.
SignatureData Zero or more. Signature(s) associated with this email message. See Section 3.27.
The Record class is a container class for log and audit data that provides supportive information about the events in an incident. The source of this data will often be the output of monitoring tools. These logs substantiate the activity described in the document.
RecordData One or more. Log or audit data generated by a particular tool. Separate instances of the RecordData class SHOULD be used for each type of log. See Section 3.22.1.
The RecordPattern class describes where in the log data provided or referenced in the RecordData class relevant information can be found. It provides a way to reference subsets of information, identified by a pattern, in a large log file, audit trail, or forensic data.
The content of the class is of type STRING and specifies a search pattern.
The attributes of the RecordPattern class are:
type Required. ENUM. Describes the type of pattern being specified in the element content. The default is "regex". These values are maintained in the "RecordPattern-type" IANA registry per Section 10.2.
1. regex. Regular expression as defined by POSIX Extended Regular Expressions (ERE) in Chapter 9 of [IEEE.POSIX].
2. binary. Binhex-encoded binary pattern, per the HEXBIN data type.
3. xpath. XML Path (XPath) [W3C.XPATH].
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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
offset Optional. INTEGER. Amount of units (determined by the offsetunit attribute) to seek into the RecordItem data before matching the pattern.
Danyliw Standards Track [Page 86]
RFC 7970 IODEF Version 2 November 2016
offsetunit Optional. ENUM. Describes the units of the offset attribute. The default is "line". These values are maintained in the "RecordPattern-offsetunit" IANA registry per Section 10.2.
1. line. Offset is a count of lines.
2. byte. Offset is a count of bytes.
3. 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-offsetunit Optional. STRING. A means by which to extend the offsetunit attribute. See Section 5.1.1.
instance Optional. INTEGER. Number of times to apply the specified pattern.
The WindowsRegistryKeysModified class describes Windows operating system registry keys and the operations that were performed on them. This class was derived from [RFC5901].
KeyName One. STRING. The name of a Windows operating system registry key (e.g., [HKEY_LOCAL_MACHINE\Software\Test\KeyName]).
KeyValue Zero or one. STRING. The value of the registry key identified in the KeyName class encoded per the .reg file format [KB310516].
The attributes of the Key class are:
registryaction Optional. ENUM. The type of action taken on the registry key. These values are maintained in the "Key-registryaction" IANA registry per Section 10.2.
1. add-key. Registry key added.
2. add-value. Value added to a registry key.
3. delete-key. Registry key deleted.
4. delete-value. Value deleted from a registry key.
5. modify-key. Registry key modified.
6. modify-value. Value modified in a registry key.
7. 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.
Danyliw Standards Track [Page 88]
RFC 7970 IODEF Version 2 November 2016
ext-registryaction Optional. STRING. A means by which to extend the registryaction attribute. See Section 5.1.1.
FileName Zero or one. STRING. The name of the file.
FileSize Zero or one. INTEGER. The size of the file in bytes.
FileType Zero or one. STRING. The type of file per the IANA "Media Types" registry [IANA.Media]. Valid values correspond to the text in the "Template" column (e.g., "application/pdf").
URL Zero or more. URL. A URL reference to the file.
Danyliw Standards Track [Page 91]
RFC 7970 IODEF Version 2 November 2016
HashData Zero or one. Hash(es) associated with this file. See Section 3.26.
SignatureData Zero or one. Signature(s) associated with this file. See Section 3.27.
AssociatedSoftware Zero or one. SOFTWARE. The software application or operating system to which this file belongs or by which it can be processed.
FileProperties Zero or more. EXTENSION. Mechanism by which to extend the data model to describe properties of the file.
HashTargetID Zero or one. STRING. An identifier that references a subset of the object being hashed. The semantics of this identifier are specified by the scope attribute.
Hash Zero or more. The hash of an object. See Section 3.26.1.
FuzzyHash Zero or more. The fuzzy hash of an object. See Section 3.26.2.
Danyliw Standards Track [Page 92]
RFC 7970 IODEF Version 2 November 2016
At least one instance of either Hash or FuzzyHash MUST be present.
The attribute of the HashData class is:
scope Required. ENUM. Describes on which part of the object the hash should be applied. These values are maintained in the "HashData- scope" IANA registry per Section 10.2.
1. file-contents. A hash computed over the entire contents of a file.
2. file-pe-section. A hash computed on a given section of a Windows Portable Executable (PE) file. If set to this value, the HashTargetID class MUST identify the section being hashed. A section is identified by an ordinal number (starting at 1) corresponding to the order in which the given section header was defined in the Section Table of the PE file header.
3. file-pe-iat. A hash computed on the Import Address Table (IAT) of a PE file. As IAT hashes are often tool dependent, if this value is set, the Application class of either the Hash or FuzzyHash classes MUST specify the tool used to generate the hash.
4. file-pe-resource. A hash computed on a given resource in a PE file. If set to this value, the HashTargetID class MUST identify the resource being hashed. A resource is identified by an ordinal number (starting at 1) corresponding to the order in which the given resource is declared in the Resource Directory of the Data Dictionary in the PE file header.
5. file-pdf-object. A hash computed on a given object in a Portable Document Format (PDF) file. If set to this value, the HashTargetID class MUST identify the object being hashed. This object is identified by its offset in the PDF file.
6. email-hash. A hash computed over the headers and body of an email message.
7. email-headers-hash. A hash computed over all of the headers of an email message.
8. email-body-hash. A hash computed over the body of an email message.
Danyliw Standards Track [Page 93]
RFC 7970 IODEF Version 2 November 2016
9. 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-scope Optional. STRING. A means by which to extend the scope attribute. See Section 5.1.1.
The Hash class describes a cryptographic hash value; the algorithm and application used to generate it; and the canonicalization method applied to the object being hashed.
The Indicator class describes an indicator. An indicator consists of observable features and phenomenon that aid in the forensic or proactive detection of malicious activity and associated metadata. An indicator can be described outright by referencing or composing previously defined indicators or by referencing observables described in the incident report found in this document.
IndicatorID One. An identifier for this indicator. See Section 3.29.1.
AlternativeIndicatorID Zero or more. An alternative identifier for this indicator. See Section 3.29.2.
Description Zero or more. ML_STRING. A free-form text description of the indicator.
StartTime Zero or one. DATETIME. A timestamp of the start of the time period during which this indicator is valid.
EndTime Zero or one. DATETIME. A timestamp of the end of the time period during which this indicator is valid.
Confidence Zero or one. An estimate of the confidence in the quality of the indicator. See Section 3.12.5.
Danyliw Standards Track [Page 97]
RFC 7970 IODEF Version 2 November 2016
Contact Zero or more. Contact information for this indicator. See Section 3.9.
Observable Zero or one. An observable feature or phenomenon of this indicator. See Section 3.29.3.
ObservableReference Zero or one. A reference to an observable feature or phenomenon defined elsewhere in the document. See Section 3.29.6.
IndicatorExpression Zero or one. A composition of observables. See Section 3.29.4.
IndicatorReference Zero or one. A reference to an indicator. See Section 3.29.7.
NodeRole Zero or more. The role of the system in the attack should this indicator be matched to it. See Section 3.18.2.
AttackPhase Zero or more. The phase in an attack life cycle during which this indicator might be seen. See Section 3.29.8.
Reference Zero or more. A reference to additional information relevant to this indicator. See Section 3.11.1.
AdditionalData Zero or more. EXTENSION. Mechanism by which to extend the data model.
The Indicator class MUST have exactly one instance of an Observable, IndicatorExpression, ObservableReference, or IndicatorReference class.
The StartTime and EndTime classes can be used to define an interval during which the indicator is valid. If both classes are present, the indicator is consider valid only during the described interval. If neither class is provided, the indicator is considered valid during any time interval. If only a StartTime is provided, the indicator is valid anytime after this timestamp. If only an EndTime is provided, the indicator is valid anytime prior to this timestamp.
The IndicatorID class identifies an indicator with a globally unique identifier. The combination of the name and version attributes and the element content form this identifier. Indicators generated by given CSIRT MUST NOT reuse the same value unless they are referencing the same indicator.
+------------------+ | IndicatorID | +------------------+ | ID | | | | STRING name | | STRING version | +------------------+
Figure 60: The IndicatorID Class
The content of the class is of type ID and specifies an identifier for an indicator.
The attributes of the IndicatorID class are:
name Required. STRING. An identifier describing the CSIRT that created the indicator. In order to have a globally unique CSIRT name, the fully qualified domain name associated with the CSIRT MUST be used. This format is identical to the IncidentID@name attribute in Section 3.4.
version Required. STRING. A version number of an indicator.
The BulkObservable class allows the enumeration of a single type of observable without requiring each one to be encoded individually in multiple instances of the same class.
The type attribute describes the type of observable listed in the child BulkObservableList class. The BulkObservableFormat class optionally provides additional metadata.
The aggregate classes of the BulkObservable class are:
BulkObservableFormat Zero or one. Provides additional metadata about the observables enumerated in the BulkObservableList class. See Section 3.29.3.1.1.
BulkObservableList One. STRING. A list of observables, one per line. Each line is separated with either a LF character or CR and LF characters. The type attribute specifies which observables will be listed.
AdditionalData Zero or more. EXTENSION. Mechanism by which to extend the data model.
Danyliw Standards Track [Page 103]
RFC 7970 IODEF Version 2 November 2016
The attributes of the BulkObservable class are:
type Optional. ENUM. The type of the observable listed in the child ObservableList class. These values are maintained in the "BulkObservable-type" IANA registry per Section 10.2.
1. asn. Autonomous System Number (per the Address@category attribute).
2. atm. Asynchronous Transfer Mode (ATM) address (per the Address@category attribute).
3. e-mail. Email address (per the Address@category attribute).
4. ipv4-addr. IPv4 host address in dotted-decimal notation, e.g., 192.0.2.1 (per the Address@category attribute).
5. ipv4-net. IPv4 network address in dotted-decimal notation, slash, significant bits, e.g., 192.0.2.0/24 (per the Address@category attribute).
6. ipv4-net-mask. IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation, i.e., 192.0.2.0/255.255.255.0 (per the Address@category attribute).
10. mac. Media Access Control (MAC) address, i.e., a:b:c:d:e:f (per the Address@category attribute).
11. site-uri. A URL or URI for a resource (per the Address@category attribute).
12. domain-name. A fully qualified domain name or part of a name (e.g., fqdn.example.com, example.com).
13. domain-to-ipv4. A mapping of FQDN to IPv4 address specified as a comma-separated list (e.g., "fqdn.example.com, 192.0.2.1").
Danyliw Standards Track [Page 104]
RFC 7970 IODEF Version 2 November 2016
14. domain-to-ipv6. A mapping of FQDN to IPv6 address specified as a comma-separated list (e.g., "fqdn.example.com, 2001:DB8::3").
15. domain-to-ipv4-timestamp. Same as domain-to-ipv4 but with a timestamp (in the DATETIME format) of the resolution (e.g., "fqdn.example.com, 192.0.2.1, 2015-06-11T00:38:31-06:00").
16. domain-to-ipv6-timestamp. Same as domain-to-ipv6 but with a timestamp (in the DATETIME format) of the resolution (e.g., "fqdn.example.com, 2001:DB8::3, 2015-06-11T00:38:31-06:00").
17. ipv4-port. An IPv4 address, port, and protocol tuple (e.g., 192.0.2.1, 80, TCP). The protocol name corresponds to the "Keyword" column in the "Assigned Internet Protocol Numbers" registry [IANA.Protocols].
18. ipv6-port. An IPv6 address, port, and protocol tuple (e.g., 2001:DB8::3, 80, TCP). The protocol name corresponds to the "Keyword" column in the "Assigned Internet Protocol Numbers" registry [IANA.Protocols].
19. windows-reg-key. A Microsoft Windows registry key.
20. file-hash. A file hash. The format of this hash is described in the Hash class that MUST be present in a sibling BulkObservableFormat class.
21. email-x-mailer. An X-Mailer field from an email.
22. email-subject. An email subject line.
23. http-user-agent. A User Agent field from an HTTP request header (e.g., "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0").
24. http-request-uri. The Request URI from an HTTP request header.
25. mutex. The name of a system mutex (mutual exclusion lock).
26. file-path. A file path (e.g., "/tmp/local/file", "c:\windows\system32\file.sys").
27. user-name. A username.
Danyliw Standards Track [Page 105]
RFC 7970 IODEF Version 2 November 2016
28. 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-type Optional. STRING. A means by which to extend the type attribute. See Section 5.1.1.
The IndicatorExpression describes an expression composed of observed phenomenon, features, or indicators. Elements of the expression can be described directly, reference relevant data from other parts of a given IODEF document, or reference previously defined indicators.
All child classes of a given instance of IndicatorExpression form a boolean algebraic expression where the operator between them is determined by the operator attribute.
The aggregate classes of the IndicatorExpression class are:
IndicatorExpression Zero or more. An expression composed of other observables or indicators. See Section 3.29.4.
Observable Zero or more. A description of an observable. See Section 3.29.3.
ObservableReference Zero or more. A reference to an observable. See Section 3.29.6.
IndicatorReference Zero or more. A reference to an indicator. See Section 3.29.7.
Confidence Zero or one. An estimate of the confidence in the quality of the terms expressed in the expression. See Section 3.12.5.
AdditionalData Zero or more. EXTENSION. Mechanism by which to extend the data model.
The attributes of the IndicatorExpression class are:
operator Optional. ENUM. The operator to be applied between the child elements. See Section 3.29.5 for parsing guidance. The default value is "and". These values are maintained in the "IndicatorExpression-operator" IANA registry per Section 10.2.
1. not. negation operator.
2. and. conjunction operator.
Danyliw Standards Track [Page 107]
RFC 7970 IODEF Version 2 November 2016
3. or. disjunction operator.
4. xor. exclusive disjunction operator.
ext-operator Optional. STRING. A means by which to extend the operator attribute. See Section 5.1.1.
Boolean algebraic expressions can be used to specify relationships between observables and indicators. These expressions are constructed through the use of the operator attribute and parent- child relationships in IndicatorExpressions. These expressions should be parsed as follows:
1. The operator specified by the operator attribute is applied between each of the child elements of the immediate parent IndicatorExpression element. If no operator attribute is specified, it should be assumed to be the conjunction operator (i.e., operator="and").
2. A nested IndicatorExpression element with a parent IndicatorExpression is the equivalent of a parentheses in the expression.
The following examples in Figures 66 through 70 illustrate these parsing rules:
The attribute of the ObservableReference class is:
uid-ref Required. IDREF. An identifier that serves as a reference to a class in the IODEF document. The referenced class will have this identifier set in its observable-id attribute.
The IndicatorReference describes a reference to an indicator. This reference may be to an indicator described in this IODEF document or in a previously exchanged IODEF document.
The attributes of the IndicatorReference class are:
uid-ref Optional. IDREF. An identifier that references an Indicator class in the IODEF document. The referenced Indicator class will have this identifier set in its IndicatorID class.
Danyliw Standards Track [Page 110]
RFC 7970 IODEF Version 2 November 2016
euid-ref Optional. STRING. An identifier that references an IndicatorID not in this IODEF document.
version Optional. STRING. A version number of an indicator.
Either the uid-ref or the euid-ref attribute MUST be set.
Every IODEF document MUST begin with an XML declaration and MUST specify the XML version used. The character encoding MUST also be explicitly specified. UTF-8 [RFC3629] SHOULD be used unless UTF-16 [RFC2781] is necessary. Encodings other than UTF-8 and UTF-16 SHOULD NOT be used. The IODEF conforms to all XML data-encoding conventions and constraints.
The XML declaration with UTF-8 character encoding will read as follows:
<?xml version="1.0" encoding="UTF-8" ?>
Certain characters have special meaning in XML and MUST not appear in literal form. Per Section 2.4 of [W3C.XML], these characters MUST be escaped with a numeric character or entity reference.
The IODEF schema declares a namespace of "urn:ietf:params:xml:ns:iodef-2.0" and registers it per [W3C.XMLNS]. Each IODEF document MUST include a valid reference to the IODEF schema using the "xsi:schemaLocation" attribute. An example of such a declaration would look as follows:
IODEF documents MUST be well-formed XML. It is RECOMMENDED that recipients validate the document against the schema described in Section 8. However, mere conformance to this schema is not sufficient for a semantically valid IODEF document. The text of Section 3 describes further formatting and constraints, including some that cannot be conveniently encoded in the schema. These MUST also be considered by an IODEF implementation. Furthermore, the enumerated values present in this document are a static list that will be incomplete over time as select attributes can be extended by a corresponding IANA registry per Section 10.2. Therefore, IODEF
Danyliw Standards Track [Page 112]
RFC 7970 IODEF Version 2 November 2016
implementations SHOULD periodically update their schema and MAY need to update their parsing algorithms to incorporate newly registered values.
The IODEF data model in this document makes a number of changes to [RFC5070]. These changes were largely additive -- classes and enumerated values were added. However, some incompatibilities between [RFC5070] and this new specification were introduced. These incompatibilities are as follows:
o The IODEF-Document@version attribute is set to "2.0".
o Attributes with enumerated values can now also be extended with IANA registries.
o All iodef:MLStringType classes use xml:lang. IODEF-Document also uses xml:lang.
o The Service@ip_protocol attribute was renamed to @ip-protocol.
o The Node/NodeName class was removed in favor of representing domain names with Node/DomainData/Name class. The Node/DataTime class was also removed, so that the Node/DomainData/ DateDomainWasChecked class can represent the time at which the name-to-address resolution occurred.
o The Node/NodeRole class was moved to System/NodeRole.
o The Reference class is now defined by [RFC7495].
o The data previously represented in the Impact class is now in the SystemImpact and IncidentCategory classes. The Impact class has been removed.
o The semantics of Counter@type are now represented in Counter@unit.
o The IODEF-Document@formatid attribute has been renamed to @format- id.
o The Incident/ReportTime class is no longer required. However, the GenerationTime class is required.
o The Fax class was removed and is now represented by a generic Telephone class.
Danyliw Standards Track [Page 113]
RFC 7970 IODEF Version 2 November 2016
o The Telephone, Email, and PostalAddress classes were redefined from improved internationalization.
o The "ipv6-net-mask" value was removed from the category attribute of Address.
5. Extending the IODEF
In order to support the dynamic nature of security operations, the IODEF data model will need to continue to evolve. This section discusses how new data elements can be incorporated into the IODEF. There is support to add additional enumerated values and new classes. Adding additional attributes to existing classes is not supported.
These extension mechanisms are designed so that adding new data elements is possible without requiring modifications to this document. Extensions can be implemented publicly or privately. With proven value, well-documented extensions can be incorporated into future versions of the specification.
5.1. Extending the Enumerated Values of Attributes
Additional enumerated values can be added to select attributes either through the use of specially marked attributes with the "ext-" prefix or through a set of corresponding IANA registries. The former approach allows for the extension to remain private. The latter approach is public.
The data model supports adding new enumerated values to an attribute without public registration. For each attribute that supports this extension technique, there is a corresponding attribute in the same element whose name is identical but with a prefix of "ext-". This special attribute is referred to as the extension attribute. The attribute being extended is referred to as an extensible attribute. For example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". An element may have many extensible attributes.
In addition to a corresponding extension attribute, each extensible attribute has "ext-value" as one its possible enumerated values. Selection of this particular value in an extensible attribute signals that the extension attribute contains data. Otherwise, this "ext-value" value has no meaning.
Danyliw Standards Track [Page 114]
RFC 7970 IODEF Version 2 November 2016
In order to add a new enumerated value to an extensible attribute, the value of this attribute MUST be set to "ext-value", and the new desired value MUST be set in the corresponding extension attribute. For example, extending the type attribute of the SystemImpact class would look as follows:
The data model also supports publicly extending select enumerated attributes. A new entry can be added by registering a new entry in the appropriate IANA registry. Section 10.2 provides a mapping between the extensible attributes and their corresponding registry. Section 4.3 discusses the XML validation implications of this type of extension. All extensible attributes that support private extensions also support public extensions.
Classes of the EXTENSION (iodef:ExtensionType) type can extend the data model. They provide the ability to have new atomic or XML- encoded data elements in all of the top-level classes of the Incident class and in a few of the complex subordinate classes. As there are multiple instances of the extensible classes in the data model, there is discretion on where to add a new data element. It is RECOMMENDED that the extension be placed in the most closely related class to the new information.
Extensions using the atomic data types (i.e., all values of the dtype attributes other than "xml") MUST:
1. Set the element content to the desired value, and
2. Set the dtype attribute to correspond to the data type of the element content.
Danyliw Standards Track [Page 115]
RFC 7970 IODEF Version 2 November 2016
The following guidelines exist for extensions using XML (i.e., dtype="xml"):
1. The element content of the extensible class MUST be set to the desired value, and the dtype attribute MUST be set to "xml".
2. The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions have the prefix "iodef-". This recommendation makes readability of the document easier by allowing the reader to infer which namespaces relate to IODEF by inspection.
3. It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. This too improves the readability of extended IODEF documents. The names of all elements SHOULD be capitalized. For elements with composed names, a capital letter SHOULD be used for each word. Attribute names SHOULD be in lowercase. Attributes with composed names SHOULD be separated by a hyphen.
4. Implementations that encounter an unrecognized element, attribute, or attribute value in a supported namespace SHOULD reject the document as a syntax error.
5. There are security and performance implications in requiring implementations to dynamically download schemas at runtime. Therefore, implementations MUST NOT download schemas at runtime unless the appropriate precautions are taken. Implementations also need to contend with the potential of significant network and processing issues.
6. Some adopters of the IODEF may have private schema definitions that are not publicly available. Thus, implementations may encounter IODEF documents with references to private schemas that may not be resolvable. Hence, IODEF document recipients MUST be prepared for a schema definition in an IODEF document never to resolve.
Danyliw Standards Track [Page 116]
RFC 7970 IODEF Version 2 November 2016
The following schema and XML document excerpt provide a template for an extension schema and its use in the IODEF document.
This example schema defines a namespace of "iodef-extension1" and a single element named "newdata".
To disambiguate which private extension is used in an IODEF document, the data model provides a means to identify the source of an extension. Two attributes in the IODEF-Document class, private-enum-name and private-enum-id, are used to specify this attribution. Only a single private extension can be identified in a given IODEF-Document.
Danyliw Standards Track [Page 117]
RFC 7970 IODEF Version 2 November 2016
If an implementor has a single private extension, then only the private-enum-name attribute needs to be specified. Multiple distinct private extensions or versioning of a single extension can be attributed by also setting the corresponding private-num-id attribute.
The following XML excerpt demonstrates the specification of a private extension from "example.com" with an identifier of "13".
If an unrecognized private extension is encountered in processing, the recipient MAY reject the entire document as a syntax error.
6. Internationalization Issues
Internationalization and localization is of specific concern to the IODEF as it facilitates operational coordination with a diverse set of partners. The IODEF implements internationalization by relying on XML constructs and through explicit design choices in the data model.
Since the IODEF is implemented as an XML schema, it supports different character encodings, such as UTF-8 and UTF-16, that are possible with XML. Additionally, each IODEF document MUST specify the language in which its content is encoded. The language can be specified with the attribute "xml:lang" (per Section 2.12 of [W3C.XML]) in the top-level element (i.e., IODEF-Document) and lets all other elements inherit that definition. All IODEF classes with a free-form text definition (i.e., all those defined with type iodef:MLStringType) can also specify a language different from the rest of the document.
The data model supports multiple translations of free-form text. All ML_STRING (iodef:MLStringType) classes have a one-to-many cardinality to their parent. This allows the identical text translated into different languages to be encoded in different instances of the same class with a common parent. This design also enables the creation of a single document containing all the translations. The IODEF implementation SHOULD extract the appropriate language relevant to the recipient.
Danyliw Standards Track [Page 118]
RFC 7970 IODEF Version 2 November 2016
Related instances of a given iodef:MLStringType class that are translations of each other are identified by a common identifier set in the translation-id attribute. The example below shows three instances of a Description class expressed in three different languages. The relationship between these three instances of the Description class is conveyed by the common value of "1" in the translation-id attribute.
The IODEF balances internationalization support with the need for interoperability. While the IODEF supports different languages, the data model also relies heavily on standardized enumerated attributes that can crudely approximate the contents of the document. With this approach, a CSIRT should be able to make some sense of an IODEF document it receives even if the free-form text data elements are written in a language unfamiliar to the recipient.
7. Examples
This section provides examples of IODEF documents. These examples do not represent the full capabilities of the data model or the only way to encode particular information.
<Email> <EmailTo>contact@csirt.example.com</EmailTo> </Email> </Contact> <!-- Add more fields to make the document useful --> </Incident> </IODEF-Document>
The IODEF data model does not directly introduce security or privacy issues. However, as the data encoded by the IODEF might be considered sensitive by the parties exchanging it or by those described by it, care needs to be taken to ensure appropriate handling during the document construction, exchange, processing, archiving, subsequent retrieval, and analysis.
The underlying messaging format and protocol used to exchange instances of the IODEF MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. The Real-time Inter- network Defense (RID) protocol [RFC6545] and its associated transport binding IODEF/RID over HTTP/TLS [RFC6546] provide such security.
An IODEF implementation may act on the data in the document. These actions might be explicitly requested in the document or the result of analytical logic that triggered on data in the document. For this reason, care must be taken by IODEF implementations to properly authenticate the sender and receiver of the document. The sender needs confidence that sensitive information and timely requests for action are sent to the correct recipient. The recipient may interpret the contents of the document differently based on who sent it or vary actions based on the sender. While the sender of the document may explicitly convey confidence in the data in a granular way using the Confidence class, the recipient is free to ignore or refine this information to make its own assessment. Ambiguous Confidence elements (where it is unclear to which of a set of other elements the Confidence element relates) in a document MUST be ignored by the recipient.
Certain classes may require out-of-band coordination to agree upon their semantics (e.g., Confidence@rating="low" or DefinedCOA). This coordination MUST occur prior to operational data exchange to prevent the incorrect interpretation of these select data elements. When parsing these data elements, implementations should validate, when possible, that they conform to the agreed upon semantics. These semantics may need to be periodically reevaluated.
Executable content of various forms could be embedded into the IODEF document directly or through an extension. Implementation MUST handle this content with care to prevent unintentional automated execution. The following classes are explicitly intended to represent content that might be executable:
Danyliw Standards Track [Page 161]
RFC 7970 IODEF Version 2 November 2016
o All classes of type iodef:ExtensionType and the RecordPattern class can represent arbitrary binary strings such as legitimate software programs or malware.
o The EmailMessage and EmailBody classes can represent email attachments that can contain arbitrary content.
o The DetectionPattern class could specify a machine-readable configuration that directs the execution of the corresponding tool.
Per Section 4.3, IODEF implementations will need to periodically consult the IANA registries specified in Section 10.2 to discover newly registered enumerated attribute values. These implementations MUST communicate with IANA in a way that ensures the integrity of the values and the authenticity of the source. HTTPS over TLS [RFC2818][RFC5246] provides such security.
The IODEF contains numerous fields that are identifiers that could be linked to an individual or organization. IODEF documents may contain sensitive information about these identified parties; repeated document exchanges about the same and related parties may enable the correlation of data about them. Likewise, a party may report on another to a third party without their knowledge.
When creating an IODEF document, careful consideration must be given to what information is shared. Personal identifiers and attributable sensitive information should only be shared when necessary.
When exchanging documents, transport security MUST provide document- level confidentiality. XML element-level confidentiality can also be provided by using [W3C.XMLENC].
In order to suggest data processing and handling guidelines of the encoded information, the IODEF allows a document sender to convey a privacy policy using the restriction attribute. The various instances of this attribute allow different data elements of the document to be covered by dissimilar policies. While flexible, it must be stressed that this approach only serves as a guideline from the sender, as the recipient is free to ignore it.
Although outside of the scope of an IODEF implementation, the contents of IODEF documents and any derived analysis should be archived with appropriate confidentiality controls. Likewise, access to retrieve and analyze this data should be restricted to authorized users.
Danyliw Standards Track [Page 162]
RFC 7970 IODEF Version 2 November 2016
10. IANA Considerations
This document registers a namespace, an XML schema, and a number of registries that map to enumerated values defined in the data model. It also defines an Expert Review process for IODEF-related XML registry entries.
* Value. A value for a given IODEF attribute. It MUST conform to the formatting specified by the IODEF ENUM data type which is implemented as an "xs:NMTOKEN" type per Section 3.3.4 of [W3C.SCHEMA.DTYPES]. The value SHOULD conform to the convention specified in Section 5.2.
Danyliw Standards Track [Page 163]
RFC 7970 IODEF Version 2 November 2016
* Description. A short description of the enumerated value.
* Reference. An optional list of URIs to further describe the value.
o Allocation policy: Expert Review per [RFC5226]. This reviewer will ensure that the requested registry entry conforms to the prescribed formatting. The reviewer will also ensure that the entry is an appropriate value for the attribute per the information model (Section 3).
The registries to be created are named in the "Registry Name" column of Table 1. Each registry is initially populated with values and descriptions that come from an attribute specified in the IODEF schema (Section 8) whose description is found in a sub-section of the information model (Section 3). The initial values for the Value and Description fields of a given registry are listed in the "IV (Value)" and "IV (Desc.)" columns, respectively. The "IV (Value)" points to a given schema type per Section 8. Each enumerated value in the schema gets a corresponding entry in a given registry. The "IV (Desc.)" points to a section in the text of this document that describes each enumerated value. The initial value of the Reference field of every registry entry described below should be this document.
10.3. Expert Review of IODEF-Related XML Registry Entries
IODEF class extensions, per Section 5.2, could register their namespaces and schemas with the IANA XML namespace ("ns" on <http://www.iana.org/assignments/xml-registry/>) and schema registries ("schema" on <http://www.iana.org/assignments/ xml-registry/>) described in [RFC3688]. In addition to any reviews required by IANA, changes to the XML "schema" registry for schema names beginning with "urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF Expert Review [RFC5226] to ensure compatibility with IODEF and other existing IODEF extensions.
Danyliw Standards Track [Page 166]
RFC 7970 IODEF Version 2 November 2016
The IODEF expert(s) for these reviews will be designated by the IETF Security Area Directors.
[E.164] ITU Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, November 2010.
[IEEE.POSIX] IEEE, "Information Technology - Portable Operating System Interface (POSIX) Base Specifications, Issue 7", IEEE Std 1003.1-2001, DOI 10.1109/IEEESTD.2009.5393893, September 2009.
[ISO19770] International Organization for Standardization, "Information technology -- Software asset management -- Part 2: Software identification tag", ISO Standard 19770-2:2015, October 2015.
[ISO4217] International Organization for Standardization, "Codes for the representation of currencies", ISO 4217:2015, 2015.
[NIST.CPE] Cheikes, B., Waltermire, D., and K. Scarfone, "Common Platform Enumeration: Naming Specification Version 2.3", NIST Interagency Report 7695, August 2011, <http://csrc.nist.gov/publications/nistir/ir7695/ NISTIR-7695-CPE-Naming.pdf>.
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information", RFC 7203, DOI 10.17487/RFC7203, April 2014, <http://www.rfc-editor.org/info/rfc7203>.
[W3C.SCHEMA] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.SCHEMA.DTYPES] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation REC-xmlschema- 2-20041028, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[W3C.XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.XMLNS] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
[W3C.XMLSIG] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. Roessler, "XML Signature Syntax and Processing (Second Edition)", W3C Recommendation REC-xmldsig-core-20080610, June 2008, <http://www.w3.org/TR/xmldsig-core/>.
[W3C.XPATH] Robie, J., Dyck, M., and J. Spiegel, "XML Path Language (XPath) 3.1", W3C Candidate Recommendation CR-xpath- 31-20151217, December 2015, <https://www.w3.org/TR/xpath-3/>.
[KB310516] Microsoft Corporation, "How to add, modify, or delete registry subkeys and values by using a .reg file", September 2013, <https://support.microsoft.com/en-us/kb/310516>.
[NIST800.61rev2] National Institute of Standards and Technology, "Computer Security Incident Handling Guide", NIST Special Publication 800-61, Revision 2, August 2012, <http://dx.doi.org/10.6028/NIST.SP.800-61r2>.
[W3C.XMLENC] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, M., Roessler, T., and K. Yiu, "XML Encryption Syntax and Processing Version 1.1", W3C Recommendation REC-xmldsig- core1-20130411, April 2013, <https://www.w3.org/TR/xmlenc-core1/>.
Acknowledgments
Thanks to Paul Stoecker for his editorial leadership in the transition of an early draft to the current document.
Thanks to Kathleen Moriarty, Brian Trammel, Alexey Melnikov, Takeshi Takahashi, David Waltermire, and Sean Turner (as the MILE working group chairs, secretary, and area directors) for providing feedback and coordination of this document.
Thanks to the following individuals (listed alphabetically) who provided feedback during the meetings, on the mailing list, or through implementation experience: Jerome Athias, David Black, Eric Burger, Toma Cejka, Patrick Curry, John Field, Christopher Harrington, Chris Inacio, Panos Kampanakis, David Misell, Daisuke Miyamoto, Adam Montville, Robert Moskowitz, Lagadec Philippe, Tony Rutkowski, Mio Suzuki, and Nik Teague.
Danyliw Standards Track [Page 171]
RFC 7970 IODEF Version 2 November 2016
Author's Address
Roman Danyliw CERT Software Engineering Institute Carnegie Mellon University 4500 Fifth Avenue Pittsburgh, PA United States of America