From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7970.txt | 9635 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 9635 insertions(+) create mode 100644 doc/rfc/rfc7970.txt (limited to 'doc/rfc/rfc7970.txt') diff --git a/doc/rfc/rfc7970.txt b/doc/rfc/rfc7970.txt new file mode 100644 index 0000000..bf2d8a9 --- /dev/null +++ b/doc/rfc/rfc7970.txt @@ -0,0 +1,9635 @@ + + + + + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 2] + +RFC 7970 IODEF Version 2 November 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.3. About the IODEF Data Model . . . . . . . . . . . . . . . 7 + 1.4. Changes from RFC 5070 . . . . . . . . . . . . . . . . . . 7 + 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 9 + 2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . 9 + 2.3. Characters and Strings . . . . . . . . . . . . . . . . . 9 + 2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . 9 + 2.5. Binary Strings . . . . . . . . . . . . . . . . . . . . . 10 + 2.5.1. Base64 Bytes . . . . . . . . . . . . . . . . . . . . 10 + 2.5.2. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . 11 + 2.6. Enumerated Types . . . . . . . . . . . . . . . . . . . . 11 + 2.7. Date-Time String . . . . . . . . . . . . . . . . . . . . 11 + 2.8. Timezone String . . . . . . . . . . . . . . . . . . . . . 11 + 2.9. Port Lists . . . . . . . . . . . . . . . . . . . . . . . 11 + 2.10. Postal Address . . . . . . . . . . . . . . . . . . . . . 12 + 2.11. Telephone Number . . . . . . . . . . . . . . . . . . . . 12 + 2.12. Email String . . . . . . . . . . . . . . . . . . . . . . 12 + 2.13. Uniform Resource Locator Strings . . . . . . . . . . . . 12 + 2.14. Identifiers and Identifier References . . . . . . . . . . 12 + 2.15. Software . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.15.1. SoftwareReference Class . . . . . . . . . . . . . . 14 + 2.16. Extension . . . . . . . . . . . . . . . . . . . . . . . . 15 + 3. The IODEF Information Model . . . . . . . . . . . . . . . . . 18 + 3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . 18 + 3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . 20 + 3.3. Common Attributes . . . . . . . . . . . . . . . . . . . . 23 + 3.3.1. restriction Attribute . . . . . . . . . . . . . . . . 23 + 3.3.2. observable-id Attribute . . . . . . . . . . . . . . . 25 + 3.4. IncidentID Class . . . . . . . . . . . . . . . . . . . . 25 + 3.5. AlternativeID Class . . . . . . . . . . . . . . . . . . . 26 + 3.6. RelatedActivity Class . . . . . . . . . . . . . . . . . . 27 + 3.7. ThreatActor Class . . . . . . . . . . . . . . . . . . . . 28 + 3.8. Campaign Class . . . . . . . . . . . . . . . . . . . . . 29 + 3.9. Contact Class . . . . . . . . . . . . . . . . . . . . . . 30 + 3.9.1. RegistryHandle Class . . . . . . . . . . . . . . . . 34 + 3.9.2. PostalAddress Class . . . . . . . . . . . . . . . . . 35 + 3.9.3. Email Class . . . . . . . . . . . . . . . . . . . . . 36 + 3.9.4. Telephone Class . . . . . . . . . . . . . . . . . . . 37 + 3.10. Discovery Class . . . . . . . . . . . . . . . . . . . . . 38 + 3.10.1. DetectionPattern Class . . . . . . . . . . . . . . . 40 + 3.11. Method Class . . . . . . . . . . . . . . . . . . . . . . 41 + 3.11.1. Reference Class . . . . . . . . . . . . . . . . . . 42 + + + + +Danyliw Standards Track [Page 3] + +RFC 7970 IODEF Version 2 November 2016 + + + 3.12. Assessment Class . . . . . . . . . . . . . . . . . . . . 43 + 3.12.1. SystemImpact Class . . . . . . . . . . . . . . . . . 45 + 3.12.2. BusinessImpact Class . . . . . . . . . . . . . . . . 48 + 3.12.3. TimeImpact Class . . . . . . . . . . . . . . . . . . 50 + 3.12.4. MonetaryImpact Class . . . . . . . . . . . . . . . . 52 + 3.12.5. Confidence Class . . . . . . . . . . . . . . . . . . 53 + 3.13. History Class . . . . . . . . . . . . . . . . . . . . . . 54 + 3.13.1. HistoryItem Class . . . . . . . . . . . . . . . . . 54 + 3.14. EventData Class . . . . . . . . . . . . . . . . . . . . . 57 + 3.14.1. Relating the Incident and EventData Classes . . . . 59 + 3.14.2. Recursive Definition of EventData . . . . . . . . . 59 + 3.15. Expectation Class . . . . . . . . . . . . . . . . . . . . 60 + 3.16. Flow Class . . . . . . . . . . . . . . . . . . . . . . . 63 + 3.17. System Class . . . . . . . . . . . . . . . . . . . . . . 64 + 3.18. Node Class . . . . . . . . . . . . . . . . . . . . . . . 67 + 3.18.1. Address Class . . . . . . . . . . . . . . . . . . . 68 + 3.18.2. NodeRole Class . . . . . . . . . . . . . . . . . . . 69 + 3.18.3. Counter Class . . . . . . . . . . . . . . . . . . . 73 + 3.19. DomainData Class . . . . . . . . . . . . . . . . . . . . 75 + 3.19.1. Nameservers Class . . . . . . . . . . . . . . . . . 77 + 3.19.2. DomainContacts Class . . . . . . . . . . . . . . . . 78 + 3.20. Service Class . . . . . . . . . . . . . . . . . . . . . . 79 + 3.20.1. ServiceName Class . . . . . . . . . . . . . . . . . 80 + 3.20.2. ApplicationHeader Class . . . . . . . . . . . . . . 81 + 3.21. EmailData Class . . . . . . . . . . . . . . . . . . . . . 82 + 3.22. Record Class . . . . . . . . . . . . . . . . . . . . . . 83 + 3.22.1. RecordData Class . . . . . . . . . . . . . . . . . . 84 + 3.22.2. RecordPattern Class . . . . . . . . . . . . . . . . 85 + 3.23. WindowsRegistryKeysModified Class . . . . . . . . . . . . 87 + 3.23.1. Key Class . . . . . . . . . . . . . . . . . . . . . 88 + 3.24. CertificateData Class . . . . . . . . . . . . . . . . . . 89 + 3.24.1. Certificate Class . . . . . . . . . . . . . . . . . 90 + 3.25. FileData Class . . . . . . . . . . . . . . . . . . . . . 90 + 3.25.1. File Class . . . . . . . . . . . . . . . . . . . . . 91 + 3.26. HashData Class . . . . . . . . . . . . . . . . . . . . . 92 + 3.26.1. Hash Class . . . . . . . . . . . . . . . . . . . . . 94 + 3.26.2. FuzzyHash Class . . . . . . . . . . . . . . . . . . 95 + 3.27. SignatureData Class . . . . . . . . . . . . . . . . . . . 95 + 3.28. IndicatorData Class . . . . . . . . . . . . . . . . . . . 96 + 3.29. Indicator Class . . . . . . . . . . . . . . . . . . . . . 96 + 3.29.1. IndicatorID Class . . . . . . . . . . . . . . . . . 99 + 3.29.2. AlternativeIndicatorID Class . . . . . . . . . . . . 100 + 3.29.3. Observable Class . . . . . . . . . . . . . . . . . . 101 + 3.29.4. IndicatorExpression Class . . . . . . . . . . . . . 106 + 3.29.5. Expressions with IndicatorExpression . . . . . . . . 108 + 3.29.6. ObservableReference Class . . . . . . . . . . . . . 110 + 3.29.7. IndicatorReference Class . . . . . . . . . . . . . . 110 + 3.29.8. AttackPhase Class . . . . . . . . . . . . . . . . . 111 + + + +Danyliw Standards Track [Page 4] + +RFC 7970 IODEF Version 2 November 2016 + + + 4. Processing Considerations . . . . . . . . . . . . . . . . . . 112 + 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 112 + 4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 112 + 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 112 + 4.4. Incompatibilities with v1 . . . . . . . . . . . . . . . . 113 + 5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 114 + 5.1. Extending the Enumerated Values of Attributes . . . . . . 114 + 5.1.1. Private Extension of Enumerated Values . . . . . . . 114 + 5.1.2. Public Extension of Enumerated Values . . . . . . . . 115 + 5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 115 + 5.3. Deconflicting Private Extensions . . . . . . . . . . . . 117 + 6. Internationalization Issues . . . . . . . . . . . . . . . . . 118 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 119 + 7.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 119 + 7.2. Indicators from a Campaign . . . . . . . . . . . . . . . 120 + 8. The IODEF Data Model (XML Schema) . . . . . . . . . . . . . . 121 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 161 + 9.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 161 + 9.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 162 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163 + 10.1. Namespace and Schema . . . . . . . . . . . . . . . . . . 163 + 10.2. Enumerated Value Registries . . . . . . . . . . . . . . 163 + 10.3. Expert Review of IODEF-Related XML Registry Entries . . 166 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 167 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 167 + 11.2. Informative References . . . . . . . . . . . . . . . . . 170 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 171 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 172 + +1. Introduction + + Organizations require help from other parties to mitigate malicious + activity targeting their network and to gain insight into potential + threats. This coordination might entail working with an ISP to + filter attack traffic, contacting a remote site to take down a + botnet, or sharing watch lists of known malicious indicators in a + consortium. + + The Incident Object Description Exchange Format (IODEF) is a format + for representing computer security information commonly exchanged + between Computer Security Incident Response Teams (CSIRTs) or other + operational security teams. It provides an XML representation for + conveying: + + o indicators to characterize a threat; + + o security incident reports to document attacks against an + organization; + + + +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. + +1.1. Terminology + + The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," + "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Notations + + The IODEF is specified as an Extensible Markup Language (XML) + [W3C.XML] schema [W3C.SCHEMA]. The normative IODEF data model is + found in the XML schema in Section 8. To aid in the understanding of + the data elements, Section 3 also depicts the underlying information + model using Unified Modeling Language (UML). This abstract + presentation of the IODEF is not normative. + + + +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. + +1.3. About the IODEF Data Model + + A number of considerations were made in the design of the IODEF data + model. + + o The data model found in this document is an evolution of the one + previously specified in [RFC5070]. New fields were added to + represent additional information. [RFC5070] was developed + primarily to represent incident reports. This document builds + upon it by adding support for indicators and revising it to + reflect the current challenges faced by CSIRTs. An attempt was + made to preserve backward compatibility, but this was not possible + in all cases. See Section 4.4. This document obsoletes + [RFC5070]. + + o The IODEF is a transport format. Therefore, the data model may + not be the optimal archival or in-memory processing format. + + o The IODEF is intended to be a framework to convey only commonly + exchanged information. It ensures that there are mechanisms for + extensibility to support organization-specific information and + techniques to reference information kept outside of the data + model. + + o Not all commonly exchanged information has a well-defined format + or taxonomy. The IODEF attempts to strike a balance between + enforcing sufficient structure to allow automated processing and + supporting free-form content that enables maximum flexibility. + + o The IODEF fits into a broader ecosystem of standards and + conventions. An attempt was made to harmonize the data model with + this context. + +1.4. Changes from RFC 5070 + + A detailed list of additions made to the data model in [RFC5070] are + enumerated in this section. See Section 4.4 for a list of + incompatible changes. + + + +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. + +2. IODEF Data Types + + The IODEF uses a number of simple and complex types. This section + describes these data types. + +2.1. Integers + + An integer is represented in the information model by the INTEGER + data type. Integer data MUST be encoded in Base 10. + + The INTEGER data type is implemented in the data model as an + "xs:integer" type per Section 3.3.13 of [W3C.SCHEMA.DTYPES]. + +2.2. Real Numbers + + A real (floating-point) number is represented in the information + model by the REAL data type. Real data MUST be encoded in Base 10. + + The REAL data type is implemented in the data model as an "xs:float" + type per Section 3.2.4 of [W3C.SCHEMA.DTYPES]. + +2.3. Characters and Strings + + A single character is represented in the information model by the + CHARACTER data type. A string is represented by the STRING data + type. Special characters MUST be encoded using entity references. + See Section 4.1. + + The CHARACTER and STRING data types are implemented in the data model + as an "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES]. + +2.4. Multilingual Strings + + A string that needs to be represented in a human-readable language + different than the default encoding of the document is represented in + the information model by the ML_STRING data type. + + The ML_STRING data type is implemented in the data model as the + "iodef:MLStringType" type. This type extends the "xs:string" to + include two attributes. + + + +Danyliw Standards Track [Page 9] + +RFC 7970 IODEF Version 2 November 2016 + + + +------------------------+ + | iodef:MLStringType | + +------------------------+ + | xs:string | + | | + | ENUM xml:lang | + | STRING translation-id | + +------------------------+ + + Figure 1: The iodef:MLStringType Type + + The content of the class is a character string of type "xs:string" + whose language MAY be specified by the xml:lang attribute. + + The attributes of the iodef:MLStringType type are: + + xml:lang + Optional. ENUM. A language identifier per Section 2.12 of + [W3C.XML] whose values and format are described in [RFC5646]. The + interpretation of this code is described in Section 6. + + translation-id + Optional. STRING. An identifier to relate other instances of + this class with the same parent as translations of this text. The + scope of this identifier is limited to all of the direct, peer + child classes of a given parent class. + + Using this class enables representing translations of the same text + in multiple languages. Each translation is a distinct instance of + this class with a common parent. A group of classes each with a + translated instance of text is related by setting a common identifier + in the translation-id attribute. The language of a given class is + set by the xml:lang attribute. See Section 6 for more details on + representing translations of free-form text. + +2.5. Binary Strings + + Binary octets can be represented with two encodings. + +2.5.1. Base64 Bytes + + A binary octet encoded with base64 is represented in the information + model by the BYTE data type. A sequence of these octets is of the + BYTE[] data type. + + The BYTE and BYTE[] data types are implemented in the data model as + an "xs:base64Binary" type per Section 3.2.16 of [W3C.SCHEMA.DTYPES]. + + + + +Danyliw Standards Track [Page 10] + +RFC 7970 IODEF Version 2 November 2016 + + +2.5.2. Hexadecimal Bytes + + A binary octet encoded as a character tuple consistent of two + hexadecimal digits is represented in the information model by the + HEXBIN data type. A sequence of these octets is of the HEXBIN[] data + type. + + The HEXBIN and HEXBIN[] data types are implemented in the data model + as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES]. + +2.6. Enumerated Types + + An enumerated type is represented in the information model by the + ENUM data type. It is an ordered list of acceptable string values. + Each value has a representative keyword. Within the data model, the + enumerated type keywords are used as attribute values. + + The ENUM data type is implemented in the data model as values of an + "xs:NMTOKEN" type per Section 3.3.4 of [W3C.SCHEMA.DTYPES]. + +2.7. Date-Time String + + A date-time string that describes a particular instant in time is + represented in the information model by the DATETIME data type. + Ranges are not supported. + + The DATETIME data type is implemented in the data model as an + "xs:dateTime" type per Section 3.2.7 of [W3C.SCHEMA.DTYPES]. + +2.8. Timezone String + + A timezone offset from UTC is represented in the information model by + the TIMEZONE data type. It is formatted according to the following + regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". + + The TIMEZONE data type is implemented in the data model as an + "iodef:TimezoneType" type. + +2.9. Port Lists + + A list of network ports is represented in the information model by + the PORTLIST data type. A PORTLIST consists of a comma-separated + list of numbers and ranges (N-M means ports N through M, inclusive). + It is formatted according to the following regular expression: + "\d+(\-\d+)?(,\d+(\-\d+)?)*". For example, + "2,5-15,30,32,40-50,55-60". + + + + + +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. + +2.10. Postal Address + + A postal address is represented in the information model by the + POSTAL data type. The format of the POSTAL data type is documented + in Section 2.23 of [RFC4519] as a free-form multi-line string + separated by the "$" character. + + The POSTAL data type is implemented in the data model as an + "iodef:MLStringType" type. + +2.11. Telephone Number + + A telephone number is represented in the information model by the + PHONE data type. The format of the PHONE data type is documented in + [E.164]. + + The PHONE data type is implemented in the data model as an + "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES]. + +2.12. Email String + + An email address is represented in the information model by the EMAIL + data type. The format of the EMAIL data type is documented in + Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531]. + + The EMAIL data type is implemented in the data model as an + "xs:string" type per Section 3.2.1 of [W3C.SCHEMA.DTYPES]. + +2.13. Uniform Resource Locator Strings + + A uniform resource locator (URL) is represented in the information + model by the URL data type. The format of the URL data type is + documented in [RFC3986]. + + The URL data type is implemented as an "xs:anyURI" type per + Section 3.2.17 of [W3C.SCHEMA.DTYPES]. + +2.14. Identifiers and Identifier References + + An identifier unique to the IODEF document is represented in the + information model by the ID data type. A reference to this + identifier is represented by the IDREF data type. + + + + + + +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]. + +2.15. Software + + A particular version of software is represented in the information + model by the SOFTWARE data type. This software can be described by + using a reference, a URL, or with free-form text. + + The SOFTWARE data type is implemented in the data model as the + "iodef:SoftwareType" type. + + +--------------------+ + | iodef:SoftwareType | + +--------------------+ + | |<>--{0..1}--[ SoftwareReference ] + | |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + +--------------------+ + + Figure 2: The SoftwareType Type + + The aggregate classes of the SoftwareType type are: + + SoftwareReference + Zero or one. Reference to a software application. See + Section 2.15.1. + + URL + Zero or more. URL. A URL to a resource describing the software. + + Description + Zero or more. ML_STRING. A free-form text description of the + software. + + At least one of these classes MUST be present. + + The iodef:SoftwareType type has no attributes. + + + + + + + + + + + + +Danyliw Standards Track [Page 13] + +RFC 7970 IODEF Version 2 November 2016 + + +2.15.1. SoftwareReference Class + + The SoftwareReference class is a reference to a particular version of + software. + + +----------------------+ + | SoftwareReference | + +----------------------+ + | xs:any | + | | + | ENUM spec-name | + | STRING ext-spec-name | + | ENUM dtype | + | STRING ext-dtype | + +----------------------+ + + Figure 3: The SoftwareReference Class + + The element content varies according to the value of the spec-name + attribute. It is defined in the data model as "xs:any" per + [W3C.SCHEMA]. + + The attributes of the SoftwareReference class are: + + spec-name + Required. ENUM. Identifies the format and semantics of the + element body of this class. Formal standards and specifications + can be referenced as well as a free-form text description with a + user-provided data type. These values are maintained in the + "SoftwareReference-spec-id" IANA registry per Section 10.2 + + 1. custom. The element content is free-form and of the data type + specified by the dtype attribute. If this value is selected, + then the dtype attribute MUST be set. + + 2. cpe. The element content describes a Common Platform + Enumeration (CPE) entry per [NIST.CPE]. + + 3. swid. The element content describes a software identification + (SWID) tag per [ISO19770]. + + 4. ext-value. A value used to indicate that this attribute is + extended and the actual value is provided using the + corresponding ext-* attribute. See Section 5.1.1. + + + + + + + +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. + + 3. real. The element content is of type REAL. + + 4. string. The element content is of type STRING. + + 5. xml. The element content is XML. See Section 5.2. + + 6. ext-value. A value used to indicate that this attribute is + extended and the actual value is provided using the + corresponding ext-* attribute. See Section 5.1.1. + + ext-dtype + Optional. STRING. A means by which to extend the dtype + attribute. See Section 5.1.1. + +2.16. Extension + + Information not otherwise represented in the IODEF can be added using + the EXTENSION data type. This data type is a generic extension + mechanism. + + The EXTENSION data type is implemented in the data model as the + "iodef:ExtensionType" type. + + The data type of an EXTENSION is described by the dtype attribute. + For simple information, atomic data types (e.g., integers, strings) + are supported. Their semantics are further described by the meaning + and formatid attributes. Encapsulating XML documents conforming to + another schema is also supported. A detailed discussion of extending + the schema can be found in Section 5. Additional coordination may be + required to ensure that a recipient of a document using this type can + parse and process it. + + + + + + +Danyliw Standards Track [Page 15] + +RFC 7970 IODEF Version 2 November 2016 + + + +------------------------+ + | iodef:ExtensionType | + +------------------------+ + | xs:any | + | | + | STRING name | + | ENUM dtype | + | STRING ext-dtype | + | STRING meaning | + | STRING formatid | + | ENUM restriction | + | STRING ext-restriction | + | ID observable-id | + +------------------------+ + + Figure 4: The iodef:ExtensionType Type + + The element content of this type is the extension being added to the + data model. This content is defined in the data model as "xs:any" + per [W3C.SCHEMA]. + + The attributes of the iodef:ExtensionType type are: + + name + Optional. STRING. A free-form name of the field or data element. + + dtype + Required. ENUM. The data type of the element content. The + default value is "string". These values are maintained in the + "ExtensionType-dtype" IANA registry per Section 10.2. + + 1. boolean. The element content is of type BOOLEAN. + + 2. byte. The element content is of type BYTE. + + 3. bytes. The element content is of type HEXBIN. + + 4. character. The element content is of type CHARACTER. + + 5. date-time. The element content is of type DATETIME. + + 6. ntpstamp. Same as date-time. + + 7. integer. The element content is of type INTEGER. + + 8. portlist. The element content is of type PORTLIST. + + 9. real. The element content is of type REAL. + + + +Danyliw Standards Track [Page 16] + +RFC 7970 IODEF Version 2 November 2016 + + + 10. string. The element content is of type STRING. + + 11. file. The element content is a base64-encoded binary file + encoded as a BYTE[] type. + + 12. path. The element content is a file-system path encoded as a + STRING type. + + 13. frame. The element content is a Layer 2 frame encoded as a + HEXBIN type. + + 14. packet. The element content is a Layer 3 packet encoded as a + HEXBIN type. + + 15. ipv4-packet. The element content is an IPv4 packet encoded + as a HEXBIN type. + + 16. ipv6-packet. The element content is an IPv6 packet encoded + as a HEXBIN type. + + 17. url. The element content is of type URL. + + 18. csv. The element content is a comma-separated value (CSV) + list per Section 2 of [RFC4180] encoded as a STRING type. + + 19. winreg. The element content is a Microsoft Windows registry + key encoded as a STRING type. + + 20. xml. The element content is XML. See Section 5.2. + + 21. ext-value. A value used to indicate that this attribute is + extended and the actual value is provided using the + corresponding ext-* attribute. See Section 5.1.1. + + ext-dtype + Optional. STRING. A means by which to extend the dtype + attribute. See Section 5.1.1. + + meaning + Optional. STRING. A free-form text description of the element + content. + + formatid + Optional. STRING. An identifier referencing the format or + semantics of the element content. + + + + + + +Danyliw Standards Track [Page 17] + +RFC 7970 IODEF Version 2 November 2016 + + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3. The IODEF Information Model + + 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. + +3.1. IODEF-Document Class + + The IODEF-Document class is the top level class in the IODEF data + model. All IODEF documents are an instance of this class. + + +--------------------------+ + | IODEF-Document | + +--------------------------+ + | STRING version |<>--{1..*}--[ Incident ] + | ENUM xml:lang |<>--{0..*}--[ AdditionalData ] + | STRING format-id | + | STRING private-enum-name | + | STRING private-enum-id | + +--------------------------+ + + Figure 5: The IODEF-Document Class + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 19] + +RFC 7970 IODEF Version 2 November 2016 + + +3.2. Incident Class + + The Incident class describes commonly exchanged information when + reporting or sharing derived analysis from security incidents. + + +-------------------------+ + | Incident | + +-------------------------+ + | ENUM purpose |<>----------[ IncidentID ] + | STRING ext-purpose |<>--{0..1}--[ AlternativeID ] + | ENUM status |<>--{0..*}--[ RelatedActivity ] + | STRING ext-status |<>--{0..1}--[ DetectTime ] + | ENUM xml:lang |<>--{0..1}--[ StartTime ] + | ENUM restriction |<>--{0..1}--[ EndTime ] + | STRING ext-restriction |<>--{0..1}--{ RecoveryTime ] + | ID observable-id |<>--{0..1}--[ ReportTime ] + | |<>----------[ GenerationTime ] + | |<>--{0..*}--[ Description ] + | |<>--{0..*} [ Discovery ] + | |<>--{0..*}--[ Assessment ] + | |<>--{0..*}--[ Method ] + | |<>--{1..*}--[ Contact ] + | |<>--{0..*}--[ EventData ] + | |<>--{0..1}--[ IndicatorData ] + | |<>--{0..1}--[ History ] + | |<>--{0..*}--[ AdditionalData ] + +-------------------------+ + + Figure 6: The Incident Class + + The aggregate classes of the Incident class are: + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.3. Common Attributes + + There are a number of recurring attributes used in the information + model. They are documented in this section. + +3.3.1. restriction Attribute + + 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. + + + + + + +Danyliw Standards Track [Page 24] + +RFC 7970 IODEF Version 2 November 2016 + + +3.3.2. observable-id Attribute + + 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. + +3.4. IncidentID 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. + + +------------------------+ + | IncidentID | + +------------------------+ + | STRING | + | | + | STRING name | + | STRING instance | + | ENUM restriction | + | STRING ext-restriction | + +------------------------+ + + Figure 7: The IncidentID Class + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.5. AlternativeID Class + + 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. + + +------------------------+ + | AlternativeID | + +------------------------+ + | ENUM restriction |<>--{1..*}--[ IncidentID ] + | STRING ext-restriction | + +------------------------+ + + Figure 8: The AlternativeID Class + + The aggregate class of the AlternativeID class is: + + IncidentID + One or more. The tracking number of another CSIRT. See + Section 3.4. + + The attributes of the AlternativeID class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + + + + + + + +Danyliw Standards Track [Page 26] + +RFC 7970 IODEF Version 2 November 2016 + + +3.6. RelatedActivity Class + + 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. + + +------------------------+ + | RelatedActivity | + +------------------------+ + | ENUM restriction |<>--{0..*}--[ IncidentID ] + | STRING ext-restriction |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ ThreatActor ] + | |<>--{0..*}--[ Campaign ] + | |<>--{0..*}--[ IndicatorID ] + | |<>--{0..1}--[ Confidence ] + | |<>--{0..*}--[ Description ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 9: The RelatedActivity Class + + 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 attributes of the RelatedActivity class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.7. ThreatActor Class + + The ThreatActor class describes a threat actor. + + +------------------------+ + | ThreatActor | + +------------------------+ + | ENUM restriction |<>--{0..*}--[ ThreatActorID ] + | STRING ext-restriction |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 10: The ThreatActor Class + + The aggregate classes of the ThreatActor class are: + + ThreatActorID + Zero or more. STRING. An identifier for the threat actor. + + URL + Zero or more. URL. A URL to a reference describing the threat + actor. + + Description + Zero or more. ML_STRING. A description of the threat actor. + + + + +Danyliw Standards Track [Page 28] + +RFC 7970 IODEF Version 2 November 2016 + + + AdditionalData + Zero or more. EXTENSION. A mechanism by which to extend the data + model. + + The ThreatActor class MUST have at least one instance of a child + class. + + The attributes of the ThreatActor class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.8. Campaign Class + + The Campaign class describes a campaign of attacks by a threat actor. + + +------------------------+ + | Campaign | + +------------------------+ + | ENUM restriction |<>--{0..*}--[ CampaignID ] + | STRING ext-restriction |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 11: The Campaign Class + + The aggregate classes of the Campaign class are: + + CampaignID + Zero or more. STRING. An identifier for the campaign. + + URL + Zero or more. URL. A URL to a reference describing the campaign. + + Description + Zero or more. ML_STRING. A description of the campaign. + + AdditionalData + Zero or more. EXTENSION. A mechanism by which to extend the data + model. + + The Campaign class MUST have at least one instance of a child class. + + + + +Danyliw Standards Track [Page 29] + +RFC 7970 IODEF Version 2 November 2016 + + + The attributes of the Campaign class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.9. Contact Class + + 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. + + +------------------------+ + | Contact | + +------------------------+ + | ENUM role |<>--{0..*}--[ ContactName ] + | STRING ext-role |<>--{0..*}--[ ContactTitle ] + | ENUM type |<>--{0..*}--[ Description ] + | STRING ext-type |<>--{0..*}--[ RegistryHandle ] + | ENUM restriction |<>--{0..*}--[ PostalAddress ] + | STRING ext-restriction |<>--{0..*}--[ Email ] + | |<>--{0..*}--[ Telephone ] + | |<>--{0..1}--[ Timezone ] + | |<>--{0..*}--[ Contact ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 12: The Contact Class + + + + + + +Danyliw Standards Track [Page 30] + +RFC 7970 IODEF Version 2 November 2016 + + + The aggregate classes of the Contact class are: + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 33] + +RFC 7970 IODEF Version 2 November 2016 + + +3.9.1. RegistryHandle Class + + The RegistryHandle class represents a handle into an Internet + registry or community-specific database. + + +---------------------+ + | RegistryHandle | + +---------------------+ + | STRING | + | | + | ENUM registry | + | STRING ext-registry | + +---------------------+ + + Figure 13: The RegistryHandle Class + + 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. + + + + +Danyliw Standards Track [Page 34] + +RFC 7970 IODEF Version 2 November 2016 + + +3.9.2. PostalAddress Class + + The PostalAddress class specifies a postal address and associated + annotation. + + +--------------------+ + | PostalAddress | + +--------------------+ + | ENUM type |<>----------[ PAddress ] + | STRING ext-type |<>--{0..*}--[ Description ] + +--------------------+ + + Figure 14: The PostalAddress Class + + 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. + + + + + + + + + + +Danyliw Standards Track [Page 35] + +RFC 7970 IODEF Version 2 November 2016 + + +3.9.3. Email Class + + The Email class specifies an email address and associated annotation. + + +--------------------+ + | Email | + +--------------------+ + | ENUM type |<>----------[ EmailTo ] + | STRING ext-type |<>--{0..*}--[ Description ] + +--------------------+ + + Figure 15: The Email Class + + The aggregate classes of the Email class are: + + EmailTo + One. EMAIL. An email address. + + 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. + + + + + + + + + + +Danyliw Standards Track [Page 36] + +RFC 7970 IODEF Version 2 November 2016 + + +3.9.4. Telephone Class + + The Telephone class describes a telephone number and associated + annotation. + + +--------------------+ + | Telephone | + +--------------------+ + | ENUM type |<>----------[ TelephoneNumber ] + | STRING ext-type |<>--{0..*}--[ Description ] + +--------------------+ + + Figure 16: The Telephone Class + + The aggregate classes of the Telephone class are: + + TelephoneNumber + One. PHONE. A telephone number. + + 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. + + + + + +Danyliw Standards Track [Page 37] + +RFC 7970 IODEF Version 2 November 2016 + + +3.10. Discovery Class + + The Discovery class describes how an incident was detected. + + +------------------------+ + | Discovery | + +------------------------+ + | ENUM source |<>--{0..*}--[ Description ] + | STRING ext-source |<>--{0..*}--[ Contact ] + | ENUM restriction |<>--{0..*}--[ DetectionPattern ] + | STRING ext-restriction | + +------------------------+ + + Figure 17: The Discovery Class + + The aggregate classes of the Discovery class are: + + 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. + + 4. av. Antivirus or antispam software. + + 5. third-party-monitoring. Contracted third-party monitoring + service. + + + + +Danyliw Standards Track [Page 38] + +RFC 7970 IODEF Version 2 November 2016 + + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + + + + + +Danyliw Standards Track [Page 39] + +RFC 7970 IODEF Version 2 November 2016 + + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.10.1. DetectionPattern Class + + 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. + + +------------------------+ + | DetectionPattern | + +------------------------+ + | ENUM restriction |<>----------[ Application ] + | STRING ext-restriction |<>--{0..*}--[ Description ] + | ID observable-id |<>--{0..*}--[ DetectionConfiguration ] + +------------------------+ + + Figure 18: The DetectionPattern Class + + 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 attributes of the DetectionPattern class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + + + + +Danyliw Standards Track [Page 40] + +RFC 7970 IODEF Version 2 November 2016 + + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3.11. Method Class + + 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. + + +------------------------+ + | Method | + +------------------------+ + | ENUM restriction |<>--{0..*}--[ Reference ] + | STRING ext-restriction |<>--{0..*}--[ Description ] + | |<>--{0..*}--[ sci:AttackPattern ] + | |<>--{0..*}--[ sci:Vulnerability ] + | |<>--{0..*}--[ sci:Weakness ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 19: The Method Class + + The aggregate classes of the Method class are: + + Reference + Zero or more. A reference to a vulnerability, malware sample, + advisory, or analysis of an attack technique. See Section 3.11.1. + + Description + Zero or more. ML_STRING. A free-form text description of + techniques, tactics, or procedures used by the threat actor. + + sci:AttackPattern + Zero or more. A reference to a pattern of attack or exploitation + per [RFC7203]. + + sci:Vulnerability + Zero or more. A reference to a vulnerability per [RFC7203]. + + sci:Weakness + Zero or more. A reference to the exploited weakness per + [RFC7203]. + + + + +Danyliw Standards Track [Page 41] + +RFC 7970 IODEF Version 2 November 2016 + + + AdditionalData + Zero or more. EXTENSION. A mechanism by which to extend the data + model. + + An instance of one of these children MUST be present. + + The attributes of the Method class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.11.1. Reference Class + + The Reference class is an external reference to relevant information + such as a vulnerability, IDS alert, malware sample, advisory, or + attack technique. + + +-------------------------+ + | Reference | + +-------------------------+ + | ID observable-id |<>--{0..1}--[ enum:ReferenceName ] + | |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + +-------------------------+ + + Figure 20: The Reference Class + + The aggregate classes of the Reference class are: + + enum:ReferenceName + Zero or one. Reference identifier per [RFC7495]. + + URL + Zero or more. URL. A URL to a reference. + + Description + Zero or more. ML_STRING. A free-form text description of this + reference. + + At least one of these classes MUST be present. + + + + + + + +Danyliw Standards Track [Page 42] + +RFC 7970 IODEF Version 2 November 2016 + + + The attribute of the Reference class is: + + observable-id + Optional. ID. See Section 3.3.2. + +3.12. Assessment Class + + The Assessment class describes the repercussions of the incident to + the victim. + + +-------------------------+ + | Assessment | + +-------------------------+ + | ENUM occurrence |<>--{0..*}--[ IncidentCategory ] + | ENUM restriction |<>--{0..*}--[ SystemImpact ] + | STRING ext-restriction |<>--{0..*}--[ BusinessImpact ] + | ID observable-id |<>--{0..*}--[ TimeImpact ] + | |<>--{0..*}--[ MonetaryImpact ] + | |<>--{0..*}--[ IntendedImpact ] + | |<>--{0..*}--[ Counter ] + | |<>--{0..*}--[ MitigatingFactor ] + | |<>--{0..*}--[ Cause ] + | |<>--{0..1}--[ Confidence ] + | |<>--{0..*}--[ AdditionalData ] + +-------------------------+ + + Figure 21: The Assessment Class + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + + + +Danyliw Standards Track [Page 44] + +RFC 7970 IODEF Version 2 November 2016 + + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3.12.1. SystemImpact Class + + The SystemImpact class describes the technical impact of the incident + to the systems on the network. + + +-----------------------+ + | SystemImpact | + +-----------------------+ + | ENUM severity |<>--{0..*}--[ Description ] + | ENUM completion | + | ENUM type | + | STRING ext-type | + +-----------------------+ + + Figure 22: The SystemImpact Class + + The aggregate class of the SystemImpact class is: + + 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. + + 23. unknown. The impact is unknown. + + 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. + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 47] + +RFC 7970 IODEF Version 2 November 2016 + + +3.12.2. BusinessImpact Class + + The BusinessImpact class describes and characterizes the degree to + which the function of the organization was impacted by the incident. + + +-------------------------+ + | BusinessImpact | + +-------------------------+ + | ENUM severity |<>--{0..*}--[ Description ] + | STRING ext-severity | + | ENUM type | + | STRING ext-type | + +-------------------------+ + + Figure 23: The BusinessImpact Class + + 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. + +3.12.3. TimeImpact Class + + 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. + + +---------------------+ + | TimeImpact | + +---------------------+ + | REAL | + | | + | ENUM severity | + | ENUM metric | + | STRING ext-metric | + | ENUM duration | + | STRING ext-duration | + +---------------------+ + + Figure 24: The TimeImpact Class + + 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. + + + + + + + + + + +Danyliw Standards Track [Page 51] + +RFC 7970 IODEF Version 2 November 2016 + + +3.12.4. MonetaryImpact Class + + 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. + + +------------------+ + | MonetaryImpact | + +------------------+ + | REAL | + | | + | ENUM severity | + | STRING currency | + +------------------+ + + Figure 25: The MonetaryImpact Class + + 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. + + + + + + + + + + + +Danyliw Standards Track [Page 52] + +RFC 7970 IODEF Version 2 November 2016 + + +3.12.5. Confidence Class + + 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. + + +-------------------+ + | Confidence | + +-------------------+ + | REAL | + | | + | ENUM rating | + | STRING ext-rating | + +-------------------+ + + Figure 26: The Confidence Class + + 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. + + + + +Danyliw Standards Track [Page 53] + +RFC 7970 IODEF Version 2 November 2016 + + +3.13. History Class + + The History class is a log of the significant events or actions + performed by the involved parties during the course of handling the + incident. + + The level of detail maintained in this log is left up to the + discretion of those handling the incident. + + +------------------------+ + | History | + +------------------------+ + | ENUM restriction |<>--{1..*}--[ HistoryItem ] + | STRING ext-restriction | + +------------------------+ + + Figure 27: The History Class + + The aggregate classes of the History class are: + + HistoryItem + One or more. An entry in the history log of significant events or + actions performed by the involved parties. See Section 3.13.1. + + The attributes of the History class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.13.1. HistoryItem Class + + 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. + + + + + + + + + + + +Danyliw Standards Track [Page 54] + +RFC 7970 IODEF Version 2 November 2016 + + + +-------------------------+ + | HistoryItem | + +-------------------------+ + | ENUM action |<>----------[ DateTime ] + | STRING ext-action |<>--{0..1}--[ IncidentID ] + | ENUM restriction |<>--{0..1}--[ Contact ] + | STRING ext-restriction |<>--{0..*}--[ Description ] + | ID observable-id |<>--{0..*}--[ DefinedCOA ] + | |<>--{0..*}--[ AdditionalData ] + +-------------------------+ + + Figure 28: The HistoryItem Class + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 56] + +RFC 7970 IODEF Version 2 November 2016 + + +3.14. EventData Class + + The EventData class is a container class to organize data about + events that occurred during an incident. + + +-------------------------+ + | EventData | + +-------------------------+ + | ENUM restriction |<>--{0..*}--[ Description ] + | STRING ext-restriction |<>--{0..1}--[ DetectTime ] + | ID observable-id |<>--{0..1}--[ StartTime ] + | |<>--{0..1}--[ EndTime ] + | |<>--{0..1}--[ RecoveryTime ] + | |<>--{0..1}--[ ReportTime ] + | |<>--{0..*}--[ Contact ] + | |<>--{0..*}--[ Discovery ] + | |<>--{0..1}--[ Assessment ] + | |<>--{0..*}--[ Method ] + | |<>--{0..*}--[ Flow ] + | |<>--{0..*}--[ Expectation ] + | |<>--{0..1}--[ Record ] + | |<>--{0..*}--[ EventData ] + | |<>--{0..*}--[ AdditionalData ] + +-------------------------+ + + Figure 29: The EventData Class + + The aggregate classes of the EventData class are: + + Description + Zero or more. ML_STRING. A free-form text description of the + event. + + DetectTime + Zero or one. DATETIME. The time the event was detected. + + StartTime + Zero or one. DATETIME. The time the event started. + + EndTime + Zero or one. DATETIME. The time the event ended. + + RecoveryTime + Zero or one. DATETIME. The time the site recovered from the + event. + + ReportTime + Zero or one. DATETIME. The time the event was reported. + + + +Danyliw Standards Track [Page 57] + +RFC 7970 IODEF Version 2 November 2016 + + + Contact + Zero or more. Contact information for the parties involved in the + event. See Section 3.9. + + Discovery + Zero or more. The means by which the event was detected. See + Section 3.10. + + Assessment + Zero or one. The impact of the event on the victim and the + actions taken. See Section 3.12. + + Method + Zero or more. The technique used by the threat actor in the + event. See Section 3.11. + + Flow + Zero or more. A description of the systems or networks involved. + See Section 3.16. + + Expectation + Zero or more. The expected action to be performed by the + recipient for the described event. See Section 3.15. + + Record + Zero or one. Supportive data (e.g., log files) that provides + additional information about the event. See Section 3.22. + + EventData + Zero or more. A recursive definition of the EventData class. See + Section 3.14.2 for an explanation on using this class. + + AdditionalData + Zero or more. EXTENSION. An extension mechanism for data not + explicitly represented in the data model. + + At least one of the aggregate classes MUST be present in an instance + of the EventData class. + + The attributes of the EventData class are: + + 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. + + + +Danyliw Standards Track [Page 58] + +RFC 7970 IODEF Version 2 November 2016 + + + observable-id + Optional. ID. See Section 3.3.2. + +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. + +3.14.2. Recursive Definition of EventData + + 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. + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 59] + +RFC 7970 IODEF Version 2 November 2016 + + + +------------------+ + | EventData (1) | + +------------------+ + | |<>----[ Contact ] + | | + | |<>----[ EventData (2) ]<>----[ Flow ] + | | [ ]<>----[ Assessment ] + | | + | |<>----[ EventData (3) ]<>----[ Flow ] + | | [ ]<>----[ Assessment ] + +------------------+ + + Figure 30: Recursion in the EventData Class + +3.15. Expectation Class + + The Expectation class conveys to the recipient of the IODEF document + the actions the sender is requesting. + + +-------------------------+ + | Expectation | + +-------------------------+ + | ENUM action |<>--{0..*}--[ Description ] + | STRING ext-action |<>--{0..*}--[ DefinedCOA ] + | ENUM severity |<>--{0..1}--[ StartTime ] + | ENUM restriction |<>--{0..1}--[ EndTime ] + | STRING ext-restriction |<>--{0..1}--[ Contact ] + | ID observable-id | + +-------------------------+ + + Figure 31: The Expectation Class + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.16. Flow Class + + The Flow class describes the systems and networks involved in the + incident and the relationships between them. + + +------------------+ + | Flow | + +------------------+ + | |<>--{1..*}--[ System ] + +------------------+ + + Figure 32: The Flow Class + + The aggregate class of the Flow class is: + + System + One or More. A host or network involved in an event. See + Section 3.17. + + The Flow class has no attributes. + + + + + +Danyliw Standards Track [Page 63] + +RFC 7970 IODEF Version 2 November 2016 + + +3.17. System Class + + The System class describes a system or network involved in an event. + + +------------------------+ + | System | + +------------------------+ + | ENUM category |<>----------[ Node ] + | STRING ext-category |<>--{0..*}--[ NodeRole ] + | STRING interface |<>--{0..*}--[ Service ] + | ENUM spoofed |<>--{0..*}--[ OperatingSystem ] + | ENUM virtual |<>--{0..*}--[ Counter ] + | ENUM ownership |<>--{0..*}--[ AssetID ] + | STRING ext-ownership |<>--{0..*}--[ Description ] + | ENUM restriction |<>--{0..*}--[ AdditionalData ] + | STRING ext-restriction | + | ID observable-id | + +------------------------+ + + Figure 33: The System Class + + The aggregate classes of the System class are: + + 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. + + restriction + Optional. ENUM. See Section 3.3.1. + + + + + +Danyliw Standards Track [Page 66] + +RFC 7970 IODEF Version 2 November 2016 + + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3.18. Node Class + + The Node class identifies a system, asset, or network and its + location. + + +---------------+ + | Node | + +---------------+ + | |<>--{0..*}--[ DomainData ] + | |<>--{0..*}--[ Address ] + | |<>--{0..1}--[ PostalAddress ] + | |<>--{0..*}--[ Location ] + | |<>--{0..*}--[ Counter ] + +---------------+ + + Figure 34: The Node Class + + The aggregate classes of the Node class are: + + 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 Node class has no attributes. + +3.18.1. Address Class + + The Address class represents a hardware (Layer 2), network (Layer 3), + or application (Layer 7) address. + + +-------------------------+ + | Address | + +-------------------------+ + | STRING | + | | + | ENUM category | + | STRING ext-category | + | STRING vlan-name | + | INTEGER vlan-num | + | ID observable-id | + +-------------------------+ + + Figure 35: The Address Class + + 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). + + 5. ipv4-net. IPv4 network address in dotted-decimal notation, + slash, significant bits (i.e., a.b.c.d/nn). + + + + + +Danyliw Standards Track [Page 68] + +RFC 7970 IODEF Version 2 November 2016 + + + 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). + + 8. ipv6-addr. IPv6 host address per Section 4 of [RFC5952]. + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.18.2. NodeRole Class + + The NodeRole class describes the function performed by or role of a + particular system, asset, or network. + + + + +Danyliw Standards Track [Page 69] + +RFC 7970 IODEF Version 2 November 2016 + + + +-----------------------+ + | NodeRole | + +-----------------------+ + | ENUM category |<>--{0..*}--[ Description ] + | STRING ext-category | + +-----------------------+ + + Figure 36: The NodeRole Class + + The aggregate class of the NodeRole class is: + + Description + Zero or more. ML_STRING. A free-form text description of the + role of the system. + + The attributes of the NodeRole class are: + + category + Required. ENUM. Function or role of a node. These values are + maintained in the "NodeRole-category" IANA registry per + Section 10.2. + + 1. client. Client computer. + + 2. client-enterprise. Client computer on the enterprise + network. + + 3. client-partner. Client computer on network of a partner. + + 4. client-remote. Client computer remotely connected to the + enterprise network. + + 5. client-kiosk. Client computer serving as a kiosk. + + 6. client-mobile. Mobile device. + + 7. server-internal. Server with internal services. + + 8. server-public. Server with public services. + + 9. www. WWW server. + + 10. mail. Mail server. + + 11. webmail. Web mail server. + + 12. messaging. Messaging server (e.g., NNTP, IRC, IM). + + + + +Danyliw Standards Track [Page 70] + +RFC 7970 IODEF Version 2 November 2016 + + + 13. streaming. Streaming-media server. + + 14. voice. Voice server (e.g., SIP, H.323). + + 15. file. File server. + + 16. ftp. FTP server. + + 17. p2p. Peer-to-peer node. + + 18. name. Name server (e.g., DNS, WINS). + + 19. directory. Directory server (e.g., LDAP, finger, whois). + + 20. credential. Credential server (e.g., domain controller, + Kerberos). + + 21. print. Print server. + + 22. application. Application server. + + 23. database. Database server. + + 24. backup. Backup server. + + 25. dhcp. DHCP server. + + 26. assessment. Assessment server (e.g., vulnerability scanner, + endpoint assessment). + + 27. source-control. Source code control server. + + 28. config-management. Configuration management server. + + 29. monitoring. Security monitoring server (e.g., IDS). + + 30. infra. Infrastructure server (e.g., router, firewall, DHCP). + + 31. infra-firewall. Firewall. + + 32. infra-router. Router. + + 33. infra-switch. Switch. + + 34. camera. Camera and video system. + + 35. proxy. Proxy server. + + + + +Danyliw Standards Track [Page 71] + +RFC 7970 IODEF Version 2 November 2016 + + + 36. remote-access. Remote access server. + + 37. log. Log server (e.g., syslog). + + 38. virtualization. Server running virtual machines. + + 39. pos. Point-of-sale device. + + 40. scada. Supervisory control and data acquisition (SCADA) + system. + + 41. scada-supervisory. Supervisory system for a SCADA. + + 42. sinkhole. Traffic sinkhole destination. + + 43. honeypot. Honeypot server. + + 44. anonymization. Anonymization server (e.g., Tor node). + + 45. c2-server. Malicious command and control server. + + 46. malware-distribution. Server that distributes malware + + 47. drop-server. Server to which exfiltrated content is + uploaded. + + 48. hop-point. Intermediary server used to get to a victim. + + 49. reflector. A system used in a reflector attack. + + 50. phishing-site. Site hosting phishing content. + + 51. spear-phishing-site. Site hosting spear-phishing content. + + 52. recruiting-site. Site to recruit. + + 53. fraudulent-site. Fraudulent site. + + 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. + + + + + + +Danyliw Standards Track [Page 72] + +RFC 7970 IODEF Version 2 November 2016 + + +3.18.3. Counter Class + + 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. + +3.19. DomainData Class + + The DomainData class describes a domain name and metadata associated + with this domain. + + +--------------------------+ + | DomainData | + +--------------------------+ + | ENUM system-status |<>----------[ Name ] + | STRING ext-system-status |<>--{0..1}--[ DateDomainWasChecked ] + | ENUM domain-status |<>--{0..1}--[ RegistrationDate ] + | STRING ext-domain-status |<>--{0..1}--[ ExpirationDate ] + | ID observable-id |<>--{0..*}--[ RelatedDNS ] + | |<>--{0..*}--[ Nameservers ] + | |<>--{0..1}--[ DomainContacts ] + +--------------------------+ + + Figure 38: The DomainData Class + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.19.1. Nameservers Class + + The Nameservers class describes the nameservers associated with a + given domain. + + +--------------------+ + | Nameservers | + +--------------------+ + | |<>----------[ Server ] + | |<>--{1..*}--[ Address ] + +--------------------+ + + Figure 39: The Nameservers Class + + + + + +Danyliw Standards Track [Page 77] + +RFC 7970 IODEF Version 2 November 2016 + + + The aggregate classes of the Nameservers class are: + + Server + One. STRING. The domain name of the nameserver. + + Address + One or more. The address of the nameserver. The value of the + category attribute MUST be either "ipv4-addr" or "ipv6-addr". See + Section 3.18.1. + + The Nameservers class has no attributes. + +3.19.2. DomainContacts Class + + 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. + + +--------------------+ + | DomainContacts | + +--------------------+ + | |<>--{0..1}--[ SameDomainContact ] + | |<>--{1..*}--[ Contact ] + +--------------------+ + + Figure 40: The DomainContacts Class + + 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 DomainContacts class has no attributes. + + + + + +Danyliw Standards Track [Page 78] + +RFC 7970 IODEF Version 2 November 2016 + + +3.20. Service Class + + 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. + + +-------------------------+ + | Service | + +-------------------------+ + | INTEGER ip-protocol |<>--{0..1}--[ ServiceName ] + | ID observable-id |<>--{0..1}--[ Port ] + | |<>--{0..1}--[ Portlist ] + | |<>--{0..1}--[ ProtoCode ] + | |<>--{0..1}--[ ProtoType ] + | |<>--{0..1}--[ ProtoField ] + | |<>--{0..1}--[ ApplicationHeader ] + | |<>--{0..1}--[ EmailData ] + | |<>--{0..1}--[ Application ] + +-------------------------+ + + Figure 41: The Service Class + + The aggregate classes of the Service class are: + + ServiceName + Zero or one. A protocol name. + + Port + Zero or one. INTEGER. A port number. + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.20.1. ServiceName Class + + 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. + + +--------------------+ + | ServiceName | + +--------------------+ + | |<>--{0..1}--[ IANAService ] + | |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + +--------------------+ + + Figure 42: The ServiceName Class + + + + +Danyliw Standards Track [Page 80] + +RFC 7970 IODEF Version 2 November 2016 + + + The aggregate classes of the ServiceName class are: + + IANAService + Zero or one. STRING. The name of the service per the "Service + Name" field of the registry [IANA.Ports]. + + URL + Zero or more. URL. A URL to a resource describing the service. + + Description + Zero or more. ML_STRING. A free-form text description of the + service. + + At least one of these classes MUST be present. + + The ServiceName class has no attributes. + +3.20.2. ApplicationHeader Class + + The ApplicationHeader class describes arbitrary fields from a + protocol header and its corresponding value. + + +--------------------------+ + | ApplicationHeader | + +--------------------------+ + | |<>--{1..*}--[ ApplicationHeaderField ] + +--------------------------+ + + Figure 43: The ApplicationHeader Class + + 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. + + The ApplicationHeader class has no attributes. + + + + + + + + + + + + + +Danyliw Standards Track [Page 81] + +RFC 7970 IODEF Version 2 November 2016 + + +3.21. EmailData Class + + The EmailData class describes headers from an email message and + cryptographic hashes and signatures applied to it. + + +-------------------------+ + | EmailData | + +-------------------------+ + | ID observable-id |<>--{0..*}--[ EmailTo ] + | |<>--{0..1}--[ EmailFrom ] + | |<>--{0..1}--[ EmailSubject ] + | |<>--{0..1}--[ EmailX-Mailer ] + | |<>--{0..*}--[ EmailHeaderField ] + | |<>--{0..1}--[ EmailHeaders ] + | |<>--{0..1}--[ EmailBody ] + | |<>--{0..1}--[ EmailMessage ] + | |<>--{0..*}--[ HashData ] + | |<>--{0..*}--[ SignatureData ] + +-------------------------+ + + Figure 44: EmailData Class + + The aggregate classes of the EmailData class are: + + 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 attribute of the EmailData class is: + + observable-id + Optional. ID. See Section 3.3.2. + +3.22. Record Class + + 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. + + +------------------------+ + | Record | + +------------------------+ + | ENUM restriction |<>--{1..*}--[ RecordData ] + | STRING ext-restriction | + +------------------------+ + + Figure 45: The Record Class + + The aggregate classes of the Record class are: + + 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 attributes of the Record class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + + + + +Danyliw Standards Track [Page 83] + +RFC 7970 IODEF Version 2 November 2016 + + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.22.1. RecordData Class + + The RecordData class describes or references log or audit data from a + given type of tool and provides a means to annotate the output. + + +------------------------+ + | RecordData | + +------------------------+ + | ENUM restriction |<>--{0..1}--[ DateTime ] + | STRING ext-restriction |<>--{0..*}--[ Description ] + | ID observable-id |<>--{0..1}--[ Application ] + | |<>--{0..*}--[ RecordPattern ] + | |<>--{0..*}--[ RecordItem ] + | |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ FileData ] + | |<>--{0..*}-- + | | [ WindowsRegistryKeysModified ] + | |<>--{0..*}--[ CertificateData ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 46: The RecordData Class + + The aggregate classes of the RecordData class are: + + DateTime + Zero or one. DATETIME. A timestamp of the data found in the + RecordItem or URL classes. + + Description + Zero or more. ML_STRING. A free-form text description of the + data provided in the RecordItem or URL classes. + + Application + Zero or one. SOFTWARE. Identifies the tool used to generate the + data in the RecordItem or URL classes. + + RecordPattern + Zero or more. A search string to precisely find the relevant data + in the RecordItem or URL classes. See Section 3.22.2. + + RecordItem + Zero or more. EXTENSION. Log, audit, or forensic data to support + the conclusions made during the course of analyzing the incident. + + + +Danyliw Standards Track [Page 84] + +RFC 7970 IODEF Version 2 November 2016 + + + URL + Zero or more. URL. A URL reference to a log or audit data. + + FileData + Zero or one. The files involved in the incident. See + Section 3.25. + + WindowsRegistryKeysModified + Zero or more. The registry keys that were involved in the + incident. See Section 3.23. + + CertificateData + Zero or more. The certificates that were involved in the + incident. See Section 3.24. + + AdditionalData + Zero or more. EXTENSION. An extension mechanism for data not + explicitly represented in the data model. + + At least one of the following classes MUST be present: RecordItem, + URL, FileData, WindowsRegistryKeysModified, CertificateData, or + AdditionalData. + + The attributes of the RecordData class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3.22.2. RecordPattern Class + + 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. + + + + + + + + + + +Danyliw Standards Track [Page 85] + +RFC 7970 IODEF Version 2 November 2016 + + + +-----------------------+ + | RecordPattern | + +-----------------------+ + | STRING | + | | + | ENUM type | + | STRING ext-type | + | INTEGER offset | + | ENUM offsetunit | + | STRING ext-offsetunit | + | INTEGER instance | + +-----------------------+ + + Figure 47: The RecordPattern Class + + 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. + +3.23. WindowsRegistryKeysModified Class + + The WindowsRegistryKeysModified class describes Windows operating + system registry keys and the operations that were performed on them. + This class was derived from [RFC5901]. + + +-----------------------------+ + | WindowsRegistryKeysModified | + +-----------------------------+ + | ID observable-id |<>--{1..*}--[ Key ] + +-----------------------------+ + + Figure 48: The WindowsRegistryKeysModified Class + + The aggregate classes of the WindowsRegistryKeysModified class are: + + Key + One or more. The Windows registry key. See Section 3.23.1. + + The attribute of the WindowsRegistryKeysModified class is: + + observable-id + Optional. ID. See Section 3.3.2. + + + + + + + +Danyliw Standards Track [Page 87] + +RFC 7970 IODEF Version 2 November 2016 + + +3.23.1. Key Class + + The Key class describes a Windows operating system registry key name + and value pair, as well as the operation performed on it. + + +---------------------------+ + | Key | + +---------------------------+ + | ENUM registryaction |<>----------[ KeyName ] + | STRING ext-registryaction |<>--{0..1}--[ KeyValue ] + | ID observable-id | + +---------------------------+ + + Figure 49: The Key Class + + The aggregate classes of the Key class are: + + 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. + + observable-id + Optional. ID. See Section 3.3.2. + +3.24. CertificateData Class + + The CertificateData class describes X.509 certificates. + + +------------------------+ + | CertificateData | + +------------------------+ + | ENUM restriction |<>--{1..*}--[ Certificate ] + | STRING ext-restriction | + | ID observable-id | + +------------------------+ + + Figure 50: The CertificateData Class + + The aggregate classes of the CertificateData class are: + + Certificate + One or more. A description of an X.509 certificate or certificate + chain. See Section 3.24.1. + + The attributes of the CertificateData class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + + + + + + + + + + + + + +Danyliw Standards Track [Page 89] + +RFC 7970 IODEF Version 2 November 2016 + + +3.24.1. Certificate Class + + The Certificate class describes a given X.509 certificate or + certificate chain. + + +--------------------------+ + | Certificate | + +--------------------------+ + | ID observable-id |<>----------[ ds:X509Data ] + | |<>--{0..*}--[ Description ] + +--------------------------+ + + Figure 51: The Certificate Class + + The aggregate classes of the Certificate class are: + + ds:X509Data + One. A given X.509 certificate or chain. See Section 4.4.4 of + [W3C.XMLSIG]. + + Description + Zero or more. ML_STRING. A free-form text description explaining + the context of this certificate. + + The attributes of the Certificate class are: + + observable-id + Optional. ID. See Section 3.3.2. + +3.25. FileData Class + + The FileData class describes a file or set of files. + + +------------------------+ + | FileData | + +------------------------+ + | ENUM restriction |<>--{1..*}--[ File ] + | STRING ext-restriction | + | ID observable-id | + +------------------------+ + + Figure 52: The FileData Class + + The aggregate classes of the FileData class are: + + File + One or more. A description of a file. See Section 3.25.1. + + + + +Danyliw Standards Track [Page 90] + +RFC 7970 IODEF Version 2 November 2016 + + + The attributes of the FileData class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + observable-id + Optional. ID. See Section 3.3.2. + +3.25.1. File Class + + The File class describes a file; its associated metadata; and + cryptographic hashes and signatures applied to it. + + +-----------------------+ + | File | + +-----------------------+ + | ID observable-id |<>--{0..1}--[ FileName ] + | |<>--{0..1}--[ FileSize ] + | |<>--{0..1}--[ FileType ] + | |<>--{0..*}--[ URL ] + | |<>--{0..1}--[ HashData ] + | |<>--{0..1}--[ SignatureData ] + | |<>--{0..1}--[ AssociatedSoftware ] + | |<>--{0..*}--[ FileProperties ] + +-----------------------+ + + Figure 53: The File Class + + The aggregate classes of the File class are: + + 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. + + The attributes of the File class are: + + observable-id + Optional. ID. See Section 3.3.2. + +3.26. HashData Class + + The HashData class describes different types of hashes on a given + object (e.g., file, part of a file, email). + + +--------------------------+ + | HashData | + +--------------------------+ + | ENUM scope |<>--{0..1}--[ HashTargetID ] + | |<>--{0..*}--[ Hash ] + | |<>--{0..*}--[ FuzzyHash ] + +--------------------------+ + + Figure 54: The HashData Class + + The aggregate classes of the HashData class are: + + 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. + +3.26.1. Hash Class + + 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. + + +----------------+ + | Hash | + +----------------+ + | |<>----------[ ds:DigestMethod ] + | |<>----------[ ds:DigestValue ] + | |<>--{0..1}--[ ds:CanonicalizationMethod ] + | |<>--{0..1}--[ Application ] + +----------------+ + + Figure 55: The Hash Class + + The aggregate classes of the Hash class are: + + ds:DigestMethod + One. The hash algorithm used to generate the hash. See + Section 4.3.3.5 of [W3C.XMLSIG]. + + ds:DigestValue + One. The computed hash value. See Section 4.3.3.6 of + [W3C.XMLSIG]. + + ds:CanonicalizationMethod + Zero or one. The canonicalization method used on the object being + hashed. See Section 4.3.1 of [W3C.XMLSIG]. + + Application + Zero or one. SOFTWARE. The application used to calculate the + hash. + + The HashData class has no attributes. + + + + + + + +Danyliw Standards Track [Page 94] + +RFC 7970 IODEF Version 2 November 2016 + + +3.26.2. FuzzyHash Class + + The FuzzyHash class describes a fuzzy hash and the application used + to generate it. + + +--------------------------+ + | FuzzyHash | + +--------------------------+ + | |<>--{1..*}--[ FuzzyHashValue ] + | |<>--{0..1}--[ Application ] + | |<>--{0..*}--[ AdditionalData ] + +--------------------------+ + + Figure 56: The FuzzyHash Class + + The aggregate classes of the FuzzyHash class are: + + FuzzyHashValue + One or more. EXTENSION. The computed fuzzy hash value. + + Application + Zero or one. SOFTWARE. The application used to calculate the + hash. + + AdditionalData + Zero or more. EXTENSION. Mechanism by which to extend the data + model. + + The FuzzyData class has no attributes. + +3.27. SignatureData Class + + The SignatureData class describes different types of digital + signatures on an object. + + +--------------------------+ + | SignatureData | + +--------------------------+ + | |<>--{1..*}--[ ds:Signature ] + +--------------------------+ + + Figure 57: The SignatureData Class + + + + + + + + + +Danyliw Standards Track [Page 95] + +RFC 7970 IODEF Version 2 November 2016 + + + The aggregate class of the SignatureData class is: + + Signature + One or more. A given signature. See Section 4.2 of [W3C.XMLSIG]. + + The SignatureData class has no attributes. + +3.28. IndicatorData Class + + The IndicatorData class describes indicators and metadata associated + with them. + + +--------------------------+ + | IndicatorData | + +--------------------------+ + | |<>--{1..*}--[ Indicator ] + +--------------------------+ + + Figure 58: The IndicatorData Class + + The aggregate class of the IndicatorData class is: + + Indicator + One or more. A description of an indicator. See Section 3.29. + + The IndicatorData class has no attributes. + +3.29. Indicator Class + + 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. + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 96] + +RFC 7970 IODEF Version 2 November 2016 + + + +------------------------+ + | Indicator | + +------------------------+ + | ENUM restriction |<>----------[ IndicatorID ] + | STRING ext-restriction |<>--{0..*}--[ AlternativeIndicatorID ] + | |<>--{0..*}--[ Description ] + | |<>--{0..1}--[ StartTime ] + | |<>--{0..1}--[ EndTime ] + | |<>--{0..1}--[ Confidence ] + | |<>--{0..*}--[ Contact ] + | |<>--{0..1}--[ Observable ] + | |<>--{0..1}--[ ObservableReference ] + | |<>--{0..1}--[ IndicatorExpression ] + | |<>--{0..1}--[ IndicatorReference ] + | |<>--{0..*}--[ NodeRole ] + | |<>--{0..*}--[ AttackPhase ] + | |<>--{0..*}--[ Reference ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 59: The Indicator Class + + The aggregate classes of the Indicator class are: + + 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. + + + + + + +Danyliw Standards Track [Page 98] + +RFC 7970 IODEF Version 2 November 2016 + + + The attributes of the Indicator class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.29.1. IndicatorID Class + + 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. + + + + + + + + + +Danyliw Standards Track [Page 99] + +RFC 7970 IODEF Version 2 November 2016 + + +3.29.2. AlternativeIndicatorID Class + + The AlternativeIndicatorID class lists alternative identifiers for an + indicator. + + +-------------------------+ + | AlternativeIndicatorID | + +-------------------------+ + | ENUM restriction |<>--{1..*}--[ IndicatorReference ] + | STRING ext-restriction | + +-------------------------+ + + Figure 61: The AlternativeIndicatorID Class + + The aggregate class of the AlternativeIndicatorID class is: + + IndicatorReference + One or more. A reference to an indicator. See Section 3.29.7. + + The attributes of the AlternativeIndicatorID class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 100] + +RFC 7970 IODEF Version 2 November 2016 + + +3.29.3. Observable Class + + The Observable class describes a feature and phenomenon that can be + observed or measured for the purposes of detecting malicious + behavior. + + +------------------------+ + | Observable | + +------------------------+ + | ENUM restriction |<>--{0..1}--[ System ] + | STRING ext-restriction |<>--{0..1}--[ Address ] + | |<>--{0..1}--[ DomainData ] + | |<>--{0..1}--[ Service ] + | |<>--{0..1}--[ EmailData ] + | |<>--{0..1}--[ WindowsRegistryKeysModified ] + | |<>--{0..1}--[ FileData ] + | |<>--{0..1}--[ CertificateData ] + | |<>--{0..1]--[ RegistryHandle ] + | |<>--{0..1}--[ RecordData ] + | |<>--{0..1}--[ EventData ] + | |<>--{0..1}--[ Incident ] + | |<>--{0..1}--[ Expectation ] + | |<>--{0..1}--[ Reference ] + | |<>--{0..1}--[ Assessment ] + | |<>--{0..1}--[ DetectionPattern ] + | |<>--{0..1}--[ HistoryItem ] + | |<>--{0..1}--[ BulkObservable ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 62: The Observable Class + + The aggregate classes of the Observable class are: + + System + Zero or one. A System observable. See Section 3.17. + + Address + Zero or one. An Address observable. See Section 3.18.1. + + DomainData + Zero or one. A DomainData observable. See Section 3.19. + + Service + Zero or one. A Service observable. See Section 3.20. + + EmailData + Zero or one. An EmailData observable. See Section 3.21. + + + +Danyliw Standards Track [Page 101] + +RFC 7970 IODEF Version 2 November 2016 + + + WindowsRegistryKeysModified + Zero or one. A WindowsRegistryKeysModified observable. See + Section 3.23. + + FileData + Zero or one. A FileData observable. See Section 3.25. + + CertificateData + Zero or one. A CertificateData observable. See Section 3.24. + + RegistryHandle + Zero or one. A RegistryHandle observable. See Section 3.9.1. + + RecordData + Zero or one. A RecordData observable. See Section 3.22.1. + + EventData + Zero or one. An EventData observable. See Section 3.14. + + Incident + Zero or one. An Incident observable. See Section 3.2. + + Expectation + Zero or one. An Expectation observable. See Section 3.15. + + Reference + Zero or one. A Reference observable. See Section 3.11.1. + + Assessment + Zero or one. An Assessment observable. See Section 3.12. + + DetectionPattern + Zero or one. A DetectionPattern observable. See Section 3.10.1. + + HistoryItem + Zero or one. A HistoryItem observable. See Section 3.13.1. + + BulkObservable + Zero or one. A bulk list of observables. See Section 3.29.3.1. + + AdditionalData + Zero or more. EXTENSION. Mechanism by which to extend the data + model. + + The Observable class MUST have exactly one of the possible child + classes. + + + + + +Danyliw Standards Track [Page 102] + +RFC 7970 IODEF Version 2 November 2016 + + + The attributes of the Observable class are: + + restriction + Optional. ENUM. See Section 3.3.1. + + ext-restriction + Optional. STRING. A means by which to extend the restriction + attribute. See Section 5.1.1. + +3.29.3.1. BulkObservable Class + + 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. + + +---------------------------+ + | BulkObservable | + +---------------------------+ + | ENUM type |<>--{0..1}--[ BulkObservableFormat ] + | STRING ext-type |<>----------[ BulkObservableList ] + | |<>--{0..*}--[ AdditionalData ] + +---------------------------+ + + Figure 63: The BulkObservable Class + + 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). + + 7. ipv6-addr. IPv6 host address, e.g., 2001:DB8::3 (per the + Address@category attribute). + + 8. ipv6-net. IPv6 network address, slash, significant bits, + e.g., 2001:DB8::/32 (per the Address@category attribute). + + 9. ipv6-net-mask. IPv6 network address, slash, network mask + (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. + +3.29.3.1.1. BulkObservableFormat Class + + The ObservableFormat class specifies metadata about the format of an + observable enumerated in a sibling BulkObservableList class. + + +---------------------------+ + | BulkObservableFormat | + +---------------------------+ + | |<>--{0..1}--[ Hash ] + | |<>--{0..*}--[ AdditionalData ] + +---------------------------+ + + Figure 64: The BulkObservableFormat Class + + The aggregate classes of the BulkObservableFormat class are: + + Hash + Zero or one. Describes the format of a hash. See Section 3.26.1. + + AdditionalData + Zero or more. EXTENSION. Mechanism by which to extend the data + model. + + The BulkObservableFormat class has no attributes. + + Either Hash or AdditionalData MUST be present. + +3.29.4. IndicatorExpression Class + + 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. + + + + + + +Danyliw Standards Track [Page 106] + +RFC 7970 IODEF Version 2 November 2016 + + + +--------------------------+ + | IndicatorExpression | + +--------------------------+ + | ENUM operator |<>--{0..*}--[ IndicatorExpression ] + | STRING ext-operator |<>--{0..*}--[ Observable ] + | |<>--{0..*}--[ ObservableReference ] + | |<>--{0..*}--[ IndicatorReference ] + | |<>--{0..1}--[ Confidence ] + | |<>--{0..*}--[ AdditionalData ] + +--------------------------+ + + Figure 65: The IndicatorExpression Class + + 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. + +3.29.5. Expressions with IndicatorExpression + + 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: + + 1 : + 2 [O1]: .. + 3 [O2]: .. + 4 : + + Equivalent expression: (O1 AND O2) + + Figure 66: Nested Elements in an IndicatorExpression without an + Operator Attribute Specified + + 1 : + 2 [O1]: .. + 3 [O2]: .. + 4 : + + Equivalent expression: (O1 OR O2) + + Figure 67: Nested Elements in an IndicatorExpression with an Operator + Attribute Specified + + + +Danyliw Standards Track [Page 108] + +RFC 7970 IODEF Version 2 November 2016 + + + 1 : + 2 : + 3 [O1]: .. + 4 [O2]: .. + 5 : + 6 [O3]: .. + 7 : + + Equivalent expression: ((O1 OR O2) OR O3) + + Figure 68: Nested Elements with a Recursive IndicatorExpression with + an Operator Attribute Specified + + 1 : + 2 : + 3 [O1]: .. + 4 [O2]: .. + 5 : + 6 : + + Equivalent expression: (NOT (O1 AND O2)) + + Figure 69: A Recursive IndicatorExpression with an Operator Attribute + Specified + + 1 : + 2 : + 3 [O1 with low confidence] : .. + 4 : + 5 : + 6 : + 7 [O2 with high confidence]: .. + 8 : + 9 : + 10 : + + Equivalent expression: ((O1) OR (O2)) + + Figure 70: Varying Confidence on Particular Observables + + Invalid algebraic expressions while valid XML MUST NOT be specified. + + + + + + + + + + +Danyliw Standards Track [Page 109] + +RFC 7970 IODEF Version 2 November 2016 + + +3.29.6. ObservableReference Class + + The ObservableReference describes a reference to an observable + feature or phenomenon described elsewhere in the document. + + The ObservableReference class has no content. + + +-------------------------+ + | ObservableReference | + +-------------------------+ + | IDREF uid-ref | + +-------------------------+ + + Figure 71: The ObservableReference Class + + The ObservableReference class has no content. + + 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. + +3.29.7. IndicatorReference Class + + 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 IndicatorReference class has no content. + + +--------------------------+ + | IndicatorReference | + +--------------------------+ + | IDREF uid-ref | + | STRING euid-ref | + | STRING version | + +--------------------------+ + + Figure 72: The IndicatorReference Class + + 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. + +3.29.8. AttackPhase Class + + The AttackPhase class describes a particular phase of an attack life + cycle. + + +------------------------+ + | AttackPhase | + +------------------------+ + | |<>--{0..*}--[ AttackPhaseID ] + | |<>--{0..*}--[ URL ] + | |<>--{0..*}--[ Description ] + | |<>--{0..*}--[ AdditionalData ] + +------------------------+ + + Figure 73: The AttackPhase Class + + The aggregate classes of the AttackPhase class are: + + AttackPhaseID + Zero or more. STRING. An identifier for the phase of the attack. + + URL + Zero or more. URL. A URL to a resource describing this phase of + the attack. + + Description + Zero or more. ML_STRING. A free-form text description of this + phase of the attack. + + AdditionalData + Zero or more. EXTENSION. A mechanism by which to extend the data + model. + + AttackPhase MUST have at least one instance of a child class. + + The AttackPhase class has no attributes. + + + + + + +Danyliw Standards Track [Page 111] + +RFC 7970 IODEF Version 2 November 2016 + + +4. Processing Considerations + + This section provides additional requirements and guidance on + creating and processing IODEF documents. + +4.1. Encoding + + 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: + + + + 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. + +4.2. IODEF Namespace + + 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: + + + +4.3. Validation + + 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. + +4.4. Incompatibilities with v1 + + 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. + +5.1.1. Private Extension of Enumerated Values + + 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: + + + + A given extension attribute MUST NOT be set unless the corresponding + extensible attribute has been set to "ext-value". + +5.1.2. Public Extension of Enumerated Values + + 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. + +5.2. Extending Classes + + 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". + + + attributeFormDefault="unqualified" + elementFormDefault="qualified"> + + + + + + The following XML excerpt demonstrates the use of the above schema as + an extension to the IODEF. + + + + ... + + + Field that could not be represented elsewhere + + + + + +5.3. Deconflicting Private Extensions + + 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. + + + + ... + English + Englisch + Anglais + + 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. + +7.1. Minimal Example + + A document containing only the mandatory elements and attributes. + + + + + + 492382 + 2015-07-18T09:00:00-05:00 + + + + +Danyliw Standards Track [Page 119] + +RFC 7970 IODEF Version 2 November 2016 + + + + contact@csirt.example.com + + + + + + +7.2. Indicators from a Campaign + + An example of C2 domains from a given campaign. + + + + + + 897923 + + + + TA-12-AGGRESSIVE-BUTTERFLY + + Aggressive Butterfly + + + C-2015-59405 + Orange Giraffe + + + 2015-10-02T11:18:00-05:00 + Summarizes the Indicators of Compromise + for the Orange Giraffe campaign of the Aggressive + Butterfly crime gang. + + + + + + CSIRT for example.com + + contact@csirt.example.com + + + + + +Danyliw Standards Track [Page 120] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + G90823490 + + C2 domains + 2014-12-02T11:18:00-05:00 + + + + kj290023j09r34.example.com + 09ijk23jfj0k8.example.net + klknjwfjiowjefr923.example.org + oimireik79msd.example.org + + + + + + + + +8. The IODEF Data Model (XML Schema) + + + + + + + + + + Incident Object Description Exchange Format v2.0 + + + +Danyliw Standards Track [Page 121] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 123] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 126] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 127] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 128] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 129] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 131] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 132] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 133] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 134] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 135] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 136] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 137] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 138] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 139] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 140] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 141] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 142] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 144] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 145] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 146] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 147] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 148] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 149] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 150] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 151] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 152] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 153] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 154] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 156] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 157] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 159] + +RFC 7970 IODEF Version 2 November 2016 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 160] + +RFC 7970 IODEF Version 2 November 2016 + + +9. Security Considerations + + 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. + +9.1. Security + + 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. + +9.2. Privacy + + 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. + +10.1. Namespace and Schema + + This document uses URNs to describe an XML namespace and schema + conforming to a registry mechanism described in [RFC3688]. + + Registration for the IODEF namespace: + + o URI: urn:ietf:params:xml:ns:iodef-2.0 + + o Registrant Contact: See the author in the "Author's Address" + section of this document. + + o XML: None. Namespace URIs do not represent an XML specification. + + Registration for the IODEF XML schema: + + o URI: urn:ietf:params:xml:schema:iodef-2.0 + + o Registrant Contact: See the first author of the "Author's Address" + section of this document. + + o XML: See Section 8 of this document. + +10.2. Enumerated Value Registries + + This document creates 34 identically structured registries to be + managed by IANA: + + o Name of the parent registry: "Incident Object Description Exchange + Format v2 (IODEF)" + + o URL of the registry: + + o Namespace format: A registry entry consists of: + + * 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 164] + +RFC 7970 IODEF Version 2 November 2016 + + + +-------------------------+-----------------------------+-----------+ + | Registry Name | IV (Value) | IV | + | | | (Desc.) | + +-------------------------+-----------------------------+-----------+ + | Restriction | iodef-restriction-type | 3.3.1 | + | | | | + | Incident-purpose | incident-purpose-type | 3.2 | + | | | | + | Incident-status | incident-status-type | 3.2 | + | | | | + | Contact-role | contact-role-type | 3.9 | + | | | | + | Contact-type | contact-type-type | 3.9 | + | | | | + | RegistryHandle-registry | registryhandle-registry- | 3.9.1 | + | | type | | + | | | | + | PostalAddress-type | postaladdress-type-type | 3.9.2 | + | | | | + | Telephone-type | telephone-type-type | 3.9.4 | + | | | | + | Email-type | email-type-type | 3.9.3 | + | | | | + | Expectation-action | action-type | 3.15 | + | | | | + | Discovery-source | discovery-source-type | 3.10 | + | | | | + | SystemImpact-type | systemimpact-type-type | 3.12.1 | + | | | | + | BusinessImpact-severity | businessimpact-severity- | 3.12.2 | + | | type | | + | | | | + | BusinessImpact-type | businessimpact-type-type | 3.12.2 | + | | | | + | TimeImpact-metric | timeimpact-metric-type | 3.12.3 | + | | | | + | TimeImpact-duration | duration-type | 3.12.3 | + | | | | + | Confidence-rating | confidence-rating-type | 3.12.5 | + | | | | + | NodeRole-category | noderole-category-type | 3.18.2 | + | | | | + | System-category | system-category-type | 3.17 | + | | | | + | System-ownership | system-ownership-type | 3.17 | + | | | | + | Address-category | address-category-type | 3.18.1 | + | | | | + + + +Danyliw Standards Track [Page 165] + +RFC 7970 IODEF Version 2 November 2016 + + + | Counter-type | counter-type-type | 3.18.3 | + | | | | + | Counter-unit | counter-unit-type | 3.18.3 | + | | | | + | DomainData-system- | domaindata-system-status- | 3.19 | + | status | type | | + | | | | + | DomainData-domain- | domaindata-domain-status- | 3.19 | + | status | type | | + | | | | + | RecordPattern-type | recordpattern-type-type | 3.22.2 | + | | | | + | RecordPattern- | recordpattern-offsetunit- | 3.22.2 | + | offsetunit | type | | + | | | | + | Key-registryaction | key-registryaction-type | 3.23.1 | + | | | | + | HashData-scope | hashdata-scope-type | 3.26 | + | | | | + | BulkObservable-type | bulkobservable-type-type | 3.29.3.1 | + | | | | + | IndicatorExpression- | indicatorexpression- | 3.29.4 | + | operator | operator-type | | + | | | | + | ExtensionType-dtype | dtype-type | 2.16 | + | | | | + | SoftwareReference-spec- | softwarereference-spec-id- | 2.15.1 | + | id | type | | + | | | | + | SoftwareReference-dtype | softwarereference-dtype- | 2.15.1 | + | | type | | + +-------------------------+-----------------------------+-----------+ + + Table 1: IANA Enumerated Value Registries + +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 + ) and schema + registries ("schema" on ) 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. + + This document obsoletes [RFC6685]. + +11. References + +11.1. Normative References + + [E.164] ITU Telecommunication Standardization Sector, "The + International Public Telecommunication Numbering Plan", + ITU-T Recommendation E.164, November 2010. + + [IANA.Media] + IANA, "Media Types", + . + + [IANA.Ports] + IANA, "Service Name and Transport Protocol Port Number + Registry", . + + [IANA.Protocols] + IANA, "Assigned Internet Protocol Numbers", + . + + [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, + . + + + + + + +Danyliw Standards Track [Page 167] + +RFC 7970 IODEF Version 2 November 2016 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO + 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November + 2003, . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, February + 2006, . + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol + (LDAP): Schema for User Applications", RFC 4519, + DOI 10.17487/RFC4519, June 2006, + . + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + . + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + + [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized + Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, + . + + + + +Danyliw Standards Track [Page 168] + +RFC 7970 IODEF Version 2 November 2016 + + + [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, + . + + [RFC7495] Montville, A. and D. Black, "Enumeration Reference Format + for the Incident Object Description Exchange Format + (IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015, + . + + [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, + . + + [W3C.SCHEMA.DTYPES] + Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes + Second Edition", W3C Recommendation REC-xmlschema- + 2-20041028, October 2004, + . + + [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, . + + [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, + . + + [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, . + + [W3C.XPATH] + Robie, J., Dyck, M., and J. Spiegel, "XML Path Language + (XPath) 3.1", W3C Candidate Recommendation CR-xpath- + 31-20151217, December 2015, + . + + + + + + +Danyliw Standards Track [Page 169] + +RFC 7970 IODEF Version 2 November 2016 + + +11.2. Informative References + + [KB310516] Microsoft Corporation, "How to add, modify, or delete + registry subkeys and values by using a .reg file", + September 2013, + . + + [NIST800.61rev2] + National Institute of Standards and Technology, "Computer + Security Incident Handling Guide", NIST Special + Publication 800-61, Revision 2, August 2012, + . + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + + [RFC3982] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) + Type for the Internet Registry Information Service + (IRIS)", RFC 3982, DOI 10.17487/RFC3982, January 2005, + . + + [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- + Separated Values (CSV) Files", RFC 4180, + DOI 10.17487/RFC4180, October 2005, + . + + [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident + Object Description Exchange Format", RFC 5070, + DOI 10.17487/RFC5070, December 2007, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document + Class for Reporting Phishing", RFC 5901, + DOI 10.17487/RFC5901, July 2010, + . + + + + + +Danyliw Standards Track [Page 170] + +RFC 7970 IODEF Version 2 November 2016 + + + [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", + RFC 6545, DOI 10.17487/RFC6545, April 2012, + . + + [RFC6546] Trammell, B., "Transport of Real-time Inter-network + Defense (RID) Messages over HTTP/TLS", RFC 6546, + DOI 10.17487/RFC6546, April 2012, + . + + [RFC6685] Trammell, B., "Expert Review for Incident Object + Description Exchange Format (IODEF) Extensions in IANA XML + Registry", RFC 6685, DOI 10.17487/RFC6685, July 2012, + . + + [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, + . + +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 + + Email: rdd@cert.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Danyliw Standards Track [Page 172] + -- cgit v1.2.3