[要約] RFC 8274は、インシデントオブジェクトの記述交換形式の使用ガイダンスを提供するものであり、インシデント情報の共有と相互運用性を向上させることを目的としています。
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
インシデントオブジェクトの説明Exchange形式の使用ガイダンス
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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 . . . . . . . . . . . . . . . . . . . . . . . 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 GenerationTime class (which describes the time of the incident), an IncidentID class, and at least one Contact class. The structure of the minimal IODEF-Document class is shown in Figure 1.
IODEFドキュメントには、少なくともインシデントクラス、サポートされる言語を定義するxml：lang属性、およびIODEFバージョン属性が含まれている必要があります。インシデントには、目的の属性と3つの要素を実装する必要がありますが含まれている必要があります。これらの要素は、GenerationTimeクラス（インシデントの時間を表す）、IncidentIDクラス、および少なくとも1つのContactクラスです。最小限のIODEF-Documentクラスの構造を図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 Class
図1：最小限のIODEF-Documentクラス
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仕様では要素は必要ありません。それでも、IODEFドキュメントが役立つように、Emailクラスなど、Contactクラスの要素の少なくとも1つを実装する必要があります。
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ドキュメントを示しています。実装者は、IODEF v2であるドキュメントの例について、[RFC7970]のセクション7およびこのドキュメントの付録Bも参照できます。
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).
開業医は、最小限のもの（セクション3.1を参照）および彼女の使用例に必要なもの以外のIODEFクラスおよびフィールドを使用または実装する必要はありません。実装者はスキーマを注意深く調べ、実装するクラス（または実装しないクラス）を決定する必要があります。
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.
もう1つの潜在的な使用例は、マルウェアのコマンドと制御（C2）です。最新のマルウェアがデバイスに感染すると、通常は1つ以上のC2サーバーに接続して、マスターから指示を受け取り、情報を漏えいさせる可能性があります。このようなアクティビティから保護するには、アクティビティをフィルタリングしてC2通信を中断することが重要です。 IODEFは、FlowクラスとServiceNameクラスを使用してC2アクティビティを記述できます。
For use cases where indicators need to be described, the IndicatorData class will be implemented instead of the EventData class.
インジケーターを記述する必要があるユースケースでは、EventDataクラスの代わりにIndicatorDataクラスが実装されます。
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_STRINGテキストの複数言語翻訳をサポートします[RFC7970]。このように、クラスで翻訳識別子を使用することにより、Description要素のテキストをさまざまな言語に翻訳できます。実装者は、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クラスは、攻撃の試みを引き起こした脅威を表す脅威インジケータまたはオブザーバブルを表します。たとえば、（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.
Discovery、Assessment、Method、RecoveryTimeなどのクラスは、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.
実装者は、IODEFの使用戦略について、いくつかの一般的な標準化されたオプションを検討する必要があります。
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）アラート、マルウェアサンプル、助言、攻撃手法など、外部で定義された情報に使用される参照クラスが含まれます。情報の交換を容易にするために、Referenceクラスは列挙参照形式[RFC7495]に拡張されました。列挙参照形式は、列挙形式、特定の列挙値、またはその両方を定義できる外部列挙仕様（Common Vulnerabilities and Exposures（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クラスを使用して定義することもできます。フィッシングメールを報告するためのAdditionalDataクラスの拡張は、[RFC5901]で定義されています。 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、Common Vulnerability Reporting Framework（CVRF）、Open Vulnerability and Assessment Language（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.
既存の標準を使用してデータを表現できない場合、または[RFC7203]で定義されているようにIODEFドキュメントにインポートすることが適切なオプションでない場合を除き、IODEF実装者は独自の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]は、インシデントレポートとインジケーターを記述できます。インジケータークラスには、他のインジケーター、オブザーバブル、およびインジケーターに関する詳細を含むその他のクラスへの参照を含めることができます。セキュリティインジケータについて説明する場合、セキュリティの脅威を構成するインジケータのグループを形成するために、それらをグループ化する必要があることがよくあります。たとえば、ボットネットには複数のコマンドアンドコントロールサーバーがある場合があります。そのため、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.
実装は、インジケーターの存在を評価するために、IndicatorExpressionによって提供されるブールロジックを解析および適用できる必要があります。 [RFC7970]のセクション3.29.5で説明されているように、IndicatorExpression要素演算子は、IndicatorExpressionのすべての子要素に適用される演算子を定義します。演算子が定義されていない場合は、「and」が想定されます。 IndicatorExpressionsは入れ子にすることもできます。子指標式は、親の子要素として扱われる必要があり、親の演算子で評価される前に最初に評価される必要があります。
Users can refer to Appendix A for example uses of the IndicatorExpressions in an IODEF v2.
ユーザーは、IODEF v2でのIndicatorExpressionsの使用例について付録Aを参照できます。
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 enforcement measures. For that purpose, implementers should consider appropriate privacy control measures, technical or operational, for their implementation.
開示ガイドラインの施行は、IODEFの範囲外です。 IODEFドキュメントの受信者はガイドラインに従う必要がありますが、これらのガイドライン自体は強制措置を提供していません。そのために、実装者は、実装のために、技術的または運用上の適切なプライバシー制御手段を検討する必要があります。
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]は、さまざまなベンダーおよびComputer Emergency Readiness Team（CERT）組織による一連のIODEF実装および使用について説明しています。このドキュメントでは、特定の実装必須（MTI）IODEFクラスを指定していませんが、実際の使用法のリストを提供しています。 PerlおよびPythonモジュール（XML :: IODEF、Iodef :: Pb、iodeflib）はいくつかの例です。さらに、実装者は、実用的なIODEFの使用ガイドラインについて、[RFC8134]のセクション7を参照することをお勧めします。一方、[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攻撃からの指標、マルウェアインシデント、および特定の個人に関する情報を収集した後にそれらを標的とするスピアフィッシングが含まれていました。結果は、一見競合するエンティティがIODEFを使用してサニタイズされたセキュリティ情報を交換する方法についての概念実証（PoC）として機能しました。これはPoCの演習であったため、交換の一部として共有されたのは例の情報（実際の脅威ではない）のみでした。
____________ ____________
| 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 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は、RID確認メッセージをエンティティXに送信します。このメッセージには、問題を説明するアプリケーションレベルのメッセージが含まれていました。 [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間で共有することが含まれていました。エンティティXがインシデントを検出した後、エンティティ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は、発見されたN個のマルウェアに関する情報を含むRIDレポートメッセージをプッシュします。 IODEFはRIDで使用され、
(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 Reportメッセージを受信し、RID Acknowledgementメッセージを送信します。
(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.
もう1つの使用例は、次のシナリオで説明するようにDDoS攻撃を共有することでした。CriticalInfrastructure and Key Resource（CIKR）企業であるエンティティXは、インターネット接続が異常な量のトラフィックで飽和していることを検出しました。さらなる調査により、これが実際のDDoS攻撃であることが判明しました。エンティティXのCSIRTは、ISPであるエンティティYに連絡し、攻撃トラフィックの特性に関する情報を共有します。エンティティXのISPはトラフィックの量に圧倒されているため、最も多産なホストの攻撃シグネチャとIPアドレスを隣接するISPと共有しています。
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は、DDoS攻撃に関する情報を含むRIDレポートメッセージをプッシュします。 IODEFは、RIDで以下を説明するために使用されます。
(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 Reportメッセージを受信し、RID Acknowledgementメッセージを送信します。
(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.
次のシナリオで説明するように、もう1つの使用例はスピアフィッシングの電子メール情報の共有でした。複数の防衛請負業者の役員が、サンフランシスコでの会議への参加を招待する標的型電子メールを受信しました。理事会メンバーは、自宅の住所、電話番号、会社の電子メールなどの個人を特定できる情報を、電子メールに添付された添付文書で提供するよう求められます。理事会メンバーは、会議のサインアップページにアクセスできるURLをクリックすることも求められます。受信者の1人は、電子メールがフィッシングの試みであると信じて、分析のためにその電子メールを企業のCSIRTに転送します。 CSIRTは、電子メールをスピアフィッシングの試みとして識別し、インジケータを共有パートナーに配布します。
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）エンティティXは、スピアフィッシングメールに関する情報を含むRIDレポートメッセージをプッシュします。 IODEFは、RIDで以下を説明するために使用されます。
(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 Reportメッセージを受信し、RID Acknowledgementメッセージを送信します。
(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には、このPoCの一部として組織のRIDエージェントによって交換された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がインシデントを特定して対応する場合は、全国のCERTまたは組織に通知し、CERTはインシデントを認識している場合に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）取り消す必要のある証明書を見つけると、サードパーティは証明書の完全なコンテキストで自動化されたIODEFメッセージを認証局（CA）に転送し、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-Documentクラスの拡張」、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。、「Real-time Inter-network Defense（RID）」、RFC 6545、DOI 10.17487 / RFC6545、2012年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]高橋敏夫、ランドフィールドK.、および門林由紀子、「構造化サイバーセキュリティ情報のインシデントオブジェクト記述交換フォーマット（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。、「The Incident Object Description Exchange Format Version 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] Trammell、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. 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>。
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 OR 192.0.2.106 ANDターゲットアドレス198.51.100.1を持つ1つのシステムのフローとして評価されます。
<!-- ...XML code omitted... --> <IndicatorData> <Indicator> <IndicatorID name="csirt.example.com" version="1"> G90823490 </IndicatorID> <Description>C2 domains</Description> <IndicatorExpression operator="and"> <IndicatorExpression operator="or"> <Observable> <System category="source" spoofed="no"> <Node> <Address category="ipv4-addr"> 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.
<！-... XMLコードを省略...-> <IndicatorData> <Indicator> <IndicatorID name = "csirt.example.com" version = "1"> G90823490 </ IndicatorID> <Description> C2ドメイン< /説明> <IndicatorExpression operator = "and"> <IndicatorExpression operator = "or"> <監視可能> <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コードの省略...->同様に、FileDataクラスIndicatorExpressionでオブザーバブルにすることができます。 2つのファイルのハッシュ値は、ブール「または」ロジックを使用してインジケーターと照合するために使用できます。次の例では、インジケーターは2つの異なるハッシュを持つ2つのファイルのいずれかで構成されています。
<!-- ...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... -->
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
</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テストは、プロトコルとポート、不正なIPアドレス、HTTPユーザーエージェントフィールドなど、DDoSを説明する情報を交換しました。データ表現に使用される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>
</iodef:Contact>
<iodef:EventData>
<iodef:Description>
Dummy Test sharing with ISP1
</iodef:Description>
<iodef:Method>
<iodef:Reference>
<iodef:URL>
http://blog.spiderlabs.com/2011/01/loic-ddos-
analysis-and-detection.html
</iodef:URL>
<iodef:URL>
http://en.wikipedia.org/wiki/Low_Orbit_Ion_Cannon
</iodef:URL>
<iodef:Description>
Low Orbit Ion Cannon User Agent
</iodef:Description>
</iodef:Reference>
</iodef:Method>
<iodef:Flow>
<iodef:System category="source" spoofed="no">
<iodef:Node>
<iodef:Address category="ipv4-addr">
192.0.2.104
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="no">
<iodef:Node>
<iodef:Address category="ipv4-addr">
192.0.2.106
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="yes">
<iodef:Node>
<iodef:Address category="ipv4-net">
198.51.100.0/24
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="source" spoofed="yes">
<iodef:Node>
<iodef:Address category="ipv6-addr">
2001:db8:dead:beef::1
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>1337</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">
203.0.113.1
</iodef:Address>
</iodef:Node>
<iodef:Service ip-protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="sensor">
<iodef:Node>
</iodef:Node>
<iodef:Description>
Information provided in Flow class instance is from
Inspection of traffic from network tap
</iodef:Description>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="other"/>
</iodef:EventData>
<iodef:IndicatorData>
<iodef:Indicator>
<iodef:IndicatorID name="csirt.example.com" version="1">
G83345941
</iodef:IndicatorID>
<iodef:Description>
User-Agent string
</iodef:Description>
<iodef:Observable>
<iodef:BulkObservable type="http-user-agent">
<iodef:BulkObservableList>
user-agent="Mozilla/5.0 (Macintosh; U;
Intel Mac OS X 10.5; en-US; rv:1.9.2.12)
Gecko/20101026 Firefox/3.6.12">
</iodef:BulkObservableList>
</iodef:BulkObservable>
</iodef:Observable>
</iodef:Indicator>
</iodef:IndicatorData>
</iodef:Incident>
</IODEF-Document>
The spear-phishing test exchanged information that described a spear-phishing email, including DNS records and addresses about the sender, malicious attached file information, and email data. The IODEF version used for the data representation was based on [RFC7970].
スピアフィッシングテストでは、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>
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>
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>
<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>
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].
モノのインターネット（IoT）マルウェアテストは、IoTマルウェアの不正な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>
</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
Panos Kampanakis Kissos Systems
Email: pkampana@cisco.com
Mio Suzuki NICT 4-2-1, Nukui-Kitamachi Koganei, Tokyo 184-8795 Japan
みお すずき にＣＴ ４ー２ー１、 ぬくいーきたまち こがねい、 ときょ １８４ー８７９５ じゃぱん
Email: mio@nict.go.jp