RFC 5070
The Incident Object Description Exchange Format
The Incident Object Description Exchange Format 🎀
Part 1 of 15 💖 more parts coming, bestie!
Okay so this RFC is the Network Working Group doc for the Incident Object Description Exchange Format (IODEF) ✨. It's RFC 5070, written in December 2007, and it's a Standards Track document, which means it's an actual Internet protocol spec 👑. The authors are R. Danyliw from CERT, J. Meijer from UNINETT, and Y. Demchenko from the University of Amsterdam 🫶. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own, iconic 💅.
Status of This Memo
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋. If you want to know where this protocol stands in terms of standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share it with everyone 🌈.
Abstract
So the Incident Object Description Exchange Format (IODEF) is a data representation that gives everyone a framework for sharing the info that Computer Security Incident Response Teams (CSIRTs) usually swap about computer security incidents 🔥. This doc lays out the information model for the IODEF and gives you an associated data model written in XML Schema 🧚.
Table of Contents
Here's the full table of contents, copied exactly as it appears in the original 🍓:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. About the IODEF Data Model . . . . . . . . . . . . . . . . 5
1.4. About the IODEF Implementation . . . . . . . . . . . . . . 6
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Integers . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Real Numbers . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Characters and Strings . . . . . . . . . . . . . . . . . . 7
2.4. Multilingual Strings . . . . . . . . . . . . . . . . . . . 7
2.5. Bytes . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6. Hexadecimal Bytes . . . . . . . . . . . . . . . . . . . . 7
2.7. Enumerated Types . . . . . . . . . . . . . . . . . . . . . 8
2.8. Date-Time Strings . . . . . . . . . . . . . . . . . . . . 8
2.9. Timezone String . . . . . . . . . . . . . . . . . . . . . 8
2.10. Port Lists . . . . . . . . . . . . . . . . . . . . . . . . 8
2.11. Postal Address . . . . . . . . . . . . . . . . . . . . . . 9
2.12. Person or Organization . . . . . . . . . . . . . . . . . . 9
2.13. Telephone and Fax Numbers . . . . . . . . . . . . . . . . 9
2.14. Email String . . . . . . . . . . . . . . . . . . . . . . . 9
2.15. Uniform Resource Locator strings . . . . . . . . . . . . . 9
3. The IODEF Data Model . . . . . . . . . . . . . . . . . . . . . 9
3.1. IODEF-Document Class . . . . . . . . . . . . . . . . . . . 10
3.2. Incident Class . . . . . . . . . . . . . . . . . . . . . . 10
3.3. IncidentID Class . . . . . . . . . . . . . . . . . . . . . 14
3.4. AlternativeID Class . . . . . . . . . . . . . . . . . . . 14
3.5. RelatedActivity Class . . . . . . . . . . . . . . . . . . 15
3.6. AdditionalData Class . . . . . . . . . . . . . . . . . . . 16
3.7. Contact Class . . . . . . . . . . . . . . . . . . . . . . 18
3.7.1. RegistryHandle Class . . . . . . . . . . . . . . . . . 21
3.7.2. PostalAddress Class . . . . . . . . . . . . . . . . . 22
3.7.3. Email Class . . . . . . . . . . . . . . . . . . . . . 22
3.7.4. Telephone and Fax Classes . . . . . . . . . . . . . . 23
3.8. Time Classes . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.1. StartTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.2. EndTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.8.3. DetectTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.4. ReportTime . . . . . . . . . . . . . . . . . . . . . . 24
3.8.5. DateTime . . . . . . . . . . . . . . . . . . . . . . . 24
3.9. Method Class . . . . . . . . . . . . . . . . . . . . . . . 24
3.9.1. Reference Class . . . . . . . . . . . . . . . . . . . 25
3.10. Assessment Class . . . . . . . . . . . . . . . . . . . . . 25
3.10.1. Impact Class . . . . . . . . . . . . . . . . . . . . . 27
3.10.2. TimeImpact Class . . . . . . . . . . . . . . . . . . . 29
3.10.3. MonetaryImpact Class . . . . . . . . . . . . . . . . . 30
3.10.4. Confidence Class . . . . . . . . . . . . . . . . . . . 31
3.11. History Class . . . . . . . . . . . . . . . . . . . . . . 32
3.11.1. HistoryItem Class . . . . . . . . . . . . . . . . . . 33
3.12. EventData Class . . . . . . . . . . . . . . . . . . . . . 34
3.12.1. Relating the Incident and EventData Classes . . . . . 36
3.12.2. Cardinality of EventData . . . . . . . . . . . . . . . 37
3.13. Expectation Class . . . . . . . . . . . . . . . . . . . . 37
3.14. Flow Class . . . . . . . . . . . . . . . . . . . . . . . . 40
3.15. System Class . . . . . . . . . . . . . . . . . . . . . . . 40
3.16. Node Class . . . . . . . . . . . . . . . . . . . . . . . . 42
3.16.1. Counter Class . . . . . . . . . . . . . . . . . . . . 43
3.16.2. Address Class . . . . . . . . . . . . . . . . . . . . 45
3.16.3. NodeRole Class . . . . . . . . . . . . . . . . . . . . 46
3.17. Service Class . . . . . . . . . . . . . . . . . . . . . . 48
3.17.1. Application Class . . . . . . . . . . . . . . . . . . 50
3.18. OperatingSystem Class . . . . . . . . . . . . . . . . . . 51
3.19. Record Class . . . . . . . . . . . . . . . . . . . . . . . 51
3.19.1. RecordData Class . . . . . . . . . . . . . . . . . . . 51
3.19.2. RecordPattern Class . . . . . . . . . . . . . . . . . 53
3.19.3. RecordItem Class . . . . . . . . . . . . . . . . . . . 54
4. Processing Considerations . . . . . . . . . . . . . . . . . . 54
4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2. IODEF Namespace . . . . . . . . . . . . . . . . . . . . . 55
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 55
5. Extending the IODEF . . . . . . . . . . . . . . . . . . . . . 56
5.1. Extending the Enumerated Values of Attributes . . . . . . 56
5.2. Extending Classes . . . . . . . . . . . . . . . . . . . . 57
6. Internationalization Issues . . . . . . . . . . . . . . . . . 59
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.1. Worm . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2. Reconnaissance . . . . . . . . . . . . . . . . . . . . . . 61
7.3. Bot-Net Reporting . . . . . . . . . . . . . . . . . . . . 63
7.4. Watch List . . . . . . . . . . . . . . . . . . . . . . . . 65
8. The IODEF Schema . . . . . . . . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . . 87
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 89
12.1. Normative References . . . . . . . . . . . . . . . . . . . 89
12.2. Informative References . . . . . . . . . . . . . . . . . . 901. Introduction ✨
Okay, so organizations need help from other parties to deal with malicious activity aimed at their network and to get a read on potential threats 🔥. That coordination might look like working with an ISP to filter attack traffic, asking a remote site to take down a bot-network, or sharing watch-lists of known malicious IP addresses across a consortium 🦋.
The Incident Object Description Exchange Format (IODEF) is a format for representing computer security information that CSIRTs commonly swap 💅. It gives you an XML representation for passing incident info across administrative domains, between parties who are responsible for remediation or for watch-and-warning over a defined constituency 🫶. The data model encodes info about hosts, networks, and the services running on those systems; attack methodology and the forensic evidence tied to it; the impact of the activity; and some limited approaches for documenting workflow 🧚.
The main goal of the IODEF is to level up the operational capabilities of CSIRTs 👑. When the community adopts the IODEF, everyone gets better at resolving incidents and sharing situational awareness, because collaboration and data sharing get so much simpler 💖. This structured format allows for:
- increased automation in processing incident data, since security analysts won't have to parse free-form textual documents as much 🤖;
- less effort normalizing similar data (even when it's already highly structured) from different sources; and
- a common format to build interoperable tools for incident handling and later analysis, especially when the data comes from multiple constituencies 🌸.
Coordinating with other CSIRTs isn't strictly a technical problem 🙈. There are lots of procedural, trust, and legal considerations that might stop an organization from sharing information, and the IODEF doesn't try to solve those. Still, operational implementations of the IODEF will need to think about that bigger picture 💀.
Sections 3 and 8 specify the IODEF data model with text and an XML schema 📝. The types the data model uses are covered in Section 2. Processing considerations, how extensions are handled, and internationalization issues for the data model are covered in Sections 4, 5, and 6, respectively 🌈. Examples are in Section 7. Section 1 gives the background for the IODEF, and Section 9 documents the security considerations 🔐.
1.1. Terminology
Here's the key bit: 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 [6] 🎀.
Definitions for some of the common computer security terms used in this document can be found in Section 2 of [16] 📚.
1.2. Notations
The normative IODEF data model is specified with the text in Section 3 and the XML schema in Section 8 💖. To help you understand the data elements, Section 3 also draws the underlying information model using Unified Modeling Language (UML). That abstract presentation of the IODEF is not normative 🦋.
For clarity, the term "XML document" is used when talking about any instance of an XML document in general ✨. The term "IODEF document" refers to specific elements and attributes of the IODEF schema 🧚. The terms "class" and "element" are used interchangeably to reference the corresponding data element in the information or data models, respectively 🍓.
1.3. About the IODEF Data Model ✨
okay so the IODEF data model is basically a shared language 💅 that gives CSIRTs a framework for trading info about computer security incidents. A bunch of design choices went into it, and bestie you need to know these 🧠
- The data model is a transport format 🚚. That means its specific representation is NOT the optimal representation for on-disk storage, long-term archiving, or in-memory processing. It's built for moving stuff between systems, not sitting on a hard drive forever.
- There's no precise, widely agreed-upon definition of an incident 🤷♀️, so the data model doesn't try to force one on anybody. It assumes a broad understanding that's flexible enough to cover most operators. no cap, that's iconic of them 🫶
- Describing an incident for every possible definition would need an extremely complex data model 😭. So the IODEF only aims to be a framework for conveying commonly exchanged incident information. It gives you plenty of extensibility for organization-specific info, plus ways to reference information kept outside the explicit data model 🧚
- The security analysis world isn't fully standardized yet, so it has to lean on free-form textual descriptions 📝. The IODEF tries to strike a balance: it supports that free-form content while still letting machines automatically process incident info. the balance is everything 🌸
- The IODEF is only one of several security-relevant data representations being standardized 🦋. The designers tried to make sure they were complementary (they wrote "complimentary" in the original, lol, but you get the vibe). The data model of the Intrusion Detection Message Exchange Format [17] influenced the design of the IODEF 💜
If you want more on the desirable properties of the IODEF, check the Requirements for the Format for Incident Information Exchange (FINE) [16] 📚
1.4. About the IODEF Implementation 🎀
The IODEF implementation is specified as an Extensible Markup Language (XML) [1] Schema [2] in Section 8 👑
Implementing the IODEF in XML is giving major advantages ✨. Its extensibility makes it ideal for a data encoding framework that supports various character encodings. The abundance of related technologies (e.g., XSL, XPath, XML-Signature) also makes manipulation way simpler 🧁. BUT ngl, XML is fundamentally a text representation 😬, which makes it inherently inefficient when binary data has to be embedded or when large volumes of data need to be exchanged. the tradeoff is real 💀
2. IODEF Data Types 🌈
The various data elements of the IODEF data model are typed 🏷️. This section breaks down those data types. When possible, native Schema data types were adopted. For more complicated formats, regular expressions (see Appendix F of [3]) or external standards were used. it's all about reusing what already slaps 💅
2.1. Integers 🔢
An integer is represented by the INTEGER data type. Integer data MUST be encoded in Base 10 💖
The INTEGER data type is implemented as an "xs:integer" [3] in the schema.
2.2. Real Numbers 🦋
Real (floating-point) attributes are represented by the REAL data type. Real data MUST be encoded in Base 10 ✨
The REAL data type is implemented as an "xs:float" [3] in the schema.
2.3. Characters and Strings 📝
A single character is represented by the CHARACTER data type. A character 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 as an "xs:string" [3] in the schema.
2.4. Multilingual Strings 🌍
STRING data that represents multi-character attributes in a language different from the default encoding of the document is of the ML_STRING data type 🫧
The ML_STRING data type is implemented as an "iodef:MLStringType" in the schema.
2.5. Bytes 🍓
A binary octet is represented by the BYTE data type. A sequence of binary octets is represented by the BYTE[] data type. These octets are encoded using base64 🧃
The BYTE data type is implemented as an "xs:base64Binary" [3] in the schema.
2.6. Hexadecimal Bytes 🌸
A binary octet is represented by the HEXBIN (and HEXBIN[]) data type. This octet is encoded as a character tuple made of two hexadecimal digits 🔥
The HEXBIN data type is implemented as an "xs:hexBinary" [3] in the schema.
2.7. Enumerated Types 📋
Enumerated types are represented by the ENUM data type, and they consist of an ordered list of acceptable values. Each value has a representative keyword. Within the IODEF schema, the enumerated type keywords are used as attribute values 💜
The ENUM data type is implemented as a series of "xs:NMTOKEN" in the schema.
2.8. Date-Time Strings ⏰
Date-time strings are represented by the DATETIME data type. Each date-time string identifies one particular instant in time. Ranges are NOT supported 🚫
Date-time strings are formatted according to a subset of ISO 8601: 2000 [13] documented in RFC 3339 [12] 🗓️
The DATETIME data type is implemented as an "xs:dateTime" [3] in the schema.
2.9. Timezone String 🌍
A timezone offset from UTC is represented by the TIMEZONE data type 🕰️ It's formatted according to the following regular expression:
Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]
The TIMEZONE data type is implemented as an "xs:string" with a regular expression constraint in the schema. This regular expression is identical to the timezone representation implemented in an "xs:dateTime" ✨
2.10. Port Lists 🔌
A list of network ports is represented 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's formatted according to the following regular expression:
\d+(\-\d+)?(,\d+(\-\d+)?)*
For example:
2,5-15,30,32,40-50,55-60
The PORTLIST data type is implemented as an "xs:string" with a regular expression constraint in the schema.
2.11. Postal Address 📮
A postal address is represented by the POSTAL data type. This data type is an ML_STRING whose format is documented in Section 2.23 of RFC 4519 [10]. It defines a postal address as a free-form, multi-line string separated by the $ character 🏠
The POSTAL data type is implemented as an "xs:string" in the schema.
2.12. Person or Organization 🧑🤝🧑
The name of an individual or organization is represented by the NAME data type. This data type is an ML_STRING whose format is documented in Section 2.3 of RFC 4519 [10] 💅
The NAME data type is implemented as an "xs:string" in the schema.
2.13. Telephone and Fax Numbers 📞
A telephone or fax number is represented by the PHONE data type. The format of the PHONE data type is documented in Section 2.35 of RFC 4519 [10] 📠
The PHONE data type is implemented as an "xs:string" in the schema.
2.14. Email String 💌
An email address is represented by the EMAIL data type. The format of the EMAIL data type is documented in Section 3.4.1 RFC 2822 [11] 📧
The EMAIL data type is implemented as an "xs:string" in the schema.
2.15. Uniform Resource Locator Strings 🔗
A uniform resource locator (URL) is represented by the URL data type. The format of the URL data type is documented in RFC 2396 [8] 🌐
The URL data type is implemented as an "xs:anyURI" in the schema.
3. The IODEF Data Model 🧠
In this section, the individual components of the IODEF data model get broken down in detail. For each class, the semantics are described and the relationship with other classes is shown with UML. When necessary, specific comments are made about the corresponding definition in 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 lang |
| STRING formatid |
+-----------------+
Figure 1: IODEF-Document ClassThe aggregate class that constitutes IODEF-Document is:
Incident One or more. The information related to a single incident 📦
The IODEF-Document class has three attributes:
version Required. STRING. The IODEF specification version number to which this IODEF document conforms. The value of this attribute MUST be "1.00" 🫶
lang Required. ENUM. A valid language code per RFC 4646 [7], constrained by the definition of "xs:language". The interpretation of this code is described in Section 6 🌈
formatid Optional. STRING. A free-form string to convey processing instructions to the recipient of the document. Its semantics must be negotiated out-of-band 🤝
⚠️ bestie, the version attribute is the one with a hard MUST, so don't skip it 💀
3.2. Incident Class ✨
Every incident is represented by an instance of the Incident class 🎀. It gives us a standardized way to represent the incident data that CSIRTs trade all the time, so everyone's on the same page 🧚
+--------------------+
| Incident |
+--------------------+
| ENUM purpose |<>----------[ IncidentID ]
| STRING ext-purpose |<>--{0..1}--[ AlternativeID ]
| ENUM lang |<>--{0..1}--[ RelatedActivity ]
| ENUM restriction |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>----------[ ReportTime ]
| |<>--{0..*}--[ Description ]
| |<>--{1..*}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{1..*}--[ Contact ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..1}--[ History ]
| |<>--{0..*}--[ AdditionalData ]
+--------------------+
Figure 2: The Incident ClassThe aggregate classes that make up Incident are:
- IncidentID: One. An incident tracking number assigned to this incident by the CSIRT that generated the IODEF document 🔥
- AlternativeID: Zero or one. The incident tracking numbers that other CSIRTs use to refer to the incident described in the document.
- RelatedActivity: Zero or one. The incident tracking numbers of related incidents.
- DetectTime: Zero or one. The time the incident was first detected.
- StartTime: Zero or one. The time the incident started.
- EndTime: Zero or one. The time the incident ended.
- ReportTime: One. The time the incident was reported.
- Description: Zero or more. ML_STRING. A free-form textual description of the incident.
- Assessment: One or more. A characterization of the impact of the incident.
- Method: Zero or more. The techniques used by the intruder in the incident.
- Contact: One or more. Contact information for the parties involved in the incident.
- EventData: Zero or more. A description of the events that make up the incident.
- History: Zero or one. A log of significant events or actions that happened while the incident was being handled.
- AdditionalData: Zero or more. The mechanism for extending the data model 🌈
The Incident class has four attributes:
- purpose: Required. ENUM. The purpose attribute is the reason the IODEF document was created 💖 It's closely related to the Expectation class (Section 3.13). This attribute is an enumerated list:
traceback. The document was sent for trace-back purposes.mitigation. The document was sent to request aid in mitigating the described activity.reporting. The document was sent to comply with reporting requirements.other. The document was sent for purposes specified in the Expectation class.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-purpose: Optional. STRING. A way to extend the purpose attribute. See Section 5.1.
- lang: Optional. ENUM. A valid language code per RFC 4646 [7], constrained by the definition of "xs:language". How this code is interpreted is described in Section 6 🦋
- restriction: Optional. ENUM. This attribute tells the recipient which disclosure guidelines the sender expects them to follow for the information in this class and its children. ngl, this guideline gives you zero security, because there are no specified technical means to make sure the recipient actually handles the info the way the sender asked 💀
The value of this attribute is logically inherited by the children of this class. In other words, the disclosure rules applied to this class also apply to its children 🫶
A granular disclosure policy is possible, because all of the high-level classes (the children of the Incident class) have a restriction attribute. That means a child can override the guidelines of its parent, either to restrict or to relax the disclosure rules. For example, a child can have a weaker policy than an ancestor, or an ancestor can have a weak policy while its children selectively apply stricter controls 👑 The implicit value of the restriction attribute for a class that didn't specify one can be found in the closest ancestor that did specify a value.
This attribute is an enumerated value with a default value of "private". The default is only defined in the context of the Incident class. In other classes where this attribute is used, no default is specified 🙈
public. There are no restrictions placed on the information.need-to-know. The information may be shared with other parties involved in the incident, as determined by the recipient of this document (for example, multiple victim sites can be informed of each other).private. The information may not be shared.default. The information can be shared according to an information disclosure policy that the communicating parties arranged beforehand.
3.3. IncidentID Class 🍓
The IncidentID class represents an incident tracking number that is unique in the context of the CSIRT and identifies the activity characterized in an IODEF Document 🦋 This identifier serves as an index into the CSIRT's incident handling 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 |
+------------------+
Figure 3: The IncidentID ClassThe IncidentID class has three attributes:
- name: Required. STRING. An identifier describing the CSIRT that created the document. To get a globally unique CSIRT name, the fully qualified domain name associated with the CSIRT MUST be used 💅
- instance: Optional. STRING. An identifier referencing a subset of the named incident.
- restriction: Optional. ENUM. This attribute was defined in Section 3.2.
3.4. AlternativeID Class 🧚
The AlternativeID class lists the incident tracking numbers that CSIRTs other than the one generating the document use to refer to the identical activity described in the IODEF document 💜 A tracking number listed as an AlternativeID refers to the same incident, detected by another CSIRT. The incident tracking numbers of the CSIRT that generated the IODEF document should never be considered an AlternativeID. Don't mix them up, bestie 🙅♀️
+------------------+
| AlternativeID |
+------------------+
| ENUM restriction |<>--{1..*}--[ IncidentID ]
| |
+------------------+
Figure 4: The AlternativeID ClassThe aggregate class that makes up AlternativeID is:
- IncidentID: One or more. The incident tracking number of another CSIRT.
The AlternativeID class has one attribute:
- restriction: Optional. ENUM. This attribute was defined in Section 3.2.
3.5. RelatedActivity Class 🌸
The RelatedActivity class lists either incident tracking numbers or URLs (not both) that refer to activity related to the one described in the IODEF document 🎀 These references may point to local incident tracking numbers or to those of other CSIRTs.
The specifics of how a CSIRT comes to believe that two incidents are related are out of scope ✨
+------------------+
| RelatedActivity |
+------------------+
| ENUM restriction |<>--{0..*}--[ IncidentID ]
| |<>--{0..*}--[ URL ]
+------------------+
Figure 5: RelatedActivity ClassThe aggregate classes that make up RelatedActivity are:
- IncidentID: One or more. The incident tracking number of a related incident.
- URL: One or more. URL. A URL to activity related to this incident.
The RelatedActivity class has one attribute:
- restriction: Optional. ENUM. This attribute was defined in Section 3.2.
3.6. AdditionalData Class 🧩
okay so the AdditionalData class is basically the extension mechanism 💅 It's for info the data model doesn't already have a home for. Simple stuff gets atomic data types (integers, strings, etc.) plus a way to say what they mean. For bigger stuff, you can wrap a whole XML document from another schema (like IDMEF) inside it, which lets you add proprietary extensions 🎀 The full extending-the-model-and-schema deal is in Section 5, so go check that out too.
Unlike XML, which describes itself, atomic data has to be documented to make sense 🤓 That meaning lives in the meaning attribute. These descriptions are outside the scope of the spec, so you might need some extra coordination so the recipient can actually understand your custom stuff 🫶
+------------------+
| AdditionalData |
+------------------+
| ANY |
| |
| ENUM dtype |
| STRING ext-dtype |
| STRING meaning |
| STRING formatid |
| ENUM restriction |
+------------------+
Figure 6: The AdditionalData ClassThe AdditionalData class has five attributes ✨
dtype Required. ENUM. This is the data type of the element content. The permitted values are listed below, and the default is "string" 💖
- boolean. The element content is of type BOOLEAN.
- byte. The element content is of type BYTE.
- character. The element content is of type CHARACTER.
- date-time. The element content is of type DATETIME.
- integer. The element content is of type INTEGER.
- portlist. The element content is of type PORTLIST.
- real. The element content is of type REAL.
- string. The element content is of type STRING.
- file. The element content is a base64 encoded binary file encoded as a BYTE[] type.
- frame. The element content is a layer-2 frame encoded as a HEXBIN type.
- packet. The element content is a layer-3 packet encoded as a HEXBIN type.
- ipv4-packet. The element content is an IPv4 packet encoded as a HEXBIN type.
- ipv6-packet. The element content is an IPv6 packet encoded as a HEXBIN type.
- path. The element content is a file-system path encoded as a STRING type.
- url. The element content is of type URL.
- csv. The element content is a common separated value (CSV) list per Section 2 of [20] encoded as a STRING type.
- winreg. The element content is a Windows registry key encoded as a STRING type.
- xml. The element content is XML (see Section 5).
- ext-value. An escape value used to extend this attribute. See Section 5.1.
ext-dtype Optional. STRING. This is how you extend the dtype attribute 🌈 See Section 5.1.
meaning Optional. STRING. A free-form description of the element content 📝
formatid Optional. STRING. An identifier that points to the format and semantics of the element content 🔖
restriction Optional. ENUM. This attribute was already defined in Section 3.2 🌸
3.7. Contact Class 👩💼
The Contact class is where you describe the people and organizations involved in the incident 💜 It lets you name the party, give their contact info, and say what role they play in the whole mess.
People and orgs are treated the same way as contacts 🤝 You can link one to the other because the Contact class is aggregated into itself (recursive, iykyk). The type attribute tells you what kind of contact info you're looking at.
The inheriting setup is honestly so clever ✨ It lets you relate info without needing explicit identifiers or copying the same data over and over. A complete point of contact comes from traversing from the root Contact class down to a leaf Contact class. So one instance can hold multiple points of contact 🦋 Each child Contact logically inherits contact info from its ancestors.
+------------------+
| Contact |
+------------------+
| ENUM role |<>--{0..1}--[ ContactName ]
| STRING ext-role |<>--{0..*}--[ Description ]
| ENUM type |<>--{0..*}--[ RegistryHandle ]
| STRING ext-type |<>--{0..1}--[ PostalAddress ]
| ENUM restriction |<>--{0..*}--[ Email ]
| |<>--{0..*}--[ Telephone ]
| |<>--{0..1}--[ Fax ]
| |<>--{0..1}--[ Timezone ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 7: The Contact ClassThese are the aggregate classes that make up the Contact class 🧁
ContactName Zero or one. ML_STRING. The name of the contact. It can be an organization or a person, and the type attribute tells you which 🏷️
Description Zero or many. ML_STRING. A free-form description of this contact. For a person, this is often their organizational title 💼
RegistryHandle Zero or many. A handle name into the registry of the contact 🗂️
PostalAddress Zero or one. The postal address of the contact 📮
Email Zero or many. The email address of the contact 💌
Telephone Zero or many. The telephone number of the contact 📞
Fax Zero or one. The facsimile telephone number of the contact 📠
Timezone Zero or one. TIMEZONE. The timezone where the contact lives, formatted according to Section 2.9 🌍
Contact Zero or many. A Contact instance nested inside another Contact instance inherits the values of its parent(s). This recursive setup is great for grouping shared data across several points of contact, and it's especially handy when you're listing multiple contacts at the same organization 👑
AdditionalData Zero or many. A mechanism for extending the data model 🧩
At least one of the aggregate classes MUST be present in an instance of the Contact class. This isn't enforced in the IODEF schema, because there's no simple way to do it 🙈
The Contact class has five attributes 💅
role Required. ENUM. Says what role the contact plays. This attribute is an enumerated list:
- creator. The entity that generated the document.
- admin. An administrative contact for a host or network.
- tech. A technical contact for a host or network.
- irt. The CSIRT involved in handling the incident.
- cc. An entity that is to be kept informed about the handling of the incident.
- ext-value. An escape value used to extend this attribute. See Section 5.1.
ext-role Optional. STRING. This is how you extend the role attribute. See Section 5.1 🌷
type Required. ENUM. Says what type of contact is being described. This attribute is an enumerated list:
- person. The information for this contact references an individual.
- organization. The information for this contact references an organization.
- ext-value. An escape value used to extend this attribute. See Section 5.1.
ext-type Optional. STRING. This is how you extend the type attribute. See Section 5.1 🎀
restriction Optional. ENUM. This attribute is defined in Section 3.2 🔒
3.7.1. RegistryHandle Class 🗃️
The RegistryHandle class is a handle into an Internet registry or a community-specific database 🌐 The handle goes in the element content, and the type attribute says which database it belongs to.
+---------------------+
| RegistryHandle |
+---------------------+
| STRING |
| |
| ENUM registry |
| STRING ext-registry |
+---------------------+
Figure 8: The RegistryHandle ClassThe RegistryHandle class has two attributes ✨
registry Required. ENUM. The database the handle belongs to. The default is 'local'. The possible values are:
- internic. Internet Network Information Center
- apnic. Asia Pacific Network Information Center
- arin. American Registry for Internet Numbers
- lacnic. Latin-American and Caribbean IP Address Registry
- ripe. Reseaux IP Europeens
- afrinic. African Internet Numbers Registry
- local. A database local to the CSIRT
- ext-value. An escape value used to extend this attribute. See Section 5.1.
ext-registry Optional. STRING. This is how you extend the registry attribute. See Section 5.1 💖
3.7.2. PostalAddress Class 📮
The PostalAddress class specifies a postal address formatted according to the POSTAL data type (Section 2.11) 🏡
+---------------------+
| PostalAddress |
+---------------------+
| POSTAL |
| |
| ENUM meaning |
| ENUM lang |
+---------------------+
Figure 9: The PostalAddress ClassThe PostalAddress class has two attributes 🌸
meaning Optional. ENUM. A free-form description of the element content.
lang Required. ENUM. A valid language code per RFC 4646 [7], constrained by the definition of "xs:language". How this code is interpreted is described in Section 6 🌍
3.7.3. Email Class 💌
The Email class specifies an email address formatted according to the EMAIL data type (Section 2.14) 💕
+--------------+
| Email |
+--------------+
| EMAIL |
| |
| ENUM meaning |
+--------------+
Figure 10: The Email ClassThe Email class has one attribute 🦄
meaning Optional. ENUM. A free-form description of the element content.
3.7.4. Telephone and Fax Classes ☎️
The Telephone and Fax classes specify a voice or fax telephone number, respectively. They're formatted according to the PHONE data type (Section 2.13) 📱
+--------------------+
| {Telephone | Fax } |
+--------------------+
| PHONE |
| |
| ENUM meaning |
+--------------------+
Figure 11: The Telephone and Fax ClassesThe Telephone class has one attribute 🍓
meaning Optional. ENUM. A free-form description of the element content (e.g., hours of coverage for a given number) 🕰️
3.8. Time Classes ⏰
The data model uses five different classes to represent a timestamp 🕒 Their definitions are identical, but each one has its own name so the semantics are clear 💜
The element content of each class is a timestamp formatted according to the DATETIME data type (see Section 2.8) 🗓️
+----------------------------------+
| {Start| End| Report| Detect}Time |
+----------------------------------+
| DATETIME |
+----------------------------------+
Figure 12: The Time Classes3.8.1. StartTime 🚀
The StartTime class represents the time the incident began 🌅
3.8.2. EndTime 🌙
The EndTime class represents the time the incident ended 🎬
3.8.3. DetectTime ✨
okay so the DetectTime class is the time the very first activity of the incident got detected 🕵️♀️ like the moment someone noticed something was off!!
3.8.4. ReportTime 🕰️
the ReportTime class is the time the incident was reported 📣 and this timestamp SHOULD coincide to the time at which the IODEF document is generated. bestie, that's the vibe: report time and doc generation time line up 💅
3.8.5. DateTime 💜
the DateTime class is a generic timestamp, like a catch-all clock ⏰ its semantics should be inferred from the parent class it's aggregated in, so the context tells you what it means 🫶
3.9. Method Class 🧪
the Method class describes the methodology the intruder used to pull off the events of the incident 😈 it's giving detective energy. it has a list of references describing the attack method, plus a free form description of the technique ✨
+------------------+
| Method |
+------------------+
| ENUM restriction |<>--{0..*}--[ Reference ]
| |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 13: The Method Classthe Method class is built from three aggregate classes 🧩
- Reference: zero or many. A reference to a vulnerability, malware sample, advisory, or analysis of an attack technique.
- Description: zero or many. ML_STRING. A free-form text description of the methodology used by the intruder.
- AdditionalData: zero or many. A mechanism by which to extend the data model.
Either an instance of the Reference or Description class MUST be present. no skipping both, periodt 🙅♀️
the Method class has one attribute:
- restriction: optional. ENUM. This attribute is defined in Section 3.2.
3.9.1. Reference Class 🔗
the Reference class is a reference to a vulnerability, IDS alert, malware sample, advisory, or attack technique 🦋 a reference is made up of a name, a URL pointing to it, and an optional description.
+------------------+
| Reference |
+------------------+
| |<>----------[ ReferenceName ]
| |<>--{0..*}--[ URL ]
| |<>--{0..*}--[ Description ]
+------------------+
Figure 14: The Reference Classthe aggregate classes that make up Reference are:
- ReferenceName: one. ML_STRING. Name of the reference.
- URL: zero or many. URL. A URL associated with the reference.
- Description: zero or many. ML_STRING. A free-form text description of this reference.
3.10. Assessment Class 📊
the Assessment class describes the technical and non-technical repercussions of the incident on the CSIRT's constituency 💥 this class was derived from the IDMEF[17].
+------------------+
| Assessment |
+------------------+
| ENUM occurrence |<>--{0..*}--[ Impact ]
| ENUM restriction |<>--{0..*}--[ TimeImpact ]
| |<>--{0..*}--[ MonetaryImpact ]
| |<>--{0..*}--[ Counter ]
| |<>--{0..1}--[ Confidence ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 15: Assessment Classthe aggregate classes that make up Assessment are:
- Impact: zero or many. Technical impact of the incident on a network.
- TimeImpact: zero or many. Impact of the activity measured with respect to time.
- MonetaryImpact: zero or many. Impact of the activity measured with respect to financial loss.
- Counter: zero or more. A counter with which to summarize the magnitude of the activity.
- Confidence: zero or one. An estimate of confidence in the assessment.
- AdditionalData: zero or many. A mechanism by which to extend the data model.
A least one instance of the possible three impact classes (i.e., Impact, TimeImpact, or MonetaryImpact) MUST be present. so at least one of those impact classes has to show up, no exceptions 🙅♀️
the Assessment class has two attributes:
- occurrence: optional. ENUM. Specifies whether the assessment is describing actual or potential outcomes. The default is "actual" and is assumed if not specified.
actual. This assessment describes activity that has occurred.potential. This assessment describes potential activity that might occur.
- restriction: optional. ENUM. This attribute is defined in Section 3.2.
3.10.1. Impact Class 💫
the Impact class lets you categorize and describe the technical impact of the incident on an organization's network 🌐 this class is based on the IDMEF [17].
+------------------+
| Impact |
+------------------+
| ML_STRING |
| |
| ENUM lang |
| ENUM severity |
| ENUM completion |
| ENUM type |
| STRING ext-type |
+------------------+
Figure 16: Impact Classthe element content will be a free-form textual description of the impact ✍️
the Impact class has five attributes:
- lang: required. ENUM. A valid language code per RFC 4646 [7] constrained by the definition of "xs:language". The interpretation of this code is described in Section 6.
- severity: optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
low. Low severitymedium. Medium severityhigh. High severity
- completion: optional. ENUM. An indication whether the described activity was successful. The permitted values are shown below. There is no default value.
failed. The attempted activity was not successful.succeeded. The attempted activity succeeded.
- type: required. ENUM. Classifies the malicious activity into incident categories. The permitted values are shown below. The default value is "other".
admin. Administrative privileges were attempted.dos. A denial of service was attempted.file. An action that impacts the integrity of a file or database was attempted.info-leak. An attempt was made to exfiltrate information.misconfiguration. An attempt was made to exploit a mis-configuration in a system.policy. Activity violating site's policy was attempted.recon. Reconnaissance activity was attempted.social-engineering. A social engineering attack was attempted.user. User privileges were attempted.unknown. The classification of this activity is unknown.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-type: optional. STRING. A means by which to extend the type attribute. See Section 5.1.
3.10.2. TimeImpact Class ⏳
the TimeImpact class describes the impact of the incident on an organization as a function of time ⌛ it gives you a way to convey down time and recovery time 🛠️
+---------------------+
| TimeImpact |
+---------------------+
| REAL |
| |
| ENUM severity |
| ENUM metric |
| STRING ext-metric |
| ENUM duration |
| STRING ext-duration |
+---------------------+
Figure 17: TimeImpact Classthe element content is a positive, floating point (REAL) number specifying a unit of time. the duration and metric attributes imply the semantics of the element content 🧠
the TimeImpact class has five attributes:
- severity: optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
low. Low severitymedium. Medium severityhigh. High severity
- metric: required. ENUM. Defines the metric in which the time is expressed. The permitted values are shown below. There is no default value.
labor. Total staff-time to recovery from the activity (e.g., 2 employees working 4 hours each would be 8 hours).elapsed. Elapsed time from the beginning of the recovery to its completion (i.e., wall-clock time).downtime. Duration of time for which some provided service(s) was not available.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-metric: optional. STRING. A means by which to extend the metric attribute. See Section 5.1.
- duration: required. ENUM. Defines a unit of time that, when combined with the metric attribute, fully describes a metric of impact that will be conveyed in the element content. The permitted values are shown below. The default value is "hour".
second. The unit of the element content is seconds.minute. The unit of the element content is minutes.hour. The unit of the element content is hours.day. The unit of the element content is days.month. The unit of the element content is months.quarter. The unit of the element content is quarters.year. The unit of the element content is years.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-duration: optional. STRING. A means by which to extend the duration attribute. See Section 5.1.
3.10.3. 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 18: MonetaryImpact Classthe element content is a positive, floating point number (REAL) specifying a unit of currency described in the currency attribute 🪙
the MonetaryImpact class has two attributes:
- severity: optional. ENUM. An estimate of the relative severity of the activity. The permitted values are shown below. There is no default value.
low. Low severitymedium. Medium severityhigh. High severity
- currency: required. STRING. Defines the currency in which the monetary impact is expressed. The permitted values are defined in ISO 4217:2001, Codes for the representation of currencies and funds [14]. There is no default value.
3.10.4. Confidence Class ✨
okay so the Confidence class is basically the vibe check on how legit and accurate the impact from [Section 3.10](#) is 🔍 like, how much should we actually trust this read on the incident? and it can be a category or a number, your pick bestie 💅
this one's built off of IDMEF [17]) 🫶
+------------------+
| Confidence |
+------------------+
| REAL |
| |
| ENUM rating |
+------------------+
Figure 19: Confidence Classso the element content is a numerical take on how confident we are in the data, but only when the rating attribute is "numeric" 🔢 otherwise, this element should be empty 🙅♀️
Confidence has just one attribute, lowkey simple 🎀
- rating: Required. ENUM. A rating of the analytical validity of the specified Assessment. The permitted values are shown below. There is no default value.
- low. Low confidence in the validity.
- medium. Medium confidence in the validity.
- high. High confidence in the validity.
- numeric. The element content contains a number that conveys the confidence of the data. The semantics of this number outside the scope of this specification.
3.11. History Class 📜
the History class is basically a log of the big moments and actions the involved parties took while handling the incident 👀 the vibe is that everyone gets to decide how detailed this log is, so it's totally up to whoever's handling it 💖
+------------------+
| History |
+------------------+
| ENUM restriction |<>--{1..*}--[ HistoryItem ]
| |
+------------------+
Figure 20: The History Classthe class that makes up History is:
- HistoryItem: One or many. Entry in the history log of significant events or actions performed by the involved parties.
The History class has one attribute:
- restriction: Optional. ENUM. This attribute is defined in Section 3.2.
3.11.1. HistoryItem Class 🦋
the HistoryItem class is one single entry in the History (Section 3.11) log 🌸 it documents a specific action or event that went down during the incident. the details are free-form, but each entry can be sorted into a category with the type attribute 🗂️
+-------------------+
| HistoryItem |
+-------------------+
| ENUM restriction |<>----------[ DateTime ]
| ENUM action |<>--{0..1}--[ IncidentId ]
| STRING ext-action |<>--{0..1}--[ Contact ]
| |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+-------------------+
Figure 21: HistoryItem Classthe aggregate classes that make up HistoryItem are:
- DateTime: One. Timestamp of this entry in the history log (e.g., when the action described in the Description was taken).
- 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 incident tracking number. When a single organization is maintaining the log, this class can be ignored. 🕵️♀️
- Contact: Zero or One. Provides contact information for the person that performed the action documented in this class.
- Description: Zero or many. ML_STRING. A free-form textual description of the action or event.
- AdditionalData: Zero or many. A mechanism by which to extend the data model. 🧩
The HistoryItem class has three attributes:
- restriction: Optional. ENUM. This attribute has been defined in Section 3.2.
- 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 internal investigation, this attribute is identical to the category 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.13. ⏰
- ext-action: Optional. STRING. A means by which to extend the action attribute. See Section 5.1.
3.12. EventData Class 🎬
the EventData class describes one particular event of the incident for a given set of hosts or networks 💜 this includes the systems the activity came from and the ones it targeted, an assessment of the techniques the intruder used, the impact on the organization, and any forensic evidence that got found 🔎
+------------------+
| EventData |
+------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ DetectTime ]
| |<>--{0..1}--[ StartTime ]
| |<>--{0..1}--[ EndTime ]
| |<>--{0..*}--[ Contact ]
| |<>--{0..1}--[ Assessment ]
| |<>--{0..*}--[ Method ]
| |<>--{0..*}--[ Flow ]
| |<>--{0..*}--[ Expectation ]
| |<>--{0..1}--[ Record ]
| |<>--{0..*}--[ EventData ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 22: The EventData Classthe aggregate classes that make up EventData are:
- Description: Zero or more. ML_STRING. A free-form textual description of the event.
- DetectTime: Zero or one. The time the event was detected.
- StartTime: Zero or one. The time the event started.
- EndTime: Zero or one. The time the event ended.
- Contact: Zero or more. Contact information for the parties involved in the event.
- Assessment: Zero or one. The impact of the event on the target and the actions taken.
- Method: Zero or more. The technique used by the intruder in the event.
- Flow: Zero or more. A description of the systems or networks involved.
- Expectation: Zero or more. The expected action to be performed by the recipient for the described event.
- Record: Zero or one. Supportive data (e.g., log files) that provides additional information about the event.
- EventData: Zero or more. EventData instances contained within another EventData instance inherit the values of the parent(s); this recursive definition can be used to group common data pertaining to multiple events. When EventData elements are defined recursively, only the leaf instances (those EventData instances not containing other EventData instances) represent actual events. 🌳
- AdditionalData: Zero or more. 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. This is not enforced in the IODEF schema as there is no simple way to accomplish it. 🚨
The EventData class has one attribute:
- restriction: Optional. ENUM. This attribute is defined in Section 3.2.
3.12.1. Relating the Incident and EventData Classes 🧠
there's a lot of overlap between the Incident and EventData classes, but they mean pretty different things 💅 the Incident class gives summary info about the whole incident, while EventData gives info about each individual event that makes it up. usually EventData just gets more specific than the general description in Incident 🎯 but it's also possible the overall summary and some individual info in an EventData class clash, especially when a bunch of different events are stacked together in the incident. in that case, the more specific EventData MUST supersede the more generic information provided in IncidentData. ✨
3.12.2. Cardinality of EventData 🧁
the EventData class is basically a container for an event's properties in an incident 💖 those properties include the hosts involved, the impact of the activity on those hosts, forensic logs, and so on. with an EventData instance, the hosts (i.e., System class) get grouped around these shared properties 🫧
the recursive definition (or instance property inheritance) of EventData, where EventData is aggregated into EventData, is a clever way to relate info without needing explicit unique attribute identifiers in the classes or copying the same info everywhere 🙈 instead, the relative depth (nesting) of a class is what groups the related info together. 🪆
for example, an EventData class might be used to describe two machines involved in an incident. you can do that with multiple instances of the Flow class. it just happens that these two machines share a common technical contact (i.e., Contact class), but the impact (i.e., Assessment class) on each one is different 😭 a picture of how that looks is in Figure 23.
+------------------+
| EventData |
+------------------+
| |<>----[ Contact ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
| |
| |<>----[ EventData ]<>----[ Flow ]
| | [ ]<>----[ Assessment ]
+------------------+
Figure 23: Recursion in the EventData Class3.13. Expectation Class 💖
Okay bestie, the Expectation class is where the sender tells the recipient what they're hoping will happen next 🎀 The requested action is only scoped to the EventData class this is aggregated inside ✨
+-------------------+
| Expectation |
+-------------------+
| ENUM restriction |<>--{0..*}--[ Description ]
| ENUM severity |<>--{0..1}--[ StartTime ]
| ENUM action |<>--{0..1}--[ EndTime ]
| STRING ext-action |<>--{0..1}--[ Contact ]
+-------------------+Figure 24: The Expectation Class
The aggregate classes that constitute Expectation are:
- Description: Zero or many. ML_STRING. A free-form description of the desired action(s). 📝
- StartTime: Zero or one. The time at which the action should be performed. A timestamp that is earlier than the ReportTime specified in the Incident class denotes that the expectation should be fulfilled as soon as possible. The absence of this element leaves the execution of the expectation to the discretion of the recipient. ⏰
- EndTime: Zero or one. The time by which the action should be completed. If the action is not carried out by this time, it should no longer be performed. 🛑
- Contact: Zero or one. The expected actor for the action. 🙋♀️
The Expectations class has four attributes:
- restriction: Optional. ENUM. This attribute is defined in Section 3.2. 🔒
- 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. Ranked, but the vibe depends on the situation 🌡️
low. Low prioritymedium. Medium priorityhigh. High priority
- action: Optional. ENUM. Classifies the type of action requested. This attribute is an enumerated list with no default value. 🎬
nothing. No action is requested. Do nothing with the information.contact-source-site. Contact the site(s) identified as the source of the activity.contact-target-site. Contact the site(s) identified as the target of the activity.contact-sender. Contact the originator of the document.investigate. Investigate the systems(s) listed in the event.block-host. Block traffic from the machine(s) listed as sources the event.block-network. Block traffic from the network(s) lists as sources in the event.block-port. Block the port listed as sources in the event.rate-limit-host. Rate-limit the traffic from the machine(s) listed as sources in the event.rate-limit-network. Rate-limit the traffic from the network(s) lists as sources in the event.rate-limit-port. Rate-limit the port(s) listed as sources in the event.remediate-other. Remediate the activity in a way other than by rate limiting or blocking.status-triage. Conveys receipts and the triaging of an incident.status-new-info. Conveys that new information was received for this incident.other. Perform some custom action described in the Description class.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-action: Optional. STRING. A means by which to extend the action attribute. See Section 5.1. 🧩
3.14. Flow Class 🌊
The Flow class groups the related source and target hosts together, like a little friend group 👯♀️
+------------------+
| Flow |
+------------------+
| |<>--{1..*}--[ System ]
+------------------+Figure 25: The Flow Class
The aggregate class that constitutes Flow is:
- System: One or More. A host or network involved in an event. 💻
The Flow System class has no attributes. Nothing to see here, just vibes 🫶
3.15. System Class 🖥️
The System class describes a system or network involved in an event. The systems or networks represented by this class are categorized according to the role they played in the incident through the category attribute. The value of this category attribute dictates the semantics of the aggregated classes in the System class. If the category attribute has a value of "source", then the aggregated classes denote the machine and service from which the activity is originating. With a category attribute value of "target" or "intermediary", then the machine or service is the one targeted in the activity. A value of "sensor" dictates that this System was part of an instrumentation to monitor the network. 👀
+---------------------+
| System |
+---------------------+
| ENUM restriction |<>----------[ Node ]
| ENUM category |<>--{0..*}--[ Service ]
| STRING ext-category |<>--{0..*}--[ OperatingSystem ]
| STRING interface |<>--{0..*}--[ Counter ]
| ENUM spoofed |<>--{0..*}--[ Description ]
| |<>--{0..*}--[ AdditionalData ]
+---------------------+Figure 26: The System Class
The aggregate classes that constitute System are:
- Node: One. A host or network involved in the incident. 🏷️
- Service: Zero or more. A network service running on the system. 🛎️
- OperatingSystem: Zero or one. The operating system running on the system. 🧠
- Counter: Zero or more. A counter with which to summarize properties of this host or network. 🔢
- Description: Zero or more. ML_STRING. A free-form text description of the System. 📝
- AdditionalData: Zero or many. A mechanism by which to extend the data model. 🧩
The System class has five attributes:
- restriction: Optional. ENUM. This attribute is defined in Section 3.2. 🔒
- category: Required. ENUM. Classifies the role the host or network played in the incident. The possible values are: 🎭
source. The System was the source of the event.target. The System was the target of the event.intermediate. The System was an intermediary in the event.sensor. The System was a sensor monitoring the event.infrastructure. The System was an infrastructure node of IODEF document exchange.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-category: Optional. STRING. A means by which to extend the category attribute. See Section 5.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". 🕵️♀️unknown. The accuracy of the category attribute value is unknown.yes. The category attribute value is probably incorrect. In the case of a source, the System is likely a decoy; with a target, the System was likely not the intended victim.no. The category attribute value is believed to be correct.
3.16. Node Class 🏷️
The Node class names a system (e.g., PC, router) or network. 💅
This class was derived from the IDMEF [17].
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ NodeName ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ Location ]
| |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ NodeRole ]
| |<>--{0..*}--[ Counter ]
+---------------+Figure 27: The Node Class
The aggregate classes that constitute Node are:
- NodeName: Zero or more. ML_STRING. The name of the Node (e.g., fully qualified domain name). This information MUST be provided if no Address information is given. 📛
- Address: Zero or more. The hardware, network, or application address of the Node. If a NodeName is not provided, at least one Address MUST be specified. 📍
- Location: Zero or one. ML_STRING. A free-from description of the physical location of the equipment. 🗺️
- DateTime: Zero or one. A timestamp of when the resolution between the name and address was performed. This information SHOULD be provided if both an Address and NodeName are specified. ⏱️
- NodeRole: Zero or more. The intended purpose of the Node. 🎯
- Counter: Zero or more. A counter with which to summarizes properties of this host or network. 🔢
3.16.1. Counter Class 🔢✨
The Counter class summarize multiple occurrences of some event, or conveys counts or rates on various features (e.g., packets, sessions, events). 📊
The value of the counter is the element content with its units represented in the type attribute. A rate for a given feature can be expressed by setting the duration attribute. The complete semantics are entirely context dependent based on the class in which the Counter is aggregated. 🌈
+---------------------+
| Counter |
+---------------------+
| REAL |
| |
| ENUM type |
| STRING ext-type |
| STRING meaning |
| ENUM duration |
| STRING ext-duration |
+---------------------+Figure 28: The Counter Class
The Counter class has three attributes:
- type: Required. ENUM. Specifies the units of the element content. 📏
byte. Count of bytes.packet. Count of packets.flow. Count of flow (e.g., NetFlow records).session. Count of sessions.alert. Count of notifications generated by another system (e.g., IDS or SIM).message. Count of messages (e.g., mail messages).event. Count of events.host. Count of hosts.site. Count of site.organization. Count of organizations.ext-value. An escape value used to extend this attribute. See Section 5.1.
- ext-type: Optional. STRING. A means by which to extend the type attribute. See Section 5.1. 🧩
- duration: Optional. ENUM. If present, the Counter class represents a rate rather than a count over the entire event. In that case, this attribute specifies the denominator of the rate (where the type attribute specified the nominator). The possible values of this attribute are defined in Section 3.10.2 ⏳
- ext-duration: Optional. STRING. A means by which to extend the duration attribute. See Section 5.1. 🧩
3.16.2. Address Class ✨
okay so the Address class is the one that holds an address 💅 It can be a hardware (layer-2), network (layer-3), or application (layer-7) address, and it's giving versatile 🦋
this one was borrowed from IDMEF [17] 🎀
+---------------------+
| Address |
+---------------------+
| ENUM category |
| STRING ext-category |
| STRING vlan-name |
| INTEGER vlan-num |
+---------------------+
Figure 29: The Address Classthe Address class has four attributes 🌸
category : Required. ENUM. This is the type of address. The permitted values are listed below, and the default is ipv4-addr. 💖
asn. Autonomous System Numberatm. Asynchronous Transfer Mode (ATM) addresse-mail. Electronic mail address (RFC 822)ipv4-addr. IPv4 host address in dotted-decimal notation (a.b.c.d)ipv4-net. IPv4 network address in dotted-decimal notation, slash, significant bits (a.b.c.d/nn)ipv4-net-mask. IPv4 network address in dotted-decimal notation, slash, network mask in dotted-decimal notation (a.b.c.d/w.x.y.z)ipv6-addr. IPv6 host addressipv6-net. IPv6 network address, slash, significant bitsipv6-net-mask. IPv6 network address, slash, network maskmac. Media Access Control (MAC) addressext-value. An escape value used to extend this attribute. See Section 5.1. 🧚
ext-category : Optional. STRING. This is how you extend the category attribute. See Section 5.1. 🌈
vlan-name : Optional. STRING. The name of the Virtual LAN the address belongs to. 🍓
vlan-num : Optional. STRING. The number of the Virtual LAN the address belongs to. 🫶
3.16.3. NodeRole Class 🎀
the NodeRole class describes what job a particular host is doing. like, its whole purpose in life 👑
+---------------------+
| NodeRole |
+---------------------+
| ENUM category |
| STRING ext-category |
| ENUM lang |
+---------------------+
Figure 30: The NodeRole Classthe NodeRole class has three attributes ⭐
category : Required. ENUM. The functionality a node provides. 💅
client. Client computerserver-internal. Server with internal servicesserver-public. Server with public serviceswww. WWW servermail. Mail servermessaging. Messaging server (e.g., NNTP, IRC, IM)streaming. Streaming-media servervoice. Voice server (e.g., SIP, H.323)file. File server (e.g., SMB, CVS, AFS)ftp. FTP serverp2p. Peer-to-peer nodename. Name server (e.g., DNS, WINS)directory. Directory server (e.g., LDAP, finger, whois)credential. Credential server (e.g., domain controller, Kerberos)print. Print serverapplication. Application serverdatabase. Database serverinfra. Infrastructure server (e.g., router, firewall, DHCP)log. Logserver (e.g., syslog)ext-value. An escape value used to extend this attribute. See Section 5.1. 🔥
ext-category : Optional. STRING. This is how you extend the category attribute. See Section 5.1. ✨
lang : Required. ENUM. A valid language code per RFC 4646 [7], constrained by the definition of "xs:language". How this code is interpreted is described in Section 6. 🌸
3.17. Service Class 🦋
the Service class describes a network service of a host or network. it's identified by a specific port (or a list of ports), plus the application listening on that port 🧚
when Service shows up as an aggregate class of a System that is a source, that service is where the activity of interest is coming from. flip it: when Service is part of a System that is a target, that service is where the activity is headed 💖
this one was borrowed from IDMEF [17] 🎀
+---------------------+
| Service |
+---------------------+
| INTEGER ip_protocol |<>--{0..1}--[ Port ]
| |<>--{0..1}--[ Portlist ]
| |<>--{0..1}--[ ProtoCode ]
| |<>--{0..1}--[ ProtoType ]
| |<>--{0..1}--[ ProtoFlags ]
| |<>--{0..1}--[ Application ]
+---------------------+
Figure 31: The Service Classthese are the aggregate classes that make up Service 🍓
Port : Zero or one. INTEGER. A port number.
Portlist : Zero or one. PORTLIST. A list of port numbers, formatted according to Section 2.10.
ProtoCode : Zero or one. INTEGER. A layer-4 protocol-specific code field (e.g., ICMP code field).
ProtoType : Zero or one. INTEGER. A layer-4 protocol-specific type field (e.g., ICMP type field).
ProtoFlags : Zero or one. INTEGER. A layer-4 protocol-specific flag field (e.g., TCP flag field).
Application : Zero or more. The application bound to the specified Port or Portlist. 👑
either a Port or a Portlist class MUST be specified for any given instance of a Service class. no skipping both, bestie 🙈
for a given source, System@type="source", there may be a corresponding target, System@type="target", or vice versa. when a Portlist class is defined in the Service class of both the source and the target in a given instance of the Flow class, there MUST be symmetry in how the ports are enumerated. so if n-ports are listed for a source, n-ports should be listed for the target. the ports should also be listed in an identical sequence, so the n-th port in the source lines up with the n-th port in the target. this symmetry applies whether you've got 1-to-1, 1-to-many, or many-to-many sources-to-targets 🦋 in the 1-to-many or many-to-many cases, the exact order in which the System classes are enumerated in the Flow class matters 🔥
the Service class has one attribute 💅
ip_protocol : Required. INTEGER. The IANA protocol number.
3.17.1. Application Class ✨
the Application class describes an application running on a System that provides a Service 🧚
+--------------------+
| Application |
+--------------------+
| STRING swid |<>--{0..1}--[ URL ]
| STRING configid |
| STRING vendor |
| STRING family |
| STRING name |
| STRING version |
| STRING patch |
+--------------------+
Figure 32: The Application Classthe aggregate class that makes up Application is 🌈
URL : Zero or one. URL. A URL describing the application.
the Application class has seven attributes 💖
swid : Optional. STRING. An identifier that can be used to reference this software.
configid : Optional. STRING. An identifier that can be used to reference a particular configuration of this software.
vendor : Optional. STRING. Vendor name of the software.
family : Optional. STRING. Family of the software.
name : Optional. STRING. Name of the software.
version : Optional. STRING. Version of the software.
patch : Optional. STRING. Patch or service pack level of the software. 🎀
3.18. OperatingSystem Class 🖥️
the OperatingSystem class describes the operating system running on a System. it's literally identical to the Application class (Section 3.17.1), so no new homework 🫶
3.19. Record Class 🍓
the Record class is a container class for log and audit data. it gives supportive info about the incident. the source of this data will usually be the output of monitoring tools, and these logs should back up the activity described in the document 🔥
+------------------+
| Record |
+------------------+
| ENUM restriction |<>--{1..*}--[ RecordData ]
+------------------+
Figure 33: Record Classthe aggregate class that makes up Record is 💜
RecordData : One or more. Log or audit data generated by a particular type of sensor. Separate instances of the RecordData class SHOULD be used for each sensor type. 🌸
the Record class has one attribute ✨
restriction : Optional. ENUM. This attribute has been defined in Section 3.2.
3.19.1. RecordData Class 🦋
the RecordData class groups log or audit data from a given sensor (e.g., IDS, firewall log) and gives you a way to annotate the output 🧚
+------------------+
| RecordData |
+------------------+
| ENUM restriction |<>--{0..1}--[ DateTime ]
| |<>--{0..*}--[ Description ]
| |<>--{0..1}--[ Application ]
| |<>--{0..*}--[ RecordPattern ]
| |<>--{1..*}--[ RecordItem ]
| |<>--{0..*}--[ AdditionalData ]
+------------------+
Figure 34: The RecordData Classthese are the aggregate classes that make up RecordData 🍓
DateTime : Zero or one. Timestamp of the RecordItem data.
Description : Zero or more. ML_STRING. Free-form textual description of the provided RecordItem data. at minimum, this description should convey the significance of the provided RecordItem data. 💅
Application : Zero or one. Information about the sensor used to generate the RecordItem data.
RecordPattern : Zero or more. A search string to precisely find the relevant data in a RecordItem.
RecordItem : One or more. Log, audit, or forensic data.
AdditionalData : Zero or one. An extension mechanism for data not explicitly represented in the data model. 🌈
the RecordData class has one attribute 👑
restriction : Optional. ENUM. This attribute has been defined in Section 3.2.
3.19.2. RecordPattern Class ✨
okay so RecordPattern is the class that points you to the exact spot where the good stuff lives inside a RecordItem 🔍 Logs, audit trails, and forensic data can be HUGE, so this lets you grab just the subset you need by describing a pattern to look for. literally a treasure map 🗺️💖
+-----------------------+
| RecordPattern |
+-----------------------+
| STRING |
| |
| ENUM type |
| STRING ext-type |
| INTEGER offset |
| ENUM offsetunit |
| STRING ext-offsetunit |
| INTEGER instance |
+-----------------------+Figure 35: The RecordPattern Class
the actual pattern you're searching for goes in the body of the element 🎀 and it has four attributes that help describe it:
type💅- Required. ENUM. This tells you what kind of pattern is in the element content. The default is
"regex".regex. Regular expression, per Appendix F of [3].binary. Binhex encoded binary pattern, per the HEXBIN data type.xpath. XML Path (XPath) [5]ext-value. An escape value used to extend this attribute. See Section 5.1.
- Required. ENUM. This tells you what kind of pattern is in the element content. The default is
ext-type🦋- Optional. STRING. A means by which to extend the
typeattribute. See Section 5.1.
- Optional. STRING. A means by which to extend the
offset🌸- Optional. INTEGER. Amount of units (determined by the
offsetunitattribute) to seek into the RecordItem data before matching the pattern.
- Optional. INTEGER. Amount of units (determined by the
offsetunit✨- Optional. ENUM. Describes the units of the
offsetattribute. The default is"line".line. Offset is a count of lines.binary. Offset is a count of bytes.ext-value. An escape value used to extend this attribute. See Section 5.1.
- Optional. ENUM. Describes the units of the
ext-offsetunit🧚- Optional. STRING. A means by which to extend the
offsetunitattribute. See Section 5.1.
- Optional. STRING. A means by which to extend the
instance💜- Optional. INTEGER. Number of types to apply the specified pattern.
3.19.3. RecordItem Class
the RecordItem class is how you bring in the relevant logs, audit trails, or forensic data that back up your conclusions while you're analyzing an incident 🕵️♀️🫶 it can hold the data directly inside itself, OR it can give you primitives that point to data stored somewhere else. two ways to slay 💅
This class is identical to AdditionalData class (Section 3.6). 🌈
4. Processing Considerations ✨
this section adds some extra rules for making and parsing IODEF documents, so pay attention bestie 🎀
4.1. Encoding
every IODEF document MUST begin with an XML declaration, and MUST specify the XML version used. if UTF-8 encoding is not used, the character encoding MUST also be explicitly specified 🙈 the IODEF follows all the XML data encoding conventions and constraints, no exceptions.
an XML declaration with no character encoding looks like this:
<?xml version="1.0" ?>and when you do specify a character encoding, it looks like this:
<?xml version="1.0" encoding="charset" ?>where "charset" is the name of the character encoding as registered with the Internet Assigned Numbers Authority (IANA), see [9]. 🌸
the following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). these entity references are "&", "<", ">", """, and "'" respectively. no skipping these, iykyk 😭
4.2. IODEF Namespace
the IODEF schema declares a namespace of "urn:ietf:params:xml:ns:iodef-1.0" and registers it per [4]. each IODEF document SHOULD include a valid reference to the IODEF schema using the "xsi:schemaLocation" attribute 🦋 an example of what that declaration looks like:
<IODEF-Document
version="1.00" lang="en-US"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0">4.3. Validation
the IODEF documents MUST be well-formed XML and SHOULD be validated against the schema described in Section 8. BUT mere conformance to the schema is not sufficient for a semantically valid IODEF document 💀 there's extra specification in the text of Section 3 that the schema can't easily encode, so an IODEF parser must consider it too. here's the list of discrepancies, where the normative text (Section 3) is stricter than what the schema actually enforces:
- The elements or attributes that are defined as POSTAL, NAME, PHONE, and EMAIL data-types are implemented as
xs:string, but more rigid formatting requirements are specified in the text. 📮 - The
IODEF-Document@langandMLStringType@langattributes are declared as anxs:languagethat constrains values with a regular expression. however, the value of this attribute still needs to be validated against the list of possible enumerated values is defined in [7]. 🌍 - The
MonetaryImpact@currencyattribute is declared as anxs:string, but the list of valid values as defined in [14]. 💸 - All of the aggregated classes Contact and EventData are optional in the schema, but at least one of these aggregated classes MUST be present. 🫶
- There are multiple conventions that can be used to categorize a system using the NodeRole class or to specify software with the Application and OperatingSystem classes. IODEF parsers MUST accept incident reports that do not use these fields in accordance with local conventions. 🌈 main character energy for every org's own style, honestly
- The
Confidence@ratingattribute determines whether the element content of Confidence should be empty. 🎀 - The
Address@typeattribute determines the format of the element content. 🧚 - The attributes
AdditionalData@dtypeandRecordItem@dtypederived fromiodef:ExtensionTypedetermine the semantics and formatting of the element content. 💜 - Symmetry in the enumerated ports of a Portlist class is required between sources and targets. See Section 3.17. 🔥
5. Extending the IODEF ✨
okay so the CSIRTs keep changing what they do, which means the IODEF data model has to evolve with them 🦋 this section talks about how brand-new data elements with no current home in the data model can still get in. the cool part is these techniques are designed so that adding new data will NOT require a change to the IODEF schema 😱 (ha, no, not in caps, I'm just hyping it up). with proven value, well documented extensions can be pulled into future versions of the specification. and this approach also supports private extensions that are only relevant to a closed consortium 🔒
5.1. Extending the Enumerated Values of Attributes
the data model has a way to add new enumerated values to an attribute 🌸 for every attribute that supports this extension technique, there's a matching attribute in the same element whose name is identical, minus a prefix of "ext-". this special attribute is called the extension attribute, and the attribute being extended is called an extensible attribute. for example, an extensible attribute named "foo" will have a corresponding extension attribute named "ext-foo". an element can have many extensible, and therefore many extension, attributes 🧚
on top of its corresponding extension attribute, each extensible attribute has "ext-value" as one of its possible values. this particular value is an escape sequence and has no valid meaning on its own 🙈
so, 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, an extended instance of the type attribute of the Impact class would look like this:
<Impact type="ext-value" ext-type="new-attack-type">and the last rule, the one you can't skip 💅: a given extension attribute MUST NOT be set unless the corresponding extensible attribute has been set to "ext-value". no shortcuts, periodt 💖
5.2. Extending Classes ✨
Okay so, the ONLY way to add stuff to the classes in the data model is through the AdditionalData and RecordItem classes 💖. These container classes (collectively called the extensible classes) are built with the iodef:ExtensionType data type in the schema. They let you add new atomic or XML-encoded data elements to all of the top-level classes of the Incident class and a few of the more complicated subordinate classes 🎀. There are lots of extensible classes in the data model, so you get to pick where your new element goes. It is RECOMMENDED that you put the extension in the most closely related class to the new information 🧚.
If you're doing an atomic extension (so, any dtype value that isn't "xml"), you MUST do the following 💅:
- Set the element content of the extensible class to the desired value, and
- Set the dtype attribute to match the data type of the element content.
For XML extensions, here's the vibe check 🔥:
- The element content of the extensible class MUST be set to the desired value, and the dtype attribute MUST be set to "xml".
- The extension schema MUST declare a separate namespace. It is RECOMMENDED that these extensions use the prefix "iodef-" 🌸.
- It is RECOMMENDED that extension schemas follow the naming convention of the IODEF data model. All element names are capitalized, and for composed names, each word gets a capital letter. Attribute names are lower case ✨.
- When a parser runs into an IODEF document with an extension it doesn't understand, that extension MUST be ignored (and not processed), but the rest of the document MUST be processed 🙈. Parsers can spot these extensions they have no processing logic for through the namespace declaration. Parsers that run into an unrecognized element in a namespace they DO support SHOULD reject the document as a syntax error 💀.
- Implementations SHOULD NOT download schemas at runtime because of the security implications 🔒, and extensions MUST NOT be required to provide a resolvable location of their schema.
Here's a template for an extension schema and how it shows up in an IODEF document 🦋. This example schema defines a namespace of "iodef-extension1" and a single element called "newdata":
<xs:schema
targetNamespace="iodef-extension1.xsd"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
attributeFormDefault="unqualified"
elementFormDefault="qualified">
<xs:import
namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation=" urn:ietf:params:xml:schema:iodef-1.0"/>
<xs:element name="newdata" type="xs:string" />
</xs:schema>And here's the extension in action 😭:
<IODEF-Document
version="1.00" lang="en-US"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef=" urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef-extension1="iodef-extension1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="iodef-extension1.xsd">
<Incident purpose="reporting">
...
<AdditionalData dtype="xml" meaning="xml">
<iodef-extension1:newdata>
Field that could not be represented elsewhere
</iodef-extension1:newdata>
</AdditionalData>
</Incident>
</IODEF-Document>6. Internationalization Issues 🌈
Internationalization and localization are a big deal for the IODEF, since some incidents only get resolved through collaboration, often across language barriers 🫶. The IODEF supports this goal by leaning on XML constructs and by making some explicit design choices in the data model.
Since IODEF is implemented as an XML Schema, it implicitly supports all the different character encodings XML can handle, like UTF-8 and UTF-16 💜. On top of that, each IODEF document MUST specify the language its contents are encoded in. The language can be set with the xml:lang attribute (per Section 2.12 of [1]) on the top-level element (i.e., IODEF-Document@lang), and then every other element just inherits that setting ✨. All IODEF classes with a free-form text definition (i.e., every class of type iodef:MLStringType) can also specify a language that's different from the rest of the document. The valid language codes for the xml:lang attribute are described in RFC 4646 [7].
The data model supports multiple translations of free-form text 🍓. Wherever free text is used for descriptive purposes, the class always has a one-to-many cardinality to its parent (e.g., the Description class). The idea is that the identical text can be encoded in different instances of the same class, with each one in a different language. This means an IODEF document author can send recipients who speak different languages one identical document 🌸. The IODEF parser SHOULD extract the appropriate language for the recipient.
The intent of the data model is to offer internationalization and localization, but not at the expense of interoperability 🙅♀️. Even though the IODEF supports different languages, the data model also leans heavily on standardized enumerated attributes that can roughly approximate what the document is about. Because of this, a CSIRT should be able to make some sense of an IODEF document it receives, even if the text-based data elements are written in a language the analyst doesn't speak 🧠💖.
7. Examples 🎀
This section has examples of an incident encoded in the IODEF 👑. These examples do not necessarily represent the only way to encode a particular incident.
7.1. Worm 🐛
Here's a CSIRT reporting an instance of the Code Red worm. Very old worm, very iconic 💀.
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example demonstrates a report for a very
old worm (Code Red) -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">189493</IncidentID>
<ReportTime>2001-09-13T23:19:24+00:00</ReportTime>
<Description>Host sending out Code Red probes</Description>
<!-- An administrative privilege was attempted, but failed -->
<Assessment>
<Impact completion="failed" type="admin"/>
</Assessment>
<Contact role="creator" type="organization">
<ContactName>Example.com CSIRT</ContactName>
<RegistryHandle registry="arin">example-com</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_protocol="6">
<Port>80</Port>
</Service>
</System>
</Flow>
<Expectation action="block-host" />
<!-- <RecordItem> has an excerpt from a log -->
<Record>
<RecordData>
<DateTime>2001-09-13T18:11:21+02:00</DateTime>
<Description>Web-server logs</Description>
<RecordItem dtype="string">
192.0.2.1 - - [13/Sep/2001:18:11:21 +0200] "GET /default.ida?
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</RecordItem>
<!-- Additional logs -->
<RecordItem dtype="url">
http://mylogs.example.com/logs/httpd_access</RecordItem>
</RecordData>
</Record>
</EventData>
<History>
<!-- Contact was previously made with the source network owner -->
<HistoryItem action="contact-source-site">
<DateTime>2001-09-14T08:19:01+00:00</DateTime>
<Description>Notification sent to
constituency-contact@192.0.2.200</Description>
</HistoryItem>
</History>
</Incident>
</IODEF-Document>7.2. Reconnaissance 🔍
This one's a CSIRT reporting some scanning activity 👀.
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes reconnaissance activity: one-to-one and
one-to-many scanning -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting">
<IncidentID name="csirt.example.com">59334</IncidentID>
<ReportTime>2006-08-02T05:54:02-05:00</ReportTime>
<Assessment>
<Impact type="recon" completion="succeeded" />
</Assessment>
<Method>
<!-- Reference to the scanning tool "nmap" -->
<Reference>
<ReferenceName>nmap</ReferenceName>
<URL>http://nmap.toolsite.example.com</URL>
</Reference>
</Method>
<!-- Organizational contact and that for staff in that
organization -->
<Contact role="creator" type="organization">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
<Telephone>+1 412 555 12345</Telephone>
<!-- Since this <Contact> is nested, Joe Smith is part of the
CSIRT for example.com -->
<Contact role="tech" type="person" restriction="need-to-know">
<ContactName>Joe Smith</ContactName>
<Email>smith@csirt.example.com</Email>
</Contact>
</Contact>
<EventData>
<!-- Scanning activity as follows:
192.0.2.1:60524 >> 192.0.2.3:137
192.0.2.1:60526 >> 192.0.2.3:138
192.0.2.1:60527 >> 192.0.2.3:139
192.0.2.1:60531 >> 192.0.2.3:445
-->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
</Node>
<Service ip_protocol="6">
<Portlist>60524,60526,60527,60531</Portlist>
</Service>
</System>
<System category="target">
<Node>
<Address category="ipv4-addr">192.0.2.201</Address>
</Node>
<Service ip_protocol="6">
<Portlist>137-139,445</Portlist>
</Service>
</System>
</Flow>
<!-- Scanning activity as follows:
192.0.2.2 >> 192.0.2.3/28:445 -->
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.240</Address>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.64/28</Address>
</Node>
<Service ip_protocol="6">
<Port>445</Port>
</Service>
</System>
</Flow>
</EventData>
</Incident>
</IODEF-Document>7.3. Bot-Net Reporting ✨
okay so this one is a CSIRT reporting a whole bot-network, and it's giving villain origin story 💀 A machine gets compromised through a known IE vulnerability, a bot gets installed, and then those bots talk to an IRC server for commands. the example covers all of it, with the malware, the vuln, the bots, and the C2 server 🦋
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example describes a compromise and subsequent installation
of bots -->
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="mitigation">
<IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-06-08T05:44:53-05:00</ReportTime>
<Description>Large bot-net</Description>
<Assessment>
<Impact type="dos" severity="high" completion="succeeded" />
</Assessment>
<Method>
<!-- References a given piece of malware, "GT Bot" -->
<Reference>
<ReferenceName>GT Bot</ReferenceName>
</Reference>
<!-- References the vulnerability used to compromise the
machines -->
<Reference>
<ReferenceName>CA-2003-22</ReferenceName>
<URL>http://www.cert.org/advisories/CA-2003-22.html</URL>
<Description>Root compromise via this IE vulnerability to
install the GT Bot</Description>
</Reference>
</Method>
<!-- A member of the CSIRT that is coordinating this
incident -->
<Contact type="person" role="irt">
<ContactName>Joe Smith</ContactName>
<Email>jsmith@csirt.example.com</Email>
</Contact>
<EventData>
<Description>These hosts are compromised and acting as bots
communicating with irc.example.com.</Description>
<Flow>
<!-- bot running on 192.0.2.1 and sending DoS traffic at
10,000 bytes/second -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.1</Address>
</Node>
<Counter type="byte" duration="second">10000</Counter>
<Description>bot</Description>
</System>
<!-- a second bot on 192.0.2.3 -->
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.3</Address>
</Node>
<Counter type="byte" duration="second">250000</Counter>
<Description>bot</Description>
</System>
<!-- Command-and-control IRC server for these bots-->
<System category="intermediate">
<Node>
<NodeName>irc.example.com</NodeName>
<Address category="ipv4-addr">192.0.2.20</Address>
<DateTime>2006-06-08T01:01:03-05:00</DateTime>
</Node>
<Description>IRC server on #give-me-cmd channel</Description>
</System>
</Flow>
<!-- Request to take these machines offline -->
<Expectation action="investigate">
<Description>Confirm the source and take machines off-line and
remediate</Description>
</Expectation>
</EventData>
</Incident>
</IODEF-Document>7.4. Watch List 👀
this one is a CSIRT passing along a watch-list 🧚 basically a list of known bad IPs and networks, shared so everyone can keep an eye on them. the formatid is set to "watch-list-043" to show how extra meaning could get carried along, as long as both sides actually understand it 💜
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This example demonstrates a trivial IP watch-list -->
<!-- @formatid is set to "watch-list-043" to demonstrate how additional
semantics about this document could be conveyed assuming both
parties understood it-->
<IODEF-Document version="1.00" lang="en" formatid="watch-list-043"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:schema:iodef-1.0">
<Incident purpose="reporting" restriction="private">
<IncidentID name="csirt.example.com">908711</IncidentID>
<ReportTime>2006-08-01T00:00:00-05:00</ReportTime>
<Description>Watch-list of known bad IPs or networks</Description>
<Assessment>
<Impact type="admin" completion="succeeded" />
<Impact type="recon" completion="succeeded" />
</Assessment>
<Contact type="organization" role="creator">
<ContactName>CSIRT for example.com</ContactName>
<Email>contact@csirt.example.com</Email>
</Contact>
<!-- Separate <EventData> used to convey different <Expectation> -->
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.53</Address>
</Node>
<Description>Source of numerous attacks</Description>
</System>
</Flow>
<!-- Expectation class indicating that sender of list would like
to be notified if activity from the host is seen -->
<Expectation action="contact-sender" />
</EventData>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Description>
Source of heavy scanning over past 1-month
</Description>
</System>
</Flow>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.241</Address>
</Node>
<Description>C2 IRC server</Description>
</System>
</Flow>
<!-- Expectation class recommends that these networks
be filtered -->
<Expectation action="block-host" />
</EventData>
</Incident>
</IODEF-Document>8. The IODEF Schema 💅
okay the schema is the official rulebook 📖 the XML has to match it, so this is where all the element names, attributes and "how many times can this show up" rules live. it's a lot, but it's so organised once you see the pattern 🫶
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:iodef-1.0"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
Incident Object Description Exchange Format v1.00, see RFC 5070
</xs:documentation>
</xs:annotation>
<!--
====================================================================
== IODEF-Document class ==
====================================================================
-->
<xs:element name="IODEF-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Incident"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version"
type="xs:string" fixed="1.00"/>
<xs:attribute name="lang"
type="xs:language" use="required"/>
<xs:attribute name="formatid"
type="xs:string"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Incident class ===
====================================================================
-->
<xs:element name="Incident">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"/>
<xs:element ref="iodef:AlternativeID"
minOccurs="0"/>
<xs:element ref="iodef:RelatedActivity"
minOccurs="0"/>
<xs:element ref="iodef:DetectTime"
minOccurs="0"/>
<xs:element ref="iodef:StartTime"
minOccurs="0"/>
<xs:element ref="iodef:EndTime"
minOccurs="0"/>
<xs:element ref="iodef:ReportTime"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment"
maxOccurs="unbounded"/>
<xs:element ref="iodef:Method"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Contact"
maxOccurs="unbounded"/>
<xs:element ref="iodef:EventData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:History"
minOccurs="0"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="purpose" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="traceback"/>
<xs:enumeration value="mitigation"/>
<xs:enumeration value="reporting"/>
<xs:enumeration value="other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-purpose"
type="xs:string" use="optional"/>
<xs:attribute name="lang"
type="xs:language"/>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="private"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== IncidentID class ==
====================================================================
-->
<xs:element name="IncidentID" type="iodef:IncidentIDType"/>
<xs:complexType name="IncidentIDType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name"
type="xs:string" use="required"/>
<xs:attribute name="instance"
type="xs:string" use="optional"/>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="public"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!--
====================================================================
== AlternativeID class ==
====================================================================
-->
<xs:element name="AlternativeID">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
== RelatedActivity class ==
====================================================================
-->
<xs:element name="RelatedActivity">
<xs:complexType>
<xs:choice>
<xs:element ref="iodef:IncidentID"
maxOccurs="unbounded"/>
<xs:element ref="iodef:URL"
maxOccurs="unbounded"/>
</xs:choice>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== AdditionalData class ===
====================================================================
-->
<xs:element name="AdditionalData" type="iodef:ExtensionType"/>
<!--
====================================================================
=== Contact class ===
====================================================================
-->
<xs:element name="Contact">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ContactName"
minOccurs="0"/><xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:RegistryHandle" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:PostalAddress" minOccurs="0"/> <xs:element ref="iodef:Email" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Telephone" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Fax" minOccurs="0"/> <xs:element ref="iodef:Timezone" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="role" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="creator"/> <xs:enumeration value="admin"/> <xs:enumeration value="tech"/> <xs:enumeration value="irt"/> <xs:enumeration value="cc"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-role" type="xs:string" use="optional"/> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="person"/> <xs:enumeration value="organization"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="ContactName" type="iodef:MLStringType"/> <xs:element name="RegistryHandle"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="registry"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="internic"/> <xs:enumeration value="apnic"/> <xs:enumeration value="arin"/> <xs:enumeration value="lacnic"/> <xs:enumeration value="ripe"/> <xs:enumeration value="afrinic"/> <xs:enumeration value="local"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-registry" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name="PostalAddress"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:MLStringType"> <xs:attribute name="meaning" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="Email" type="iodef:ContactMeansType"/> <xs:element name="Telephone" type="iodef:ContactMeansType"/> <xs:element name="Fax" type="iodef:ContactMeansType"/>
<xs:complexType name="ContactMeansType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="meaning" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent>
</xs:complexType>
<!-- ==================================================================== === Time-based classes === ==================================================================== --> <xs:element name="DateTime" type="xs:dateTime"/> <xs:element name="ReportTime" type="xs:dateTime"/> <xs:element name="DetectTime" type="xs:dateTime"/> <xs:element name="StartTime" type="xs:dateTime"/> <xs:element name="EndTime" type="xs:dateTime"/> <xs:element name="Timezone" type="iodef:TimezoneType"/> <xs:simpleType name="TimezoneType"> <xs:restriction base="xs:string"> <xs:pattern value="Z|[\+-](0[0-9]|1[0-4]):[0-5][0-9]"/> </xs:restriction> </xs:simpleType> <!-- ==================================================================== === History class === ==================================================================== --> <xs:element name="History"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:HistoryItem" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type" default="default"/> </xs:complexType> </xs:element> <xs:element name="HistoryItem"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:DateTime"/> <xs:element ref="iodef:IncidentID" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0"/> <xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> <xs:attribute name="action" type="iodef:action-type" use="required"/> <xs:attribute name="ext-action" type="xs:string" use="optional"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Expectation class === ==================================================================== --> <xs:element name="Expectation"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:StartTime" minOccurs="0"/> <xs:element ref="iodef:EndTime" minOccurs="0"/> <xs:element ref="iodef:Contact" minOccurs="0"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type" default="default"/> <xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="action" type="iodef:action-type" default="other"/> <xs:attribute name="ext-action" type="xs:string" use="optional"/> </xs:complexType> </xs:element> <!-- ==================================================================== === Method class === ==================================================================== --> <xs:element name="Method"> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:Reference"/> <xs:element ref="iodef:Description"/> </xs:choice> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="Reference"> <xs:complexType> <xs:sequence> <xs:element name="ReferenceName" type="iodef:MLStringType"/> <xs:element ref="iodef:URL" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <!-- ==================================================================== === Assessment class === ==================================================================== --> <xs:element name="Assessment"> <xs:complexType> <xs:sequence> <xs:choice maxOccurs="unbounded"> <xs:element ref="iodef:Impact"/> <xs:element ref="iodef:TimeImpact"/> <xs:element ref="iodef:MonetaryImpact"/> </xs:choice> <xs:element ref="iodef:Counter" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Confidence" minOccurs="0"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="occurrence"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="actual"/> <xs:enumeration value="potential"/> </xs:restriction> </xs:simpleType>
</xs:attribute> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="Impact"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:MLStringType"> <xs:attribute name="severity" type="iodef:severity-type"/> <xs:attribute name="completion"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="failed"/> <xs:enumeration value="succeeded"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="type" use="optional" default="unknown"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="admin"/> <xs:enumeration value="dos"/> <xs:enumeration value="extortion"/> <xs:enumeration value="file"/> <xs:enumeration value="info-leak"/> <xs:enumeration value="misconfiguration"/> <xs:enumeration value="recon"/> <xs:enumeration value="policy"/> <xs:enumeration value="social-engineering"/> <xs:enumeration value="user"/> <xs:enumeration value="unknown"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="TimeImpact"> <xs:complexType> <xs:simpleContent> <xs:extension base="iodef:PositiveFloatType">
okay bestie, the schema keeps going and it's giving pure structure 🎀💅
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="metric"
use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="labor"/>
<xs:enumeration value="elapsed"/>
<xs:enumeration value="downtime"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-metric"
type="xs:string" use="optional"/>
<xs:attribute name="duration"
type="iodef:duration-type"/>
<xs:attribute name="ext-duration"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="MonetaryImpact">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:PositiveFloatType">
<xs:attribute name="severity"
type="iodef:severity-type"/>
<xs:attribute name="currency"
type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Confidence">
<xs:complexType mixed="true">
<xs:attribute name="rating" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="low"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="high"/>
<xs:enumeration value="numeric"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== EventData class ===
====================================================================
-->
<xs:element name="EventData">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:DetectTime"
minOccurs="0"/>
<xs:element ref="iodef:StartTime"
minOccurs="0"/>
<xs:element ref="iodef:EndTime"
minOccurs="0"/>
<xs:element ref="iodef:Contact"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Assessment"
minOccurs="0"/>
<xs:element ref="iodef:Method"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Flow"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Expectation"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Record"
minOccurs="0"/>
<xs:element ref="iodef:EventData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" default="default"/>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Flow class ===
====================================================================
-->
<xs:element name="Flow">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:System"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== System class ===
====================================================================
-->
<xs:element name="System">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef:Service"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:OperatingSystem"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type"/>
<xs:attribute name="interface"
type="xs:string"/>
<xs:attribute name="category">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="source"/>
<xs:enumeration value="target"/>
<xs:enumeration value="intermediate"/>
<xs:enumeration value="sensor"/>
<xs:enumeration value="infrastructure"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="spoofed"
default="unknown">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unknown"/>
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<!--
====================================================================
=== Node class ===
====================================================================
-->
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element name="NodeName"
type="iodef:MLStringType" minOccurs="0"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:Location"
minOccurs="0"/>
<xs:element ref="iodef:DateTime"
minOccurs="0"/>
<xs:element ref="iodef:NodeRole"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Address">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="category" default="ipv4-addr">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/>
<xs:enumeration value="mac"/>
<xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
<xs:attribute name="vlan-name"
type="xs:string"/>
<xs:attribute name="vlan-num"
type="xs:integer"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Location" type="iodef:MLStringType"/>
<xs:element name="NodeRole">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="iodef:MLStringType">
<xs:attribute name="category" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="client"/>
<xs:enumeration value="server-internal"/>
<xs:enumeration value="server-public"/>
<xs:enumeration value="www"/>
<xs:enumeration value="mail"/>
<xs:enumeration value="messaging"/>
<xs:enumeration value="streaming"/>
<xs:enumeration value="voice"/>
<xs:enumeration value="file"/>
<xs:enumeration value="ftp"/>
<xs:enumeration value="p2p"/>
<xs:enumeration value="name"/>
<xs:enumeration value="directory"/>
<xs:enumeration value="credential"/>
<xs:enumeration value="print"/>
<xs:enumeration value="application"/>
<xs:enumeration value="database"/>
<xs:enumeration value="infra"/>
<xs:enumeration value="log"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-category"
type="xs:string" use="optional"/>
</xs:extension></xs:simpleContent> </xs:complexType> </xs:element> <!-- ==================================================================== === Service Class === ==================================================================== --> <xs:element name="Service"> <xs:complexType> <xs:sequence> <xs:choice minOccurs="0"> <xs:element name="Port" type="xs:integer"/> <xs:element name="Portlist" type="iodef:PortlistType"/> </xs:choice> <xs:element name="ProtoType" type="xs:integer" minOccurs="0"/> <xs:element name="ProtoCode" type="xs:integer" minOccurs="0"/> <xs:element name="ProtoField" type="xs:integer" minOccurs="0"/> <xs:element ref="iodef:Application" minOccurs="0"/> </xs:sequence> <xs:attribute name="ip_protocol" type="xs:integer" use="required"/> </xs:complexType> </xs:element> <xs:simpleType name="PortlistType"> <xs:restriction base="xs:string"> <xs:pattern value="\d+(-\d+)?(,\d+(-\d+)?)*"/> </xs:restriction> </xs:simpleType> <!-- ==================================================================== === Counter class === ==================================================================== --> <xs:element name="Counter"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:double"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="byte"/> <xs:enumeration value="packet"/> <xs:enumeration value="flow"/> <xs:enumeration value="session"/> <xs:enumeration value="event"/> <xs:enumeration value="alert"/> <xs:enumeration value="message"/> <xs:enumeration value="host"/> <xs:enumeration value="site"/> <xs:enumeration value="organization"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="meaning" type="xs:string" use="optional"/> <xs:attribute name="duration" type="iodef:duration-type"/> <xs:attribute name="ext-duration" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <!-- ==================================================================== === Record class === ==================================================================== --> <xs:element name="Record"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:RecordData" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="RecordData"> <xs:complexType> <xs:sequence> <xs:element ref="iodef:DateTime" minOccurs="0"/> <xs:element ref="iodef:Description" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:Application"
minOccurs="0"/> <xs:element ref="iodef:RecordPattern" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="iodef:RecordItem" maxOccurs="unbounded"/> <xs:element ref="iodef:AdditionalData" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> </xs:element> <xs:element name="RecordPattern"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="type" use="required"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="regex"/> <xs:enumeration value="binary"/> <xs:enumeration value="xpath"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-type" type="xs:string" use="optional"/> <xs:attribute name="offset" type="xs:integer" use="optional"/> <xs:attribute name="offsetunit" use="optional" default="line"> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="line"/> <xs:enumeration value="byte"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ext-offsetunit" type="xs:string" use="optional"/> <xs:attribute name="instance" type="xs:integer" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="RecordItem" type="iodef:ExtensionType"/> <!-- ==================================================================== === Classes that describe software === ==================================================================== --> <xs:complexType name="SoftwareType"> <xs:sequence> <xs:element ref="iodef:URL" minOccurs="0"/> </xs:sequence> <xs:attribute name="swid" type="xs:string" default="0"/> <xs:attribute name="configid" type="xs:string" default="0"/> <xs:attribute name="vendor" type="xs:string"/> <xs:attribute name="family" type="xs:string"/> <xs:attribute name="name" type="xs:string"/> <xs:attribute name="version" type="xs:string"/> <xs:attribute name="patch" type="xs:string"/> </xs:complexType> <xs:element name="Application" type="iodef:SoftwareType"/> <xs:element name="OperatingSystem" type="iodef:SoftwareType"/> <!-- ==================================================================== === Miscellaneous simple classes === ==================================================================== --> <xs:element name="Description" type="iodef:MLStringType"/> <xs:element name="URL" type="xs:anyURI"/> <!-- ==================================================================== === Data Types === ==================================================================== --> <xs:simpleType name="PositiveFloatType"> <xs:restriction base="xs:float"> <xs:minExclusive value="0"/>
</xs:restriction> </xs:simpleType> <xs:complexType name="MLStringType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="lang" type="xs:language" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="ExtensionType" mixed="true"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="dtype" type="iodef:dtype-type" use="required"/> <xs:attribute name="ext-dtype" type="xs:string" use="optional"/> <xs:attribute name="meaning" type="xs:string"/> <xs:attribute name="formatid" type="xs:string"/> <xs:attribute name="restriction" type="iodef:restriction-type"/> </xs:complexType> <!-- ==================================================================== === Global attribute type declarations === ==================================================================== --> <xs:simpleType name="restriction-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="default"/> <xs:enumeration value="public"/> <xs:enumeration value="need-to-know"/> <xs:enumeration value="private"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="severity-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="low"/> <xs:enumeration value="medium"/> <xs:enumeration value="high"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="duration-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="second"/> <xs:enumeration value="minute"/> <xs:enumeration value="hour"/> <xs:enumeration value="day"/> <xs:enumeration value="month"/> <xs:enumeration value="quarter"/> <xs:enumeration value="year"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="action-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="nothing"/> <xs:enumeration value="contact-source-site"/> <xs:enumeration value="contact-target-site"/> <xs:enumeration value="contact-sender"/> <xs:enumeration value="investigate"/> <xs:enumeration value="block-host"/> <xs:enumeration value="block-network"/> <xs:enumeration value="block-port"/> <xs:enumeration value="rate-limit-host"/> <xs:enumeration value="rate-limit-network"/> <xs:enumeration value="rate-limit-port"/> <xs:enumeration value="remediate-other"/> <xs:enumeration value="status-triage"/> <xs:enumeration value="status-new-info"/> <xs:enumeration value="other"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType>
<xs:simpleType name="dtype-type"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="boolean"/> <xs:enumeration value="byte"/> <xs:enumeration value="character"/> <xs:enumeration value="date-time"/> <xs:enumeration value="integer"/> <xs:enumeration value="ntpstamp"/> <xs:enumeration value="portlist"/> <xs:enumeration value="real"/> <xs:enumeration value="string"/> <xs:enumeration value="file"/> <xs:enumeration value="path"/> <xs:enumeration value="frame"/> <xs:enumeration value="packet"/> <xs:enumeration value="ipv4-packet"/> <xs:enumeration value="ipv6-packet"/> <xs:enumeration value="url"/> <xs:enumeration value="csv"/> <xs:enumeration value="winreg"/> <xs:enumeration value="xml"/> <xs:enumeration value="ext-value"/> </xs:restriction> </xs:simpleType> </xs:schema>
9. Security Considerations 🔐💅
okay bestie, this section is SERIOUS but also kind of iconic ngl 😭🫶 So the IODEF data model itself doesn't directly introduce security issues. It's just a way to represent incident information, like a neat little container 🎀 But the thing is, IODEF data can be privacy sensitive for the people exchanging it or the people it's about, so you have to be careful about who sees it 👀 The disclosure part during document exchange has to be handled by a messaging format, and the processing part has to be handled by the systems that process, store, and archive IODEF documents and whatever info they derive from them. Main character responsibility, fr fr 💜
An IODEF document can include a request for action, and an IODEF parser might also have its own logic to take certain actions based on what it finds 🧚 So the parser has to properly authenticate the recipient of the document and give the data an appropriate level of confidence before it acts on anything. No yolo-ing into action, periodt 💀
The underlying messaging format and protocol used to exchange IODEF instances MUST provide appropriate guarantees of confidentiality, integrity, and authenticity 🔥 Using a standardized security protocol is encouraged, and the Real-time Inter-network Defense (RID) protocol [18] and its transport binding IODEF/RID over SOAP [19] both provide that security 🦋
The IODEF lets a document sender convey a privacy policy using the restriction attribute 🌸 Different instances of that attribute let different data elements in the document follow different policies, which is very flexible and very cute. BUT (and this is a big but 🙈) this is only a guideline from the sender, because the recipient is free to ignore it. Enforcement is not a technical problem, it's a people-and-policy problem 💖
⚠️ Read that last bit again. The restriction attribute is a suggestion, not a lock. Plan accordingly, bestie 🫶
10. IANA Considerations 📋✨
This document uses URNs to describe an XML namespace and schema that conform to a registry mechanism described in [15] 🌈
Registration for the IODEF namespace:
- URI:
urn:ietf:params:xml:ns:iodef-1.0 - Registrant Contact: See the first author of the "Author's Address" section of this document.
- XML: None. Namespace URIs do not represent an XML specification.
Registration for the IODEF XML schema:
- URI:
urn:ietf:params:xml:schema:iodef-1.0 - Registrant Contact: See the first author of the "Author's Address" section of this document.
- XML: See the "IODEF Schema" in Section 8 of this document.
11. Acknowledgments 🙏🎀
The following groups and individuals, listed alphabetically, contributed substantially to this document and deserve a huge shoutout for their efforts 👑
- Patrick Cain, Cooper-Cain Group, Inc.
- The eCSIRT.net Project
- The Incident Object Description and Exchange Format Working-Group of the TERENA task-force (TF-CSIRT)
- Glenn Mansfield Keeni, Cyber Solutions, Inc.
- Hiroyuki Kido, NARA Institute of Science and Technology
- Kathleen Moriarty, MIT Lincoln Laboratory
- Brian Trammell, CERT/NetSA
12. References 📚
12.1. Normative References
- [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
- [2] World Wide Web Consortium, "XML XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
- [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
- [4] World Wide Web Consortium, "Namespaces in XML", W3C Recommendation, January 1999, <http://www.w3.org/TR/REC-xml-names/>.
- [5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C Candidate Recommendation, June 2006, <http://www.w3.org/TR/xpath20/>.
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
- [7] Philips, A. and M. Davis, "Tags for Identifying of Languages", RFC 4646, September 2006.
- [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005`.
- [9] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 2978, October 2000.
- [10] Sciberras, A., "Schema for User Applications", RFC 4519, June 2006.
- [11] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [12] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
- [13] International Organization for Standardization, "International Standard: Data elements and interchange formats - Information interchange - Representation of dates and times", ISO 8601, Second Edition, December 2000.
- [14] International Organization for Standardization, "International Standard: Codes for the representation of currencies and funds, ISO 4217:2001", ISO 4217:2001, August 2001.
- [15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
12.2. Informative References
- [16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the Format for Incident Information Exchange (FINE)", Work in Progress, June 2006.
- [17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion Detection Message Exchange Format", RFC 4765, March 2007.
- [18] Moriarty, K., "Real-time Inter-network Defense", Work in Progress, April 2007.
- [19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work in Progress, April 2007.
- [20] Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) File", RFC 4180, October 2005.
Authors' Addresses 🖊️
Roman Danyliw CERT - Software Engineering Institute Pittsburgh, PA USA
EMail: rdd@cert.org
Jan Meijer
EMail: jan@flyingcloggies.nl
Yuri Demchenko University of Amsterdam Amsterdam Netherlands
EMail: demch@chello.nl
Full Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 💜
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5070 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms