| MILE Working Group | P. Kampanakis |
| Internet-Draft | Cisco Systems |
| Intended status: Informational | M. Suzuki |
| Expires: September 30, 2017 | NICT |
| March 29, 2017 |
IODEF Usage Guidance
draft-ietf-mile-iodef-guidance-09
The Incident Object Description Exchange Format v2 [RFC7970] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. 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 can leverage IODEF for incident sharing. This document provides guidelines for IODEF practitioners. It also addresses how common security indicators can be represented in IODEF and use-cases of how IODEF is being. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 30, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Incident Object Description Exchange Format v2 [RFC7970] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. 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 be able to describe all the possible fields that would be needed in a security incident exchange. Thus, IODEF contains a plethora of data constructs that could potentially make it harder for IODEF implementers to decide which are the most important ones to use. Additionally, in the IODEF schema, there exist multiple fields and classes which do not necessarily need to be used in every possible data exchange. Moreover, some IODEF classes are useful only in rare security events representation exchanges. This document tries to address how to avoid these concerns. It also addresses how common security indicators can be represented in IODEF. It points out the most important IODEF classes for an implementer and describe other ones that are not as important. Also, it presents some common challenges for IODEF implementers and how to address them. The end goal of this document is to make IODEF's use by vendors easier and encourage wider adoption of the model by CSIRTs around the world.
Section 3 discusses the recommended classes and how an IODEF implementer should chose the classes to implement. Section 4 presents common considerations a practicioner will come across and how to address them. Section 5 goes over some common uses of IODEF.
The terminology used in this document follows the one defined in [RFC5070] and [RFC7203].
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 [RFC2119].
It is important for IODEF practitioners to be able to distinguish how the IODEF classes will be used in incident information exchanges. To do that one has to follow a strategy according to which of the various IODEF classes will be implemented. It is also important to know the most common classes that will be used to describe common security incidents or indicators. Thus, this section describes the most important classes and factors an IODEF practicioner should take into consideration before using IODEF, or designing an implementation.
+-------------------------+
| Incident |
+-------------------------+
| ENUM purpose |<>----------[ IncidentID ]
| |<>----------[ GenerationTime ]
| |<>--{1..*}--[ Contact ]
+-------------------------+
Minimal-style Incident class
IODEF includes some mandatory classes. An IODEF document MUST include at least an Incident class and a version attribute. An Incident MUST contain three minimal mandatory-to-implement classes. An Incident class needs to have a Generation time and IncidentID class and at least one Contact class. The structure of the minimal-style Incident class follows below.
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 Email class, SHOULD be implemented so that the IODEF document can be practical.
Implementers can refer to Appendix B and Section 7 of [RFC7970] for example IODEF v2 documents.
There is no need for an practicioner to use or implement IODEF classes and fields other than the minimal ones (Section 3.1) and the ones that are necessary for her use-cases. The implementer should carefully look into the schema and decide classes to implement (or not).
For example, if we have has 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 hosts and victim hosts, which information could help automated filtering or sink-hole operations.
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 and the necessary included in it classes will be implemented instead of the EventData class and its subclasses.
In summary, an implementer SHOULD identify her 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 is not always necessary. Other external schemata can also be used in IODEF to describe incidents or indicators which should be treated accordingly only if the implementer's IODEF use-cases require external schema support.
[RFC7970] contains classes that can describe attack Methods, Events, Indicents, how they were discovered and the Assessment of the reprecussions of the incident to the victim. It is important for IODEF users to know the distinction between these classes in order to decide which ones fulfills their use-cases.
An IndicatorData class depicts a threat indicator or observable that could be used to describe a threat that does not necessarily mean that an exploit happened. For example, we could see an attack happening 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 as an incident report of something that took place.
Classes like Discovery, Assessment, Method, RecoveryTime are used in conjuction with EventData as they related 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.
When defining the IODEF use strategy practitioners need to consider some common options defined in standards.
The IODEF format includes the Reference class that refers to 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 [RFC7495]. The Enumeration Reference Format specifies a format to include enumeration values from external data representations into IODEF like CVE, and manages references to external representations using IANA registry. Practitioners SHOULD only support external enumerations that are expected to be used in IODEF documents for their use-cases.
The IODEF data model ([RFC7970]) is extensible. Many class attributes and their values can be extended using the "ext-*" prefix. Additional classed can also be defined by using the AdditionalData and RecordItem classes. An extension to the AdditionalData class for reporting Phishing emails is defined in [RFC5901]. Information about extending IODEF class attributes and enumerated values can be found in Section 5 of [RFC7970].
Additionally, IODEF can import existing schemata by using an extension framework defined in [RFC7203]. 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, CVRF and OVAL. Thus, [RFC7203] enhances the IODEF capabilities without further extending the data model.
IODEF practitioners SHOULD NOT consider using their own IODEF extensions unless data cannot be represented using existing standards or importing them in and IODEF document using [RFC7203] is not a suitable option.
An IODEF [RFC7970] document can describe incident reports and indicators. The Indicator class can include references to other indicators, observables and more classes the 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 indicator 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 that is used to add the indicator predicate logic when grouping more than one indicators or observables.
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 Section 3.29.5 of [RFC7970] the IndicatorExpression element operator defines the operator applied to all the child element 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 evaluated with the operator of their parent.
Users can refer to Appendix A for example uses of the IndicatorExpressions in an IODEF v2.
The information conveyed in IODEF documents SHOULD be treated carefully 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 RID 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 goes beyond IODEF. The recipient of the IODEF document needs to follow the guidelines, but these guidelines themselves do not provide any enforcement measures. For that purpose, practitioners SHOULD consider appropriate measures, technical or operational.
IODEF is currently used by various organizations in order to represent security incidents and share incident and threat information between security operations organizations.
In order to use IODEF, tools like IODEF parsers are necessary. [I-D.ietf-mile-implementreport] describes a set of IODEF implementations and uses by various vendors and CERT organizations. The document does not specify any specific 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. Section 7 also includes practical IODEF use guidelines. Implementers are encouraged to refer to [I-D.ietf-mile-implementreport]. [implementations], on the other hand, includes various vendor incident reporting products that can consume and export in IODEF format.
Various vendors organized and executed an exercise where multiple threat indicators were exchanged using IODEF. The transport protocol used was RID. The threat information shared included incidents like DDoS attacks. Malware and Spear-Phishing. As this was a proof-of-concept (PoC) exercise only example information (no real threats) were shared as part of the exchanges.
____________ ____________
| Vendor X | | Vendor Y |
| RID Agent |_______-------------________| RID Agent |
|___________| | Internet | |___________|
-------------
---- RID Report message --->
-- carrying IODEF example ->
--------- over TLS -------->
<----- RID Ack message -----
<--- in case of failure ----
PoC peering topology
[RFC6545] and [RFC6546], was also proven in this exercise.
The first use-case included sharing of Malware Data Related to an Incident between CSIRTs. After Entity X detected an incident, she 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:
Another use-case was sharing Distributed Denial of Service (DDoS) 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 CSIT contacts their ISP, Entity Y, and shares information with them about the attack traffic characteristics. Entitty 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:
One more use-case was sharing spear-phishing email information as explained in the following scenario: The board members of several defense contractors receive an 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 which came with the email. The board members are also asked to click on a URL which 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 was part of this PoC.
Appendix B includes some of the incident IODEF example information that was exchanged by the organizations' RID Agents as part of this proof-of-concept.
Other use-cases of IODEF could be:
This document does not incur any new security issues, since it only talks about the usage of IODEF, which is defined in RFC5070. Nevertheless, readers of this document SHOULD refer to the security consideration section of [RFC5070] and [RFC7970].
[ EDNOTE: To delete during last call. ]
version -08 updates:
version -07 updates:
version -06 updates:
version -05 updates:
version -04 updates:
version -03 updates:
version -02 updates:
| [I-D.ietf-mile-implementreport] | Inacio, C. and D. Miyamoto, "MILE Implementation Report", Internet-Draft draft-ietf-mile-implementreport-10, November 2016. |
| [implementations] | , , "Implementations on IODEF" |
In the following example the EventData class evaluates as a Flow of one System with source address being (10.10.10.104 OR 10.10.10.106) AND target address 10.1.1.1.
<!-- ...XML code omitted... -->
<IndicatorData>
<Indicator>
<IndicatorID name="csirt.example.com" version="1">
G90823490
</IndicatorID>
<Description>C2 domains</Description>
<IndicatorExpression operator="and">
<IndicatorExpression operator="or">
<Observable>
<System category="source" spoofed="no">
<Node>
<Address category="ipv4-addr">
10.10.10.104
</Address>
</Node>
</System>
</Observable>
<Observable>
<System category="source" spoofed="no">
<Node>
<Address category="ipv4-addr">
10.10.10.106
</Address>
</Node>
</System>
</Observable>
</IndicatorExpression>
<Observable>
<System category="target" spoofed="no">
<Node>
<Address category="ipv4-addr">
10.1.1.1
</Address>
</Node>
</System>
</Observable>
</IndicatorExpression>
</Indicator>
</IndicatorData>
<!-- ...XML code omitted... -->
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.
<!-- ...XML code omitted... -->
<IndicatorData>
<Indicator>
<IndicatorID name="csirt.example.com" version="1">
A4399IWQ
</IndicatorID>
<Description>File hash watchlist</Description>
<IndicatorExpression operator="or">
<Observable>
<FileData>
<File>
<FileName>dummy.txt</FileName>
<HashData>
<Hash>
<ds:DigestMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
</ds:DigestValue>
</Hash>
</HashData>
</File>
</FileData>
</Observable>
<Observable>
<FileData>
<File>
<FileName>dummy2.txt</FileName>
<HashData>
<Hash>
<ds:DigestMethod Algorithm=
"http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
</ds:DigestValue>
</Hash>
</HashData>
</File>
</FileData>
</Observable>
</IndicatorExpression>
</Indicator>
</IndicatorData>
<!-- ...XML code omitted... -->
Below some of the incident IODEF example information that was exchanged by the vendors as part of this proof-of-concept Inter-vendor and Service Provider Exercise.
This example indicates malware and related URL for file delivery.
<?xml version="1.0" encoding="UTF-8"?>
<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">
<iodef:Incident purpose="reporting">
<iodef:IncidentID name="csirt.example.com">
189801
</iodef:IncidentID>
<iodef:ReportTime>2012-12-05T12:20:00+00:00</iodef:ReportTime>
<iodef:GenerationTime>2012-12-05T12:20:00+00:00</iodef:GenerationTime>
<iodef:Description>Malware and related indicators</iodef:Description>
<iodef:Assessment occurrence="potential">
<iodef:SystemImpact severity="medium" type="breach-privacy">
<iodef:Description>Malware with C&C
</iodef:Description>
</iodef:SystemImpact>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>example.com CSIRT
</iodef:ContactName>
<iodef:Email>
<iodef:EmailTo>contact@csirt.example.com
</iodef:EmailTo>
</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.200
</iodef:Address>
<iodef:Address category="site-uri">
/log-bin/lunch_install.php?aff_id=1&lunch_id=1&maddr=&action=install
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="www"/>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:Incident>
</IODEF-Document>
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 [RFC7970].
<?xml version="1.0" encoding="UTF-8"?>
<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">
<iodef:Incident purpose="reporting" restriction="default">
<iodef:IncidentID name="csirt.example.com">
189701
</iodef:IncidentID>
<iodef:DetectTime>2013-02-05T01:15:45+00:00</iodef:DetectTime>
<iodef:StartTime>2013-02-05T00:34:45+00:00</iodef:StartTime>
<iodef:ReportTime>2013-02-05T01:34:45+00:00</iodef:ReportTime>
<iodef:GenerationTime>2013-02-05T01:15:45+00:00</iodef:GenerationTime>
<iodef:Description>DDoS Traffic Seen</iodef:Description>
<iodef:Assessment occurrence="actual">
<iodef:SystemImpact severity="medium" type="availability-system">
<iodef:Description>DDoS Traffic
</iodef:Description>
</iodef:SystemImpact>
<iodef:Confidence rating="high"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Dummy Test</iodef:ContactName>
<iodef:Email>
<iodef:EmailTo>contact@dummytest.com
</iodef:EmailTo>
</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Description>
Dummy Test sharing with ISP1
</iodef:Description>
<iodef:Method>
<iodef:Reference>
<iodef:URL>
http://blog.spiderlabs.com/2011/01/loic-ddos-
analysis-and-detection.html
</iodef:URL>
<iodef:URL>
http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
</iodef:URL>
<iodef:Description>
Low Orbit Ion Cannon User Agent
</iodef:Description>
</iodef:Reference>
</iodef:Method>
<iodef:Flow>
<iodef:System category="source" spoofed="no">
<iodef:Node>
<iodef:Address category="ipv4-addr">
192.0.2.104
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="no">
<iodef:Node>
<iodef:Address category="ipv4-addr">
192.0.2.106
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="yes">
<iodef:Node>
<iodef:Address category="ipv4-net">
198.51.100.0/24
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="yes">
<iodef:Node>
<iodef:Address category="ipv6-addr">
2001:db8:dead:beef::1
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
203.0.113.1
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="sensor">
<iodef:Node>
</iodef:Node>
<iodef:Description>
Information provided in Flow class instance is from
Inspection of traffic from network tap
</iodef:Description>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="other"/>
</iodef:EventData>
<iodef:IndicatorData>
<iodef:Indicator>
<iodef:IndicatorID name="csirt.example.com" version="1">
G83345941
</iodef:IndicatorID>
<iodef:Description>
User-Agent string
</iodef:Description>
<iodef:Observable>
<iodef:BulkObservable type="http-user-agent">
<iodef:BulkObservableList>
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">
</iodef:BulkObservableList>
</iodef:BulkObservable>
</iodef:Observable>
</iodef:Indicator>
</iodef:IndicatorData>
</iodef:Incident>
</IODEF-Document>
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 [RFC7970].
<?xml version="1.0" encoding="UTF-8"?>
<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#">
<iodef:Incident purpose="reporting">
<iodef:IncidentID name="csirt.example.com">
189601
</iodef:IncidentID>
<iodef:DetectTime>2013-01-04T08:06:12+00:00</iodef:DetectTime>
<iodef:StartTime>2013-01-04T08:01:34+00:00</iodef:StartTime>
<iodef:EndTime>2013-01-04T08:31:27+00:00</iodef:EndTime>
<iodef:ReportTime>2013-01-04T09:15:45+00:00</iodef:ReportTime>
<iodef:GenerationTime>2013-01-04T09:15:45+00:00</iodef:GenerationTime>
<iodef:Description>
Zeus Spear Phishing E-mail with Malware Attachment
</iodef:Description>
<iodef:Assessment occurrence="potential">
<iodef:SystemImpact severity="medium" type="takeover-system">
<iodef:Description>
Malware with Command and Control Server and System Changes
</iodef:Description>
</iodef:SystemImpact>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>example.com CSIRT</iodef:ContactName>
<iodef:Email>
<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>
</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Description>
Targeting Defense Contractors,
specifically board members attending Dummy Con
</iodef:Description>
<iodef:Method>
<iodef:Reference observable-id="ref-1234">
<iodef:Description>Zeus</iodef:Description>
</iodef:Reference>
</iodef:Method>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="site-uri">
http://www.zeusevil.example.com
</iodef:Address>
<iodef:Address category="ipv4-addr">
192.0.2.166
</iodef:Address>
<iodef:Address category="asn">
65535
</iodef:Address>
<iodef:Address category="ext-value"
ext-category="as-name">
EXAMPLE-AS - University of Example"
</iodef:Address>
<iodef:Address category="ext-value"
ext-category="as-prefix">
192.0.2.0/24
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="malware-distribution"/>
</iodef:System>
</iodef:Flow>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:DomainData>
<Name>mail1.evildave.example.com</Name>
</iodef:DomainData>
<iodef:Address category="ipv4-addr">
198.51.100.6
</iodef:Address>
<iodef:Address category="asn">
65534
</iodef:Address>
<iodef:Address category="ext-value"
ext-category="as-name">
EXAMPLE-AS - University of Example
</iodef:Address>
<iodef:DomainData>
<iodef:Name>evildave.example.com</iodef:Name>
<iodef:DateDomainWasChecked>2013-01-04T09:10:24+00:00
</iodef:DateDomainWasChecked>
<!-- <iodef:RelatedDNS RecordType="MX"> -->
<iodef:RelatedDNS dtype="string">
evildave.example.com MX prefernce = 10, mail exchanger
= mail1.evildave.example.com
</iodef:RelatedDNS>
<iodef:RelatedDNS dtype="string">
mail1.evildave.example.com
internet address = 198.51.100.6
</iodef:RelatedDNS>
<iodef:RelatedDNS dtype="string">
zuesevil.example.com. IN TXT \"v=spf1 a mx -all\"
</iodef:RelatedDNS>
</iodef:DomainData>
</iodef:Node>
<iodef:NodeRole category="mail">
<iodef:Description>
Sending phishing mails
</iodef:Description>
</iodef:NodeRole>
<iodef:Service>
<iodef:EmailData>
<iodef:EmailFrom>
emaildave@evildave.example.com
</iodef:EmailFrom>
<iodef:EmailSubject>
Join us at Dummy Con
</iodef:EmailSubject>
<iodef:EmailX-Mailer>
StormRider 4.0
</iodef:EmailX-Mailer>
</iodef:EmailData>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
203.0.113.2
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="other"/>
<iodef:Record>
<iodef:RecordData>
<iodef:FileData observable-id="fd-1234">
<iodef:File>
<iodef:FileName>
Dummy Con Sign Up Sheet.txt
</iodef:FileName>
<iodef:FileSize>
152
</iodef:FileSize>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
141accec23e7e5157de60853cb1e01bc38042d
08f9086040815300b7fe75c184
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
</iodef:FileData>
</iodef:RecordData>
<iodef:RecordData>
<iodef:CertificateData>
<iodef:Certificate>
<ds:X509Data>
<ds:X509IssuerSerial>
<ds:X509IssuerName>FakeCA
</ds:X509IssuerName>
<ds:X509SerialNumber>
57482937101
</ds:X509SerialNumber>
</ds:X509IssuerSerial>
<ds:X509SubjectName>EvilDaveExample
</ds:X509SubjectName>
</ds:X509Data>
</iodef:Certificate>
</iodef:CertificateData>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
</iodef:Incident>
</IODEF-Document>
In this test, malware information was exchanged using RID and IODEF. The information included file hashes, registry setting changes and the C&C servers the malware uses.
<?xml version="1.0" encoding="UTF-8"?>
<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#">
<iodef:Incident purpose="reporting">
<iodef:IncidentID name="csirt.example.com">
189234
</iodef:IncidentID>
<iodef:ReportTime>2013-03-07T16:14:56.757+05:30</iodef:ReportTime>
<iodef:GenerationTime>2013-03-07T16:14:56.757+05:30</iodef:GenerationTime>
<iodef:Description>
Malware and related indicators identified
</iodef:Description>
<iodef:Assessment occurrence="potential">
<iodef:SystemImpact severity="medium" type="breach-proprietary">
<iodef:Description>
Malware with Command and Control Server and System Changes
</iodef:Description>
</iodef:SystemImpact>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>example.com CSIRT</iodef:ContactName>
<iodef:Email>
<iodef:EmailTo>contact@csirt.example.com</iodef:EmailTo>
</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Method>
<iodef:Reference>
<iodef:URL>
http://www.threatexpert.example.com/report.aspx?
md5=e2710ceb088dacdcb03678db250742b7
</iodef:URL>
<iodef:Description>Zeus</iodef:Description>
</iodef:Reference>
</iodef:Method>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr" observable-id="addr-c2-91011-001">
203.0.113.200
</iodef:Address>
<iodef:Address category="site-uri" observable-id="addr-c2-91011-002">
http://zeus.556677889900.example.com/log-bin/
lunch_install.php?aff_id=1&amp;
lunch_id=1&amp;maddr=&amp;
action=install
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="c2-server"/>
</iodef:System>
</iodef:Flow>
<iodef:Record>
<iodef:RecordData>
<iodef:FileData observable-id="file-91011-001">
<iodef:File>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>
<ds:DigestValue>
MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJFREZG
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
<iodef:File>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#md5"/>
<ds:DigestValue>
MHgyRTg4ODA5ODBENjI0NDdFOTc5MEFGQTg5NTEzRjBBNA==
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
</iodef:FileData>
<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-001">
<iodef:Key registryaction="add-value">
<iodef:KeyName>
HKLM\Software\Microsoft\Windows\
CurrentVersion\Run\tamg
</iodef:KeyName>
<iodef:Value>
?\?\?%System%\wins\mc.exe\?\??
</iodef:Value>
</iodef:Key>
<iodef:Key registryaction="modify-value">
<iodef:KeyName>HKLM\Software\Microsoft\
Windows\CurrentVersion\Run\dqo
</iodef:KeyName>
<iodef:Value>"\"\"%Windir%\Resources\
Themes\Luna\km.exe\?\?"
</iodef:Value>
</iodef:Key>
</iodef:WindowsRegistryKeysModified>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:EventData>
<iodef:Method>
<iodef:Reference>
<iodef:URL>
http://www.threatexpert.example.com/report.aspx?
md5=c3c528c939f9b176c883ae0ce5df0001
</iodef:URL>
<iodef:Description>Cridex</iodef:Description>
</iodef:Reference>
</iodef:Method>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr" observable-id="addr-c2-91011-003">
203.0.113.100
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="c2-server"/>
<iodef:Service ip-protocol="6">
<iodef:Port>8080</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Record>
<iodef:RecordData>
<iodef:FileData observable-id="file-91011-002">
<iodef:File>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha1"/>
<ds:DigestValue>
MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM1ODVFMzQzRTcxNDFD
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
</iodef:FileData>
<iodef:FileData observable-id="file-91011-003">
<iodef:File>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#md5"/>
<ds:DigestValue>
MHg0M0NEODUwRkNEQURFNDMzMEE1QkVBNkYxNkVFOTcxQw==
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
</iodef:FileData>
<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-002">
<iodef:Key registryaction="add-value">
<iodef:KeyName>
HKLM\Software\Microsoft\Windows\
CurrentVersion\Run\KB00121600.exe
</iodef:KeyName>
<iodef:Value>
\?\?%AppData%\KB00121600.exe\?\?
</iodef:Value>
</iodef:Key>
</iodef:WindowsRegistryKeysModified>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:IndicatorData>
<iodef:Indicator>
<iodef:IndicatorID name="csirt.example.com" version="1">
ind-91011
</iodef:IndicatorID>
<iodef:Description>
evil c2 server, file hash, and registry key
</iodef:Description>
<iodef:IndicatorExpression operator="or">
<iodef:IndicatorExpression operator="or">
<iodef:Observable>
<iodef:Address category="site-uri" observable-id="addr-qrst">
http://foo.example.com:12345/evil/cc.php
</iodef:Address>
</iodef:Observable>
<iodef:Observable>
<iodef:Address category="ipv4-addr" observable-id="addr-stuv">
192.0.2.1
</iodef:Address>
</iodef:Observable>
<iodef:Observable>
<iodef:Address category="ipv4-addr" observable-id="addr-tuvw">
198.51.100.1
</iodef:Address>
</iodef:Observable>
<iodef:Observable>
<iodef:Address category="ipv6-addr" observable-id="addr-uvwx">
2001:db8:dead:beef::1
</iodef:Address>
</iodef:Observable>
<iodef:ObservableReference uid-ref="addr-c2-91011-001"/>
<iodef:ObservableReference uid-ref="addr-c2-91011-002"/>
<iodef:ObservableReference uid-ref="addr-c2-91011-003"/>
</iodef:IndicatorExpression>
<iodef:IndicatorExpression operator="and">
<iodef:Observable>
<iodef:FileData observable-id="file-91011-000">
<iodef:File>
<iodef:HashData scope="file-contents">
<iodef:Hash>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>
141accec23e7e5157de60853cb1e01bc38042d08f9086040815300b7fe75c184
</ds:DigestValue>
</iodef:Hash>
</iodef:HashData>
</iodef:File>
</iodef:FileData>
</iodef:Observable>
<iodef:Observable>
<iodef:WindowsRegistryKeysModified observable-id="regkey-91011-000">
<iodef:Key registryaction="add-key"
observable-id="regkey-vwxy">
<iodef:KeyName>
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR
</iodef:KeyName>
</iodef:Key>
<iodef:Key registryaction="add-key"
observable-id="regkey-wxyz">
<iodef:KeyName>
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR\Parameters
</iodef:KeyName>
<iodef:Value>
\"\"%AppData%\KB00121600.exe\"\"
</iodef:Value>
</iodef:Key>
<iodef:Key registryaction="add-value"
observable-id="regkey-xyza">
<iodef:KeyName>
HKLM\SYSTEM\CurrentControlSet\Services\
.Net CLR\Parameters\ServiceDll
</iodef:KeyName>
<iodef:Value>C:\bad.exe</iodef:Value>
</iodef:Key>
<iodef:Key registryaction="modify-value"
observable-id="regkey-zabc">
<iodef:KeyName>
HKLM\SYSTEM\CurrentControlSet\
Services\.Net CLR\Parameters\Bar
</iodef:KeyName>
<iodef:Value>Baz</iodef:Value>
</iodef:Key>
</iodef:WindowsRegistryKeysModified>
</iodef:Observable>
</iodef:IndicatorExpression>
<iodef:IndicatorExpression operator="or">
<iodef:IndicatorExpression operator="and">
<iodef:ObservableReference uid-ref="file-91011-001"/>
<iodef:ObservableReference uid-ref="regkey-91011-001"/>
</iodef:IndicatorExpression>
<iodef:IndicatorExpression operator="and">
<iodef:IndicatorExpression operator="or">
<iodef:ObservableReference uid-ref="file-91011-002"/>
<iodef:ObservableReference uid-ref="file-91011-003"/>
</iodef:IndicatorExpression>
<iodef:ObservableReference uid-ref="regkey-91011-002"/>
</iodef:IndicatorExpression>
</iodef:IndicatorExpression>
</iodef:IndicatorExpression>
</iodef:Indicator>
</iodef:IndicatorData>
</iodef:Incident>
</IODEF-Document>
The 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 in [I-D.ietf-mile-implementreport]. The IODEF version used for the data representation was based on [RFC7970].
<?xml version="1.0" encoding="UTF-8"?>
<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">
<iodef:Incident purpose="reporting">
<iodef:IncidentID name="csirt.example.com">
189802
</iodef:IncidentID>
<iodef:ReportTime>2017-03-01T01:15:00+09:00</iodef:ReportTime>
<iodef:GenerationTime>2017-03-01T01:15:00+09:00</iodef:GenerationTime>
<iodef:Description>IoT Malware and related indicators</iodef:Description>
<iodef:Assessment occurrence="potential">
<iodef:SystemImpact severity="medium" type="takeover-system">
<iodef:Description>IoT Malware is scanning other hosts
</iodef:Description>
</iodef:SystemImpact>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>example.com CSIRT
</iodef:ContactName>
<iodef:Email>
<iodef:EmailTo>contact@csirt.example.com
</iodef:EmailTo>
</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Discovery source="nidps">
<iodef:Description>
Detected by darknet monitoring
</iodef:Description>
</iodef:Discovery>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">
192.0.2.210
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="camera"/>
<iodef:Service ip-protocol="6">
<iodef:Port>23</iodef:Port>
</iodef:Service>
<iodef:OperatingSystem>
<iodef:Description>
Example Surveillance Camera OS 2.1.1
</iodef:Description>
</iodef:OperatingSystem>
</iodef:System>
</iodef:Flow>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
198.51.100.1
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="honeypot"/>
<iodef:Service ip-protocol="6">
<iodef:Port>23</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
198.51.100.94
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="honeypot"/>
<iodef:Service ip-protocol="6">
<iodef:Port>23</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
198.51.100.237
</iodef:Address>
</iodef:Node>
<iodef:NodeRole category="honeypot"/>
<iodef:Service ip-protocol="6">
<iodef:Port>2323</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:EventData>
</iodef:Incident>
</IODEF-Document>