Internet Engineering Task Force (IETF) P. Kampanakis
Request for Comments: 8274 Cisco Systems
Category: Informational M. Suzuki
ISSN: 2070-1721 NICT
November 2017
Internet Engineering Task Force (IETF) P. Kampanakis
Request for Comments: 8274 Cisco Systems
Category: Informational M. Suzuki
ISSN: 2070-1721 NICT
November 2017
Incident Object Description Exchange Format Usage Guidance
事件对象描述交换格式使用指南
Abstract
摘要
The Incident Object Description Exchange Format (IODEF) v2 (RFC 7970) 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.
事件对象描述交换格式（IODEF）v2（RFC 7970）定义了一种数据表示形式，该数据表示形式提供了一个框架，用于共享有关计算机安全事件响应团队（CSIRT）通常交换的计算机安全事件的信息。由于IODEF模型包含大量可用选项，可用于描述安全事件或问题，因此安全从业人员开发利用IODEF共享事件的工具可能具有挑战性。本文档为IODEF实施者提供了指南。它解决了如何在IODEF中表示常见的安全指标，并提供了如何使用IODEF的用例。本文件旨在使供应商更容易采用IODEF，并鼓励全球CSIRT更快、更广泛地采用该模型。
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 Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8274.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . . . . . 33
The Incident Object Description Exchange Format (IODEF) v2 [RFC7970] 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.
事件对象描述交换格式（IODEF）v2[RFC7970]定义了一种数据表示形式，该数据表示形式为共享计算机安全事件响应团队（CSIRT）通常交换的计算机安全事件信息提供了一个框架。IODEF数据模型由IODEF XML模式中定义的多个类和数据类型组成。
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.
IODEF模式旨在描述安全事件交换中所需的所有可能字段。因此，IODEF包含过多的数据结构，这使得IODEF实现者很难决定哪些是重要的。此外，在IODEF模式中，存在多个字段和类，这些字段和类不一定需要在每次可能的数据交换中使用。此外，一些IODEF类仅在极少数情况下有用。本文件试图解决这些问题。它还介绍了如何在IODEF中表示常见的安全指标，指出了实现者最重要的IODEF类，并描述了其他不重要的类，还介绍了IODEF实现者的一些常见陷阱以及如何解决这些陷阱。本文档的最终目标是使供应商更容易使用IODEF，并鼓励全球CSIRT更广泛地采用该模型。
Section 3 discusses the recommended classes and how an IODEF implementer should choose the classes to implement. Section 4 presents common considerations a practitioner will come across and how to address them. Section 5 goes over some common uses of IODEF.
第3节讨论了推荐的类以及IODEF实现者应该如何选择要实现的类。第4节介绍了从业者将遇到的常见问题以及如何解决这些问题。第5节介绍了IODEF的一些常见用法。
The terminology used in this document is defined in [RFC7970].
本文件中使用的术语定义见[RFC7970]。
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.
IODEF实现者必须区分IODEF类在事件信息交换中的使用方式。了解描述常见安全事件或指标的最常见IODEF类也很重要。本节描述了IODEF实践者在使用IODEF或设计实现之前应该考虑的最重要的类和因素。
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
IODEF文档必须至少包含一个事件类、一个定义支持的语言的xml:lang属性以及IODEF版本属性。事件必须包含一个purpose属性和三个必须实现的元素。这些元素是
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.
GenerationTime类（描述事件发生的时间）、IncidentID类和至少一个Contact类。最小IODEF文档类的结构如图1所示。
+---------------+ +--------------+
|IODEF-Document | | Incident |
+---------------+ +--------------+ +--------------+
|STRING version |<>--{1..*}--| ENUM purpose |<>---------| IncidentID |
|ENUM xml:lang | | | +--------------+
| | | | | STRING name |
+---------------+ | | +--------------+
| |
| |<>---------[GenerationTime]
| |
| | +--------------+
| |<>-{1..*}--[ Contact |
+--------------+ +--------------+
| ENUM role |
| ENUM type |
+--------------+
+---------------+ +--------------+
|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 Class
图1：最小IODEF文档类
The IncidentID class must contain at least a name attribute.
IncidentID类必须至少包含name属性。
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.
反过来，Contact类需要type和role属性，但IODEF v2规范不需要任何元素。然而，应该实现Contact类中的至少一个元素，例如Email类，以便IODEF文档有用。
Section 7.1 of [RFC7970] presents a minimal IODEF document with only the mandatory classes and attributes. Implementers can also refer to Section 7 of [RFC7970] and Appendix B of this document for examples of documents that are IODEF v2.
[RFC7970]第7.1节介绍了一个仅包含必需类和属性的最小IODEF文档。实施者还可以参考[RFC7970]第7节和本文件附录B，了解IODEF v2文件的示例。
There is no need for a practitioner to use or implement IODEF classes and fields other than the minimal ones (see Section 3.1) and the ones necessary for her use cases. The implementer should carefully look into the schema and decide which classes to implement (or not).
从业者不需要使用或实现IODEF类和字段，除了最小类和字段（参见第3.1节）以及其用例所需的类和字段之外。实现者应该仔细研究模式并决定实现（或不实现）哪些类。
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.
例如，如果我们将分布式拒绝服务（DDoS）作为一个潜在用例，那么流类及其包含的信息是最重要的类。Flow类描述了与攻击者和受害者主机相关的信息，这些信息有助于自动筛选或天坑操作。
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.
另一个潜在用例是恶意软件命令和控制（C2）。现代恶意软件感染设备后，它通常会连接到一个或多个C2服务器，以接收来自其主机的指令，并可能泄漏信息。为防止此类活动，重要的是通过过滤活动中断C2通信。IODEF可以使用流和ServiceName类描述C2活动。
For use cases where indicators need to be described, the IndicatorData class will be implemented instead of the EventData class.
对于需要描述指标的用例，将实现IndicatorData类而不是EventData类。
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 v2中需要支持的类。在某些情况下，实现和解析所有IODEF类可能会很麻烦，而且是不必要的。IODEF中还可以使用其他外部模式来描述事件或指标。只有当实现者的IODEF用例需要外部模式信息时，才应该相应地解析外部模式。但是，即使IODEF实现无法解析外部模式，IODEF报告对事件响应团队仍然很有价值。当与能够解析此信息的内容使用者进一步共享时，此信息也会很有用。
IODEF supports multiple language translations of free-form, ML_STRING text in all classes [RFC7970]. 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.
IODEF支持所有类中自由格式的ML_字符串文本的多种语言翻译[RFC7970]。这样，通过在类中使用翻译标识符，可以将描述元素中的文本翻译成不同的语言。实现者应该能够解析iodef:MLStringType类，并仅提取与感兴趣的语言相关的信息。
[RFC7970] 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.
[RFC7970]包含可以描述攻击方法、事件、事件、指标、发现它们的方式以及对受害者影响的评估的类。IODEF用户了解这些类之间的区别对于决定哪些类满足他们的用例是很重要的。
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.
IndicatorData类描述了威胁指示器或可观察到的，用于描述导致攻击未遂的威胁。例如，我们可以看到攻击正在发生（在指示数据中描述），但它可能已经被阻止，并且没有导致事件或安全事件。另一方面，EventData类通常描述安全事件，可以将其视为已发生事件的报告。
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.
发现、评估、方法和恢复时间等类与EventData一起使用，因为它们与EventData中描述的事件报告相关。RelatedActivity类可以引用事件、指示器或其他相关威胁活动。
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.
在决定哪些类对于所需用例很重要时，IODEF用户应该仔细评估必要的类以及如何使用这些类，以避免不必要的工作。例如，如果我们只想在IODEF中描述指标，那么方法或评估的实施可能并不重要。
Implementers need to consider some common, standardized options for their IODEF use strategy.
实现者需要考虑他们的IDEF使用策略的一些常见的、标准化的选项。
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 [RFC7495]. 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.
IODEF格式包括用于外部定义信息的引用类，如漏洞、入侵检测系统（IDS）警报、恶意软件样本、咨询或攻击技术。为了便于信息交换，引用类被扩展为枚举引用格式[RFC7495]。枚举参考格式指定了使用外部枚举规范（例如，常见漏洞和暴露（CVE））的方法，这些规范可定义枚举格式、特定枚举值或两者。由于外部枚举可能有很大的差异，实现者应该只支持那些期望描述其特定用例的枚举。
The IODEF data model [RFC7970] 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 [RFC5901]. Information about extending IODEF class attributes and enumerated values can be found in Section 5 of [RFC7970].
IODEF数据模型[RFC7970]是可扩展的。许多具有枚举值的属性可以使用“ext-*”前缀进行扩展。还可以使用AdditionalData和RecordItem类定义其他类。[RFC5901]中定义了用于报告钓鱼电子邮件的AdditionalData类的扩展。有关扩展IODEF类属性和枚举值的信息，请参见[RFC7970]的第5节。
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, Common Vulnerability Reporting Framework (CVRF), and Open Vulnerability and Assessment Language (OVAL). [RFC7203] enhances the IODEF capabilities without further extending the data model.
此外，IODEF可以使用[RFC7203]中定义的扩展框架导入现有模式。该框架允许IODEF用户使用外部模式或外部规范定义的结构将XML数据嵌入IODEF文档中。示例包括CVE、通用漏洞报告框架（CVRF）和开放漏洞和评估语言（OVAL）。[RFC7203]增强了IODEF功能，而无需进一步扩展数据模型。
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 [RFC7203] is not a suitable option.
IODEF实现者不应使用自己的IODEF扩展，除非无法使用现有标准表示数据，或者除非在[RFC7203]中定义的IODEF文档中导入数据不是合适的选项。
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 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.
IODEF文件[RFC7970]可以描述事件报告和指标。Indicator类可以包括对其他指标、可观察对象和更多包含指标详细信息的类的引用。在描述安全指标时，通常需要将它们组合在一起，以形成一组构成安全威胁的指标。例如，僵尸网络可能有多个命令和控制服务器。因此，IODEF v2引入了IndicatorExpression类，用于在对多个指示器或可观察对象进行分组时添加指示器谓词逻辑。
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 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.
实现必须能够解析和应用指示符表达式提供的布尔逻辑，以便评估指示符的存在性。如[RFC7970]第3.29.5节所述，IndicatorExpression element运算符定义了适用于IndicatorExpression所有子元素的运算符。如果未定义运算符，则应假定为“和”。指示符号也可以嵌套在一起。子指示符表达式应被视为其父元素的子元素，在使用其父元素的运算符进行评估之前，应首先对其进行评估。
Users can refer to Appendix A for example uses of the IndicatorExpressions in an IODEF v2.
用户可参考附录A，了解IODEF v2中指示符号的使用示例。
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) [RFC6545] is used to transfer the IODEF documents, it can provide policy guidelines for handling IODEF documents by using the RIDPolicy class.
对IODEF文档中信息的访问应严格锁定，因为内容可能是机密的。IODEF有一个公共属性，称为“限制”，它表示发送方希望接收方遵守的类及其子类中表示的信息的披露准则。这样，发送方就可以表示IODEF文档中每个组件的公开级别。可根据限制水平实施适当的外部措施。一个例子是，当使用实时网络间防御（RID）[RFC6545]传输IODEF文档时，它可以通过使用RIDPolicy类提供处理IODEF文档的策略指南。
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
信息披露指南的执行超出了IODEF的范围。IODEF文件的接收者需要遵循指南，但这些指南本身没有提供任何信息
enforcement measures. For that purpose, implementers should consider appropriate privacy control measures, technical or operational, for their implementation.
执法措施。为此目的，实施者应考虑适当的隐私控制措施，技术或操作，为其实施。
IODEF is currently used by various organizations in order to represent security incidents and share incident and threat information between security operations organizations.
IODEF目前被多个组织使用，用于表示安全事件，并在安全运营组织之间共享事件和威胁信息。
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 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 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.
为了使用IODEF，像IODEF解析器这样的工具是必要的。[RFC8134]描述了一组IODEF实施和由不同供应商和计算机应急准备团队（CERT）组织使用。该文档没有指定任何特定的强制实现（MTI）IODEF类，但提供了实际使用的列表。Perl和Python模块（XML:：IODEF、IODEF:：Pb、iodeflib）就是一些示例。此外，鼓励实施者参考[RFC8134]第7节了解实际的IODEF使用指南。另一方面，[IODEF_IMP]包括各种供应商事件报告产品，这些产品可以以IODEF格式消费和导出。
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.
作为一项互操作性活动，数量有限的供应商于2013年在IODEF组织并执行了威胁指标交换。使用的传输协议是RID。共享的威胁信息包括DDoS攻击、恶意软件事件以及在获取特定个人信息后针对特定个人的鱼叉式网络钓鱼的指标。研究结果可作为概念证明（PoC），说明看似相互竞争的实体如何使用IODEF交换经过消毒的安全信息。由于这是一次PoC演习，在交换过程中只共享了示例信息（没有真正的威胁）。
____________ ____________
| Vendor X | | Vendor Y |
| RID Agent |_______-------------________| RID Agent |
|___________| | Internet | |___________|
-------------
____________ ____________
| Vendor X | | Vendor Y |
| RID Agent |_______-------------________| RID Agent |
|___________| | Internet | |___________|
-------------
---- RID Report message --->
-- carrying IODEF example ->
--------- over TLS -------->
---- RID Report message --->
-- carrying IODEF example ->
--------- over TLS -------->
<----- RID Ack message -----
<--- in case of failure ----
<----- RID Ack message -----
<--- in case of failure ----
Figure 2: PoC Peering Topology
图2:PoC对等拓扑
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 [RFC6545] and [RFC6546] was also confirmed.
图2显示了PoC期间RID交互是如何发生的。参与组织在现场运行RID代理软件。RID代理与其他参与组织形成对等关系。当实体X有一个新的事件要交换时，它会将其打包到IODEF中，并在RID报告消息中通过传输层安全性（TLS）发送给实体Y。如果消息出现问题，实体Y将向实体X发送一条RID确认消息，其中包括一条用于描述问题的应用程序级消息。实现[RFC6545]和[RFC6546]的RID代理之间的互操作性也得到了确认。
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.
第一个用例包括在CSIRT之间共享与事件相关的恶意软件数据。在Entity X检测到事件后，Entity X会将事件期间发现的恶意软件的数据放在后端系统中。实体X随后决定与实体Y共享所发现恶意软件的事件信息。这可能是人为的决定，也可能是自动化过程的一部分。
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.
(1) 实体X与实体Y有共享协议，并且已使用实体Y的RID代理的IP地址进行配置。
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
(2) 实体X的RID代理连接到实体Y的RID代理，并使用PKI数字证书进行相互身份验证。
(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
(3) 实体X推出一条RID报告消息，其中包含有关N个已发现恶意软件的信息。在RID中使用IODEF来描述
(a) hash of malware files;
(a) 恶意软件文件的散列；
(b) registry settings changed by the malware; and
(b) 恶意软件更改的注册表设置；和
(c) C2 information for the malware.
(c) 恶意软件的C2信息。
(4) Entity Y receives a RID Report message and sends a RID Acknowledgement message.
(4) 实体Y接收RID报告消息并发送RID确认消息。
(5) Entity Y stores the data in a format that makes it possible for the backend to know which source the data came from.
(5) 实体Y以一种格式存储数据，使后端能够知道数据来自哪个源。
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.
另一个用例是共享DDoS攻击，如以下场景中所述：Entity X，一家关键基础设施和关键资源（CIKR）公司，检测到其internet连接被异常流量饱和。进一步调查确定这是一次实际的DDoS攻击。实体X的CSIRT联系其ISP实体Y，并与他们共享有关攻击流量特征的信息。实体X的ISP正被流量所淹没，因此它与相邻的ISP共享攻击特征码和最多产主机的IP地址。
Below are the steps followed for a DDoS information exchange:
以下是DDoS信息交换所遵循的步骤：
(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.
(1) 实体X与实体Y有共享协议，并且已使用实体Y的RID代理的IP地址进行配置。
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
(2) 实体X的RID代理连接到实体Y的RID代理，并使用PKI数字证书进行相互身份验证。
(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:
(3) 实体X推出一条RID报告消息，其中包含有关DDoS攻击的信息。在RID中使用IODEF来描述以下内容：
(a) Start and Detect dates and times;
(a) 开始并检测日期和时间；
(b) IP addresses of nodes sending DDoS traffic;
(b) 发送DDoS流量的节点的IP地址；
(c) sharing and use restrictions;
(c) 共享和使用限制；
(d) traffic characteristics (protocols and ports);
(d) 流量特性（协议和端口）；
(e) HTTP user agents used; and
(e) 使用HTTP用户代理；和
(f) IP addresses of C2 for a botnet.
(f) 僵尸网络C2的IP地址。
(4) Entity Y receives a RID Report message and sends a RID Acknowledgement message.
(4) 实体Y接收RID报告消息并发送RID确认消息。
(5) Entity Y stores the data in a format that makes it possible for the backend to know which source the data came from.
(5) 实体Y以一种格式存储数据，使后端能够知道数据来自哪个源。
(6) Entity Y shares information with other ISP entities it has an established relationship with.
(6) 实体Y与其他与其建立关系的ISP实体共享信息。
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.
另一个用例是共享鱼叉式钓鱼电子邮件信息，如以下场景所解释：几个国防承包商的董事会成员收到一封有针对性的电子邮件，邀请他们参加在旧金山的一个会议。董事会成员被要求在电子邮件附带的文件中提供其个人身份信息，如家庭地址、电话号码、公司电子邮件等。董事会成员还被要求点击一个URL，这样他们就可以进入会议的注册页面。其中一名收件人认为该电子邮件是钓鱼企图，并将该电子邮件转发给其公司CSIRT进行分析。CSIRT将该电子邮件识别为一次尝试的spear网络钓鱼事件，并将指标分发给其共享合作伙伴。
Below are the steps followed for a spear-phishing information exchange between CSIRTs that were part of this PoC.
以下是作为本PoC一部分的CSIRT之间的矛式网络钓鱼信息交换所遵循的步骤。
(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.
(1) 实体X与实体Y有共享协议，并且已使用实体Y的RID代理的IP地址进行配置。
(2) Entity X's RID Agent connects to Entity Y's RID Agent, and mutual authentication occurs using PKI digital certificates.
(2) 实体X的RID代理连接到实体Y的RID代理，并使用PKI数字证书进行相互身份验证。
(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:
(3) Entity X推出一条RID报告消息，其中包含有关spear网络钓鱼电子邮件的信息。在RID中使用IODEF来描述以下内容：
(a) attachment details (file Name, hash, size, malware family);
(a) 附件详细信息（文件名、哈希、大小、恶意软件系列）；
(b) target description (IP, domain, NSLookup);
(b) 目标描述（IP、域、NSLookup）；
(c) email information (From, Subject, header information, date/ time, digital signature); and
(c) 电子邮件信息（发件人、主题、标题信息、日期/时间、数字签名）；和
(d) confidence score.
(d) 信心分数。
(4) Entity Y receives a RID Report message and sends a RID Acknowledgement message.
(4) 实体Y接收RID报告消息并发送RID确认消息。
(5) Entity Y stores the data in a format that makes it possible for the backend to know which source the data came from.
(5) 实体Y以一种格式存储数据，使后端能够知道数据来自哪个源。
Appendix B includes some of the IODEF example information that was exchanged by the organizations' RID Agents as part of this PoC.
附录B包括组织的RID代理作为本PoC的一部分交换的一些IODEF示例信息。
Other use cases of IODEF, aside from the ones described above, could be as follows:
除上述情况外，IODEF的其他用例如下：
(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.
(1) ISP在发现事件并采取行动时通知国家证书或组织，证书在ISP意识到事件时通知ISP。
(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.
(2) 可疑的网络钓鱼电子邮件可以在组织和国家机构之间共享。自动化可以验证可疑电子邮件指向的web内容。然后，可以使用IODEF共享钓鱼电子邮件中链接的已识别恶意内容。因此，通过使用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.
(3) 当发现应撤销的证书时，第三方将向证书颁发机构（CA）转发一条自动IODEF消息，其中包含证书的完整上下文，CA可在检查其有效性后采取相应行动。或者，在证书私钥泄露的情况下，第三方可以使用IODEF向证书所有者发出泄露警报。
This memo does not require any IANA actions.
本备忘录不要求IANA采取任何行动。
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].
本文档不会产生任何新的安全问题，因为它只讨论RFC 7970中定义的IODEFv2的使用。然而，本文件的读者应参考[RFC7970]的安全注意事项部分。
[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>.
[RFC5901]Cain，P.和D.Jevans，“用于报告网络钓鱼的IODEF文档类的扩展”，RFC 5901，DOI 10.17487/RFC5901，2010年7月<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>.
[RFC6545]Moriarty，K.，“实时网络间防御（RID）”，RFC 6545，DOI 10.17487/RFC65452012年4月<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>.
[RFC7203]Takahashi，T.，Landfield，K.，和Y.Kadobayashi，“结构化网络安全信息的事件对象描述交换格式（IODEF）扩展”，RFC 7203，DOI 10.17487/RFC7203，2014年4月<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>.
[RFC7495]蒙特维尔，A.和D.布莱克，“事件对象描述交换格式（IODEF）的枚举参考格式”，RFC 7495，DOI 10.17487/RFC7495，2015年3月<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>.
[RFC7970]Danyliw，R.，“事件对象描述交换格式版本2”，RFC 7970，DOI 10.17487/RFC7970，2016年11月<https://www.rfc-editor.org/info/rfc7970>.
[IODEF_IMP] "Implementations on Incident Object Description Exchange Format", <http://siis.realmv6.org/implementations/>.
[IODEF_IMP]“事件对象描述交换格式的实现”<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>.
[RFC6546]特拉梅尔，B.，“通过HTTP/TLS传输实时网络间防御（RID）消息”，RFC 6546，DOI 10.17487/RFC6546，2012年4月<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>.
[RFC8134]Inacio，C.和D.Miyamoto，“管理事件轻型交换（MILE）实施报告”，RFC 8134，DOI 10.17487/RFC8134，2017年5月<https://www.rfc-editor.org/info/rfc8134>.
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.
在下面的示例中，EventData类作为源地址为192.0.2.104或192.0.2.106且目标地址为198.51.100.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... -->
<!-- ...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... -->
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.
类似地，FileData类可以是指示符表达式中的可见对象。两个文件的散列值可用于使用布尔“或”逻辑与指示符匹配。在下面的示例中，该指示符由两个文件中的任意一个文件和两个不同的哈希组成。
<!-- ...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>
<!-- ...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... -->
</IndicatorExpression>
</Indicator>
</IndicatorData>
<!-- ...XML code omitted... -->
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.
以下是供应商交换的一些IODEF示例信息，作为概念验证、供应商间和服务提供商实践的一部分。
This example indicates malware and a related URL for file delivery.
此示例表示用于文件传递的恶意软件和相关URL。
<?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
<?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>
</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].
DDoS测试交换描述DDoS的信息，包括协议和端口、错误IP地址和HTTP用户代理字段。用于数据表示的IODEF版本基于[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>
<?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: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: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>
</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].
spear网络钓鱼测试交换描述spear网络钓鱼电子邮件的信息，包括有关发件人的DNS记录和地址、恶意附加文件信息和电子邮件数据。用于数据表示的IODEF版本基于[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>
<?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>
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: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>
<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 C2 servers the malware uses.
在这个测试中，恶意软件信息是使用RID和IODEF交换的。这些信息包括文件哈希、注册表设置更改以及恶意软件使用的C2服务器。
<?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>
<?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&
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: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>
</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">
<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: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: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>
</iodef:IndicatorExpression>
</iodef:IndicatorExpression>
</iodef:Indicator>
</iodef:IndicatorData>
</iodef:Incident>
</IODEF-Document>
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 [RFC8134]. The IODEF version used for the data representation was based on [RFC7970].
物联网恶意软件测试交换了描述物联网恶意软件及其扫描端口的坏IP地址的信息。此示例信息是从[RFC8134]中提到的黑暗监控系统的警报消息中提取的。用于数据表示的IODEF版本基于[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>
<?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: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>
</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
Panos Kampanakis思科系统公司
Email: pkampana@cisco.com
Email: pkampana@cisco.com
Mio Suzuki NICT 4-2-1, Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan
Mio Suzuki NICT 4-2-1，日本东京北天町新贵，184-8795
Email: mio@nict.go.jp
Email: mio@nict.go.jp