RFC 8274
Incident Object Description Exchange Format Usage Guidance
Incident Object Description Exchange Format Usage Guidance 🎀
Okay bestie, this is RFC 8274, and it's a total gift for anyone building tools around IODEF 💖 It's an Informational document, not a standards-track spec. It's from the IETF, dated November 2017, ISSN 2070-1721. The authors are P. Kampanakis (Cisco Systems) and M. Suzuki (NICT). The title block doesn't list anything it obsoletes or updates, so it stands on its own 🦋
Abstract ✨
Okay so, IODEF v2 ([RFC 7970]) is a data format for sharing info about computer security incidents, which is the stuff CSIRTs (Computer Security Incident Response Teams) swap all the time 🔥 The model has SO many options that it can be genuinely hard for security folks to build tools that use it. This doc gives IODEF implementers guidelines, covers how common security indicators can be represented in IODEF, and shows use cases of how IODEF is actually being used. The goal is to make vendors' lives easier and get CSIRTs around the world adopting it faster and wider 🌍💅
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🧐
For the latest status, errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8274 ✨
Copyright Notice 💅
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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Implementation and Use Strategy . . . . . . . . . . . . . . . 3
3.1. Minimal IODEF Document . . . . . . . . . . . . . . . . . 3
3.2. Information Represented . . . . . . . . . . . . . . . . . 4
3.3. IODEF Classes . . . . . . . . . . . . . . . . . . . . . . 5
4. IODEF Usage Considerations . . . . . . . . . . . . . . . . . 6
4.1. External References . . . . . . . . . . . . . . . . . . . 6
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Indicator Predicate Logic . . . . . . . . . . . . . . . . 7
4.4. Disclosure Level . . . . . . . . . . . . . . . . . . . . 7
5. IODEF Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Implementations . . . . . . . . . . . . . . . . . . . . . 8
5.2. Inter-vendor and Service Provider Exercise . . . . . . . 8
5.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Indicator Predicate Logic Examples . . . . . . . . . 14
Appendix B. Inter-vendor and Service Provider Exercise Examples 16
B.1. Malware Delivery URL . . . . . . . . . . . . . . . . . . 16
B.2. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B.3. Spear Phishing . . . . . . . . . . . . . . . . . . . . . 20
B.4. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.5. IoT Malware . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 331. Introduction 🦋
Okay, so IODEF v2 [RFC7970] is the data representation that gives you a framework for sharing computer security incident info, the kind CSIRTs trade all the time 💖 The IODEF data model is made of multiple classes and data types, and they're all defined in the IODEF XML schema 🧚
Here's the thing though. The IODEF schema was designed to describe every field you could possibly need in an incident exchange, so there's a PLETHORA of data constructs and it can be hard for implementers to figure out which ones actually matter 😭 On top of that, lots of fields and classes don't need to show up in every single exchange, and some classes are only useful in rare situations. This doc is here to fix that vibe 💅
It also shows how common security indicators can be represented in IODEF, points out which classes matter most to an implementer, describes the less important ones, and calls out common pitfalls along with how to deal with them 🍓 The endgame is making IODEF easier for vendors to use and getting CSIRTs around the world to adopt the model more widely 🌈
Section 3 covers the recommended classes and how an IODEF implementer should pick which ones to implement. Section 4 walks through common considerations a practitioner will run into and how to handle them. Section 5 goes over some common uses of IODEF ✨
2. Terminology 💜
The terminology used in this document is defined in [RFC7970] 📚
3. Implementation and Use Strategy 🔥
It's super important for IODEF implementers to know how the IODEF classes get used in incident information exchanges 🧐 It's also key to understand the most common classes that describe common security incidents or indicators. This section covers the most important classes, plus the factors an IODEF practitioner should weigh before using IODEF or designing an implementation 💖
3.1. Minimal IODEF Document 🍓
Every IODEF document has to include at least an Incident class, an xml:lang attribute that defines the supported language, and the IODEF version attribute 🎀 An Incident needs a purpose attribute and three mandatory-to-implement elements: the GenerationTime class (which describes when the incident happened), an IncidentID class, and at least one Contact class 😤 Here's the minimal IODEF-Document class, shown in Figure 1 👇
+---------------+ +--------------+
|IODEF-Document | | Incident |
+---------------+ +--------------+ +--------------+
|STRING version |<>--{1..*}--| ENUM purpose |<>---------| IncidentID |
|ENUM xml:lang | | | +--------------+
| | | | | STRING name |
+---------------+ | | +--------------+
| |
| |<>---------[GenerationTime]
| |
| | +--------------+
| |<>-{1..*}--[ Contact |
+--------------+ +--------------+
| ENUM role |
| ENUM type |
+--------------+
Figure 1: Minimal IODEF-Document ClassThe IncidentID class has to contain at least a name attribute 🏷️
The Contact class needs the type and role attributes. The IODEF v2 spec doesn't require any elements inside it, BUT you should totally implement at least one of them, like an Email class, so your IODEF document is actually useful 💌
Section 7.1 of [RFC7970] has a minimal IODEF document with only the mandatory classes and attributes. Implementers can also check Section 7 of [RFC7970] and Appendix B of this document for examples of IODEF v2 documents 🦋
3.2. Information Represented 🌸
Okay, so there's no need for a practitioner to use or implement IODEF classes and fields beyond the minimal ones (see Section 3.1) and whatever her use cases actually need. The implementer should carefully look into the schema and decide which classes to implement (or not) 🧚
For example, if Distributed Denial of Service (DDoS) is a potential use case, then the Flow class and the info inside it are the most important ones to use. The Flow class describes info about the attacker and victim hosts, which could help with automated filtering or sinkhole operations 🔥
Another potential use case is malware command and control (C2) 😈 After modern malware infects a device, it usually connects to one or more C2 servers to get instructions from its master, and it might exfiltrate info too. To protect against that, it's important to interrupt the C2 communication by filtering the activity. IODEF can describe C2 activities using the Flow and ServiceName classes 🛡️
For use cases where indicators need to be described, the IndicatorData class gets implemented instead of the EventData class 💜
Bottom line: an implementer should identify the use cases and find the classes needed to support in IODEF v2. Implementing and parsing ALL the IODEF classes can be cumbersome, and sometimes it's just unnecessary 😅 Other external schemata can also be used in IODEF to describe incidents or indicators. External schemata should only be parsed accordingly if the implementer's IODEF use cases actually require that external schema info. But even when an IODEF implementation can't parse an external schema, the IODEF report can still be valuable to an incident response team. The info can also be useful when it's shared further with content consumers who CAN parse it 🫶
IODEF supports multiple language translations of free-form, ML_STRING text in all classes [RFC7970] 🌈 So text in Description elements can be translated into different languages using a translation identifier in the class. Implementers should be able to parse iodef:MLStringType classes and pull out only the info relevant to the languages they care about ✨
3.3. IODEF Classes ✨
okay so [RFC7970] has a whole bunch of classes that can describe attack Methods, Events, Incidents, Indicators, how they got discovered, and the Assessment of the damage to the victim 😭🎀 it's SO important that IODEF users know how these classes differ, so they can pick the ones that actually fit their use case 💅
an IndicatorData class is giving threat indicator or observable vibes, describing a threat that resulted in an attempted attack 🕵️♀️ like, we could see an attack happening (described in the IndicatorData), but it might have been prevented and never turned into an incident or security event 🙈 on the flip side, an EventData class usually describes a security event and can be considered a report of something that actually took place 🔥
Discovery, Assessment, Method, and RecoveryTime are classes that get used together with EventData, since they relate to the incident report described in the EventData 🫶 and the RelatedActivity class can reference an incident, an indicator, or other related threat activity 🦋
while you're deciding which classes matter for your use cases, IODEF users should carefully evaluate the classes they actually need and how they get used, so they don't do unnecessary work 🧚 for example, if we only want to describe indicators in IODEF, then the implementation of Method or Assessment might not be important at all 💀
4. IODEF Usage Considerations 🌸
implementers need to think about some common, standardized options for their IODEF use strategy 💜
4.1. External References 🔗
the IODEF format includes the Reference class, which is used for externally defined information like a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique 🍓 to make info exchange smoother, the Reference class got extended to the enumeration reference format [RFC7495] 🌈 the enumeration reference format gives you a way to use external enumeration specifications (e.g., Common Vulnerabilities and Exposures (CVE)) that could define an enumeration format, specific enumeration values, or both ✨ external enumerations can vary a LOT, so implementers should only support the ones expected to describe their specific use cases 🎀
4.2. Extensions 🧩
the IODEF data model [RFC7970] is extensible, and tbh that's so iconic 👑 lots of 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 [RFC5901] 📧 info about extending IODEF class attributes and enumerated values can be found in Section 5 of [RFC7970] 💅
IODEF can also import existing schemata by using an extension framework defined in [RFC7203] 🫶 the framework lets IODEF users 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) ✨ [RFC7203] boosts IODEF capabilities without further extending the data model 💜
IODEF implementers should not use their own IODEF extensions unless the data cannot be represented using existing standards, or unless importing them in an IODEF document as defined in [RFC7203] is not a suitable option 🙅♀️
4.3. Indicator Predicate Logic 🧠
an IODEF document [RFC7970] 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's often common to need to group them together so they form a group of indicators that constitute a security threat 🕸️ for example, a botnet might have multiple command and control servers 🤖 that's why IODEF v2 introduced the IndicatorExpression class, which is used to add 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 Section 3.29.5 of [RFC7970], the IndicatorExpression element's 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 Appendix A for example uses of the IndicatorExpressions in an IODEF v2 📚
4.4. Disclosure Level 🔒
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 the sender expects the recipient to follow 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) [RFC6545] is used to transfer IODEF documents, since it can provide policy guidelines for handling them by using the RIDPolicy class 📜
the enforcement of disclosure guidelines is out of scope for IODEF 🙃 the recipient of the IODEF document needs to follow the guidelines, but the guidelines themselves don't provide any enforcement measures 🥲 for that purpose, implementers SHOULD consider appropriate privacy control measures, technical or operational, for their implementation 🔐
5. IODEF Uses 🌍
IODEF is currently used by various organizations to represent security incidents and share incident and threat information between security operations organizations 🫶
5.1. Implementations 🛠️
in order to use IODEF, tools like IODEF parsers are necessary 🧰 [RFC8134] 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 it does provide 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 Section 7 of [RFC8134] for practical IODEF usage guidelines 📖 on the other hand, [IODEF_IMP] includes various vendor incident reporting products that can consume and export in IODEF format 🛒
5.2. Inter-vendor and Service Provider Exercise 🦋
Okay bestie, so back in 2013 a limited number of vendors ran an interop exercise where they swapped threat indicators in IODEF 💖 The transport was RID. The threat info covered indicators from DDoS attacks, malware incidents, and spear phishing that targets specific people after harvesting info about them 💀 The whole point was a proof-of-concept (PoC) showing that even seemingly competing entities could use IODEF to exchange sanitized security info ✨ Since it was only a PoC, the exchanges only shared example info. No real threats, no cap 🙈
____________ ____________
| Vendor X | | Vendor Y |
| RID Agent |_______-------------________| RID Agent |
|___________| | Internet | |___________|
-------------
---- RID Report message --->
-- carrying IODEF example ->
--------- over TLS -------->
<----- RID Ack message -----
<--- in case of failure ----
Figure 2: PoC Peering TopologyFigure 2 shows how the RID interactions went down during the PoC 🌸 Participating orgs ran RID Agent software on their own premises, and the RID Agents formed peering relationships with other participating orgs. When Entity X had a new incident to share, it packaged it in IODEF and sent it to Entity Y over Transport Layer Security (TLS) in a RID Report message. If something was wrong with the message, Entity Y sent a RID Acknowledgement message back to Entity X, which included an application-level message describing the issue. Interoperability between RID Agents implementing [RFC6545] and [RFC6546] was also confirmed, which is so iconic 👑
The first use case was sharing malware data about an incident between CSIRTs 🧚 After Entity X detected an incident, it put data about the malware it found into a backend system. Then Entity X decided to share the incident info with Entity Y about that malware. That could be a human decision or part of an automated process.
Here are the steps for the malware info exchange:
- Entity X has a sharing agreement with Entity Y and has already been configured with the IP address of Entity Y's RID Agent.
- Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
- 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.
- Entity Y receives a RID Report message and sends a RID Acknowledgement message.
- 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 🔥 Entity X is a Critical Infrastructure and Key Resource (CIKR) company. It detects that its internet connection is saturated with an abnormal amount of traffic, and further investigation shows it's an actual DDoS attack. Entity X's CSIRT contacts their ISP, Entity Y, and shares info about the attack traffic characteristics. Entity X's ISP is getting overwhelmed by the traffic too, so it shares attack signatures and the IP addresses of the most prolific hosts with its adjacent ISPs. The drama is real 😭
Here are the steps for the DDoS info exchange:
- Entity X has a sharing agreement with Entity Y and has already been configured with the IP address of Entity Y's RID Agent.
- Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
- 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);
- (e) HTTP user agents used; and
- (f) IP addresses of C2 for a botnet.
- Entity Y receives a RID Report message and sends a RID Acknowledgement message.
- Entity Y stores the data in a format that makes it possible for the backend to know which source the data came from.
- Entity Y shares information with other ISP entities it has an established relationship with.
One more use case was sharing spear-phishing email info 🍓 The board members of several defense contractors get a targeted email inviting them to a conference in San Francisco. The email asks them to provide personally identifiable information, like home address, phone number, corporate email, and so on, in an attached document. It also asks them to click a URL to reach the conference sign-up page. One recipient thinks it's a phishing attempt and forwards the email to their corporate CSIRT for analysis. The CSIRT identifies it as an attempted spear-phishing incident and distributes the indicators to its sharing partners. Main character energy for the CSIRT, honestly 💅
Here are the steps for the spear-phishing info exchange between the CSIRTs that were part of this PoC:
- Entity X has a sharing agreement with Entity Y and has already been configured with the IP address of Entity Y's RID Agent.
- Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
- 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.
- Entity Y receives a RID Report message and sends a RID Acknowledgement message.
- Entity Y stores the data in a format that makes it possible for the backend to know which source the data came from.
Appendix B includes some of the IODEF example info that the organizations' RID Agents exchanged during this PoC 🎀
5.3. Use Cases 🌈
Other IODEF use cases, beyond the ones above, could look like this 💜
- 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.
- Suspected phishing emails could be shared amongst organizations and national agencies. Automation could validate the web content that the suspicious emails point 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 info sharing using IODEF. Literally so efficient ⭐
- When a certificate that should be revoked is found, 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, if the private key of a certificate is compromised, a third party could alert the certificate owner about the compromise using IODEF.
6. IANA Considerations 🧾
This memo does not require any IANA actions. Nothing to see here for the registry gremlins 🫶
7. Security Considerations 🔐
This document does not incur any new security issues, because it only talks about the usage of IODEFv2 defined in RFC 7970. Nevertheless, readers of this document should refer to the Security Considerations section of [RFC7970]. Do not skip that section, bestie, it's serious business 💀🔥
8. References 📚
8.1. Normative References
[RFC5901] Cain, P. and D. Jevans, "Extensions to the IODEF-Document
Class for Reporting Phishing", RFC 5901,
DOI 10.17487/RFC5901, July 2010,
<https://www.rfc-editor.org/info/rfc5901>.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, DOI 10.17487/RFC6545, April 2012,
<https://www.rfc-editor.org/info/rfc6545>.
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information",
RFC 7203, DOI 10.17487/RFC7203, April 2014,
<https://www.rfc-editor.org/info/rfc7203>.
[RFC7495] Montville, A. and D. Black, "Enumeration Reference Format
for the Incident Object Description Exchange Format
(IODEF)", RFC 7495, DOI 10.17487/RFC7495, March 2015,
<https://www.rfc-editor.org/info/rfc7495>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>.8.2. Informative References
[IODEF_IMP]
"Implementations on Incident Object Description Exchange
Format", <http://siis.realmv6.org/implementations/>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012,
<https://www.rfc-editor.org/info/rfc6546>.
[RFC8134] Inacio, C. and D. Miyamoto, "Management Incident
Lightweight Exchange (MILE) Implementation Report",
RFC 8134, DOI 10.17487/RFC8134, May 2017,
<https://www.rfc-editor.org/info/rfc8134>.Appendix A. Indicator Predicate Logic Examples 🧩
Okay bestie, time for the examples 💖 In this first one, the EventData class evaluates as a Flow of one System. It's giving source address 192.0.2.104 OR 192.0.2.106, AND target address 198.51.100.1. So it's (source .104 or source .106) and then target .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">
192.0.2.104
</Address>
</Node>
</System>
</Observable>
<Observable>
<System category="source" spoofed="no">
<Node>
<Address category="ipv4-addr">
192.0.2.106
</Address>
</Node>
</System>
</Observable>
</IndicatorExpression>
<Observable>
<System category="target" spoofed="no">
<Node>
<Address category="ipv4-addr">
198.51.100.1
</Address>
</Node>
</System>
</Observable>
</IndicatorExpression>
</Indicator>
</IndicatorData>
<!-- ...XML code omitted... -->Now, the FileData Class can also be an observable inside an IndicatorExpression 📁✨ Here the hash values of two files get matched against an indicator using Boolean "or" logic. So the indicator is made up of either one of the two files, and the example below shows exactly that setup 🌈
<!-- ...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 scope="file-contents">
<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 scope="file-contents">
<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... -->Appendix B. Inter-vendor and Service Provider Exercise Examples 🦋
Below is some of the IODEF example info that the vendors swapped during this proof-of-concept, inter-vendor and service provider exercise. Real-world coordination, bestie, it's so iconic 🫶
B.1. Malware Delivery URL 🍓
This example shows malware plus a related URL used for file delivery. Lowkey scary, highkey useful 💀
<?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 C2
</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>B.2. DDoS 🌊
The DDoS test swapped info describing a DDoS, covering 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>B.3. Spear Phishing
okay so this one is giving spy thriller 🕵️♀️🎀 the spear-phishing test swapped info about a spear-phishing email, including the DNS records and addresses for the sender, the malicious attached file info, and the 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 preference = 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>B.4. Malware
okay next up, the malware test 🦋 in this one, malware info got exchanged using RID and IODEF. the info included file hashes, registry setting changes, and the C2 servers the malware uses 🫶
<?xml version="1.0" encoding="UTF-8"?>okay bestie, this is the whole malware example, and it's giving full incident report energy 🕵️♀️💅
<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&
lunch_id=1&maddr=&
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>
MHg2NzUxQTI1MzQ4M0E2N0Q4NkUwRjg0NzYwRjYxRjEwQkJDQzJF
REZG
</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>
MHg3MjYzRkUwRDNBMDk1RDU5QzhFMEM4OTVBOUM
1ODVFMzQzRTcxNDFD
</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>
141accec23e7e5157de60853cb1e01bc38042d08f
9086040815300b7fe75c184
</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>B.5. IoT Malware 🦾🌸
okay so the IoT malware test is so cute and also kinda scary 😭. It exchanges info about a bad IP address of IoT malware and the ports it's scanning 👀. The example data comes from alert messages of a darknet monitoring system mentioned in [RFC8134] 🕵️♀️. And the IODEF version used for the data representation is 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>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📦 where this page comes from
- ietf: rfc8274 2017-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms