RFC 8727 | JSON-IODEF | August 2020 |
Takahashi, et al. | Standards Track | [Page] |
The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8727.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
The Incident Object Description Exchange Format (IODEF) [RFC7970] defines a data representation for security incident reports and indicators commonly exchanged by operational security teams. It facilitates the automated exchange of this information to enable mitigation and watch-and-warning. An information model using Unified Modeling Language (UML) is defined in Section 3 of [RFC7970] and a corresponding Extensible Markup Language (XML) schema data model is defined in Section 8 of [RFC7970]. This UML-based information model and XML-based data model are referred to as IODEF UML and IODEF XML, respectively, in this document.¶
IODEF documents are structured and thus suitable for machine processing. They will streamline incident response operations. Another well-used and structured format that is suitable for machine processing is JavaScript Object Notation (JSON) [RFC8259]. To facilitate the automation of incident response operations, IODEF documents and implementations should support JSON representation and its encoding in Concise Binary Object Representation (CBOR) [RFC7049].¶
This document defines an alternate implementation of the IODEF UML information model by specifying a JSON data model using Concise Data Definition Language (CDDL) [RFC8610] and a JSON Schema [JSON-SCHEMA]. This JSON data model is referred to as IODEF JSON in this document. IODEF JSON provides all of the expressivity of IODEF XML. It gives implementers and operators an alternative format to exchange the same information.¶
The normative IODEF JSON data model is found in Section 6. Sections 2 and 3 describe the data types and elements of this data model. Section 4 provides examples.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
IODEF JSON implements the abstract data types specified in Section 2 of [RFC7970].¶
IODEF JSON uses native and derived JSON data types. Table 1 describes the mapping between the abstract data types in Section 2 of [RFC7970] and their corresponding implementations in IODEF JSON.¶
IODEF Data Type | Reference | JSON Data Type |
---|---|---|
INTEGER | Section 2.1 of [RFC7970] | integer; see Section 2.2.1 |
REAL | Section 2.2 of [RFC7970] | "number" per [RFC8259] |
CHARACTER | Section 2.3 of [RFC7970] | "string" per [RFC8259] |
STRING | Section 2.3 of [RFC7970] | "string" per [RFC8259] |
ML_STRING | Section 2.4 of [RFC7970] | see Section 2.2.2 |
BYTE | Section 2.5.1 of [RFC7970] | "string" per [RFC8259] |
BYTE[] | Section 2.5.1 of [RFC7970] | "string" per [RFC8259] |
HEXBIN | Section 2.5.2 of [RFC7970] | "string" per [RFC8259] |
HEXBIN[] | Section 2.5.2 of [RFC7970] | "string" per [RFC8259] |
ENUM | Section 2.6 of [RFC7970] | see Section 2.2.3 |
DATETIME | Section 2.7 of [RFC7970] | "string" per [RFC8259] |
TIMEZONE | Section 2.8 of [RFC7970] | "string" per [RFC8259] |
PORTLIST | Section 2.9 of [RFC7970] | "string" per [RFC8259] |
POSTAL | Section 2.10 of [RFC7970] | ML_STRING; see Section 2.2.2 |
PHONE | Section 2.11 of [RFC7970] | "string" per [RFC8259] |
Section 2.12 of [RFC7970] | "string" per [RFC8259] | |
URL | Section 2.13 of [RFC7970] | "string" per [RFC8259] |
ID | Section 2.14 of [RFC7970] | "string" per [RFC8259] |
IDREF | Section 2.14 of [RFC7970] | "string" per [RFC8259] |
SOFTWARE | Section 2.15 of [RFC7970] | see Section 2.2.4 |
STRUCTUREDINFO | Section 4.4 of [RFC7203] | see Section 2.2.5 |
EXTENSION | Section 2.16 of [RFC7970] | see Section 2.2.6 |
IODEF Data Type | CBOR Data Type | CDDL Prelude [RFC8610] |
---|---|---|
INTEGER | 0, 1, 6 tag 2, 6 tag 3 | integer |
REAL | 7 bits 26 | float32 |
CHARACTER | 3 | text |
STRING | 3 | text |
ML_STRING | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
BYTE | 6 tag 22 | eb64legacy |
BYTE[] | 6 tag 22 | eb64legacy |
HEXBIN | 6 tag 23 | eb16 |
HEXBIN[] | 6 tag 23 | eb16 |
ENUM | - | Choices (Section 2.2.2 of [RFC8610]) |
DATETIME | 6 tag 0 | tdate |
TIMEZONE | 3 | text |
PORTLIST | 3 | text |
POSTAL | 3 | ML_STRING (Section 2.2.2) |
PHONE | 3 | text |
3 | text | |
URL | 6 tag 32 | uri |
ID | 3 | text |
IDREF | 3 | text |
SOFTWARE | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
STRUCTUREDINFO | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
EXTENSION | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
An integer is a subset of the "number" type of JSON, which represents signed digits encoded in Base 10. The definition of this integer is "[ minus ] int" per [RFC8259], Section 6.¶
A string that needs to be represented in a human-readable language different from the default encoding of the document is represented in the information model by the ML_STRING data type. This data type is implemented as either an object with "value", "lang", and "translation-id" elements or a text string as defined in Section 6. An example is shown below.¶
"MLStringType": { "value": "free-form text", # STRING "lang": "en", # ENUM "translation-id": "jp2en0023" # STRING }¶
Note that in figures throughout this document, some supplementary information follows "#", but these are not valid syntax in JSON; instead, they are intended to facilitate reader understanding.¶
Enum is an ordered list of acceptable string values. Each value has a representative keyword. Within the data model, the enumerated type keywords are used as attribute values.¶
A particular version of software is represented in the information model by the SOFTWARE data type. This software can be described by using a reference, a Uniform Resource Locator (URL) [RFC3986], or free-form text. The SOFTWARE data type is implemented as an object with "SoftwareReference", "URL", and "Description" elements as defined in Section 6. Examples are shown below.¶
"SoftwareType": { "SoftwareReference": {...}, # SoftwareReference "Description": ["MS Windows"] # STRING }¶
SoftwareReference class is a reference to a particular version of software. Examples are shown below.¶
"SoftwareReference": { "value": "cpe:/a:google:chrome:59.0.3071.115", # STRING "spec-name": "cpe", # ENUM "dtype": "string" # ENUM }¶
Information provided in the form of a structured string, such as an ID, or structured information, such as XML documents, is represented in the information model by the STRUCTUREDINFO data type. Note that this type was originally specified in Section 4.4 of [RFC7203] as a basic structure of its extension classes. The STRUCTUREDINFO data type is implemented as an object with "SpecID", "ext-SpecID", "ContentID", "RawData", and "Reference" elements. An example for embedding a structured ID is shown below.¶
"STRUCTUREDINFO": { "SpecID": "urn:ietf:params:xml:ns:mile:cwe:3.3", # ENUM "ContentID": "CWE-89" # STRING }¶
When embedding the raw data, it should be encoded as a BYTE type object, as shown below.¶
"STRUCTUREDINFO": { "SpecID": "urn:ietf:params:xml:ns:mile:mmdef:1.2", # ENUM "RawData": "<<< encoded structured data >>>" # BYTE }¶
When embedding the raw data, base64 encoding defined in Section 4 of [RFC4648] MUST be used for JSON IODEF while binary representation MUST be used for CBOR IODEF.¶
Information not otherwise represented in the IODEF can be added using the EXTENSION data type. This data type is a generic extension mechanism. The EXTENSION data type is implemented as an ExtensionType object with "value", "name", "dtype", "ext-dtype", "meaning", "formatid", "restriction", "ext-restriction", and "observable-id" elements. An example for embedding a structured ID is shown below.¶
"ExtensionType": { "value": "xxxxxxx", # STRING "name": "Syslog", # STRING "dtype": "string", # ENUM "meaning": "Syslog from the security appliance X" # STRING }¶
Note that this data type is specified in [RFC7970] as its generic extension mechanism. If a data item has internal structure that is intended to be processed outside of the IODEF framework, one may consider using the STRUCTUREDINFO data type mentioned in Section 2.2.5.¶
The following table shows the list of IODEF classes and their elements and the corresponding sections in [RFC7970]. Note that the complete JSON schema is defined in Section 6 using CDDL.¶
IODEF Class | Class, Element, and Attribute | Section in [RFC7970] |
---|---|---|
IODEF-Document | 3.1 | |
Incident |
|
3.2 |
IncidentID | 3.4 | |
AlternativeID | 3.5 | |
RelatedActivity | 3.6 | |
ThreatActor | 3.7 | |
Campaign | 3.8 | |
Contact | 3.9 | |
RegistryHandle | 3.9.1 | |
PostalAddress | 3.9.2 | |
3.9.3 | ||
Telephone | 3.9.4 | |
Discovery | 3.10 | |
DetectionPattern | 3.10.1 | |
Method | 3.11 | |
Weakness | 4.5.5 in [RFC7203] | |
Reference | 3.11.1 | |
Assessment | 3.12 | |
SystemImpact | 3.12.1 | |
BusinessImpact | 3.12.2 | |
TimeImpact | 3.12.3 | |
MonetaryImpact | 3.12.4 | |
Confidence | 3.12.5 | |
History | 3.13 | |
HistoryItem | 3.13.1 | |
EventData | 3.14 | |
Expectation | 3.15 | |
System | 3.17 | |
Node | 3.18 | |
Address | 3.18.1 | |
NodeRole | 3.18.2 | |
Counter | 3.18.3 | |
DomainData | 3.19 | |
Nameservers | 3.19.1 | |
DomainContacts | 3.19.2 | |
Service | 3.20 | |
ServiceName | 3.20.1 | |
EmailData | 3.21 | |
RecordData | 3.22.1 | |
RecordPattern | 3.22.2 | |
WindowsRegistryKeysModified | 3.23 | |
Key | 3.23.1 | |
CertificateData | 3.24 | |
Certificate | 3.24.1 | |
FileData | 3.25 | |
File | 3.25.1 | |
HashData | 3.26 | |
Hash | 3.26.1 | |
FuzzyHash | 3.26.2 | |
Indicator | 3.29 | |
IndicatorID | 3.29.1 | |
AlternativeIndicatorID | 3.29.2 | |
Observable |
|
3.29.3 |
BulkObservable | 3.29.3.1 | |
BulkObservableFormat | 3.29.3.1.1 | |
IndicatorExpression | 3.29.4 | |
IndicatorReference | 3.29.7 | |
AttackPhase | 3.29.8 |
This section provides examples of IODEF documents. These examples do not represent the full capabilities of the data model or the only way to encode particular information.¶
A document containing only the mandatory elements and attributes is shown below in JSON and CBOR, respectively.¶
An example of C2 domains from a given campaign is shown below in JSON and CBOR, respectively.¶
The mapkeys are provided in Table 4 for minimizing the CBOR size.¶
mapkey | cborkey |
---|---|
iodef-version | -24 |
iodef-lang | -23 |
iodef-format-id | -22 |
iodef-private-enum-name | -21 |
iodef-private-enum-id | -20 |
iodef-Incident | -19 |
iodef-AdditionalData | -18 |
iodef-value | -17 |
iodef-translation-id | -16 |
iodef-name | -15 |
iodef-dtype | -14 |
iodef-ext-dtype | -13 |
iodef-meaning | -12 |
iodef-formatid | -11 |
iodef-restriction | -10 |
iodef-ext-restriction | -9 |
iodef-observable-id | -8 |
iodef-SoftwareReference | -7 |
iodef-URL | -6 |
iodef-Description | -5 |
iodef-spec-name | -4 |
iodef-ext-spec-name | -3 |
iodef-purpose | -2 |
iodef-ext-purpose | -1 |
iodef-status | 0 |
iodef-ext-status | 1 |
iodef-IncidentID | 2 |
iodef-AlternativeID | 3 |
iodef-RelatedActivity | 4 |
iodef-DetectTime | 5 |
iodef-StartTime | 6 |
iodef-EndTime | 7 |
iodef-RecoveryTime | 8 |
iodef-ReportTime | 9 |
iodef-GenerationTime | 10 |
iodef-Discovery | 11 |
iodef-Assessment | 12 |
iodef-Method | 13 |
iodef-Contact | 14 |
iodef-EventData | 15 |
iodef-Indicator | 16 |
iodef-History | 17 |
iodef-id | 18 |
iodef-instance | 19 |
iodef-ThreatActor | 20 |
iodef-Campaign | 21 |
iodef-IndicatorID | 22 |
iodef-Confidence | 23 |
iodef-ThreatActorID | 24 |
iodef-CampaignID | 25 |
iodef-role | 26 |
iodef-ext-role | 27 |
iodef-type | 28 |
iodef-ext-type | 29 |
iodef-ContactName | 30 |
iodef-ContactTitle | 31 |
iodef-RegistryHandle | 32 |
iodef-PostalAddress | 33 |
iodef-Email | 34 |
iodef-Telephone | 35 |
iodef-Timezone | 36 |
iodef-handle | 37 |
iodef-registry | 38 |
iodef-ext-registry | 39 |
iodef-PAddress | 40 |
iodef-EmailTo | 41 |
iodef-TelephoneNumber | 42 |
iodef-source | 43 |
iodef-ext-source | 44 |
iodef-DetectionPattern | 45 |
iodef-DetectionConfiguration | 46 |
iodef-Application | 47 |
iodef-Reference | 48 |
iodef-AttackPattern | 49 |
iodef-Vulnerability | 50 |
iodef-Weakness | 51 |
iodef-SpecID | 52 |
iodef-ext-SpecID | 53 |
iodef-ContentID | 54 |
iodef-RawData | 55 |
iodef-Platform | 56 |
iodef-Scoring | 57 |
iodef-ReferenceName | 58 |
iodef-specIndex | 59 |
iodef-ID | 60 |
iodef-occurrence | 61 |
iodef-IncidentCategory | 62 |
iodef-Impact | 63 |
iodef-SystemImpact | 64 |
iodef-BusinessImpact | 65 |
iodef-TimeImpact | 66 |
iodef-MonetaryImpact | 67 |
iodef-IntendedImpact | 68 |
iodef-Counter | 69 |
iodef-MitigatingFactor | 70 |
iodef-Cause | 71 |
iodef-severity | 72 |
iodef-completion | 73 |
iodef-ext-severity | 74 |
iodef-metric | 75 |
iodef-ext-metric | 76 |
iodef-duration | 77 |
iodef-ext-duration | 78 |
iodef-currency | 79 |
iodef-rating | 80 |
iodef-ext-rating | 81 |
iodef-HistoryItem | 82 |
iodef-action | 83 |
iodef-ext-action | 84 |
iodef-DateTime | 85 |
iodef-DefinedCOA | 86 |
iodef-System | 87 |
iodef-Expectation | 88 |
iodef-RecordData | 89 |
iodef-category | 90 |
iodef-ext-category | 91 |
iodef-interface | 92 |
iodef-spoofed | 93 |
iodef-virtual | 94 |
iodef-ownership | 95 |
iodef-ext-ownership | 96 |
iodef-Node | 97 |
iodef-NodeRole | 98 |
iodef-Service | 99 |
iodef-OperatingSystem | 100 |
iodef-AssetID | 101 |
iodef-DomainData | 102 |
iodef-Address | 103 |
iodef-Location | 104 |
iodef-vlan-name | 105 |
iodef-vlan-num | 106 |
iodef-unit | 107 |
iodef-ext-unit | 108 |
iodef-system-status | 109 |
iodef-ext-system-status | 110 |
iodef-domain-status | 111 |
iodef-ext-domain-status | 112 |
iodef-Name | 113 |
iodef-DateDomainWasChecked | 114 |
iodef-RegistrationDate | 115 |
iodef-ExpirationDate | 116 |
iodef-RelatedDNS | 117 |
iodef-NameServers | 118 |
iodef-DomainContacts | 119 |
iodef-Server | 120 |
iodef-SameDomainContact | 121 |
iodef-ip-protocol | 122 |
iodef-ServiceName | 123 |
iodef-Port | 124 |
iodef-Portlist | 125 |
iodef-ProtoCode | 126 |
iodef-ProtoType | 127 |
iodef-ProtoField | 128 |
iodef-ApplicationHeaderField | 129 |
iodef-EmailData | 130 |
iodef-IANAService | 131 |
iodef-EmailFrom | 132 |
iodef-EmailSubject | 133 |
iodef-EmailX-Mailer | 134 |
iodef-EmailHeaderField | 135 |
iodef-EmailHeaders | 136 |
iodef-EmailBody | 137 |
iodef-EmailMessage | 138 |
iodef-HashData | 139 |
iodef-Signature | 140 |
iodef-RecordPattern | 141 |
iodef-RecordItem | 142 |
iodef-FileData | 143 |
iodef-WindowsRegistryKeysModified | 144 |
iodef-CertificateData | 145 |
iodef-offset | 146 |
iodef-offsetunit | 147 |
iodef-ext-offsetunit | 148 |
iodef-Key | 149 |
iodef-registryaction | 150 |
iodef-ext-registryaction | 151 |
iodef-KeyName | 152 |
iodef-KeyValue | 153 |
iodef-Certificate | 154 |
iodef-X509Data | 155 |
iodef-File | 156 |
iodef-FileName | 157 |
iodef-FileSize | 158 |
iodef-FileType | 159 |
iodef-AssociatedSoftware | 160 |
iodef-FileProperties | 161 |
iodef-scope | 162 |
iodef-HashTargetID | 163 |
iodef-Hash | 164 |
iodef-FuzzyHash | 165 |
iodef-DigestMethod | 166 |
iodef-DigestValue | 167 |
iodef-CanonicalizationMethod | 168 |
iodef-FuzzyHashValue | 169 |
iodef-AlternativeIndicatorID | 170 |
iodef-Observable | 171 |
iodef-uid-ref | 172 |
iodef-IndicatorExpression | 173 |
iodef-IndicatorReference | 174 |
iodef-AttackPhase | 175 |
iodef-BulkObservable | 176 |
iodef-BulkObservableFormat | 177 |
iodef-BulkObservableList | 178 |
iodef-operator | 179 |
iodef-ext-operator | 180 |
iodef-euid-ref | 181 |
iodef-AttackPhaseID | 182 |
This section provides the IODEF data model. Note that mapkeys are described at the beginning of the CDDL data model for better readability.¶
This document has no IANA actions.¶
This document provides a mapping from XML IODEF defined in [RFC7970] to JSON, and Section 3.2 describes several issues that arise when converting XML IODEF and JSON IODEF. Though it does not provide any further security considerations other than the one described in [RFC7970], implementers of this document should be aware of those issues to avoid any unintended outcome.¶
The CDDL prelude used in this document is mapped to JSON as shown in the table below.¶
CDDL Prelude | Use of JSON | Instance | Validation |
---|---|---|---|
bytes | n/a | string | tool available |
text | string | string | unnecessary |
tdate | n/a | string | date-time per Section 7.3.1 of [JSON-SCHEMA] |
integer | n/a | number | integer |
eb64legacy | n/a | string | tool available |
uri | n/a | string | uri per Section 7.3.6 of [JSON-SCHEMA] |
float32 | float32 | number | unnecessary |
This section provides a JSON schema [JSON-SCHEMA] that defines the IODEF data model defined in this document. Note that this section is informative.¶
We would like to thank Henk Birkholz, Carsten Bormann, Benjamin Kaduk, Alexey Melnikov, Yasuaki Morita, and Takahiko Nagata for their insightful comments on this document and CDDL.¶