<pre>Internet Engineering Task Force (IETF)                     P. Kampanakis
Request for Comments: 8274                                 Cisco Systems
Category: Informational                                        M. Suzuki
ISSN: 2070-1721                                                     NICT
                                                           November 2017


       <span class="h1">Incident Object Description Exchange Format Usage Guidance</span>

Abstract

   The Incident Object Description Exchange Format (IODEF) v2 (<a href="./rfc7970">RFC 7970</a>)
   defines a data representation that provides a framework for sharing
   information about computer security incidents commonly exchanged by
   Computer Security Incident Response Teams (CSIRTs).  Since the IODEF
   model includes a wealth of available options that can be used to
   describe a security incident or issue, it can be challenging for
   security practitioners to develop tools that leverage IODEF for
   incident sharing.  This document provides guidelines for IODEF
   implementers.  It addresses how common security indicators can be
   represented in IODEF and provides use cases of how IODEF is being
   used.  This document aims to make IODEF's adoption by vendors easier
   and to encourage faster and wider adoption of the model by CSIRTs
   around the world.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   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).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc8274">https://www.rfc-editor.org/info/rfc8274</a>.











<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.

Table of Contents

   <a href="#section-1">1</a>.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-3">3</a>.  Implementation and Use Strategy . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
     <a href="#section-3.1">3.1</a>.  Minimal IODEF Document  . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
     <a href="#section-3.2">3.2</a>.  Information Represented . . . . . . . . . . . . . . . . .   <a href="#page-4">4</a>
     <a href="#section-3.3">3.3</a>.  IODEF Classes . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
   <a href="#section-4">4</a>.  IODEF Usage Considerations  . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.1">4.1</a>.  External References . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.2">4.2</a>.  Extensions  . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-6">6</a>
     <a href="#section-4.3">4.3</a>.  Indicator Predicate Logic . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-4.4">4.4</a>.  Disclosure Level  . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
   <a href="#section-5">5</a>.  IODEF Uses  . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.1">5.1</a>.  Implementations . . . . . . . . . . . . . . . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.2">5.2</a>.  Inter-vendor and Service Provider Exercise  . . . . . . .   <a href="#page-8">8</a>
     <a href="#section-5.3">5.3</a>.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-6">6</a>.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-7">7</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-12">12</a>
   <a href="#section-8">8</a>.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-8.1">8.1</a>.  Normative References  . . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-8.2">8.2</a>.  Informative References  . . . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
   <a href="#appendix-A">Appendix A</a>.  Indicator Predicate Logic Examples . . . . . . . . .  <a href="#page-14">14</a>
   <a href="#appendix-B">Appendix B</a>.  Inter-vendor and Service Provider Exercise Examples   16
     <a href="#appendix-B.1">B.1</a>.  Malware Delivery URL  . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
     <a href="#appendix-B.2">B.2</a>.  DDoS  . . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
     <a href="#appendix-B.3">B.3</a>.  Spear Phishing  . . . . . . . . . . . . . . . . . . . . .  <a href="#page-20">20</a>
     <a href="#appendix-B.4">B.4</a>.  Malware . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-24">24</a>
     <a href="#appendix-B.5">B.5</a>.  IoT Malware . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-30">30</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-33">33</a>






<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Incident Object Description Exchange Format (IODEF) v2 [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>]
   defines a data representation that provides a framework for sharing
   computer security incident information commonly exchanged by Computer
   Security Incident Response Teams (CSIRTs).  The IODEF data model
   consists of multiple classes and data types that are defined in the
   IODEF XML schema.

   The IODEF schema was designed to describe all the possible fields
   needed in a security incident exchange.  Thus, IODEF contains a
   plethora of data constructs that could make it hard for IODEF
   implementers to decide which are important.  Additionally, in the
   IODEF schema, there exist multiple fields and classes that do not
   necessarily need to be used in every possible data exchange.
   Moreover, some IODEF classes are useful only in rare circumstances.
   This document tries to address these concerns.  It also presents how
   common security indicators can be represented in IODEF, it points out
   the most important IODEF classes for an implementer and describes
   other ones that are not as important, and it presents some common
   pitfalls for IODEF implementers and how to address them.  The end
   goal of this document is to make IODEF's use by vendors easier and to
   encourage wider adoption of the model by CSIRTs around the world.

   <a href="#section-3">Section 3</a> discusses the recommended classes and how an IODEF
   implementer should choose the classes to implement.  <a href="#section-4">Section 4</a>
   presents common considerations a practitioner will come across and
   how to address them.  <a href="#section-5">Section 5</a> goes over some common uses of IODEF.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   The terminology used in this document is defined in [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Implementation and Use Strategy</span>

   It is important for IODEF implementers to distinguish how the IODEF
   classes will be used in incident information exchanges.  It is also
   important to understand the most common IODEF classes that describe
   common security incidents or indicators.  This section describes the
   most important classes and factors an IODEF practitioner should take
   into consideration before using IODEF or designing an implementation.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Minimal IODEF Document</span>

   An IODEF document must include at least an Incident class, an
   xml:lang attribute that defines the supported language, and the IODEF
   version attribute.  An Incident must contain a purpose attribute and
   three mandatory-to-implement elements.  These elements are



<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   GenerationTime class (which describes the time of the incident), an
   IncidentID class, and at least one Contact class.  The structure of
   the minimal IODEF-Document class is shown in Figure 1.

+---------------+            +--------------+
|IODEF-Document |            | Incident     |
+---------------+            +--------------+           +--------------+
|STRING version |&lt;&gt;--{1..*}--| ENUM purpose |&lt;&gt;---------| IncidentID   |
|ENUM xml:lang  |            |              |           +--------------+
|               |            |              |           | STRING name  |
+---------------+            |              |           +--------------+
                             |              |
                             |              |&lt;&gt;---------[GenerationTime]
                             |              |
                             |              |           +--------------+
                             |              |&lt;&gt;-{1..*}--[ Contact      |
                             +--------------+           +--------------+
                                                        | ENUM role    |
                                                        | ENUM type    |
                                                        +--------------+

                  Figure 1: Minimal IODEF-Document Class

   The IncidentID class must contain at least a name attribute.

   In turn, the Contact class requires the type and role attributes, but
   no elements are required by the IODEF v2 specification.
   Nevertheless, at least one of the elements in the Contact class, such
   as an Email class, should be implemented so that the IODEF document
   is useful.

   <a href="./rfc7970#section-7.1">Section&nbsp;7.1 of [RFC7970]</a> presents a minimal IODEF document with only
   the mandatory classes and attributes.  Implementers can also refer to
   <a href="./rfc7970#section-7">Section&nbsp;7 of [RFC7970]</a> and <a href="#appendix-B">Appendix B</a> of this document for examples
   of documents that are IODEF v2.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Information Represented</span>

   There is no need for a practitioner to use or implement IODEF classes
   and fields other than the minimal ones (see <a href="#section-3.1">Section 3.1</a>) and the ones
   necessary for her use cases.  The implementer should carefully look
   into the schema and decide which classes to implement (or not).

   For example, if we have Distributed Denial of Service (DDoS) as a
   potential use case, then the Flow class and its included information
   are the most important classes to use.  The Flow class describes
   information related to the attacker and victim hosts, which could
   help automated filtering or sinkhole operations.



<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   Another potential use case is malware command and control (C2).
   After modern malware infects a device, it usually proceeds to connect
   to one or more C2 servers to receive instructions from its master and
   potentially exfiltrate information.  To protect against such
   activity, it is important to interrupt the C2 communication by
   filtering the activity.  IODEF can describe C2 activities using the
   Flow and the ServiceName classes.

   For use cases where indicators need to be described, the
   IndicatorData class will be implemented instead of the EventData
   class.

   In summary, an implementer should identify the use cases and find the
   classes that are necessary to support in IODEF v2.  Implementing and
   parsing all IODEF classes can be cumbersome, in some occasions, and
   unnecessary.  Other external schemata can also be used in IODEF to
   describe incidents or indicators.  External schemata should be parsed
   accordingly only if the implementer's IODEF use cases require
   external schema information.  But even when an IODEF implementation
   cannot parse an external schema, the IODEF report can still be
   valuable to an incident response team.  The information can also be
   useful when shared further with content consumers that are able to
   parse this information.

   IODEF supports multiple language translations of free-form, ML_STRING
   text in all classes [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].  That way, text in Description
   elements can be translated to different languages by using a
   translation identifier in the class.  Implementers should be able to
   parse iodef:MLStringType classes and extract only the information
   relevant to languages of interest.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  IODEF Classes</span>

   [<a id="ref-RFC7970">RFC7970</a>] contains classes that can describe attack Methods, Events,
   Incidents, Indicators, how they were discovered, and the Assessment
   of the repercussions for the victim.  It is important for IODEF users
   to know the distinction between these classes in order to decide
   which ones fulfill their use cases.

   An IndicatorData class depicts a threat indicator or observable that
   describe a threat that resulted in an attempted attack.  For example,
   we could see an attack happening (described in the IndicatorData),
   but it might have been prevented and not have resulted in an incident
   or security event.  On the other hand, an EventData class usually
   describes a security event and can be considered a report of
   something that took place.





<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   Classes like Discovery, Assessment, Method, and RecoveryTime are used
   in conjunction with EventData as they relate to the incident report
   described in the EventData.  The RelatedActivity class can reference
   an incident, an indicator, or other related threat activity.

   While deciding what classes are important for the needed use cases,
   IODEF users should carefully evaluate the necessary classes and how
   these are used in order to avoid unnecessary work.  For example, if
   we want to only describe indicators in IODEF, the implementation of
   Method or Assessment might not be important.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  IODEF Usage Considerations</span>

   Implementers need to consider some common, standardized options for
   their IODEF use strategy.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  External References</span>

   The IODEF format includes the Reference class used for externally
   defined information, such as a vulnerability, Intrusion Detection
   System (IDS) alert, malware sample, advisory, or attack technique.
   To facilitate the exchange of information, the Reference class was
   extended to the enumeration reference format [<a href="./rfc7495" title="&quot;Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)&quot;">RFC7495</a>].  The
   enumeration reference format specifies a means to use external
   enumeration specifications (e.g., Common Vulnerabilities and
   Exposures (CVE)) that could define an enumeration format, specific
   enumeration values, or both.  As external enumerations can vary
   greatly, implementers should only support the ones expected to
   describe their specific use cases.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Extensions</span>

   The IODEF data model [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>] is extensible.  Many attributes with
   enumerated values can be extended using the "ext-*" prefix.
   Additional classes can also be defined by using the AdditionalData
   and RecordItem classes.  An extension to the AdditionalData class for
   reporting phishing emails is defined in [<a href="./rfc5901" title="&quot;Extensions to the IODEF-Document Class for Reporting Phishing&quot;">RFC5901</a>].  Information about
   extending IODEF class attributes and enumerated values can be found
   in <a href="./rfc7970#section-5">Section&nbsp;5 of [RFC7970]</a>.

   Additionally, IODEF can import existing schemata by using an
   extension framework defined in [<a href="./rfc7203" title="&quot;An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information&quot;">RFC7203</a>].  The framework enables
   IODEF users to embed XML data inside an IODEF document using external
   schemata or structures defined by external specifications.  Examples
   include CVE, Common Vulnerability Reporting Framework (CVRF), and
   Open Vulnerability and Assessment Language (OVAL).  [<a href="./rfc7203" title="&quot;An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information&quot;">RFC7203</a>]
   enhances the IODEF capabilities without further extending the data
   model.



<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   IODEF implementers should not use their own IODEF extensions unless
   data cannot be represented using existing standards or unless
   importing them in an IODEF document as defined in [<a href="./rfc7203" title="&quot;An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information&quot;">RFC7203</a>] is not a
   suitable option.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Indicator Predicate Logic</span>

   An IODEF document [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>] can describe incident reports and
   indicators.  The Indicator class can include references to other
   indicators, observables, and more classes that contain details about
   the indicator.  When describing security indicators, it is often
   common to need to group them together in order to form a group of
   indicators that constitute a security threat.  For example, a botnet
   might have multiple command and control servers.  For that reason,
   IODEF v2 introduced the IndicatorExpression class, which is used to
   add the indicator predicate logic when grouping more than one
   indicator or observable.

   Implementations must be able to parse and apply the Boolean logic
   offered by an IndicatorExpression in order to evaluate the existence
   of an indicator.  As explained in <a href="./rfc7970#section-3.29.5">Section&nbsp;3.29.5 of [RFC7970]</a>, the
   IndicatorExpression element operator defines the operator applied to
   all the child elements of the IndicatorExpression.  If no operator is
   defined, "and" should be assumed.  IndicatorExpressions can also be
   nested together.  Child IndicatorExpressions should be treated as
   child elements of their parent, and they should be evaluated first
   before being evaluated with the operator of their parent.

   Users can refer to <a href="#appendix-A">Appendix A</a> for example uses of the
   IndicatorExpressions in an IODEF v2.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Disclosure Level</span>

   Access to information in IODEF documents should be tightly locked
   since the content may be confidential.  IODEF has a common attribute,
   called "restriction", which indicates the disclosure guideline to
   which the sender expects the recipient to adhere to for the
   information represented in the class and its children.  That way, the
   sender can express the level of disclosure for each component of an
   IODEF document.  Appropriate external measures could be implemented
   based on the restriction level.  One example is when Real-time Inter-
   network Defense (RID) [<a href="./rfc6545" title="&quot;Real-time Inter-network Defense (RID)&quot;">RFC6545</a>] is used to transfer the IODEF
   documents, it can provide policy guidelines for handling IODEF
   documents by using the RIDPolicy class.

   The enforcement of the disclosure guidelines is out of scope for
   IODEF.  The recipient of the IODEF document needs to follow the
   guidelines, but these guidelines themselves do not provide any



<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   enforcement measures.  For that purpose, implementers should consider
   appropriate privacy control measures, technical or operational, for
   their implementation.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  IODEF Uses</span>

   IODEF is currently used by various organizations in order to
   represent security incidents and share incident and threat
   information between security operations organizations.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Implementations</span>

   In order to use IODEF, tools like IODEF parsers are necessary.
   [<a href="./rfc8134" title="&quot;Management Incident Lightweight Exchange (MILE) Implementation Report&quot;">RFC8134</a>] describes a set of IODEF implementations and uses by
   various vendors and Computer Emergency Readiness Team (CERT)
   organizations.  The document does not specify any particular
   mandatory-to-implement (MTI) IODEF classes but provides a list of
   real-world uses.  Perl and Python modules (XML::IODEF, Iodef::Pb,
   iodeflib) are some examples.  Moreover, implementers are encouraged
   to refer to <a href="./rfc8134#section-7">Section&nbsp;7 of [RFC8134]</a> for practical IODEF usage
   guidelines.  On the other hand, [<a href="#ref-IODEF_IMP">IODEF_IMP</a>] includes various vendor
   incident reporting products that can consume and export in IODEF
   format.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Inter-vendor and Service Provider Exercise</span>

   As an interoperability exercise, a limited number of vendors
   organized and executed exchanges of threat indicators in IODEF in
   2013.  The transport protocol used was RID.  The threat information
   shared included indicators from DDoS attacks as well as malware
   incidents and spear phishing that targets specific individuals after
   harvesting information about them.  The results served as proof-of-
   concept (PoC) about how seemingly competing entities could use IODEF
   to exchange sanitized security information.  As this was a PoC
   exercise, only example information (no real threats) was shared as
   part of the exchanges.















<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


         ____________                             ____________
         | Vendor X  |                            | Vendor Y  |
         | RID Agent |_______-------------________| RID Agent |
         |___________|       | Internet  |        |___________|
                             -------------

                      ---- RID Report message ---&gt;
                      -- carrying IODEF example -&gt;
                      --------- over TLS --------&gt;

                      &lt;----- RID Ack message -----
                      &lt;--- in case of failure ----

                      Figure 2: PoC Peering Topology

   Figure 2 shows how RID interactions took place during the PoC.
   Participating organizations were running RID Agent software on
   premises.  The RID Agents formed peering relationships with other
   participating organizations.  When Entity X had a new incident to
   exchange, it would package it in IODEF and send it to Entity Y over
   Transport Layer Security (TLS) in a RID Report message.  In case
   there was an issue with the message, Entity Y would send a RID
   Acknowledgement message back to Entity X, which included an
   application-level message to describe the issue.  Interoperability
   between RID Agents implementing [<a href="./rfc6545" title="&quot;Real-time Inter-network Defense (RID)&quot;">RFC6545</a>] and [<a href="./rfc6546" title="&quot;Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS&quot;">RFC6546</a>] was also
   confirmed.

   The first use case included sharing of malware data related to an
   Incident between CSIRTs.  After Entity X detected an incident, Entity
   X would put data about malware found during the incident in a backend
   system.  Entity X then decided to share the incident information with
   Entity Y about the malware discovered.  This could be a human
   decision or part of an automated process.

   Below are the steps followed for the malware information exchange
   that was taking place:

   (1)  Entity X has a sharing agreement with Entity Y and has already
        been configured with the IP address of Entity Y's RID Agent.

   (2)  Entity X's RID Agent connects to Entity Y's RID Agent, and
        mutual authentication occurs using PKI digital certificates.









<span class="grey">Kampanakis &amp; Suzuki           Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   (3)  Entity X pushes out a RID Report message, which contains
        information about N pieces of discovered malware.  IODEF is used
        in RID to describe the

        (a)  hash of malware files;

        (b)  registry settings changed by the malware; and

        (c)  C2 information for the malware.

   (4)  Entity Y receives a RID Report message and sends a RID
        Acknowledgement message.

   (5)  Entity Y stores the data in a format that makes it possible for
        the backend to know which source the data came from.

   Another use case was sharing a DDoS attack as explained in the
   following scenario: Entity X, a Critical Infrastructure and Key
   Resource (CIKR) company, detects that their internet connection is
   saturated with an abnormal amount of traffic.  Further investigation
   determines that this is an actual DDoS attack.  Entity X's CSIRT
   contacts their ISP, Entity Y, and shares information with them about
   the attack traffic characteristics.  Entity X's ISP is being
   overwhelmed by the amount of traffic, so it shares attack signatures
   and IP addresses of the most prolific hosts with its adjacent ISPs.

   Below are the steps followed for a DDoS information exchange:

   (1)  Entity X has a sharing agreement with Entity Y and has already
        been configured with the IP address of Entity Y's RID Agent.

   (2)  Entity X's RID Agent connects to Entity Y's RID Agent, and
        mutual authentication occurs using PKI digital certificates.

   (3)  Entity X pushes out a RID Report message, which contains
        information about the DDoS attack.  IODEF is used in RID to
        describe the following:

        (a)  Start and Detect dates and times;

        (b)  IP addresses of nodes sending DDoS traffic;

        (c)  sharing and use restrictions;

        (d)  traffic characteristics (protocols and ports);






<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


        (e)  HTTP user agents used; and

        (f)  IP addresses of C2 for a botnet.

   (4)  Entity Y receives a RID Report message and sends a RID
        Acknowledgement message.

   (5)  Entity Y stores the data in a format that makes it possible for
        the backend to know which source the data came from.

   (6)  Entity Y shares information with other ISP entities it has an
        established relationship with.

   One more use case was sharing spear-phishing email information as
   explained in the following scenario: the board members of several
   defense contractors receive a targeted email inviting them to attend
   a conference in San Francisco.  The board members are asked to
   provide their personally identifiable information such as their home
   address, phone number, corporate email, etc., in an attached document
   that came with the email.  The board members are also asked to click
   on a URL that would allow them to reach the sign-up page for the
   conference.  One of the recipients believes the email to be a
   phishing attempt and forwards the email to their corporate CSIRT for
   analysis.  The CSIRT identifies the email as an attempted spear-
   phishing incident and distributes the indicators to their sharing
   partners.

   Below are the steps followed for a spear-phishing information
   exchange between CSIRTs that were part of this PoC.

   (1)  Entity X has a sharing agreement with Entity Y and has already
        been configured with the IP address of Entity Y's RID Agent.

   (2)  Entity X's RID Agent connects to Entity Y's RID Agent, and
        mutual authentication occurs using PKI digital certificates.

   (3)  Entity X pushes out a RID Report message that contains
        information about the spear-phishing email.  IODEF is used in
        RID to describe the following:

        (a)  attachment details (file Name, hash, size, malware family);

        (b)  target description (IP, domain, NSLookup);

        (c)  email information (From, Subject, header information, date/
             time, digital signature); and

        (d)  confidence score.



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   (4)  Entity Y receives a RID Report message and sends a RID
        Acknowledgement message.

   (5)  Entity Y stores the data in a format that makes it possible for
        the backend to know which source the data came from.

   <a href="#appendix-B">Appendix B</a> includes some of the IODEF example information that was
   exchanged by the organizations' RID Agents as part of this PoC.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Use Cases</span>

   Other use cases of IODEF, aside from the ones described above, could
   be as follows:

   (1)  ISP notifying a national CERT or organization when it identifies
        and acts upon an incident, and CERTs notifying ISPs when they
        are aware of incidents.

   (2)  Suspected phishing emails could be shared amongst organizations
        and national agencies.  Automation could validate web content
        that the suspicious emails are pointing to.  Identified
        malicious content linked in a phishing email could then be
        shared using IODEF.  Phishing campaigns could thus be subverted
        much faster by automating information sharing using IODEF.

   (3)  When finding a certificate that should be revoked, a third party
        would forward an automated IODEF message to the Certification
        Authority (CA) with the full context of the certificate, and the
        CA could act accordingly after checking its validity.
        Alternatively, in the event of a compromise of the private key
        of a certificate, a third party could alert the certificate
        owner about the compromise using IODEF.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  IANA Considerations</span>

   This memo does not require any IANA actions.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   This document does not incur any new security issues, because it only
   talks about the usage of IODEFv2 defined in <a href="./rfc7970">RFC 7970</a>.  Nevertheless,
   readers of this document should refer to the Security Considerations
   section of [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].








<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-RFC5901">RFC5901</a>]  Cain, P. and D. Jevans, "Extensions to the IODEF-Document
              Class for Reporting Phishing", <a href="./rfc5901">RFC 5901</a>,
              DOI 10.17487/RFC5901, July 2010,
              &lt;<a href="https://www.rfc-editor.org/info/rfc5901">https://www.rfc-editor.org/info/rfc5901</a>&gt;.

   [<a id="ref-RFC6545">RFC6545</a>]  Moriarty, K., "Real-time Inter-network Defense (RID)",
              <a href="./rfc6545">RFC 6545</a>, DOI 10.17487/RFC6545, April 2012,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6545">https://www.rfc-editor.org/info/rfc6545</a>&gt;.

   [<a id="ref-RFC7203">RFC7203</a>]  Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
              Incident Object Description Exchange Format (IODEF)
              Extension for Structured Cybersecurity Information",
              <a href="./rfc7203">RFC 7203</a>, DOI 10.17487/RFC7203, April 2014,
              &lt;<a href="https://www.rfc-editor.org/info/rfc7203">https://www.rfc-editor.org/info/rfc7203</a>&gt;.

   [<a id="ref-RFC7495">RFC7495</a>]  Montville, A. and D. Black, "Enumeration Reference Format
              for the Incident Object Description Exchange Format
              (IODEF)", <a href="./rfc7495">RFC 7495</a>, DOI 10.17487/RFC7495, March 2015,
              &lt;<a href="https://www.rfc-editor.org/info/rfc7495">https://www.rfc-editor.org/info/rfc7495</a>&gt;.

   [<a id="ref-RFC7970">RFC7970</a>]  Danyliw, R., "The Incident Object Description Exchange
              Format Version 2", <a href="./rfc7970">RFC 7970</a>, DOI 10.17487/RFC7970,
              November 2016, &lt;<a href="https://www.rfc-editor.org/info/rfc7970">https://www.rfc-editor.org/info/rfc7970</a>&gt;.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-IODEF_IMP">IODEF_IMP</a>]
              "Implementations on Incident Object Description Exchange
              Format", &lt;<a href="http://siis.realmv6.org/implementations/">http://siis.realmv6.org/implementations/</a>&gt;.

   [<a id="ref-RFC6546">RFC6546</a>]  Trammell, B., "Transport of Real-time Inter-network
              Defense (RID) Messages over HTTP/TLS", <a href="./rfc6546">RFC 6546</a>,
              DOI 10.17487/RFC6546, April 2012,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6546">https://www.rfc-editor.org/info/rfc6546</a>&gt;.

   [<a id="ref-RFC8134">RFC8134</a>]  Inacio, C. and D. Miyamoto, "Management Incident
              Lightweight Exchange (MILE) Implementation Report",
              <a href="./rfc8134">RFC 8134</a>, DOI 10.17487/RFC8134, May 2017,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8134">https://www.rfc-editor.org/info/rfc8134</a>&gt;.








<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Indicator Predicate Logic Examples</span>

   In the following example, the EventData class evaluates as a Flow of
   one System with source address 192.0.2.104 OR 192.0.2.106 AND target
   address 198.51.100.1.

   &lt;!-- ...XML code omitted... --&gt;
    &lt;IndicatorData&gt;
      &lt;Indicator&gt;
        &lt;IndicatorID name="csirt.example.com" version="1"&gt;
        G90823490
        &lt;/IndicatorID&gt;
        &lt;Description&gt;C2 domains&lt;/Description&gt;
        &lt;IndicatorExpression operator="and"&gt;
          &lt;IndicatorExpression operator="or"&gt;
            &lt;Observable&gt;
              &lt;System category="source" spoofed="no"&gt;
                &lt;Node&gt;
                  &lt;Address category="ipv4-addr"&gt;
                    192.0.2.104
                  &lt;/Address&gt;
                &lt;/Node&gt;
              &lt;/System&gt;
            &lt;/Observable&gt;
            &lt;Observable&gt;
              &lt;System category="source" spoofed="no"&gt;
                &lt;Node&gt;
                  &lt;Address category="ipv4-addr"&gt;
                    192.0.2.106
                  &lt;/Address&gt;
                &lt;/Node&gt;
              &lt;/System&gt;
            &lt;/Observable&gt;
          &lt;/IndicatorExpression&gt;
          &lt;Observable&gt;
            &lt;System category="target" spoofed="no"&gt;
              &lt;Node&gt;
                &lt;Address category="ipv4-addr"&gt;
                  198.51.100.1
                &lt;/Address&gt;
              &lt;/Node&gt;
            &lt;/System&gt;
          &lt;/Observable&gt;
        &lt;/IndicatorExpression&gt;
      &lt;/Indicator&gt;
    &lt;/IndicatorData&gt;
   &lt;!-- ...XML code omitted... --&gt;




<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


   Similarly, the FileData Class can be an observable in an
   IndicatorExpression.  The hash values of two files can be used to
   match against an indicator using Boolean "or" logic.  In the
   following example, the indicator consists of either of the two files
   with two different hashes.

   &lt;!-- ...XML code omitted... --&gt;
    &lt;IndicatorData&gt;
      &lt;Indicator&gt;
        &lt;IndicatorID name="csirt.example.com" version="1"&gt;
        A4399IWQ
        &lt;/IndicatorID&gt;
        &lt;Description&gt;File hash watchlist&lt;/Description&gt;
        &lt;IndicatorExpression operator="or"&gt;
            &lt;Observable&gt;
              &lt;FileData&gt;
                &lt;File&gt;
                  &lt;FileName&gt;dummy.txt&lt;/FileName&gt;
                  &lt;HashData scope="file-contents"&gt;
                    &lt;Hash&gt;
                     &lt;ds:DigestMethod Algorithm=
                     "<a href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a>"/&gt;
                     &lt;ds:DigestValue&gt;
                      141accec23e7e5157de60853cb1e01bc38042d
                      08f9086040815300b7fe75c184
                     &lt;/ds:DigestValue&gt;
                    &lt;/Hash&gt;
                  &lt;/HashData&gt;
                &lt;/File&gt;
              &lt;/FileData&gt;
            &lt;/Observable&gt;
            &lt;Observable&gt;
              &lt;FileData&gt;
                &lt;File&gt;
                  &lt;FileName&gt;dummy2.txt&lt;/FileName&gt;
                  &lt;HashData scope="file-contents"&gt;
                    &lt;Hash&gt;
                     &lt;ds:DigestMethod Algorithm=
                     "<a href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a>"/&gt;
                     &lt;ds:DigestValue&gt;
                      141accec23e7e5157de60853cb1e01bc38042d
                      08f9086040815300b7fe75c184
                     &lt;/ds:DigestValue&gt;
                    &lt;/Hash&gt;
                  &lt;/HashData&gt;
                &lt;/File&gt;
              &lt;/FileData&gt;
            &lt;/Observable&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


        &lt;/IndicatorExpression&gt;
      &lt;/Indicator&gt;
    &lt;/IndicatorData&gt;
   &lt;!-- ...XML code omitted... --&gt;

<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Inter-vendor and Service Provider Exercise Examples</span>

   Below, some of the IODEF example information that was exchanged by
   the vendors as part of this proof-of-concept, inter-vendor and
   service provider exercise.

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  Malware Delivery URL</span>

   This example indicates malware and a related URL for file delivery.

  &lt;?xml version="1.0" encoding="UTF-8"?&gt;
  &lt;IODEF-Document version="2.00"
                  xmlns="urn:ietf:params:xml:ns:iodef-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
    &lt;iodef:Incident purpose="reporting"&gt;
      &lt;iodef:IncidentID name="csirt.example.com"&gt;
        189801
      &lt;/iodef:IncidentID&gt;
      &lt;iodef:ReportTime&gt;2012-12-05T12:20:00+00:00&lt;/iodef:ReportTime&gt;
      &lt;iodef:GenerationTime&gt;2012-12-05T12:20:00+00:00
      &lt;/iodef:GenerationTime&gt;
      &lt;iodef:Description&gt;Malware and related indicators
      &lt;/iodef:Description&gt;
      &lt;iodef:Assessment occurrence="potential"&gt;
        &lt;iodef:SystemImpact severity="medium" type="breach-privacy"&gt;
          &lt;iodef:Description&gt;Malware with C2
          &lt;/iodef:Description&gt;
        &lt;/iodef:SystemImpact&gt;
      &lt;/iodef:Assessment&gt;
      &lt;iodef:Contact role="creator" type="organization"&gt;
        &lt;iodef:ContactName&gt;example.com CSIRT
        &lt;/iodef:ContactName&gt;
        &lt;iodef:Email&gt;
          &lt;iodef:EmailTo&gt;contact@csirt.example.com
          &lt;/iodef:EmailTo&gt;
        &lt;/iodef:Email&gt;
      &lt;/iodef:Contact&gt;
      &lt;iodef:EventData&gt;
        &lt;iodef:Flow&gt;
          &lt;iodef:System category="source"&gt;
            &lt;iodef:Node&gt;
              &lt;iodef:Address category="ipv4-addr"&gt;192.0.2.200



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


              &lt;/iodef:Address&gt;
                          &lt;iodef:Address category="site-uri"&gt;
                /log-bin/lunch_install.php?aff_id=1&amp;amp;lunch_id=1&amp;amp;
                maddr=&amp;amp;action=install
              &lt;/iodef:Address&gt;
            &lt;/iodef:Node&gt;
            &lt;iodef:NodeRole category="www"/&gt;
          &lt;/iodef:System&gt;
        &lt;/iodef:Flow&gt;
      &lt;/iodef:EventData&gt;
    &lt;/iodef:Incident&gt;
  &lt;/IODEF-Document&gt;

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  DDoS</span>

   The DDoS test exchanged information that described a DDoS, including
   protocols and ports, bad IP addresses, and HTTP user agent fields.
   The IODEF version used for the data representation was based on
   [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].

 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;IODEF-Document version="2.00"
                 xmlns="urn:ietf:params:xml:ns:iodef-2.0"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
   &lt;iodef:Incident purpose="reporting" restriction="default"&gt;
     &lt;iodef:IncidentID name="csirt.example.com"&gt;
       189701
     &lt;/iodef:IncidentID&gt;
     &lt;iodef:DetectTime&gt;2013-02-05T01:15:45+00:00&lt;/iodef:DetectTime&gt;
     &lt;iodef:StartTime&gt;2013-02-05T00:34:45+00:00&lt;/iodef:StartTime&gt;
     &lt;iodef:ReportTime&gt;2013-02-05T01:34:45+00:00&lt;/iodef:ReportTime&gt;
     &lt;iodef:GenerationTime&gt;2013-02-05T01:15:45+00:00
     &lt;/iodef:GenerationTime&gt;
     &lt;iodef:Description&gt;DDoS Traffic Seen&lt;/iodef:Description&gt;
     &lt;iodef:Assessment occurrence="actual"&gt;
       &lt;iodef:SystemImpact severity="medium" type="availability-system"&gt;
         &lt;iodef:Description&gt;DDoS Traffic
         &lt;/iodef:Description&gt;
       &lt;/iodef:SystemImpact&gt;
       &lt;iodef:Confidence rating="high"/&gt;
     &lt;/iodef:Assessment&gt;
     &lt;iodef:Contact role="creator" type="organization"&gt;
       &lt;iodef:ContactName&gt;Dummy Test&lt;/iodef:ContactName&gt;
       &lt;iodef:Email&gt;
         &lt;iodef:EmailTo&gt;contact@dummytest.com
         &lt;/iodef:EmailTo&gt;
       &lt;/iodef:Email&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


     &lt;/iodef:Contact&gt;
     &lt;iodef:EventData&gt;
       &lt;iodef:Description&gt;
         Dummy Test sharing with ISP1
       &lt;/iodef:Description&gt;
       &lt;iodef:Method&gt;
         &lt;iodef:Reference&gt;
           &lt;iodef:URL&gt;
             <a href="http://blog.spiderlabs.com/2011/01/loic-ddos-analysis-and-detection.html">http://blog.spiderlabs.com/2011/01/loic-ddos-</a>
             <a href="http://blog.spiderlabs.com/2011/01/loic-ddos-analysis-and-detection.html">analysis-and-detection.html</a>
           &lt;/iodef:URL&gt;
           &lt;iodef:URL&gt;
             <a href="http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon">http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon</a>
           &lt;/iodef:URL&gt;
           &lt;iodef:Description&gt;
             Low Orbit Ion Cannon User Agent
           &lt;/iodef:Description&gt;
         &lt;/iodef:Reference&gt;
       &lt;/iodef:Method&gt;
       &lt;iodef:Flow&gt;
         &lt;iodef:System category="source" spoofed="no"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               192.0.2.104
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Service ip-protocol="6"&gt;
             &lt;iodef:Port&gt;1337&lt;/iodef:Port&gt;
           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="source" spoofed="no"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               192.0.2.106
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Service ip-protocol="6"&gt;
             &lt;iodef:Port&gt;1337&lt;/iodef:Port&gt;
           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="source" spoofed="yes"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv4-net"&gt;
               198.51.100.0/24
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Service ip-protocol="6"&gt;
             &lt;iodef:Port&gt;1337&lt;/iodef:Port&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="source" spoofed="yes"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv6-addr"&gt;
               2001:db8:dead:beef::1
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Service ip-protocol="6"&gt;
             &lt;iodef:Port&gt;1337&lt;/iodef:Port&gt;
           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="target"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               203.0.113.1
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Service ip-protocol="6"&gt;
             &lt;iodef:Port&gt;80&lt;/iodef:Port&gt;
           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="sensor"&gt;
           &lt;iodef:Node&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:Description&gt;
             Information provided in Flow class instance is from
             Inspection of traffic from network tap
           &lt;/iodef:Description&gt;
         &lt;/iodef:System&gt;
       &lt;/iodef:Flow&gt;
       &lt;iodef:Expectation action="other"/&gt;
     &lt;/iodef:EventData&gt;
     &lt;iodef:IndicatorData&gt;
       &lt;iodef:Indicator&gt;
         &lt;iodef:IndicatorID name="csirt.example.com" version="1"&gt;
           G83345941
         &lt;/iodef:IndicatorID&gt;
         &lt;iodef:Description&gt;
           User-Agent string
         &lt;/iodef:Description&gt;
         &lt;iodef:Observable&gt;
           &lt;iodef:BulkObservable type="http-user-agent"&gt;
             &lt;iodef:BulkObservableList&gt;
               user-agent="Mozilla/5.0 (Macintosh; U;
               Intel Mac OS X 10.5; en-US; rv:1.9.2.12)
               Gecko/20101026 Firefox/3.6.12"&gt;
             &lt;/iodef:BulkObservableList&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


           &lt;/iodef:BulkObservable&gt;
         &lt;/iodef:Observable&gt;
       &lt;/iodef:Indicator&gt;
     &lt;/iodef:IndicatorData&gt;
   &lt;/iodef:Incident&gt;
 &lt;/IODEF-Document&gt;

<span class="h3"><a class="selflink" id="appendix-B.3" href="#appendix-B.3">B.3</a>.  Spear Phishing</span>

   The spear-phishing test exchanged information that described a spear-
   phishing email, including DNS records and addresses about the sender,
   malicious attached file information, and email data.  The IODEF
   version used for the data representation was based on [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].

 &lt;?xml version="1.0" encoding="UTF-8"?&gt;
 &lt;IODEF-Document version="2.00"
                 xmlns="urn:ietf:params:xml:ns:iodef-2.0"
                 xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
   &lt;iodef:Incident purpose="reporting"&gt;
     &lt;iodef:IncidentID name="csirt.example.com"&gt;
       189601
     &lt;/iodef:IncidentID&gt;
     &lt;iodef:DetectTime&gt;2013-01-04T08:06:12+00:00&lt;/iodef:DetectTime&gt;
     &lt;iodef:StartTime&gt;2013-01-04T08:01:34+00:00&lt;/iodef:StartTime&gt;
     &lt;iodef:EndTime&gt;2013-01-04T08:31:27+00:00&lt;/iodef:EndTime&gt;
     &lt;iodef:ReportTime&gt;2013-01-04T09:15:45+00:00&lt;/iodef:ReportTime&gt;
     &lt;iodef:GenerationTime&gt;2013-01-04T09:15:45+00:00
     &lt;/iodef:GenerationTime&gt;
     &lt;iodef:Description&gt;
       Zeus Spear Phishing E-mail with Malware Attachment
     &lt;/iodef:Description&gt;
     &lt;iodef:Assessment occurrence="potential"&gt;
       &lt;iodef:SystemImpact severity="medium" type="takeover-system"&gt;
         &lt;iodef:Description&gt;
           Malware with Command and Control Server and System Changes
         &lt;/iodef:Description&gt;
       &lt;/iodef:SystemImpact&gt;
     &lt;/iodef:Assessment&gt;
     &lt;iodef:Contact role="creator" type="organization"&gt;
       &lt;iodef:ContactName&gt;example.com CSIRT&lt;/iodef:ContactName&gt;
       &lt;iodef:Email&gt;
         &lt;iodef:EmailTo&gt;contact@csirt.example.com&lt;/iodef:EmailTo&gt;
         &lt;/iodef:Email&gt;
     &lt;/iodef:Contact&gt;
     &lt;iodef:EventData&gt;
       &lt;iodef:Description&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


         Targeting Defense Contractors,
         specifically board members attending Dummy Con
       &lt;/iodef:Description&gt;
       &lt;iodef:Method&gt;
         &lt;iodef:Reference observable-id="ref-1234"&gt;
           &lt;iodef:Description&gt;Zeus&lt;/iodef:Description&gt;
         &lt;/iodef:Reference&gt;
       &lt;/iodef:Method&gt;
       &lt;iodef:Flow&gt;
         &lt;iodef:System category="source"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="site-uri"&gt;
               <a href="http://www.zeusevil.example.com">http://www.zeusevil.example.com</a>
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               192.0.2.166
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="asn"&gt;
               65535
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="ext-value"
                            ext-category="as-name"&gt;
               EXAMPLE-AS - University of Example
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="ext-value"
                            ext-category="as-prefix"&gt;
               192.0.2.0/24
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:NodeRole category="malware-distribution"/&gt;
         &lt;/iodef:System&gt;
       &lt;/iodef:Flow&gt;
       &lt;iodef:Flow&gt;
         &lt;iodef:System category="source"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:DomainData&gt;
               &lt;Name&gt;mail1.evildave.example.com&lt;/Name&gt;
             &lt;/iodef:DomainData&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               198.51.100.6
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="asn"&gt;
               65534
             &lt;/iodef:Address&gt;
             &lt;iodef:Address category="ext-value"
                            ext-category="as-name"&gt;
               EXAMPLE-AS - University of Example
             &lt;/iodef:Address&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


             &lt;iodef:DomainData&gt;
               &lt;iodef:Name&gt;evildave.example.com&lt;/iodef:Name&gt;
               &lt;iodef:DateDomainWasChecked&gt;2013-01-04T09:10:24+00:00
               &lt;/iodef:DateDomainWasChecked&gt;
               &lt;!-- &lt;iodef:RelatedDNS RecordType="MX"&gt; --&gt;
               &lt;iodef:RelatedDNS dtype="string"&gt;
                 evildave.example.com MX preference = 10, mail exchanger
                 = mail1.evildave.example.com
               &lt;/iodef:RelatedDNS&gt;
               &lt;iodef:RelatedDNS dtype="string"&gt;
                 mail1.evildave.example.com
                 internet address = 198.51.100.6
               &lt;/iodef:RelatedDNS&gt;
               &lt;iodef:RelatedDNS dtype="string"&gt;
                 zuesevil.example.com. IN TXT \"v=spf1 a mx -all\"
               &lt;/iodef:RelatedDNS&gt;
             &lt;/iodef:DomainData&gt;
           &lt;/iodef:Node&gt;
           &lt;iodef:NodeRole category="mail"&gt;
             &lt;iodef:Description&gt;
               Sending phishing mails
             &lt;/iodef:Description&gt;
           &lt;/iodef:NodeRole&gt;
           &lt;iodef:Service&gt;
             &lt;iodef:EmailData&gt;
               &lt;iodef:EmailFrom&gt;
                 emaildave@evildave.example.com
               &lt;/iodef:EmailFrom&gt;
               &lt;iodef:EmailSubject&gt;
                 Join us at Dummy Con
               &lt;/iodef:EmailSubject&gt;
               &lt;iodef:EmailX-Mailer&gt;
                 StormRider 4.0
               &lt;/iodef:EmailX-Mailer&gt;
             &lt;/iodef:EmailData&gt;
           &lt;/iodef:Service&gt;
         &lt;/iodef:System&gt;
         &lt;iodef:System category="target"&gt;
           &lt;iodef:Node&gt;
             &lt;iodef:Address category="ipv4-addr"&gt;
               203.0.113.2
             &lt;/iodef:Address&gt;
           &lt;/iodef:Node&gt;
         &lt;/iodef:System&gt;
       &lt;/iodef:Flow&gt;
       &lt;iodef:Expectation action="other"/&gt;
       &lt;iodef:Record&gt;
         &lt;iodef:RecordData&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


           &lt;iodef:FileData observable-id="fd-1234"&gt;
             &lt;iodef:File&gt;
               &lt;iodef:FileName&gt;
                 Dummy Con Sign Up Sheet.txt
               &lt;/iodef:FileName&gt;
               &lt;iodef:FileSize&gt;
                 152
               &lt;/iodef:FileSize&gt;
               &lt;iodef:HashData scope="file-contents"&gt;
                 &lt;iodef:Hash&gt;
                   &lt;ds:DigestMethod Algorithm=
                   "<a href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a>"/&gt;
                   &lt;ds:DigestValue&gt;
                     141accec23e7e5157de60853cb1e01bc38042d
                     08f9086040815300b7fe75c184
                   &lt;/ds:DigestValue&gt;
                 &lt;/iodef:Hash&gt;
               &lt;/iodef:HashData&gt;
             &lt;/iodef:File&gt;
           &lt;/iodef:FileData&gt;
         &lt;/iodef:RecordData&gt;
         &lt;iodef:RecordData&gt;
           &lt;iodef:CertificateData&gt;
             &lt;iodef:Certificate&gt;
               &lt;ds:X509Data&gt;
                 &lt;ds:X509IssuerSerial&gt;
                   &lt;ds:X509IssuerName&gt;FakeCA
                   &lt;/ds:X509IssuerName&gt;
                   &lt;ds:X509SerialNumber&gt;
                     57482937101
                   &lt;/ds:X509SerialNumber&gt;
                 &lt;/ds:X509IssuerSerial&gt;
                 &lt;ds:X509SubjectName&gt;EvilDaveExample
                 &lt;/ds:X509SubjectName&gt;
               &lt;/ds:X509Data&gt;
             &lt;/iodef:Certificate&gt;
           &lt;/iodef:CertificateData&gt;
         &lt;/iodef:RecordData&gt;
       &lt;/iodef:Record&gt;
     &lt;/iodef:EventData&gt;
   &lt;/iodef:Incident&gt;
 &lt;/IODEF-Document&gt;









<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


<span class="h3"><a class="selflink" id="appendix-B.4" href="#appendix-B.4">B.4</a>.  Malware</span>

   In this test, malware information was exchanged using RID and IODEF.
   The information included file hashes, registry setting changes, and
   the C2 servers the malware uses.

&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;IODEF-Document version="2.00"
                xmlns="urn:ietf:params:xml:ns:iodef-2.0"
                xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
  &lt;iodef:Incident purpose="reporting"&gt;
    &lt;iodef:IncidentID name="csirt.example.com"&gt;
      189234
    &lt;/iodef:IncidentID&gt;
    &lt;iodef:ReportTime&gt;2013-03-07T16:14:56.757+05:30&lt;/iodef:ReportTime&gt;
    &lt;iodef:GenerationTime&gt;2013-03-07T16:14:56.757+05:30
    &lt;/iodef:GenerationTime&gt;
    &lt;iodef:Description&gt;
      Malware and related indicators identified
    &lt;/iodef:Description&gt;
    &lt;iodef:Assessment occurrence="potential"&gt;
      &lt;iodef:SystemImpact severity="medium" type="breach-proprietary"&gt;
        &lt;iodef:Description&gt;
          Malware with Command and Control Server and System Changes
        &lt;/iodef:Description&gt;
      &lt;/iodef:SystemImpact&gt;
    &lt;/iodef:Assessment&gt;
    &lt;iodef:Contact role="creator" type="organization"&gt;
      &lt;iodef:ContactName&gt;example.com CSIRT&lt;/iodef:ContactName&gt;
      &lt;iodef:Email&gt;
        &lt;iodef:EmailTo&gt;contact@csirt.example.com&lt;/iodef:EmailTo&gt;
      &lt;/iodef:Email&gt;
    &lt;/iodef:Contact&gt;
    &lt;iodef:EventData&gt;
      &lt;iodef:Method&gt;
        &lt;iodef:Reference&gt;
          &lt;iodef:URL&gt;
            <a href="http://www.threatexpert.example.com/report.aspx?">http://www.threatexpert.example.com/report.aspx?</a>
            md5=e2710ceb088dacdcb03678db250742b7
          &lt;/iodef:URL&gt;
          &lt;iodef:Description&gt;Zeus&lt;/iodef:Description&gt;
        &lt;/iodef:Reference&gt;
      &lt;/iodef:Method&gt;
      &lt;iodef:Flow&gt;
        &lt;iodef:System category="source"&gt;
          &lt;iodef:Node&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


            &lt;iodef:Address category="ipv4-addr"
                           observable-id="addr-c2-91011-001"&gt;
              203.0.113.200
            &lt;/iodef:Address&gt;
            &lt;iodef:Address category="site-uri"
                           observable-id="addr-c2-91011-002"&gt;
              <a href="http://zeus.556677889900.example.com/log-bin/lunch_install">http://zeus.556677889900.example.com/log-bin/</a>
              <a href="http://zeus.556677889900.example.com/log-bin/lunch_install">lunch_install</a>.php?aff_id=1&amp;amp;
              lunch_id=1&amp;amp;maddr=&amp;amp;
              action=install
            &lt;/iodef:Address&gt;
          &lt;/iodef:Node&gt;
          &lt;iodef:NodeRole category="c2-server"/&gt;
        &lt;/iodef:System&gt;
      &lt;/iodef:Flow&gt;
      &lt;iodef:Record&gt;
        &lt;iodef:RecordData&gt;
          &lt;iodef:FileData observable-id="file-91011-001"&gt;
            &lt;iodef:File&gt;
              &lt;iodef:HashData scope="file-contents"&gt;
                &lt;iodef:Hash&gt;
                  &lt;ds:DigestMethod Algorithm=
                          "<a href="http://www.w3.org/2001/04/xmlenc#sha1">http://www.w3.org/2001/04/xmlenc#sha1</a>"/&gt;
                  &lt;ds:DigestValue&gt;
                    MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJF
                    REZG
                  &lt;/ds:DigestValue&gt;
                &lt;/iodef:Hash&gt;
              &lt;/iodef:HashData&gt;
            &lt;/iodef:File&gt;
            &lt;iodef:File&gt;
              &lt;iodef:HashData scope="file-contents"&gt;
                &lt;iodef:Hash&gt;
                  &lt;ds:DigestMethod Algorithm=
                          "<a href="http://www.w3.org/2001/04/xmlenc#md5">http://www.w3.org/2001/04/xmlenc#md5</a>"/&gt;
                  &lt;ds:DigestValue&gt;
                    MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA==
                  &lt;/ds:DigestValue&gt;
                &lt;/iodef:Hash&gt;
              &lt;/iodef:HashData&gt;
            &lt;/iodef:File&gt;
          &lt;/iodef:FileData&gt;
          &lt;iodef:WindowsRegistryKeysModified observable-id=
          "regkey-91011-001"&gt;
            &lt;iodef:Key registryaction="add-value"&gt;
              &lt;iodef:KeyName&gt;
                HKLM\Software\Microsoft\Windows\
                CurrentVersion\Run\tamg



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


              &lt;/iodef:KeyName&gt;
              &lt;iodef:Value&gt;
                ?\?\?%System%\wins\mc.exe\?\??
              &lt;/iodef:Value&gt;
            &lt;/iodef:Key&gt;
            &lt;iodef:Key registryaction="modify-value"&gt;
              &lt;iodef:KeyName&gt;HKLM\Software\Microsoft\
                Windows\CurrentVersion\Run\dqo
              &lt;/iodef:KeyName&gt;
              &lt;iodef:Value&gt;"\"\"%Windir%\Resources\
                Themes\Luna\km.exe\?\?"
              &lt;/iodef:Value&gt;
            &lt;/iodef:Key&gt;
          &lt;/iodef:WindowsRegistryKeysModified&gt;
        &lt;/iodef:RecordData&gt;
      &lt;/iodef:Record&gt;
    &lt;/iodef:EventData&gt;
    &lt;iodef:EventData&gt;
      &lt;iodef:Method&gt;
        &lt;iodef:Reference&gt;
          &lt;iodef:URL&gt;
            <a href="http://www.threatexpert.example.com/report.aspx?">http://www.threatexpert.example.com/report.aspx?</a>
            md5=c3c528c939f9b176c883ae0ce5df0001
          &lt;/iodef:URL&gt;
          &lt;iodef:Description&gt;Cridex&lt;/iodef:Description&gt;
        &lt;/iodef:Reference&gt;
      &lt;/iodef:Method&gt;
      &lt;iodef:Flow&gt;
        &lt;iodef:System category="source"&gt;
          &lt;iodef:Node&gt;
            &lt;iodef:Address category="ipv4-addr"
                           observable-id="addr-c2-91011-003"&gt;
              203.0.113.100
            &lt;/iodef:Address&gt;
          &lt;/iodef:Node&gt;
          &lt;iodef:NodeRole category="c2-server"/&gt;
          &lt;iodef:Service ip-protocol="6"&gt;
            &lt;iodef:Port&gt;8080&lt;/iodef:Port&gt;
          &lt;/iodef:Service&gt;
        &lt;/iodef:System&gt;
      &lt;/iodef:Flow&gt;
      &lt;iodef:Record&gt;
        &lt;iodef:RecordData&gt;
          &lt;iodef:FileData observable-id="file-91011-002"&gt;
            &lt;iodef:File&gt;
              &lt;iodef:HashData scope="file-contents"&gt;
                &lt;iodef:Hash&gt;




<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


                  &lt;ds:DigestMethod Algorithm=
                          "<a href="http://www.w3.org/2001/04/xmlenc#sha1">http://www.w3.org/2001/04/xmlenc#sha1</a>"/&gt;
                  &lt;ds:DigestValue&gt;
                    MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM
                    1ODVFMzQzRTcxNDFD
                  &lt;/ds:DigestValue&gt;
                &lt;/iodef:Hash&gt;
              &lt;/iodef:HashData&gt;
            &lt;/iodef:File&gt;
          &lt;/iodef:FileData&gt;
          &lt;iodef:FileData observable-id="file-91011-003"&gt;
            &lt;iodef:File&gt;
              &lt;iodef:HashData scope="file-contents"&gt;
                &lt;iodef:Hash&gt;
                  &lt;ds:DigestMethod Algorithm=
                          "<a href="http://www.w3.org/2001/04/xmlenc#md5">http://www.w3.org/2001/04/xmlenc#md5</a>"/&gt;
                  &lt;ds:DigestValue&gt;
                    MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw==
                  &lt;/ds:DigestValue&gt;
                &lt;/iodef:Hash&gt;
              &lt;/iodef:HashData&gt;
            &lt;/iodef:File&gt;
          &lt;/iodef:FileData&gt;
          &lt;iodef:WindowsRegistryKeysModified observable-id=
                  "regkey-91011-002"&gt;
            &lt;iodef:Key registryaction="add-value"&gt;
              &lt;iodef:KeyName&gt;
                HKLM\Software\Microsoft\Windows\
                CurrentVersion\Run\KB00121600.exe
              &lt;/iodef:KeyName&gt;
              &lt;iodef:Value&gt;
                \?\?%AppData%\KB00121600.exe\?\?
              &lt;/iodef:Value&gt;
            &lt;/iodef:Key&gt;
          &lt;/iodef:WindowsRegistryKeysModified&gt;
        &lt;/iodef:RecordData&gt;
      &lt;/iodef:Record&gt;
    &lt;/iodef:EventData&gt;
    &lt;iodef:IndicatorData&gt;
      &lt;iodef:Indicator&gt;
        &lt;iodef:IndicatorID name="csirt.example.com" version="1"&gt;
          ind-91011
        &lt;/iodef:IndicatorID&gt;
        &lt;iodef:Description&gt;
          evil c2 server, file hash, and registry key
        &lt;/iodef:Description&gt;
        &lt;iodef:IndicatorExpression operator="or"&gt;
          &lt;iodef:IndicatorExpression operator="or"&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


            &lt;iodef:Observable&gt;
              &lt;iodef:Address category="site-uri"
                             observable-id="addr-qrst"&gt;
                <a href="http://foo.example.com:12345/evil/cc.php">http://foo.example.com:12345/evil/cc.php</a>
              &lt;/iodef:Address&gt;
            &lt;/iodef:Observable&gt;
            &lt;iodef:Observable&gt;
              &lt;iodef:Address category="ipv4-addr"
                             observable-id="addr-stuv"&gt;
                192.0.2.1
              &lt;/iodef:Address&gt;
            &lt;/iodef:Observable&gt;
            &lt;iodef:Observable&gt;
              &lt;iodef:Address category="ipv4-addr"
                             observable-id="addr-tuvw"&gt;
                198.51.100.1
              &lt;/iodef:Address&gt;
            &lt;/iodef:Observable&gt;
            &lt;iodef:Observable&gt;
              &lt;iodef:Address category="ipv6-addr"
                             observable-id="addr-uvwx"&gt;
                2001:db8:dead:beef::1
              &lt;/iodef:Address&gt;
            &lt;/iodef:Observable&gt;
            &lt;iodef:ObservableReference uid-ref="addr-c2-91011-001"/&gt;
            &lt;iodef:ObservableReference uid-ref="addr-c2-91011-002"/&gt;
            &lt;iodef:ObservableReference uid-ref="addr-c2-91011-003"/&gt;
          &lt;/iodef:IndicatorExpression&gt;
          &lt;iodef:IndicatorExpression operator="and"&gt;
            &lt;iodef:Observable&gt;
              &lt;iodef:FileData observable-id="file-91011-000"&gt;
                &lt;iodef:File&gt;
                  &lt;iodef:HashData scope="file-contents"&gt;
                    &lt;iodef:Hash&gt;
                      &lt;ds:DigestMethod Algorithm=
                             "<a href="http://www.w3.org/2001/04/xmlenc#sha256">http://www.w3.org/2001/04/xmlenc#sha256</a>"/&gt;
                      &lt;ds:DigestValue&gt;
                        141accec23e7e5157de60853cb1e01bc38042d08f
                        9086040815300b7fe75c184
                      &lt;/ds:DigestValue&gt;
                    &lt;/iodef:Hash&gt;
                  &lt;/iodef:HashData&gt;
                &lt;/iodef:File&gt;
              &lt;/iodef:FileData&gt;
            &lt;/iodef:Observable&gt;
            &lt;iodef:Observable&gt;
              &lt;iodef:WindowsRegistryKeysModified observable-id=
                      "regkey-91011-000"&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


                &lt;iodef:Key registryaction="add-key"
                           observable-id="regkey-vwxy"&gt;
                  &lt;iodef:KeyName&gt;
                    HKLM\SYSTEM\CurrentControlSet\
                    Services\.Net CLR
                  &lt;/iodef:KeyName&gt;
                &lt;/iodef:Key&gt;
                &lt;iodef:Key registryaction="add-key"
                           observable-id="regkey-wxyz"&gt;
                  &lt;iodef:KeyName&gt;
                    HKLM\SYSTEM\CurrentControlSet\
                    Services\.Net CLR\Parameters
                  &lt;/iodef:KeyName&gt;
                  &lt;iodef:Value&gt;
                    \"\"%AppData%\KB00121600.exe\"\"
                  &lt;/iodef:Value&gt;
                &lt;/iodef:Key&gt;
                &lt;iodef:Key registryaction="add-value"
                           observable-id="regkey-xyza"&gt;
                  &lt;iodef:KeyName&gt;
                    HKLM\SYSTEM\CurrentControlSet\Services\
                    .Net CLR\Parameters\ServiceDll
                  &lt;/iodef:KeyName&gt;
                  &lt;iodef:Value&gt;C:\bad.exe&lt;/iodef:Value&gt;
                &lt;/iodef:Key&gt;
                &lt;iodef:Key registryaction="modify-value"
                           observable-id="regkey-zabc"&gt;
                  &lt;iodef:KeyName&gt;
                    HKLM\SYSTEM\CurrentControlSet\
                    Services\.Net CLR\Parameters\Bar
                  &lt;/iodef:KeyName&gt;
                  &lt;iodef:Value&gt;Baz&lt;/iodef:Value&gt;
                &lt;/iodef:Key&gt;
              &lt;/iodef:WindowsRegistryKeysModified&gt;
            &lt;/iodef:Observable&gt;
          &lt;/iodef:IndicatorExpression&gt;
          &lt;iodef:IndicatorExpression operator="or"&gt;
            &lt;iodef:IndicatorExpression operator="and"&gt;
              &lt;iodef:ObservableReference uid-ref="file-91011-001"/&gt;
              &lt;iodef:ObservableReference uid-ref="regkey-91011-001"/&gt;
            &lt;/iodef:IndicatorExpression&gt;
            &lt;iodef:IndicatorExpression operator="and"&gt;
              &lt;iodef:IndicatorExpression operator="or"&gt;
                &lt;iodef:ObservableReference uid-ref="file-91011-002"/&gt;
                &lt;iodef:ObservableReference uid-ref="file-91011-003"/&gt;
              &lt;/iodef:IndicatorExpression&gt;
              &lt;iodef:ObservableReference uid-ref="regkey-91011-002"/&gt;
            &lt;/iodef:IndicatorExpression&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


          &lt;/iodef:IndicatorExpression&gt;
        &lt;/iodef:IndicatorExpression&gt;
      &lt;/iodef:Indicator&gt;
    &lt;/iodef:IndicatorData&gt;
  &lt;/iodef:Incident&gt;
&lt;/IODEF-Document&gt;

<span class="h3"><a class="selflink" id="appendix-B.5" href="#appendix-B.5">B.5</a>.  IoT Malware</span>

   The Internet of Things (IoT) malware test exchanged information that
   described a bad IP address of IoT malware and its scanned ports.
   This example information is extracted from alert messages of a
   darknet monitoring system referred to in [<a href="./rfc8134" title="&quot;Management Incident Lightweight Exchange (MILE) Implementation Report&quot;">RFC8134</a>].  The IODEF
   version used for the data representation was based on [<a href="./rfc7970" title="&quot;The Incident Object Description Exchange Format Version 2&quot;">RFC7970</a>].

  &lt;?xml version="1.0" encoding="UTF-8"?&gt;
  &lt;IODEF-Document version="2.00"
                  xmlns="urn:ietf:params:xml:ns:iodef-2.0"
                  xmlns:iodef="urn:ietf:params:xml:ns:iodef-2.0"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
    &lt;iodef:Incident purpose="reporting"&gt;
      &lt;iodef:IncidentID name="csirt.example.com"&gt;
        189802
      &lt;/iodef:IncidentID&gt;
      &lt;iodef:ReportTime&gt;2017-03-01T01:15:00+09:00&lt;/iodef:ReportTime&gt;
      &lt;iodef:GenerationTime&gt;2017-03-01T01:15:00+09:00
      &lt;/iodef:GenerationTime&gt;
      &lt;iodef:Description&gt;IoT Malware and related indicators
      &lt;/iodef:Description&gt;
      &lt;iodef:Assessment occurrence="potential"&gt;
        &lt;iodef:SystemImpact severity="medium" type="takeover-system"&gt;
          &lt;iodef:Description&gt;IoT Malware is scanning other hosts
          &lt;/iodef:Description&gt;
        &lt;/iodef:SystemImpact&gt;
      &lt;/iodef:Assessment&gt;
      &lt;iodef:Contact role="creator" type="organization"&gt;
        &lt;iodef:ContactName&gt;example.com CSIRT
        &lt;/iodef:ContactName&gt;
        &lt;iodef:Email&gt;
          &lt;iodef:EmailTo&gt;contact@csirt.example.com
          &lt;/iodef:EmailTo&gt;
        &lt;/iodef:Email&gt;
      &lt;/iodef:Contact&gt;
      &lt;iodef:EventData&gt;
        &lt;iodef:Discovery source="nidps"&gt;
          &lt;iodef:Description&gt;
            Detected by darknet monitoring
          &lt;/iodef:Description&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


        &lt;/iodef:Discovery&gt;
        &lt;iodef:Flow&gt;
          &lt;iodef:System category="source"&gt;
            &lt;iodef:Node&gt;
              &lt;iodef:Address category="ipv4-addr"&gt;
                192.0.2.210
              &lt;/iodef:Address&gt;
            &lt;/iodef:Node&gt;
            &lt;iodef:NodeRole category="camera"/&gt;
            &lt;iodef:Service ip-protocol="6"&gt;
              &lt;iodef:Port&gt;23&lt;/iodef:Port&gt;
            &lt;/iodef:Service&gt;
            &lt;iodef:OperatingSystem&gt;
              &lt;iodef:Description&gt;
                Example Surveillance Camera OS 2.1.1
              &lt;/iodef:Description&gt;
            &lt;/iodef:OperatingSystem&gt;
          &lt;/iodef:System&gt;
        &lt;/iodef:Flow&gt;
        &lt;iodef:EventData&gt;
          &lt;iodef:Flow&gt;
            &lt;iodef:System category="target"&gt;
              &lt;iodef:Node&gt;
                &lt;iodef:Address category="ipv4-addr"&gt;
                  198.51.100.1
                &lt;/iodef:Address&gt;
              &lt;/iodef:Node&gt;
              &lt;iodef:NodeRole category="honeypot"/&gt;
              &lt;iodef:Service ip-protocol="6"&gt;
                &lt;iodef:Port&gt;23&lt;/iodef:Port&gt;
              &lt;/iodef:Service&gt;
            &lt;/iodef:System&gt;
          &lt;/iodef:Flow&gt;
        &lt;/iodef:EventData&gt;
        &lt;iodef:EventData&gt;
          &lt;iodef:Flow&gt;
            &lt;iodef:System category="target"&gt;
              &lt;iodef:Node&gt;
                &lt;iodef:Address category="ipv4-addr"&gt;
                  198.51.100.94
                &lt;/iodef:Address&gt;
              &lt;/iodef:Node&gt;
              &lt;iodef:NodeRole category="honeypot"/&gt;
              &lt;iodef:Service ip-protocol="6"&gt;
                &lt;iodef:Port&gt;23&lt;/iodef:Port&gt;
              &lt;/iodef:Service&gt;
            &lt;/iodef:System&gt;
          &lt;/iodef:Flow&gt;



<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


        &lt;/iodef:EventData&gt;
        &lt;iodef:EventData&gt;
          &lt;iodef:Flow&gt;
            &lt;iodef:System category="target"&gt;
              &lt;iodef:Node&gt;
                &lt;iodef:Address category="ipv4-addr"&gt;
                  198.51.100.237
                &lt;/iodef:Address&gt;
              &lt;/iodef:Node&gt;
              &lt;iodef:NodeRole category="honeypot"/&gt;
              &lt;iodef:Service ip-protocol="6"&gt;
                &lt;iodef:Port&gt;2323&lt;/iodef:Port&gt;
              &lt;/iodef:Service&gt;
            &lt;/iodef:System&gt;
          &lt;/iodef:Flow&gt;
        &lt;/iodef:EventData&gt;
      &lt;/iodef:EventData&gt;
    &lt;/iodef:Incident&gt;
  &lt;/IODEF-Document&gt;
































<span class="grey">Kampanakis &amp; Suzuki           Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc8274">RFC 8274</a>                     IODEF Guidance                November 2017</span>


Authors' Addresses

   Panos Kampanakis
   Cisco Systems

   Email: pkampana@cisco.com


   Mio Suzuki
   NICT
   4-2-1, Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: mio@nict.go.jp




































Kampanakis &amp; Suzuki           Informational                    [Page 33]
</pre>