]>
JSON binding of IODEFNICT4-2-1 Nukui-KitamachiKoganeiTokyo184-8795Japan+81 42 327 5862takeshi_takahashi@nict.go.jpNICT4-2-1 Nukui-KitamachiKoganeiTokyo184-8795Japanmio@nict.go.jpSecurity
MILEJSON, IODEFRFC 7970 provides XML-based data representation on incident information, but the use of the IODEF data model is not limited to XML. JSON representation is sometimes preferred since it is easy to handle from certain programming environments. This draft represents the IODEF data model in JSON.RFC 7970 defines an data model for sharing incident information. It facilitates automated exchange of information among parties over networks. The data model can be implemented in a form of XML, but it is not always suitable for implementation. JSON-based representation is often useful.Therefore, in this document, we provide a means to represent IODEF data model in JSON.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 RFC 2119. The IODEF Data Types, defined in RFC 7970are used for the JSON IODEF, with some syntax changes for some of the types.An integer is represented in the information model by the INTEGER data type. Integer data MUST be encoded in Base 10, and is implemented as an "integer" type per JSON schema.A real (floating-point) number is represented in the information model by the REAL data type. Real data MUST be encoded in Base 10, and is implemented in the data model as an "number" type per JSON schema.A single character is represented in the information model by the CHARACTER data type. A string is represented by the STRING data type. Special characters MUST be encoded using entity references.The CHARACTER and STRING data types are implemented in the data model as an "string" type per JSON schema.A string that needs to be represented in a human-readable language different than the default encoding of the document is represented in the information model by the ML_STRING data type. This data type is implemented as an object with "value", "lang", and "translation-id" elements as defined in . Examples are shown below.A binary octet encoded with base64 is represented in the information model by the BYTE data type. A sequence of these octets is of the BYTE[] data type. The BYTE and BYTE[] data types are implemented in the data model as an "string" type per JSON schema.A binary octet encoded as a character tuple consistent of two hexadecimal digits is represented in the information model by the HEXBIN data type. A sequence of these octets is of the HEXBIN[] data type. The HEXBIN and HEXBIN[] data types are implemented in the data model as an "string" type per JSON schema.An enumerated type is represented in the information model by the ENUM data type. It is an ordered list of acceptable string values. Each value has a representative keyword. The ENUM data type is implemented in the data model as values of an enum array per JSON schema.A date-time string that describes a particular instant in time is represented in the information model by the DATETIME data type. Ranges are not supported. The DATETIME data type is implemented in the data model as an "string" type per JSON schema.A timezone offset from UTC is represented in the information model by the TIMEZONE data type. It is formatted according to the following regular expression: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]". The TIMEZONE data type is implemented in the data model as an "string" type per JSON schema.A list of network ports is represented in the information model by the PORTLIST data type. A PORTLIST consists of a comma-separated list of numbers and ranges (N-M means ports N through M, inclusive). It is formatted according to the following regular expression: "\d+(\-\d+)?(,\d+(\-\d+)?)*". For example, "2,5-15,30,32,40-50,55-60". The PORTLIST data type is implemented in the data model as an "string" type per JSON schemaA postal address is represented in the information model by the POSTAL data type. The format of the POSTAL data type is documented in Section 2.23 of [RFC4519] as a free-form multi-line string separated by the "$" character. The POSTAL data type is implemented in the data model as the aforementioned ML_STRING type.A telephone number is represented in the information model by the PHONE data type. The format of the PHONE data type is documented in [E.164]. The PHONE data type is implemented in the data model as an "string" type per JSON schema.An email address is represented in the information model by the EMAIL data type. The format of the EMAIL data type is documented in Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531]. The EMAIL data type is implemented in the data model as an "string" type per JSON schema.A uniform resource locator (URL) is represented in the information model by the URL data type. The format of the URL data type is documented in [RFC3986].The URL data type is implemented as an "string" type per JSON schema.An identifier unique to the IODEF document is represented in the information model by the ID data type. A reference to this identifier is represented by the IDREF data type. These data types are implemented in the model as an "string" type per JSON schema.A particular version of software is represented in the information model by the SOFTWARE data type. This software can be described by using a reference, a URL, or with free-form text. The SOFTWARE data type is implemented as an object with "SoftwareReference", "URL", and "Description" elements as defined in . Examples are shown below.Information provided in a form of structured string, such as 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 RFC7203. The StructuredInfo data type is implemented as an object with "SpecID", "ext-SpecID", "ContentID", "RawData", "Reference" elements. An example for embedding a structured ID is shown below.When embedding the raw data, base64 conversion should be used for encoding the data, as shown below.>>", //STRING
}
]]> The data model of IODEF is defined in RFC 7970, and this section illustrates their representations in JSON. Note that the complete JSON schema is defined in .This class is the top level class in the IODEF data model. Its class elements and an example are shown below. See Section 3.1 of RFC 7970 for the intended meanings of these elements.Class elements:version, lang?, format-id?, private-enum-name?, private-enum-id?, Incident+, AdditionalData*Example:The Incident class describes commonly exchanged information when reporting or sharing derived analysis from security incidents.
Its class elements and an example are shown below. See Section 3.2 of RFC 7970 for the intended meanings of these elements.Class elements:purpose, ext-purpose?, status?, ext-status?, lang?, restriction?, ext-restriction?, observable-id?, IncidentID, AlternativeID?, RelatedActivity*, DetectTime?, StartTime?, EndTime?, RecoveryTime?, ReportTime?, GenrationTime?, Description*, Discovery*, Assessment*, Method*, Contact+, EventData*, IndicatorData?, History?, AdditionalData*Example:There are a number of recurring attributes used in the information model. They are documented in this section.RFC 7970 defines the restriction Attribute as one of common attributes. It is defined as below:Note that you must use "ext-restriction" field (STRING type) when the value of "restriction" field is set to "ext-value".RFC 7970 defines the observable-id attribute as one of common attributes.
The value of this attribute is a unique identifier, in string type, in the scope of the document.It is defined as below:The class elements and an example are shown below. See Section 3.4 of RFC 7970 for the intended meanings of these elements.Class elements:id, name, instance?, restriction?, ext-restriction?Example:The class elements and an example are shown below. See Section 3.5 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, IncidentID+Example:>>] //IncidentID
}
]]>The class elements and an example are shown below. See Section 3.6 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, IncidentID*, URL*, ThreatActor*, Campaign*, IndicatorID*, Confidence?, Description*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.7 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, ThreatActorID*, URL*, Description*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.8 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, CampaignID*, URL*, Description*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.9 of RFC 7970 for the intended meanings of these elements.Class elements:role, ext-role?, type, ext-type?, restriction?, ext-restriction?, ContactName*, ContactTitle*, Description*, RegistryHandle*, PostalAddress*, Email*, Telephone*, Timezone?, Contact*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.9.1 of RFC 7970 for the intended meanings of these elements.Class elements:handle, registry, ext-registry?Example:The class elements and an example are shown below. See Section 3.9.2 of RFC 7970 for the intended meanings of these elements.Class elements:type?, ext-type?, PAddress, Description*Example:The class elements and an example are shown below. See Section 3.9.3 of RFC 7970 for the intended meanings of these elements.Class elements:type?, ext-type?, EmailTo, Description*Example:The class elements and an example are shown below. See Section 3.9.4 of RFC 7970 for the intended meanings of these elements.Class elements:type?, ext-type?, TelephoneNumber, Description*Example:The class elements and an example are shown below. See Section 3.10 of RFC 7970 for the intended meanings of these elements.Class elements:source?, ext-source?, restriction?, ext-restriction?, Description*, Contact*, DetectionPattern*Example:The class elements and an example are shown below. See Section 3.10.1 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, observable-id?, Application, Description*, DetectionConfiguration*Example:The class elements and an example are shown below. See Section 3.11 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, Reference*, Description*, AttackPattern*, Vulnerability*, Weakness*Example:The class elements and an example are shown below. See Section 3.11.1 of RFC 7970 for the intended meanings of these elements.Class elements:observable-id?, ReferenceName?, URL*, Description*Example:The class elements and an example are shown below. See Section 3.12 of RFC 7970 for the intended meanings of these elements.Class elements:occurence?, restriction?, ext-restriction?, observable-id?, IncidentCategory*, SystemImpact*, BusinessImpact*, TimeImpact*, MonetaryImpact*, IntendedImpact*, Counter*, MitigationFactor*, Cause*, Confidence?, AdditionalData*Example:The class elements and an example are shown below. See Section 3.12.1 of RFC 7970 for the intended meanings of these elements.Class elements:severity?, completion?, type, ext-type?, Description*Example:The class elements and an example are shown below. See Section 3.12.2 of RFC 7970 for the intended meanings of these elements.Class elements:severity?, ext-severity?, type, ext-type?, Description*Example:The class elements and an example are shown below. See Section 3.12.3 of RFC 7970 for the intended meanings of these elements.Class elements:value, severity?, metric, ext-metric?, duration?, ext-duration?Example:The class elements and an example are shown below. See Section 3.12.4 of RFC 7970 for the intended meanings of these elements.Class elements:value, severity?, currency?Example:The class elements and an example are shown below. See Section 3.12.5 of RFC 7970 for the intended meanings of these elements.Class elements:value, rating, ext-rating?Example:The class elements and an example are shown below. See Section 3.13 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, HistoryItem+Example:The class elements and an example are shown below. See Section 3.13.1 of RFC 7970 for the intended meanings of these elements.Class elements:action, ext-action?, restriction?, ext-restriction?, observable-id?, DateTime, IncidentID?, Contact?, Description*, DefinedCOA*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.14 of RFC 7970 for the intended meanings of these elements.Class elements:restriction?, ext-restriction?, observable-id?, Description*, DetectTime?, StartTime?, EndTime?, RecoveryTime?, ReportTime?, Contact*, Discovery*, Assessment?, Method*, Flow*, Expectation*, Record?, EventData*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.15 of RFC 7970 for the intended meanings of these elements.Class elements:action?, ext-action?, severity?, restriction?, ext-restriction?, Description*, DefinedCOA*, StartTime?, EndTime?, Contact?Example:The class elements and an example are shown below. See Section 3.17 of RFC 7970 for the intended meanings of these elements.Class elements:category?, ext-category?, interface?, spoofed?, virtual?, ownership?, ext-ownership?, restriction?, ext-restriction?, Node, NodeRole*, Service*, OperatingSystem*, Counter*, AssetID*, Description*, AdditionalData*Example:The class elements and an example are shown below. See Section 3.18 of RFC 7970 for the intended meanings of these elements.Class elements:DomainData*, Address*, PostalAddress?, Location*, Counter*Example:The class elements and an example are shown below. See Section 3.18.1 of RFC 7970 for the intended meanings of these elements.Class elements:value, category, ext-category?, vlan-name?, vlan-num?, observable-id?Example:The class elements and an example are shown below. See Section 3.18.2 of RFC 7970 for the intended meanings of these elements.Class elements:category, ext-category?, Description*Example:The class elements and an example are shown below. See Section 3.18.3 of RFC 7970 for the intended meanings of these elements.Class elements:value, type, ext-type?, unit, ext-unit?, meaning?, duration?, ext-duration?Example:The class elements and an example are shown below. See Section 3.19 of RFC 7970 for the intended meanings of these elements.Class elements:system-status, ext-system-status?, domain-status, ext-domain-status?, observable-id?, Name, DateDomainWasChecked?, RegistrationDate?, ExpirationDate?, RelatedDNS*, Nameservers*, DomainContacts?Example:
This class is defined in Section 3.19.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:Server, Address*Example:
This class is defined in Section 3.19.2 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:SameDomainContact?, Contact+Example:
This class is defined in Section 3.20 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:ip-protocol?, observable-id?, ServiceName?, Port?, Portlist?, ProtoCode?, ProtoType?, ProtoField?, ApplicationHeader?, EmailData?, Application?Example:
This class is defined in Section 3.20.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:IANAService?, URL*, Description*Example:
This class is defined in Section 3.20.2 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:ApplicationHeaderField+Example:
This class is defined in Section 3.21 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:observable-id?, EmailTo*, EmailFrom?, EmailSubject?, EmailX-Mailer?, EmailHeaderField*, EmailHeaders?, EmailBody?, EmailMessage?, HashData*, SignatureData*Example:
This class is defined in Section 3.22 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, RecordData+Example:
This class is defined in Section 3.22.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, observable-id?, DateTime?, Description*, Application?, RecordPattern*, RecordItem*, URL*, FileData*, WindowsRegistryKeysModified*, CertificateData*, AdditionalData*Example:
This class is defined in Section 3.22.2 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:type, ext-type?, offset?, offsetunit?, ext-offsetunit?, instance?, valueExample:
This class is defined in Section 3.23 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:observable-id?, Key+Example:
This class is defined in Section 3.23.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:registryaction?, ext-registryaction?, observable-id?, KeyName, KeyValue?Example:
This class is defined in Section 3.24 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, observable-id?, Certificate+Example:
This class is defined in Section 3.24.1 of RFC 7970.
The X509Data class contains base64 encoded form of X.509 certificate or chain as
described in Section 4.4.4 of [W3C.XMLSIG].
The example below represents how to describe this class in JSON.
Class elements:observable-id?, X509Data, Description*Example:
This class is defined in Section 3.25 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, observable-id?, File+Example:
This class is defined in Section 3.25.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:observable-id?, FileName?, FileSize?, FileType?, URL*, HashData?, SignatureData?, AssociatedSoftware?, FileProperties*Example:
This class is defined in Section 3.26 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:scope, HashTargetID?, Hash*, FuzzyHash*Example:
This class is defined in Section 3.26.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:DigestMethod, DigestValue, CanonicalizationMethod?, Application?Example:
This class is defined in Section 3.26.2 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:FuzzyHashValue+, Application?, AdditionalData?Example:
This class is defined in Section 3.27 of RFC 7970.
The Signature class contains base64 encoded form of signature as
described in Section 4.2 of [W3C.XMLSIG].
The example below represents how to describe this class in JSON.
Class elements:Signature+Example:
This class is defined in Section 3.29 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, IndicatorID, AlternativeIndicatorID*, Description*, StartTime?, EndTime?, Confidence?, Contact*, Observable?, ObservableReference?, IndicatorExpression?, IndicatorReference?, NodeRole*, AttackPhase*, Reference*, AdditionalData*Example:
This class is defined in Section 3.29.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:id, name, versionExample:
This class is defined in Section 3.29.2 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, IndicatorReference+Example:
This class is defined in Section 3.29.3 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:restriction?, ext-restriction?, System?, Address?, DomainData?, Service?, EmailData?, WindowsRegistryKeysModified?, FileData?, CertificateData?, RegistryHandle?, RecordData?, EventData?, Incident?, Expectation?, Reference?, Assessment?, DetectionPattern?, HistoryItem?, BulkObservable?, AdditionalData*Example:
This class is defined in Section 3.29.3.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:type?, ext-type?, BulkObservableFormat?, BulkObservableList, AdditionalData*Example:
This class is defined in Section 3.29.3.1.1 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:Hash?, AdditionalData*Example:
This class is defined in Section 3.29.4 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:operator?, ext-operator?, IndicatorExpression*, Observable*, ObservableReference*, IndicatorReference*, Confidence?, AdditionalData*Example:
This class is defined in Section 3.29.6 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:uid-refExample:
This class is defined in Section 3.29.7 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:uid-ref?, euid-ref?, version?Example:
This class is defined in Section 3.29.8 of RFC 7970.
The example below represents how to describe this class in JSON.
Class elements:AttackPhaseID*, URL*, Description*, AdditionalData*Example:This document treats attributes and elements of each class defined in RFC 7970 equally and is agnostic on the order of their appearances.Flow class is deleted, and EventData class now has the instance of System class.Record class is deleted, and the link to the Record class are directly connected to RecordData class, which is then renamed to Record class.
This section provides example of IODEF documents. These examples do
not represent the full capabilities of the data model or the the only
way to encode particular information.
A document containing only the mandatory elements and attributes.
An example of C2 domains from a given campaign.TBD.This memo includes no request to IANA.This memo does not provide any further security considerations than the one described in RFC 7970.
&RFC2119;
&RFC7970;
JSON Schemahttp://json-schema.org/
&RFC2629;
&RFC3552;
&RFC5226;
Ultimate Plan for Taking Over the WorldMad Dominators, Inc.