[要約] RFC 6545は、リアルタイムのインターネットネットワーク防御（RID）に関する標準化されたプロトコルです。その目的は、異なるセキュリティシステム間でのリアルタイムの情報共有と協調を可能にし、ネットワークの攻撃に対する効果的な防御を提供することです。
Internet Engineering Task Force (IETF) K. Moriarty
Request for Comments: 6545 EMC
Obsoletes: 6045 April 2012
Category: Standards Track
ISSN: 2070-1721
Real-time Inter-network Defense (RID)
リアルタイムのネットワーク間防御（RID）
Abstract
概要
Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC 6045.
システムの妥協、ワーム、ウイルス、フィッシングインシデント、サービス拒否などのセキュリティインシデントは、通常、人間とシステムの両方のサービス、データ、リソースの損失をもたらします。サービスプロバイダーとコンピューターセキュリティインシデント対応チームは、攻撃が発生する前に、ツールと手順でセキュリティインシデントを通信および追跡するのを支援する準備ができている必要があります。リアルタイムのネットワーク間防衛（RID）は、既存の検出、トレース、ソース識別、および完全なインシデント処理ソリューションの緩和メカニズムを統合しながら、インシデント処理データの共有を促進するプロアクティブなネットワーク間通信方法の概要を説明します。通信システムでこれらの機能を組み合わせることで、ネットワーク上のより高いセキュリティレベルを達成する方法が得られます。インシデントを処理するためのポリシーガイドラインが推奨され、セキュリティの推奨事項と考慮事項を使用してコンソーシアムによって合意できます。このドキュメントは、RFC 6045を廃止します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6545.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6545で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Changes from RFC 6045 ......................................5
1.2. Normative and Informative ..................................6
1.3. Terminology ................................................7
2. Characteristics of Incidents ....................................7
3. Communication between CSIRTs and Service Providers ..............8
3.1. Inter-Service-Provider RID Messaging ......................10
3.2. RID Communication Topology ................................12
4. Message Formats ................................................13
4.1. RID Data Types ............................................13
4.1.1. Boolean ............................................13
4.2. RID Message Types .........................................14
5. IODEF-RID Schema ...............................................15
5.1. RIDPolicy Class ...........................................17
5.1.1. ReportSchema .......................................23
5.2. RequestStatus .............................................26
5.3. IncidentSource ............................................28
5.4. RID Name Spaces ...........................................29
5.5. Encoding ..................................................29
5.6. Including IODEF or Other XML Documents ....................29
5.6.1. Including XML Documents in RID .....................30
6. RID Messages ...................................................31
6.1. Request ...................................................31
6.2. Acknowledgement ...........................................33
6.3. Result ....................................................34
6.4. Report ....................................................36
6.5. Query .....................................................38
7. RID Communication Exchanges ....................................39
7.1. Upstream Trace Communication Flow .........................40
7.1.1. RID TraceRequest Example ...........................43
7.1.2. Acknowledgement Message Example ....................47
7.1.3. Result Message Example .............................47
7.2. Investigation Request Communication Flow ..................50
7.2.1. Investigation Request Example ......................51
7.2.2. Acknowledgement Message Example ....................53
7.3. Report Communication Flow .................................54
7.3.1. Report Example .....................................54
7.4. Query Communication Flow ..................................56
7.4.1. Query Example ......................................57
8. RID Schema Definition ..........................................58
9. Security Requirements ..........................................62
9.1. XML Digital Signatures and Encryption .....................62
9.2. Message Transport .........................................66
9.3. Public Key Infrastructure .................................67
9.3.1. Authentication .....................................68
9.3.2. Multi-Hop Request Authentication ...................69
9.4. Consortiums and Public Key Infrastructures ................70
9.5. Privacy Concerns and System Use Guidelines ................71
9.6. Sharing Profiles and Policies .............................76
10. Security Considerations .......................................77
11. Internationalization Issues ...................................77
12. IANA Considerations ...........................................78
13. Summary .......................................................80
14. References ....................................................80
14.1. Normative References .....................................80
14.2. Informative References ...................................82
Appendix A. Acknowledgements ......................................84
Organizations require help from other parties to identify incidents, mitigate malicious activity targeting their computing resources, and to gain insight into potential threats through the sharing of information. This coordination might entail working with a service provider (SP) to filter attack traffic, working with an SP to resolve a configuration issue that is unintentionally causing problems, contacting a remote site to take down a bot network, or sharing watch-lists of known malicious IP addresses in a consortium. The term "SP" is to be interpreted as any type of service provider or Computer Security Incident Response Team (CSIRT) that may be involved in RID communications.
組織は、インシデントを特定し、コンピューティングリソースをターゲットにした悪意のある活動を緩和し、情報の共有を通じて潜在的な脅威に関する洞察を得るために、他の関係者の支援を必要とします。この調整には、サービスプロバイダー（SP）と協力して攻撃トラフィックをフィルタリングし、SPと協力して意図せず問題を引き起こしている構成問題を解決したり、リモートサイトに連絡してボットネットワークを削除したり、既知の時計リストを共有したりすることを伴う場合があります。コンソーシアムの悪意のあるIPアドレス。「SP」という用語は、RID通信に関与する可能性のあるサービスプロバイダーまたはコンピューターセキュリティインシデント対応チーム（CSIRT）として解釈される予定です。
Incident handling involves the detection, reporting, identification, and mitigation of an incident, whether it be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to an SP for resolution/mitigation,
インシデントハンドリングには、インシデントの検出、報告、識別、および緩和が含まれます。それが良性構成の問題、ITインシデント、サービスレベル契約（SLA）への違反、システムの妥協、社会的に設計されたフィッシング攻撃、または拒否が含まれます。of-service（dos）攻撃など。インシデントが検出された場合、回答には、単に報告書の提出、インシデントのソースへの通知、解決/緩和のためのSPへの要求が含まれる場合があります。
or a request to locate the source. One of the more difficult cases is that in which the source of an attack is unknown, requiring the ability to trace the attack traffic iteratively upstream through the network for the possibility of any further actions to take place. In cases when accurate records of an active session between the target or victim system and the source or attacking system are available, the source is easy to identify.
またはソースを見つけるためのリクエスト。より困難なケースの1つは、攻撃の原因が不明であることであり、それ以上のアクションが発生する可能性のために、ネットワークを介して攻撃トラフィックを繰り返し上流に追跡する能力を必要とすることです。ターゲットまたは被害者システムとソースまたは攻撃システムの間のアクティブセッションの正確な記録が利用可能な場合、ソースは簡単に識別できます。
Real-time inter-network defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. RID provides a secure method to communicate incident information, enabling the exchange of Incident Object Description and Exchange Format (IODEF) [RFC5070] Extensible Markup Language (XML) documents. RID considers security, policy, and privacy issues related to the exchange of potentially sensitive information, enabling SPs or organizations the options to make appropriate decisions according to their policies. RID includes provisions for confidentiality, integrity, and authentication.
リアルタイムのネットワーク間防衛（RID）は、既存の検出、トレース、ソース識別、および完全なインシデント処理ソリューションの緩和メカニズムを統合しながら、インシデント処理データの共有を促進するプロアクティブなネットワーク間通信方法の概要を説明します。RIDは、インシデント情報を通信する安全な方法を提供し、インシデントオブジェクトの説明と交換形式（IODEF）[RFC5070]拡張可能なマークアップ言語（XML）ドキュメントの交換を可能にします。RIDは、潜在的に機密情報の交換に関連するセキュリティ、ポリシー、およびプライバシーの問題を考慮し、SPSまたは組織がポリシーに従って適切な決定を下すオプションを可能にします。RIDには、機密性、完全性、および認証に関する規定が含まれています。
The data in RID messages is represented in an XML [XML1.0] document using the IODEF and RID. By following this model, integration with other aspects for incident handling is simplified. Methods are incorporated into the communication system to indicate what actions need to be taken closest to the source in order to halt or mitigate the effects of the incident or attack at hand. RID is intended to provide a method to communicate the relevant information between CSIRTs while being compatible with a variety of existing and possible future detection-tracing and response approaches. Incidents may be extended to include Information Technology (IT) incidents, where RID enables the communication between or within providers for non-security IT incidents.
RIDメッセージのデータは、IODEFとRIDを使用したXML [XML1.0]ドキュメントで表されます。このモデルに従うことにより、インシデント処理のための他の側面との統合が簡素化されます。メソッドは通信システムに組み込まれて、手元のインシデントまたは攻撃の影響を停止または軽減するために、ソースに最も近いアクションを使用する必要があるかを示します。RIDは、さまざまな既存および可能な将来の検出および応答アプローチと互換性がありながら、CSIRT間で関連情報を通信する方法を提供することを目的としています。インシデントは、情報技術（IT）インシデントを含むように拡張される場合があります。これには、RIDが非セキュリティITインシデントのためにプロバイダー間またはプロバイダー内での通信を可能にします。
Security and privacy considerations are of high concern since potentially sensitive information may be passed through RID messages. RID messaging takes advantage of XML security, privacy, and policy information set in the RID schema. The RID schema defines communication-specific metadata to support the communication of IODEF documents for exchanging or tracing information regarding incidents. RID messages are encapsulated for transport, which is defined in a separate document [RFC6546]. The authentication, integrity, and authorization features that RID and RID transport offer are used to achieve a necessary level of security.
セキュリティとプライバシーの考慮事項は、潜在的に機密情報がRIDメッセージを通過する可能性があるため、大きな関心事です。RID Messagingは、RIDスキーマに設定されたXMLセキュリティ、プライバシー、およびポリシー情報を活用しています。RIDスキーマは、インシデントに関する情報を交換または追跡するためのIODEFドキュメントの通信をサポートするために、通信固有のメタデータを定義します。RIDメッセージは、別のドキュメント[RFC6546]で定義されている輸送用にカプセル化されています。REDおよびRIDトランスポートオファーが必要なセキュリティを達成するために使用される認証、整合性、および認証機能が使用されます。
Coordinating with other CSIRTs is not strictly a technical problem. There are numerous procedural, trust, and legal considerations that might prevent an organization from sharing information. RID provides
他のCSIRTとの調整は、厳密に技術的な問題ではありません。組織が情報を共有するのを妨げる可能性のある手続き、信頼、および法的考慮事項が数多くあります。RIDが提供します
information and options that can be used by organizations who must then apply their own policies for sharing information. Organizations must develop policies and procedures for the use of the RID protocol and IODEF.
情報を共有するために独自のポリシーを適用する必要がある組織が使用できる情報とオプション。組織は、RIDプロトコルとIODEFを使用するためのポリシーと手順を開発する必要があります。
This document contains the following changes with respect to its predecessor [RFC6045]:
このドキュメントには、その前身に関する次の変更が含まれています[RFC6045]：
o This document is Standards Track, while [RFC6045] was published as Informational.
o このドキュメントは標準トラックであり、[RFC6045]は情報として公開されました。
o This document obsoletes [RFC6045] and moves it to Historic status.
o このドキュメントは廃止され[RFC6045]、歴史的なステータスに移動します。
o This document refers to the updated RID transport specification [RFC6546], where appropriate.
o このドキュメントは、必要に応じて更新されたRID輸送仕様[RFC6546]を指します。
o Edits reflected in this updated version of RID are primarily improvements to the informational descriptions. The descriptions have been updated to clarify that IODEF and RID can be used for all types of incidents and are not limited to network security incidents. The language has been updated to change the focus from attacks to incidents, where appropriate. The term "network provider" has been replaced with the more generic term of "service provider". Several introductory informational sections have been removed as they are not necessary for the implementation of the protocol. The sections include:
o RIDのこの更新バージョンに反映された編集は、主に情報説明の改善です。説明は、IODEFとRIDがあらゆる種類のインシデントに使用できることを明確にするために更新されており、ネットワークセキュリティインシデントに限定されません。言語は、攻撃からインシデントに焦点を変更するために更新されました。「ネットワークプロバイダー」という用語は、「サービスプロバイダー」のより一般的な用語に置き換えられました。プロトコルの実装には必要ないため、いくつかの入門情報セクションが削除されました。セクションには以下が含まれます。
* 1.3. Attack Types and RID Messaging,
* 1.3。攻撃タイプとリッドメッセージング、
* 2. RID Integration with Network Provider Technologies,
* 2.ネットワークプロバイダーテクノロジーとの統合を取り戻す、
* 3.1. Integrating Trace Approaches, and
* 3.1。トレースアプローチの統合、および
* 3.2. Superset of Packet Information for Traces.
* 3.2。トレースのパケット情報のスーパーセット。
o An option for a star topology has been included in an informational section to meet current use-case requirements of those who provide reports on incident information.
o STARトポロジのオプションは、インシデント情報に関するレポートを提供する人の現在のユースケース要件を満たすための情報セクションに含まれています。
o The schema version was incremented. The schema has changed to include IODEF [RFC5070] enveloped in RID in the RIDPolicy class using the new ReportSchema class, to include one verified erratum, to include additional enumerations in the Justification attribute, to remove the AcrossNationalBoundaries region enumeration, to add the DataWithHandlingRequirements enumeration in TrafficTypes, and to change the name of the RequestAuthorization MsgType to
o スキーマバージョンが増加しました。スキーマは、新しいReportschemaクラスを使用してRidpolicyクラスにRIDに包まれたIODEF [RFC5070]を含むように変更されました。1つの検証済みのエレナムを含めるために、正当化属性に追加の列挙を含めるために、国家国家領域の列挙を削除して、データスースリングレクアレーションの列挙を追加するために交換型で、およびrequestAuthorizationsmsgtypeの名前を変更するには
Acknowledgement. Additional text has been provided to clarify definitions of enumerated values for some attributes. The RequestAuthorization name was replaced with Acknowledgement to more accurately represent the function of that message type. Text was clarified to note the possible use of this message in response to Query and Report messages. The attributes were fixed in the schema to add 'lang' at the RID class level for language support.
了承。いくつかの属性の列挙値の定義を明確にするために、追加のテキストが提供されています。要求の承認名は、そのメッセージタイプの関数をより正確に表すために、確認に置き換えられました。テキストは、メッセージとレポートメッセージに応じてこのメッセージの使用の可能性に注意するように明確にされました。属性は、言語サポートのためにRIDクラスレベルで「ラング」を追加するためにスキーマに固定されました。
o The TraceRequest and Investigation messages have been collapsed into a single message with the requirement to set the MsgType according to the functionality required for automation. The message descriptions were identical with the exception of the MsgType, which remains an exception depending on the desired function. Since both of the enumerations for MsgType are each a Request, 'Investigation' is now 'InvestigationRequest'. Content may vary within the IODEF document for the type of Request specified.
o TraceRequestおよび調査メッセージは、自動化に必要な機能に従ってMSGTypeを設定する要件を備えた単一のメッセージに崩壊しました。メッセージの説明は、MSGTypeを除き、目的の関数に応じて例外のままであることを除いて同一でした。MSGTypeの両方の列挙はそれぞれ要求であるため、「調査」は「調査の調査」になりました。コンテンツは、指定されたリクエストのタイプのIODEFドキュメント内で異なる場合があります。
o The IncidentQuery message description name and MsgType enumeration value in the schema have been changed to the more generic name of 'Query'.
o IncissQueryメッセージの説明名とスキーマのMSGType列挙値は、「クエリ」のより一般的な名前に変更されました。
o Guidance has been improved to ensure consistent implementations and use of XML encryption to provide confidentiality based on data markers, specifically the iodef:restriction attribute in the IODEF and IODEF-RID schemas. The attribute may also be present in IODEF extension schemas, where the guidance also applies. Additional guidance and restrictions have been added for XML requirements.
o XML暗号化の一貫した実装と使用を確保するためのガイダンスが改善されました。特にIODEF：IODEFおよびIODEF-RIDスキーマのIODEF：制限属性に基づいて機密性を提供します。属性は、ガイダンスも適用されるIODEF拡張スキーマに存在する場合があります。XML要件には、追加のガイダンスと制限が追加されました。
o All of the normative text from the Security Considerations section has been moved to a new section, Security Requirements.
o セキュリティに関する考慮事項セクションのすべての規範的なテキストは、新しいセクションのセキュリティ要件に移動されました。
o The order in which the RID schema is presented in Section 5 has been changed to match the order in the IODEF-RID schema.
o セクション5でRIDスキーマが提示される順序は、IODEF-RIDスキーマの順序と一致するように変更されました。
o Additional text has been provided to explain the content and interactions between entities in the examples.
o 例のエンティティ間のコンテンツと相互作用を説明するために、追加のテキストが提供されています。
o Additional references have been provided to improve interoperability with stricter guidance on the use of XML digital signatures and encryption.
o XMLデジタル署名と暗号化の使用に関するより厳格なガイダンスにより、相互運用性を向上させるための追加の参照が提供されています。
Sections 1, 2, 3, and 12 provide helpful background information and considerations. RID systems participating in a consortium are REQUIRED to fully implement Sections 4, 5, 6, 7, 8, 9, 10, and 11 to prevent interoperability concerns.
セクション1、2、3、および12は、役立つ背景情報と考慮事項を提供します。コンソーシアムに参加しているRIDシステムは、相互運用性の懸念を防ぐためにセクション4、5、6、7、8、9、10、および11を完全に実装する必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
An incident may be defined as a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), system compromise, a worm or Trojan infection, or a single- or multiple-source denial-of-service attack. The goal of tracing a security incident may be to identify the source or to find a point on the network as close to the origin of the incident as possible. Incident tracing can be used to identify the source(s) of an attack in order to halt or mitigate the undesired behavior or to correct an identified issue. RID messages can be communicated between entities to report or investigate any type of incident and allow for actions to be taken when the source of the incident or a point closer to the source is known or has been identified. Methods to accomplish mitigation may include remediation of a configuration issue, filtering or rate-limiting the traffic close to the source, or taking the host or network offline. Care must also be taken to ensure that the systems involved in the RID communications are not abused and to use proper analysis in determining if attack traffic is, in fact, attack traffic at each SP involved in the investigation.
インシデントは、良性構成の問題、ITインシデント、サービスレベル契約（SLA）への違反、システム妥協、ワームまたはトロイの木馬感染、または単一または複数のソースのサービス拒否攻撃として定義される場合があります。セキュリティインシデントを追跡するという目標は、ソースを特定するか、ネットワーク上のポイントを可能な限りインシデントの起源に近づけることです。インシデントトレースを使用して、攻撃のソースを識別して、望ましくない動作を停止または軽減するか、特定された問題を修正することができます。エンティティ間でRIDメッセージを伝達して、あらゆる種類のインシデントを報告または調査し、インシデントのソースまたはソースに近いポイントが既知または特定されている場合にアクションを実行できるようにすることができます。緩和を達成する方法には、構成問題の修復、ソースの近くのトラフィックのフィルタリングまたはレート制限、またはホストまたはネットワークのオフラインを含めることが含まれます。また、RID通信に関与するシステムが乱用されないことを保証し、実際に調査に関与する各SPで攻撃トラフィックが攻撃するかどうかを判断するために適切な分析を使用するように注意する必要があります。
Investigating security incidents can be a difficult task since attackers go to great lengths to obscure their identity. In the case of a security incident, the true source might be identified through an existing established connection to the attacker's point of origin. However, the attacker may not connect to the compromised system for a long period of time after the initial compromise or may access the system through a series of compromised hosts spread across the network. Other methods of obscuring the source may include targeting the host with the same attack from multiple sources using both valid and spoofed source addresses. This tactic can be used to compromise a machine and leave the difficult task of locating the true origin for the administrators. Attackers use many techniques, which can vary between individuals or even organized groups of attackers. Through analysis, the techniques may be grouped into indicators of compromise to be shared via IODEF and RID, further assisting with the improvement of detection capabilities. Security incidents, including distributed denial-of-service (DDoS) attacks, can be difficult or nearly impossible to trace because of the nature of the attack. Some of the difficulties in investigating attacks include the following:
攻撃者は自分のアイデンティティを不明瞭にするためにかなりの時間を費やすため、セキュリティインシデントを調査することは困難な作業になる可能性があります。セキュリティインシデントの場合、真のソースは、攻撃者の原産地との既存の確立された接続を通じて特定される可能性があります。ただし、攻撃者は、最初の妥協後に侵害されたシステムに長期間接続したり、ネットワーク全体に広がる一連の妥協したホストを介してシステムにアクセスしたりすることができます。ソースを不明瞭にする他の方法には、有効なソースアドレスとスプーフィングされたソースアドレスの両方を使用して、複数のソースから同じ攻撃でホストをターゲットにすることが含まれます。この戦術は、マシンを妥協し、管理者の真の起源を見つけるという難しいタスクを残すために使用できます。攻撃者は多くのテクニックを使用します。これは、個人や組織化された攻撃者のグループによって異なる場合があります。分析を通じて、この手法は、IODEFを介して共有されてRIDを共有する妥協の指標にグループ化され、検出機能の改善をさらに支援することができます。分配されたサービス拒否（DDOS）攻撃を含むセキュリティインシデントは、攻撃の性質のために追跡するのが難しいか、ほぼ不可能です。攻撃の調査における困難のいくつかには、以下が含まれます。
o the incident or attack originates from multiple sources;
o インシデントまたは攻撃は複数のソースに由来します。
o the incident may leverage social-engineering techniques or other methods to gain access to resources and intellectual property using what appears to be legitimate access methods such as outbound web sessions from user systems;
o この事件は、ソーシャルエンジニアリング手法またはその他の方法を活用して、ユーザーシステムからのアウトバウンドWebセッションなどの合法的なアクセス方法と思われるリソースや知的財産へのアクセスを得ることができます。
o the attack may include various types of traffic meant to consume server resources, such as a SYN flood attack without a significant increase in bandwidth utilization;
o 攻撃には、帯域幅の使用率が大幅に増加することなくSyn洪水攻撃など、サーバーリソースを消費するためのさまざまなタイプのトラフィックが含まれる場合があります。
o the type of traffic could include valid destination services, which cannot be blocked since they are essential services to business, such as DNS servers at an SP or HTTP requests sent to an organization connected to the Internet;
o トラフィックの種類には、Internetに接続された組織に送信されたSPまたはHTTP要求でのDNSサーバーなど、ビジネスにとって不可欠なサービスであるためブロックすることはできません。
o the attack may utilize varying types of packets including TCP, UDP, ICMP, or other IP protocols;
o 攻撃は、TCP、UDP、ICMP、またはその他のIPプロトコルを含むさまざまな種類のパケットを利用する場合があります。
o the attack may be from "zombies" or large botnets, which then require additional searches to locate a controlling server as the true origin of the attack;
o 攻撃は「ゾンビ」または大きなボットネットからのものである可能性があります。これにより、攻撃の真の起源として制御サーバーを見つけるために追加の検索が必要です。
o the attack may use a very small number of packets from any particular source, thus making a trace after the fact nearly impossible;
o 攻撃は、特定のソースから非常に少数のパケットを使用する可能性があるため、事実がほぼ不可能になった後に痕跡をかけることがあります。
o the indicators of a compromise may be difficult to detect.
o 妥協の指標を検出するのは難しい場合があります。
If the source(s) of an incident cannot be determined from IP address information, it may be possible to trace the traffic based on characteristics of the incident such as tracing the increased bandwidth utilization or the type of packets seen by the client. In the case of packets with spoofed source addresses, it is not a trivial task to identify the source of an attack.
IPアドレス情報からインシデントのソースを決定できない場合、帯域幅の増加またはクライアントが見たパケットの種類を追跡するなど、インシデントの特性に基づいてトラフィックを追跡することが可能です。スプーフィングされたソースアドレスを備えたパケットの場合、攻撃のソースを識別することは些細な作業ではありません。
IODEF, any extensions to IODEF, and RID can be used to detail an incident, characteristics of the incident (as it evolves), the incident history, and communications of the incident to facilitate the resolution and reporting of the incident.
IODEF、IODEFへの拡張、およびRIDを使用して、インシデント、インシデントの特性（進化するにつれて）、インシデント履歴、インシデントの通信を詳細に説明できます。
Expediting the communication between CSIRTs and SPs is essential when responding to a security-related incident, which may cross network access points between service providers. As a result of the urgency involved in this inter-service-provider security incident communication, there must be an effective system in place to facilitate the interaction. This communication policy or method should involve multiple means of communication to avoid a single
CSIRTとSPS間の通信を促進することは、サービスプロバイダー間のネットワークアクセスポイントを越える可能性があるセキュリティ関連のインシデントに対応する場合に不可欠です。このサービス間プロバイダーのセキュリティインシデントコミュニケーションに関与する緊急性の結果として、相互作用を促進するための効果的なシステムが存在する必要があります。このコミュニケーションポリシーまたは方法には、単一を避けるために複数のコミュニケーション手段を伴う必要があります
point of failure. Email is one way to transfer information about the incident, packet traces, etc. However, email may not be received in a timely fashion or be acted upon with the same urgency as a phone call or other communication mechanism like RID.
障害点。電子メールは、インシデント、パケットトレースなどに関する情報を転送する1つの方法です。ただし、電子メールはタイムリーに受信したり、電話やRIDなどの他の通信メカニズムと同じ緊急で行動することはできません。
A technical solution to trace traffic across a single SP may include homegrown or commercial systems for which RID messaging must accommodate the input requirements. The incident-handling system used on the SP's backbone by the CSIRT to coordinate the trace across the single network requires a method to accept, process, and relay RID messages to the system, as well as to wait for responses from the system to continue the RID request process as appropriate. In this scenario, each service provider maintains its own system capable of communicating via RID and integrates with a management station used for monitoring and analysis. An alternative for providers lacking sufficient resources may be to have a neutral third party with access to the provider's network resources who could be used to perform the incident-handling functions. This could be a function of a central organization operating as a CSIRT for countries as a whole or within a consortium that may be able to provide centralized resources.
単一のSPでトラフィックを追跡するための技術的なソリューションには、RIDメッセージングが入力要件に対応する必要がある自家製または商用システムが含まれる場合があります。 CSIRTによってSPのバックボーンで使用されるインシデント処理システムは、単一のネットワーク全体のトレースを調整するために、システムへのRIDメッセージを受け入れ、処理し、リレーする方法を必要とし、システムからの応答が待機する方法が必要です。必要に応じてリクエストプロセスをRIDします。このシナリオでは、各サービスプロバイダーは、RIDを介して通信できる独自のシステムを維持し、監視と分析に使用される管理ステーションと統合します。十分なリソースを欠いているプロバイダーの代替手段は、インシデント処理機能を実行するために使用できるプロバイダーのネットワークリソースにアクセスできる中立の第三者を持つことです。これは、集中リソースを提供できる可能性のあるコンソーシアム全体またはコンソーシアム内のCSIRTとして運営されている中央組織の機能である可能性があります。
Consortiums could consist of a federation or a group of service providers or CSIRTs that agrees to participate in the RID communication protocol with an agreed-upon policy and communication protocol facilitating the secure transport of IODEF-RID XML documents. Transport for RID messages is specified in [RFC6546].
コンソーシアムは、IODEF-RID XMLドキュメントの安全な輸送を促進する合意されたポリシーと通信プロトコルを備えたRIDコミュニケーションプロトコルに参加することに同意する連邦またはサービスプロバイダーまたはCSIRTのグループで構成されます。RIDメッセージの輸送は[RFC6546]で指定されています。
One goal of RID is to prevent the need to permit access to other networks' equipment. RID provides a standard messaging mechanism to enable the communication of incident-handling information to other providers in a consortium or in neighboring networks. The third party mentioned above may be used in this technical solution to assist in facilitating incident handling and possibly traceback through smaller providers. The RID messaging mechanism may be a logical or physical out-of-band network to ensure that the communication is secure and unaffected by the state of the network under attack. The two management methods would accommodate the needs of larger providers to maintain full management of their network, and the third-party option could be available to smaller providers who lack the necessary human resources to perform incident-handling operations. The first method enables the individual providers to involve (via a notification and alerting system) their network operations staff to authorize the continuance of a trace or other necessary response to a RID communication request through their network.
RIDの目標の1つは、他のネットワークの機器へのアクセスを許可する必要性を防ぐことです。 RIDは、コンソーシアムまたは近隣のネットワークで他のプロバイダーとのインシデント処理情報の通信を可能にする標準的なメッセージングメカニズムを提供します。上記の第三者は、この技術的なソリューションで使用されて、インシデント処理の促進と、小規模なプロバイダーによるトレースバックを支援することができます。 RIDメッセージングメカニズムは、通信が攻撃中のネットワークの状態によって安全で影響を受けないようにするための論理的または物理的な帯域外ネットワークである可能性があります。 2つの管理方法は、ネットワークの完全な管理を維持するための大規模なプロバイダーのニーズに対応し、インシデント処理操作を実行するために必要な人材を欠いている小規模なプロバイダーがサードパーティオプションを利用できる可能性があります。最初の方法により、個々のプロバイダーがネットワーク運用スタッフを（通知とアラートシステムを介して）携帯スタッフを巻き込むことができ、ネットワークを介したRID通信要求に対するトレースまたはその他の必要な応答の継続を許可できます。
The network used for the communication should consist of out-of-band or protected channels (direct communication links) or encrypted channels dedicated to the transport of RID messages. The communication links would be direct connections (virtual or physical) between peers who have agreed-upon use and abuse policies through a consortium. Consortiums might be linked through policy comparisons and additional agreements to form a larger web or iterative network of peers that correlates to the traffic paths available over the larger web of networks or is based on regions and logical groups. Contact information, IP addresses of RID systems, and other information must be coordinated between bilateral peers by a consortium and may use existing databases, such as the routing arbiter. The security, configuration, and Confidence rating schemes of the RID messaging peers must be negotiated by peers and must meet certain overall requirements of the fully connected network (Internet, government, education, etc.) through the peering and/or a consortium-based agreement.
通信に使用されるネットワークは、帯域外または保護されたチャネル（直接通信リンク）またはRIDメッセージの輸送専用の暗号化されたチャネルで構成する必要があります。コミュニケーションリンクは、コンソーシアムを通じて使用と乱用ポリシーに合意したピア間の直接的な接続（仮想または物理的）です。コンソーシアムは、ポリシーの比較と追加の契約を通じてリンクされ、より大きなネットワークのWebで利用可能なトラフィックパスに相関する、または地域と論理グループに基づいている、より大きなWebまたは反復的なピアネットワークを形成する可能性があります。連絡先情報、RIDシステムのIPアドレス、およびその他の情報は、コンソーシアムによって二国間ピア間で調整する必要があり、ルーティングアービターなどの既存のデータベースを使用する場合があります。 RIDメッセージングピアのセキュリティ、構成、および信頼評価スキームは、ピアによって交渉する必要があり、ピアリングおよび/またはコンソーシアムベースのコンソーシアムベースを通じて、完全に接続されたネットワーク（インターネット、政府、教育など）の特定の全体的な要件を満たす必要があります。合意。
RID messaging established with clients of an provider may be negotiated in a contract as part of a value-added service or through a service level agreement (SLA). Further discussion is beyond the scope of this document and may be more appropriately handled in peering or service level agreements.
プロバイダーのクライアントと確立されたRIDメッセージングは、付加価値サービスの一部として、またはサービスレベル契約（SLA）を通じて契約で交渉される場合があります。さらなる議論は、このドキュメントの範囲を超えており、ピアリングまたはサービスレベルの契約により、より適切に処理される可能性があります。
Procedures for incident handling need to be established and well known by anyone that may be involved in incident response. The procedures should also contain contact information for internal escalation procedures, as well as for external assistance groups such as a CSIRT, CERT Coordination Center (CERT/CC), Global Information Assurance Certification (GIAC), and the U.S. Federal Bureau of Investigations (FBI) or other assisting government organization in the country of the investigation.
インシデント処理の手順は、インシデント対応に関与している可能性のある人が確立し、よく知られている必要があります。この手順には、内部エスカレーション手順、およびCSIRT、CERT COORDINATION CENTER（CERT/CC）、Global Information Assurance Certification（GIAC）、米国連邦調査局などの外部支援グループ（FBIなど）の連絡先情報も含める必要があります。）または調査の国における政府組織を支援する他の支援。
RID provides a protocol and format that ensures interoperability between vendors for the implementation of an incident messaging mechanism. The messages should meet several requirements in order to be meaningful as they traverse multiple networks. RID provides the framework necessary for communication between networks involved in the incident handling, possible traceback, and mitigation of a security incident. Several message types described in Section 4.2 are necessary to facilitate the handling of a security incident. The message types include the Report, Query, Request, Acknowledgement, and Result message.
RIDは、インシデントメッセージングメカニズムの実装のためにベンダー間の相互運用性を保証するプロトコルと形式を提供します。メッセージは、複数のネットワークを横断するために意味のあるものになるために、いくつかの要件を満たす必要があります。RIDは、インシデントハンドリング、可能性のあるトレースバック、およびセキュリティインシデントの緩和に関与するネットワーク間の通信に必要なフレームワークを提供します。セクション4.2で説明されているいくつかのメッセージタイプは、セキュリティインシデントの処理を促進するために必要です。メッセージタイプには、レポート、クエリ、リクエスト、謝辞、および結果メッセージが含まれます。
The Report message is used when an incident is to be filed on a RID system or associated database, where no further action is required.
レポートメッセージは、インシデントがRIDシステムまたは関連データベースに提出される場合に使用されますが、それ以上のアクションは必要ありません。
A Query message is used to request information on a particular incident. A Request message with options set to 'TraceRequest' is used when the source of the traffic may have been spoofed. In that case, each SP in the upstream path who receives this Request will issue a trace across the network to determine the upstream source of the traffic. The Acknowledgement and Result messages are used to communicate the status and result of a Request. The Request message with options set to 'InvestigationRequest' may be sent to any party assisting in an incident investigation. The InvestigationRequest leverages the bilateral relationships or a consortium's interconnections to mitigate or stop problematic traffic close to the source. Routes could determine the fastest path to a known source IP address in the case of an InvestigationRequest. A Request message (set to 'TraceRequest' or 'InvestigationRequest') sent between RID systems to stop traffic at the source through a bordering network requires the information enumerated below:
クエリメッセージは、特定のインシデントに関する情報を要求するために使用されます。 「Tracerequest」に設定されたオプションを備えたリクエストメッセージは、トラフィックのソースがスプーフィングされている可能性がある場合に使用されます。その場合、このリクエストを受信した上流パスの各SPは、ネットワーク全体でトレースを発行して、トラフィックの上流のソースを決定します。謝辞メッセージと結果メッセージは、リクエストのステータスと結果を伝えるために使用されます。 「調査リケスト」に設定されたオプションを使用した要求メッセージは、インシデント調査を支援する当事者に送信される場合があります。調査の要請は、ソースの近くで問題のあるトラフィックを緩和または停止するために、二国間関係またはコンソーシアムの相互接続を活用しています。ルートは、調査の場合に既知のソースIPアドレスへの最速のパスを決定できます。 RIDシステム間で送信されるリクエストメッセージ（「TraceRequest」または「InvestigationRequest」に設定）は、境界ネットワークを介してソースのトラフィックを停止する必要があります。
1. Enough information to enable the network administrators to make a decision about the importance of continuing the trace.
1. ネットワーク管理者がトレースを継続することの重要性について決定できるようにするのに十分な情報。
2. The incident or IP packet information needed to carry out the trace or investigation.
2. トレースまたは調査を実行するために必要なインシデントまたはIPパケット情報。
3. Contact information of the origin of the RID communication. The contact information could be provided through the Autonomous System Number (ASN) [RFC1930] or Network Information Center (NIC) handle information listed in the Registry for Internet Numbers or other Internet databases.
3. RID通信の起源の連絡先情報。連絡先情報は、自律システム番号（ASN）[RFC1930]またはネットワーク情報センター（NIC）を介して提供できます。インターネット番号またはその他のインターネットデータベースのレジストリにリストされている情報を処理できます。
4. Network path information to help prevent any routing loops through the network from perpetuating a trace. If a RID system receives a Request with MsgType set to 'TraceRequest' that contains its own information in the path, the trace must cease and the RID system should generate an alert to inform the network operations staff that a tracing loop exists.
4. ネットワークパス情報は、ネットワークを介したルーティングループがトレースを永続させるのを防ぐのに役立ちます。RIDシステムが、パスに独自の情報を含む「Tracerequest」に設定されたMSGTypeを使用してリクエストを受信した場合、トレースは停止する必要があり、RIDシステムは、トレースループが存在することをネットワーク運用スタッフに通知するアラートを生成する必要があります。
5. A unique identifier for a single attack. This identifier should be used to correlate traces to multiple sources in a DDoS attack.
5. 単一の攻撃のための一意の識別子。この識別子は、DDOS攻撃の複数のソースとトレースを相関させるために使用する必要があります。
Use of the communication network and the RID protocol must be for pre-approved, authorized purposes only. It is the responsibility of each participating party to adhere to guidelines set forth in both a global use policy established through the peering agreements for each bilateral peer or agreed-upon consortium guidelines. The purpose of such policies is to avoid abuse of the system; the policies shall be developed by a consortium or participating entities. The global policy may be dependent on the domain it operates under; for example, a government network or a commercial network such as the Internet
通信ネットワークとRIDプロトコルの使用は、事前に承認された許可された目的のみでなければなりません。各参加当事者の責任は、各両側のピアまたは合意されたコンソーシアムガイドラインのピアリング契約を通じて確立されたグローバルな使用ポリシーの両方に定められたガイドラインを遵守することです。このようなポリシーの目的は、システムの乱用を避けることです。ポリシーは、コンソーシアムまたは参加エンティティによって開発されるものとします。グローバルポリシーは、動作するドメインに依存する可能性があります。たとえば、政府ネットワークやインターネットなどの商業ネットワーク
would adhere to different guidelines to address the individual concerns. Privacy issues must be considered in public networks such as the Internet. Privacy issues are discussed in the Security Requirements section, along with other requirements that must be agreed upon by participating entities.
個々の懸念に対処するために、さまざまなガイドラインを遵守します。プライバシーの問題は、インターネットなどのパブリックネットワークで考慮する必要があります。プライバシーの問題は、セキュリティ要件セクションで、参加しているエンティティが合意しなければならない他の要件で説明します。
RID requests must be legitimate incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system includes a request to rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
RID要求は、妨害や検閲などの目的に使用されていない正当なインシデントでなければなりません。このようなシステムの不正行為の例には、インターネット上のユーザー間で情報が共有されるのを防ぐための正当なトラフィックをレートリミットする要求（オンラインバージョンの論文へのアクセスを制限）または競合他社の製品からのアクセスを制限するために、ビジネスを妨害するためのリクエストが含まれます。。
The RID system should be configurable to either require user input or automatically continue traces. This feature enables a network manager to assess the available resources before continuing a Request message set to 'InvestigationRequest' or 'TraceRequest'. If the Confidence rating (provided in IODEF) is low, it may not be in the provider's best interest to continue the Request with options set to 'InvestigationRequest' or 'TraceRequest'. The Confidence ratings must adhere to the specifications for selecting the percentage used to avoid abuse of the system. Requests must be issued by authorized individuals from the initiating CSIRT, set forth in policy guidelines established through peering or a SLA.
RIDシステムは、ユーザー入力を必要とするか、トレースを自動的に継続するように構成可能である必要があります。この機能により、ネットワークマネージャーは、「Request」または「TraceRequest」に設定された要求メッセージを継続する前に、利用可能なリソースを評価できます。信頼評価（IODEFで提供）が低い場合、「調査のリケスト」または「TraceRequest」に設定されたオプションを継続することは、プロバイダーの最大の利益ではない可能性があります。信頼評価は、システムの乱用を避けるために使用される割合を選択するための仕様に準拠する必要があります。リクエストは、PearingまたはSLAを通じて確立されたポリシーガイドラインに記載されているCSIRTの開始から認定された個人が発行する必要があります。
The most basic topology for communicating RID systems is a direct connection or a bilateral relationship as illustrated below.
RIDシステムを通信するための最も基本的なトポロジーは、以下に示すように、直接的な接続または二国間関係です。
___________ __________
| | | |
| RID |__________-------------___________| RID |
|_________| | SP Border | |________|
-------------
Figure 1: Direct Peer Topology
図1：直接ピアトポロジ
Within the consortium model, several topologies might be agreed upon and used. One would leverage bilateral network peering relationships of the members of the consortium. The peers for RID would match that of routing peers, and the logical network borders would be used. This approach may be necessary for an iterative trace where the source is unknown. The model looks like the above diagram; however, there may be an extensive number of interconnections of bilateral relationships formed. Also within a consortium model, it may be useful to establish an integrated mesh of networks to pass RID messages. This may be beneficial when the source address is known,
コンソーシアムモデル内では、いくつかのトポロジーが合意され、使用される場合があります。コンソーシアムのメンバーの二国間ネットワークのピアリング関係を活用します。RIDのピアはルーティングピアのそれと一致し、論理ネットワークの境界線が使用されます。このアプローチは、ソースが不明な繰り返しトレースに必要になる場合があります。モデルは上記の図のように見えます。ただし、形成された二国間関係の相互接続が豊富にある場合があります。また、コンソーシアムモデル内では、RIDメッセージを渡すためにネットワークの統合メッシュを確立することが有用かもしれません。これは、ソースアドレスがわかっている場合に有益かもしれません、
and an interconnection may provide a faster route to reach the closest upstream peer to the source of the attack traffic if direct communication between SPs is not possible. An example is illustrated below.
また、相互接続は、SPS間の直接通信が不可能な場合、攻撃トラフィックのソースに最も近い上流のピアに到達するためのより速いルートを提供する場合があります。例を以下に示します。
_______ _______ _______
| | | | | |
__| RID |____-------------____| RID |____-------------____| RID |__
|_____| | SP Border | |_____| | SP Border | |_____|
| ------------- ------------- |
|_______________________________________________________|
Direct connection to network that is not an immediate network peer
即時のネットワークピアではないネットワークへの直接接続
Figure 2: Mesh Peer Topology
図2：メッシュピアトポロジー
By using a fully meshed model in a consortium, broadcasting RID requests would be possible, but not advisable. By broadcasting a request, RID peers that may not have carried the attack traffic on their network would be asked to perform a trace for the potential of decreasing the time in which the true source was identified. As a result, many networks would have utilized unnecessary resources for a Request that may have also been unnecessary.
コンソーシアムで完全にメッシュ化されたモデルを使用することにより、放送のRIDリクエストは可能ですが、お勧めできません。リクエストを放送することにより、ネットワーク上の攻撃トラフィックを携帯していない可能性のあるRIDピアは、真のソースが特定された時間を減らす可能性についてトレースを実行するように求められます。その結果、多くのネットワークは、不要なリクエストにも不要なリソースを利用していました。
A star topology may be desirable in instances where a peer may be a provider of incident information. This requires trust relationships to be established between the provider of information and each of the consumers of that information. Examples may include country-level CSIRTs or service providers distributing incident information to organizations.
ピアがインシデント情報のプロバイダーである場合がある場合、スタートポロジーが望ましい場合があります。これには、情報プロバイダーとその情報の各消費者との間に信頼関係を確立する必要があります。例には、カントリーレベルのCSIRTSまたはサービスプロバイダーがインシデント情報を組織に配布することが含まれます。
RID is derived from the IODEF data model and inherits all of the data types defined in the IODEF model. One data type is added by RID: BOOLEAN.
RIDはIODEFデータモデルから派生し、IODEFモデルで定義されているすべてのデータ型を継承します。1つのデータ型がRID：Booleanによって追加されます。
A boolean value is represented by the BOOLEAN data type.
ブール値は、ブールデータ型で表されます。
The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in the schema. Note that there are two lexical representations for boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false' or FALSE.
ブールデータ型は、スキーマで「xs：boolean」[xmlschema]として実装されています。[xmlschema]には、ブール値には2つの語彙表現があることに注意してください：trueと「0」または「false」またはfalseの '1'または「true」。
The five RID message types described below MUST be implemented. RID messages uses both the IODEF [RFC5070] and RID document, which MUST be encapsulated for transport as specified in [RFC6546]. The messages are generated and received on designated systems for RID communications. Each RID message type, along with an example, is described in the following sections. The IODEF-RID schema is introduced in Section 5 to support the described RID message types.
以下に説明する5つのRIDメッセージタイプを実装する必要があります。RIDメッセージは、[RFC6546]で指定されているように輸送用にカプセル化する必要があるIODEF [RFC5070]とRIDドキュメントの両方を使用します。メッセージは、RID通信のために指定されたシステムで生成および受信されます。各RIDメッセージタイプと例とともに、次のセクションで説明します。IODEF-RIDスキーマは、セクション5に導入されており、説明されているRIDメッセージタイプをサポートしています。
1. Request. This message type is used when a request ('InvestigationRequest' or 'TraceRequest') is needed. The purpose of the Request message (set to 'InvestigationRequest') is to leverage the existing peer relationships in order to notify the SP closest to the source of the valid traffic of a security-related incident for any necessary actions to be taken. The Request (set to 'TraceRequest') is used when the traffic has to be traced iteratively through networks to find the source by setting the MsgType to 'TraceRequest'. The 'InvestigationRequest' MsgType is used for all other Request messages.
1. リクエスト。このメッセージタイプは、リクエスト（ 'restrequest'または 'tracerequest'）が必要な場合に使用されます。リクエストメッセージの目的（「調査のリケスト」に設定）は、既存のピア関係を活用して、必要なアクションを実行するためにセキュリティ関連のインシデントの有効なトラフィックのソースに最も近いSPに通知することです。リクエスト（「tracerequest」に設定）は、ネットワークを介してトラフィックを繰り返しトレースする必要がある場合に使用され、msgtypeを「tracerequest」に設定することによりソースを見つけます。「調査リクエスト」msgtypeは、他のすべての要求メッセージに使用されます。
2. Acknowledgement. This message is sent to the initiating RID system from each of the upstream provider's RID systems to provide information on the status of a Request. The Acknowledgement is also used to provide a reason why a Request, Report, or Query was not accepted.
2. 了承。このメッセージは、リクエストのステータスに関する情報を提供するために、上流のプロバイダーのRIDシステムのそれぞれからInitiating RIDシステムに送信されます。謝辞は、リクエスト、レポート、またはクエリが受け入れられなかった理由を提供するためにも使用されます。
3. Result. The Result message is used to provide a final report and the notification of actions taken for a Request. This message is sent to the initiating CSIRT through the network of RID systems in the path of the trace as notification that the source of the attack was located.
3. 結果。結果メッセージは、最終レポートとリクエストのために取られたアクションの通知を提供するために使用されます。このメッセージは、攻撃のソースが配置されたという通知として、トレースのパスにあるRIDシステムのネットワークを介してCSIRTを開始するために送信されます。
4. Report. This message is used to report a security incident, for which no action is requested. This may be used for the purpose of correlating attack information by CSIRTs, sharing incident information, statistics and trending information, etc.
4. 報告。このメッセージは、セキュリティインシデントを報告するために使用されますが、アクションは要求されません。これは、CSIRTによる攻撃情報を相関させ、インシデント情報、統計、トレンド情報を共有する目的で使用できます。
5. Query. This message is used to request information about an incident or incident type from a trusted system communicating via RID. The response is provided through the Report message.
5. クエリ。このメッセージは、RIDを介して通信する信頼できるシステムからインシデントまたはインシデントタイプに関する情報を要求するために使用されます。応答は、レポートメッセージを通じて提供されます。
When an application receives a RID message, it must be able to determine the type of message and parse it accordingly. The message type is specified in the RIDPolicy class. The RIDPolicy class may
アプリケーションがRIDメッセージを受信した場合、メッセージの種類を決定し、それに応じて解析できる必要があります。メッセージタイプは、Ridpolicyクラスで指定されています。Ridpolicyクラスは5月に
also be used by the transport protocol to facilitate the communication of security incident data to trace, investigate, query, or report information regarding security incidents.
また、セキュリティインシデントデータの通信を容易にして、セキュリティインシデントに関する情報を追跡、調査、質問、または報告するために、トランスポートプロトコルで使用されます。
There are three classes included in the RID extension required to facilitate RID communications. The RequestStatus class is used to indicate the approval status of a Request message; the IncidentSource class is used to report whether or not a source was found and to identify the source host(s) or network(s); and the RIDPolicy class provides information on the agreed-upon policies and specifies the type of communication message being used.
RID通信を促進するために必要なRID拡張機能には、3つのクラスが含まれています。RequestStatusクラスは、リクエストメッセージの承認ステータスを示すために使用されます。IncidentSourceクラスは、ソースが見つかったかどうかを報告し、ソースホストまたはネットワークを識別するために使用されます。また、Ridpolicyクラスは、合意されたポリシーに関する情報を提供し、使用されている通信メッセージのタイプを指定します。
The RID schema defines communication-specific metadata to support the exchange of incident information in an IODEF document. The intent in maintaining a separate schema and not using the AdditionalData extension of IODEF is the flexibility of sending messages between RID hosts. Since RID is a separate schema and RID messages include both the RID and IODEF documents, the RID message acts as an envelope in that policy and security defined at the RID message layer are applied to both documents. One reason for maintaining separate schemas is for flexibility, where the RIDPolicy class can be easily extracted for use in the RID message and by the transport protocol.
RIDスキーマは、IODEFドキュメントでのインシデント情報の交換をサポートするために、通信固有のメタデータを定義します。IODEFの追加のDATA拡張機能を使用しないことを目的としているのは、RIDホスト間でメッセージを送信する柔軟性です。RIDは個別のスキーマであり、RIDメッセージにはRIDとIODEFの両方のドキュメントが含まれているため、RIDメッセージは両方のドキュメントに適用されるRIDメッセージレイヤーで定義されているポリシーとセキュリティの封筒として機能します。別々のスキーマを維持する理由の1つは、Ridpolicyクラスを簡単に抽出して、RIDメッセージおよびトランスポートプロトコルによって簡単に抽出できる柔軟性です。
The security requirements of sending incident information between entities include the use of encryption. The RIDPolicy information is not required to be encrypted, so separating out this data from the IODEF XML document removes the need for decrypting and parsing the IODEF document to determine how it should be handled at each RID host.
エンティティ間でインシデント情報を送信するセキュリティ要件には、暗号化の使用が含まれます。Ridpolicy情報を暗号化する必要はないため、IODEF XMLドキュメントからこのデータを分離すると、IODEFドキュメントを復号化および解析して、各RIDホストでの処理方法を決定する必要がなくなります。
The purpose of the RIDPolicy class is to specify the message type for the receiving host, facilitate the policy needs of RID, and provide routing information in the form of an IP address of the destination RID system.
Ridpolicyクラスの目的は、受信ホストのメッセージタイプを指定し、RIDのポリシーニーズを促進し、宛先RIDシステムのIPアドレスの形でルーティング情報を提供することです。
The security requirements and policy guidelines are discussed in Section 9. The policy is defined between RID peers and within or between consortiums. RIDPolicy is meant to be a tool to facilitate the defined policies. This MUST be used in accordance with policy set between clients, peers, consortiums, and/or regions. Security, privacy, and confidentiality MUST be considered as specified in this document.
セキュリティ要件とポリシーガイドラインについては、セクション9で説明します。ポリシーは、RIDピア間およびコンソーシアム内またはコンソーシアム間で定義されています。Ridpolicyは、定義されたポリシーを促進するためのツールであることを意図しています。これは、クライアント、ピア、コンソーシアム、および/または地域の間のポリシーセットに従って使用する必要があります。このドキュメントで指定されているように、セキュリティ、プライバシー、および機密性を考慮する必要があります。
The RID schema is defined as follows:
RIDスキーマは次のように定義されています。
+------------------+
| RID |
+------------------+
| |
| ENUM lang |<>---{0..1}----[ RIDPolicy ]
| |
| |<>---{0..1}----[ RequestStatus ]
| |
| |<>---{0..1}----[ IncidentSource ]
+------------------+
Figure 3: The RID Schema
図3：RIDスキーマ
The aggregate classes that constitute the RID schema in the iodef-rid namespace are as follows:
IODEF-RIDネームスペースのRIDスキーマを構成する集約クラスは次のとおりです。
RIDPolicy
リドポリック
Zero or One. The RIDPolicy class is used by all message types to facilitate policy agreements between peers, consortiums, or federations, as well as to properly route messages.
ゼロまたは1。Ridpolicyクラスは、すべてのメッセージタイプで使用され、ピア、コンソーシアム、または連合間の政策契約を促進し、メッセージを適切にルーティングします。
RequestStatus
RequestStatus
Zero or One. The RequestStatus class is used only in Acknowledgement messages. The message reports back to the CSIRT or SP in the Acknowledgement message to provide status on a Request or if an error or problem occurs with the receipt or processing of a Report, Query, or Result message.
ゼロまたは1。RequestStatusクラスは、確認メッセージでのみ使用されます。このメッセージは、承認メッセージでCSIRTまたはSPに報告し、リクエストにステータスを提供するか、レポート、クエリ、または結果メッセージの受領または処理でエラーまたは問題が発生した場合。
IncidentSource
INCIDENTSOURCE
Zero or One. The IncidentSource class is used in the Result message only. The IncidentSource provides the information on the identified source host or network of an attack trace or investigation.
ゼロまたは1。Incidentsourceクラスは、結果メッセージのみで使用されます。Incidentsourceは、攻撃トレースまたは調査の特定されたソースホストまたはネットワークに関する情報を提供します。
Each of the three listed classes may be the only class included in the RID class, hence the option for zero or one. In some cases, RIDPolicy MAY be the only class in the RID definition when used by the transport protocol [RFC6546], as that information should be as small as possible and may not be encrypted. The RequestStatus message MUST be able to stand alone without the need for an IODEF document to facilitate the communication, limiting the data transported to the required elements per [RFC6546].
リストされた3つのクラスのそれぞれは、RIDクラスに含まれる唯一のクラスである可能性があるため、ゼロまたは1つのクラスのオプションです。場合によっては、輸送プロトコル[RFC6546]が使用する場合、RidpolicyはRID定義の唯一のクラスである可能性があります。RequestStatusメッセージは、[RFC6546]ごとに必要な要素に輸送されるデータを制限して、通信を促進するためにIODEFドキュメントを必要とせずに単独でスタンドラングできる必要があります。
The RID class has one attribute:
RIDクラスには1つの属性があります。
lang
ラング
One. REQUIRED. ENUM. A valid language code per [RFC5646] constrained by the definition of "xs:language" inherited from [XML1.0].
1。必要。列挙。[XML1.0]から継承された「XS：言語」の定義によって制約されている[RFC5646]あたりの有効な言語コード。
The RIDPolicy class facilitates the delivery of RID messages and is also referenced for transport in the transport document [RFC6546]. The RIDPolicy Class includes the ability to embed an IODEF document or XML documents that conform to schemas other than IODEF in the ReportSchema element.
Ridpolicyクラスは、RIDメッセージの配信を促進し、輸送文書[RFC6546]の輸送用にも参照されます。Ridpolicyクラスには、Reportschema要素のIODEF以外のスキーマに適合するIODEFドキュメントまたはXMLドキュメントを埋め込む機能が含まれています。
+------------------------+
| RIDPolicy |
+------------------------+
| |
| ENUM restriction |<>-------------[ Node ]
| ENUM MsgType |
| ENUM MsgDestination |<>---{0..1}----[ IncidentID ]
| ENUM ext-MsgType |
| ENUM ext-MsgDestination|<>---{1..*}----[ PolicyRegion ]
| |
| |<>---{1..*}----[ TrafficType ]
| |
| |<>---{0..1}----[ ReportSchema ]
+------------------------+
Figure 4: The RIDPolicy Class
図4：Ridpolicyクラス
The aggregate elements that constitute the RIDPolicy class are as follows:
Ridpolicyクラスを構成する集約要素は次のとおりです。
Node
ノード
One. The Node class is used to identify a host or network device, in this case to identify the system communicating RID messages, and the usage is determined by the MsgDestination attribute. The base definition of this class is reused from the IODEF specification [RFC5070], Section 3.16. See Section 11 of this document for Internationalization considerations.
1。ノードクラスは、ホストまたはネットワークデバイスを識別するために使用されます。この場合、RIDメッセージの通信システムを識別し、使用法はMSGDESTINATION属性によって決定されます。このクラスの基本定義は、IODEF仕様[RFC5070]、セクション3.16から再利用されます。国際化に関する考慮事項については、このドキュメントのセクション11を参照してください。
IncidentID
incapsid
Zero or one. Global reference pointing back to the IncidentID defined in the IODEF data model. The IncidentID includes the name of the CSIRT, an incident number, and an instance of that incident. The instance number is appended with a dash separating the values and is used in cases for which it may be desirable to group incidents. Examples of incidents that may be grouped include botnets, polymorphic attacks, DDoS attacks, multiple hops of compromised systems found during an investigation, etc.
ゼロまたは1。IODEFデータモデルで定義されているIncissidIDを指すグローバル参照。IncisidIDには、CSIRTの名前、インシデント番号、およびそのインシデントのインスタンスが含まれています。インスタンス番号は、値を分離するダッシュで追加され、グループインシデントが望ましい場合に使用されます。グループ化される可能性のあるインシデントの例には、ボットネット、多型攻撃、DDOS攻撃、調査中に見つかった侵害されたシステムの複数のホップなどが含まれます。
PolicyRegion
ポリシーリオン
One or many. REQUIRED. The values for the attribute "region" are used to determine what policy area may require consideration before a trace can be approved. The PolicyRegion may include multiple selections from the attribute list in order to fit all possible policy considerations when crossing regions, consortiums, or networks.
1つまたは多く。必要。属性「領域」の値は、トレースを承認する前に検討が必要なポリシー領域を決定するために使用されます。ポリシーリージョンには、地域、コンソーシアム、またはネットワークを横断する際に可能なすべてのポリシーに関する考慮事項に適合するために、属性リストから複数の選択を含めることができます。
region
領域
One or many. REQUIRED. ENUM. The attribute region is used to identify the expected sharing range of the incident information. The region may be within a region or defined by existing relationships such as those of a consortium or a client to a service provider.
1つまたは多く。必要。列挙。属性領域は、インシデント情報の予想される共有範囲を識別するために使用されます。この地域は、地域内にあるか、コンソーシアムやクライアントのような既存の関係によって定義されている場合があります。
1. ClientToSP. A client initiated the request to their service provider (SP). A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.). An SP may be a network, telecommunications, infrastructure, or other type of SP where a client-to-vendor relationship has been established. The client-to-vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.
1. ClientTosp。クライアントは、サービスプロバイダー（SP）へのリクエストを開始しました。クライアントは、個人、企業、またはその他のタイプのエンティティ（政府、商業、教育など）である場合があります。SPは、クライアントとベンダーとの関係が確立されたネットワーク、電気通信、インフラストラクチャ、またはその他のタイプのSPである場合があります。クライアントとベンダーとの関係は、通常、期待と信頼関係を定義するための契約または契約を確立します。
2. SPToClient. An SP initiated a RID request or report to a client. A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.). An SP may be a network, telecommunications, infrastructure, or other type of SP where a client-to-vendor relationship has been established. The client-to-vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.
2. sptoclient。SPは、クライアントへのRIDリクエストまたはレポートを開始しました。クライアントは、個人、企業、またはその他のタイプのエンティティ（政府、商業、教育など）である場合があります。SPは、クライアントとベンダーとの関係が確立されたネットワーク、電気通信、インフラストラクチャ、またはその他のタイプのSPである場合があります。クライアントとベンダーとの関係は、通常、期待と信頼関係を定義するための契約または契約を確立します。
3. IntraConsortium. Incident information that should have no restrictions within the boundaries of a consortium with the agreed-upon use and abuse guidelines. A consortium is a well-defined group with established members and trust relationships specific to sharing within that group. A consortium would typically define the types of data that can be shared in advance, define the expectations on protecting that data, as well as have established contractual agreements. Examples of consortiums may include industry-focused sharing communities (financial, government, research and education, etc.) or cross industry sharing communities (for instance, organizations within local proximity that form a sharing group).
3. コンソーシアム内。合意された使用および乱用ガイドラインを備えたコンソーシアムの境界内に制限を持たないべきインシデント情報。コンソーシアムは、そのグループ内で共有することに固有のメンバーと信頼関係を持つ明確なグループです。コンソーシアムは通常、事前に共有できるデータの種類を定義し、そのデータを保護することへの期待を定義し、契約上の合意を確立しました。コンソーシアムの例には、業界中心の共有コミュニティ（金融、政府、研究、教育など）またはクロス業界の共有コミュニティ（たとえば、共有グループを形成する地元の近接界の組織）が含まれます。
4. PeerToPeer. Incident information that should have no restrictions between two peers but may require further evaluation before continuance beyond that point with the agreed-upon use and abuse guidelines. PeerToPeer communications may involve any two individuals or entities that decide to share information directly with each other.
4. ピアツーピア。2人のピア間で制限を持たないが、合意された使用と乱用ガイドラインでその点を超えて継続する前にさらに評価が必要になる場合があるインシデント情報。Peertopeer Communicationsには、情報を直接共有することを決定する2人の個人またはエンティティが含まれる場合があります。
5. BetweenConsortiums. Incident information that should have no restrictions between consortiums that have established agreed-upon use and abuse guidelines. BetweenConsortiums is used when two consortiums (as defined in IntraConsortium above) share data. The types of data that can be shared BetweenConsortiums should be identified in their agreements and contracts along with expectations on how that data should be handled and protected.
5. betweenconsortiums。合意された使用と乱用ガイドラインを確立したコンソーシアムの間に制限を持たないべきインシデント情報。BetWeenconsortiumは、2つのコンソーシアム（上記の内部で定義されている）がデータを共有する場合に使用されます。共有できるデータの種類は、そのデータの処理方法と保護方法に関する期待とともに、契約と契約で特定される必要があります。
6. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
6. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
TrafficType
交換します
One or many. REQUIRED. The values for the attribute "type" are meant to assist in determining if a trace is appropriate for the SP receiving the request to continue the trace. Multiple values may be selected for this element; however, where possible, it should be restricted to one value that most accurately describes the traffic type.
1つまたは多く。必要。属性「タイプ」の値は、トレースがトレースを継続するリクエストを受信するのに適しているかどうかを判断するのを支援することを目的としています。この要素に対して複数の値を選択できます。ただし、可能であれば、トラフィックタイプを最も正確に説明する1つの値に制限する必要があります。
type
タイプ
One or many. REQUIRED. ENUM. The attribute type is used to identify the type of information included in the RID message or the type of incident.
1つまたは多く。必要。列挙。属性タイプは、RIDメッセージまたはインシデントのタイプに含まれる情報のタイプを識別するために使用されます。
1. Attack. This option SHOULD only be selected if the traffic is related to an information security incident or attack. The type of attack MUST also be listed in more detail in the IODEF Method and Impact classes for further clarification to assist in determining if the trace can be continued ([RFC5070], Sections 3.9 and 3.10.1).
1. 攻撃。このオプションは、トラフィックが情報セキュリティインシデントまたは攻撃に関連している場合にのみ選択する必要があります。また、攻撃のタイプは、IODEFメソッドとインパクトクラスにさらに詳細にリストされ、さらに説明して、トレースを継続できるかどうかを判断するのに役立つ必要があります（[RFC5070]、セクション3.9および3.10.1）。
2. Network. This option MUST only be selected when the trace is related to network traffic or routing issues.
2. 通信網。このオプションは、トレースがネットワークトラフィックまたはルーティングの問題に関連している場合にのみ選択する必要があります。
3. Content. This category MUST be used only in the case in which the request is related to the content and regional restrictions on accessing that type of content exist. This is not malicious traffic but may be used for determining what sources or destinations accessed certain materials available on the Internet, including, but not limited to, news, technology, or inappropriate content.
3. コンテンツ。このカテゴリは、リクエストがコンテンツとそのタイプのコンテンツへのアクセスに関する地域の制限に関連している場合にのみ使用する必要があります。これは悪意のあるトラフィックではありませんが、ニュース、テクノロジー、または不適切なコンテンツを含むがこれらに限定されない、インターネット上で利用可能な特定の資料にアクセスしたソースまたは目的地を決定するために使用される場合があります。
4. DataWithHandlingRequirements. This option is used when data shared may have additional restrictions for handling, protection, and processing based on the type of data and where it resides. Regulatory or legal restrictions may be imposed on specific types of data that could vary based on the location, region or nation, of the data or where it originated. The IODEF document, as well as any extensions, included with the RID message should indicate the specific restrictions to be considered. The use of this enumeration flag is not legally binding.
4. datawithhandlingrequirements。このオプションは、データの種類とそれが存在する場所に基づいて、共有されたデータが処理、保護、処理のための追加の制限がある場合に使用されます。規制または法的制限は、場所、地域、または国家、データの発生源に基づいて異なる可能性のある特定の種類のデータに課される場合があります。IODEFドキュメントと、RIDメッセージに含まれる拡張機能は、考慮すべき特定の制限を示す必要があります。この列挙フラグの使用は、法的に拘束力がありません。
5. AudienceRestriction. This option is used to indicate that the message contains data that should be viewed by a restricted audience. This setting should not be used for normal incidents or reporting as it could slow response times. The content may be a business-relevant notification or request. This option MAY be used by a business partner to report or request assistance if an incident has affected a supply chain. This option may also be used if the content is relevant to regulatory obligations, legal (eDiscovery), or other use cases that require management attention.
5. オーディエンシェンスストリック。このオプションは、メッセージに制限された視聴者が表示する必要があるデータが含まれていることを示すために使用されます。この設定は、応答時間が遅くなる可能性があるため、通常のインシデントやレポートに使用しないでください。コンテンツは、ビジネス関連の通知またはリクエストである場合があります。このオプションは、事業パートナーがサプライチェーンに影響を与えた場合に支援を報告または要求するために使用できます。このオプションは、コンテンツが規制義務、法的（ediscovery）、または管理の注意を必要とするその他のユースケースに関連する場合にも使用できます。
6. Other. If this option is selected, a description of the traffic type MUST be provided so that policy decisions can be made to continue or stop the investigation. The information should be provided in the IODEF message in the Expectation class or in the History class using a HistoryItem log. This may also be used for incident types other than information-security-related incidents.
6. 他の。このオプションが選択されている場合、調査を続行または停止するためにポリシー決定を行うことができるように、トラフィックタイプの説明を提供する必要があります。情報は、HistoryItemログを使用して、期待クラスのIODEFメッセージまたは履歴クラスで提供する必要があります。これは、情報セキュリティ関連のインシデント以外のインシデントタイプにも使用できます。
7. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
7. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
ReportSchema
Reportschema
Zero or One. The ReportSchema class is used by the message types that require the full IODEF schema to be included in the RID envelope. Alternate schemas may be included if approved by the Designated Reviewer and registered by IANA for use with RID.
ゼロまたは1。Reportschemaクラスは、完全なIODEFスキーマをRIDエンベロープに含める必要があるメッセージタイプによって使用されます。指定されたレビュー担当者によって承認され、IANAによって登録された場合、RIDとの使用のために登録された場合、代替スキーマが含まれる場合があります。
The RIDPolicy class has five attributes:
Ridpolicyクラスには5つの属性があります。
restriction
制限
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示します。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
MsgType
msgtype
One. REQUIRED. ENUM. The type of RID message sent. The five types of messages are described in Section 4.2 and can be noted as one of the six selections below, where a Request is set to either 'InvestigationRequest' or 'TraceRequest'.
1。必要。列挙。送信されたRIDメッセージのタイプ。5種類のメッセージはセクション4.2で説明されており、以下の6つの選択のいずれかとして記録できます。この場合、リクエストは「調査のリクエスト」または「TraceRequest」のいずれかに設定されています。
1. TraceRequest. This Request message may be used to initiate a TraceRequest or to continue a TraceRequest to an upstream network closer to the source address of the origin of the security incident.
1. TraceRequest。この要求メッセージは、TracereQuestを開始するか、セキュリティインシデントの起源のソースアドレスに近いアップストリームネットワークへのTraceRequestを継続するために使用できます。
2. Acknowledgement. This message is sent to the initiating RID system from each of the upstream RID systems to provide information on the request status in the current network.
2. 了承。このメッセージは、現在のネットワークの要求ステータスに関する情報を提供するために、各上流のRIDシステムから各RIDシステムに送信されます。
3. Result. This message indicates that the source of the attack was located, and the message is sent to the initiating RID system through the RID systems in the path of the trace.
3. 結果。このメッセージは、攻撃のソースが配置されており、メッセージがトレースのパスでRIDシステムを介して開始システムに送信されたことを示しています。
4. InvestigationRequest. This Request message type is used when the source of the traffic is believed to be valid. The purpose of the InvestigationRequest is to leverage the existing peer or consortium relationships in order to notify the SP closest to the source of the valid traffic that some event occurred, which may be a security-related incident.
4. 調査のリケスト。この要求メッセージタイプは、トラフィックのソースが有効であると考えられている場合に使用されます。調査の目的は、一部のイベントが発生した有効なトラフィックのソースに最も近いSPに通知するために、既存のピアまたはコンソーシアムの関係を活用することです。これは、セキュリティ関連のインシデントである可能性があります。
5. Report. This message is used to report a security incident for which no action is requested in the IODEF Expectation class. This may be used for the purpose of correlating attack information by CSIRTs, gathering statistics and trending information, etc.
5. 報告。このメッセージは、IODEF期待クラスでアクションが要求されないセキュリティインシデントを報告するために使用されます。これは、CSIRTによって攻撃情報を相関させ、統計を収集し、情報を流行させる目的で使用できます。
6. Query. This message is used to request information from a trusted RID system about an incident or incident type.
6. クエリ。このメッセージは、インシデントタイプまたはインシデントタイプに関する信頼できるRIDシステムから情報を要求するために使用されます。
Additionally, there is an extension attribute to add new enumerated values:
さらに、新しい列挙値を追加するための拡張属性があります。
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
MsgDestination
msgdestination
One. REQUIRED. ENUM. The destination required at this level may either be the RID messaging system intended to receive the request, or, in the case of a Request with MsgType set to 'InvestigationRequest', the source of the incident. In the case of an InvestigationRequest, the RID system that can help stop or mitigate the traffic may not be known, and the message may have to traverse RID messaging systems by following the routing path to the RID system closest to the source of the attack traffic. The Node element lists either the RID system or the IP address of the source, and the meaning of the value in the Node element is determined by the MsgDestination element.
1。必要。列挙。このレベルで必要な宛先は、リクエストを受信することを目的としたRIDメッセージングシステム、またはMSGTypeが「調査リケスト」に設定されたリクエストの場合、インシデントのソースです。調査の要因の場合、トラフィックの停止または軽減に役立つRIDシステムはわからない可能性があり、攻撃トラフィックのソースに最も近いRIDシステムへのルーティングパスに従ってRIDメッセージングシステムを通過する必要がある場合があります。。ノード要素は、ソースのRIDシステムまたはIPアドレスのいずれかをリストし、ノード要素の値の意味はMSGDestination要素によって決定されます。
1. RIDSystem. The IP address of the next upstream system accepting RID communications is REQUIRED and is listed in the Node element of the RIDPolicy class. If NodeName element of the Node class is used, it contains a DNS domain name. The originating RID system is required to check that this domain name resolves to the IP address to which the RID message is sent. This check may be performed in advance of sending the message and the result saved for future use with additional RID messages.
1. リッジシステム。RID通信を受け入れる次のアップストリームシステムのIPアドレスが必要であり、Ridpolicyクラスのノード要素にリストされています。ノードクラスのnodename要素が使用される場合、DNSドメイン名が含まれています。発信元のRIDシステムは、このドメイン名がRIDメッセージが送信されるIPアドレスに解決することを確認するために必要です。このチェックは、メッセージを送信する前に実行される場合があり、結果は追加のRIDメッセージで将来の使用のために保存されます。
2. SourceOfIncident. The Address element of the Node element contains the IP address of the incident source, and the NodeName element of the Node class is not used. The IP address is REQUIRED when this option is selected. The IP address is used to determine the path of systems accepting RID communications that will be used to find the closest RID system to the source of an attack in which the IP address used by the source is believed to be valid and a Request message with MsgDestination set to 'InvestigationRequest' is used. This is not to be confused with the IncidentSource class, as the defined value here is from an initial Request ('InvestigationRequest' or 'TraceRequest'), not the source used in a Result message.
2. IncidentのSource。ノード要素のアドレス要素には、インシデントソースのIPアドレスが含まれており、ノードクラスのnodename要素は使用されません。このオプションが選択されている場合、IPアドレスが必要です。IPアドレスは、ソースで使用されるIPアドレスが有効であると考えられている攻撃のソースに最も近いRIDシステムを見つけるために使用されるRID通信を受け入れるシステムのパスを決定するために使用され、MSGDestinationによる要求メッセージが「Request」に設定されています。これは、Incidentsourceクラスと混同しないでください。ここでの定義された値は、結果メッセージで使用されるソースではなく、初期リクエスト（「調査リケスト」または「Tracerequest」）からのものであるためです。
3. ext-value. An escape value used to extend this attribute. All extensions shall specify the contents and meaning of the Node element of RIDPolicy. See IODEF [RFC5070], Section 5.1, on extensibility. If the NodeName element of the Node class is used by an extension, NodeName may contain an Internationalized Domain Name (IDN); see Section 11 for applicable requirements. All extensions SHOULD use an IP address in the Address element of the Node class as the primary means of Node identification.
3. ext-value。この属性を拡張するために使用されるエスケープ値。すべての拡張機能は、Ridpolicyのノード要素の内容と意味を指定するものとします。拡張性については、IODEF [RFC5070]、セクション5.1を参照してください。ノードクラスのnodename要素が拡張機能によって使用される場合、nodenameには国際化ドメイン名（IDN）が含まれる場合があります。該当する要件については、セクション11を参照してください。すべての拡張機能は、ノード識別の主要な手段として、ノードクラスのアドレス要素のIPアドレスを使用する必要があります。
MsgType-ext
msgtype-ext
OPTIONAL. STRING. A means by which to extend the MsgType attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。MSGType属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
MsgDestination-ext
msgdestination-ext
OPTIONAL. STRING. A means by which to extend the MsgDestination attribute. See IODEF [RFC5070], Section 5.1
オプション。ストリング。msgdestination属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください
The ReportSchema class is an aggregate class in the RIDPolicy class. The IODEF schema is the approved schema for inclusion in RID messages via the ReportSchema class.
Reportschemaクラスは、Ridpolicyクラスの集計クラスです。IODEFスキーマは、Reportschemaクラスを介してメッセージをRIDに含めるための承認されたスキーマです。
+-------------------------+
| ReportSchema |
+-------------------------+
| |
| ENUM Version |
| STRING ext-Version |<>---{1}-------[ XMLDocument ]
| ENUM XMLSchemaID |
| STRING ext-XMLSchemaID |<>---{0..1}----[ URL ]
| |
| |<>---{0..*}----[ Signature ]
| |
+-------------------------+
Figure 5: The ReportSchema Class
図5：Reportschemaクラス
The elements that constitute the ReportSchema class are as follows:
Reportschemaクラスを構成する要素は次のとおりです。
XMLDocument
xmldocument
One. The XMLDocument is a complete XML document defined by the iodef:ExtensionType class. This class follows the guidelines in [RFC5070], Section 5, where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document.
1。XMLDocumentは、IODEF：ExtensionTypeクラスで定義された完全なXMLドキュメントです。このクラスは、[RFC5070]のセクション5のガイドラインに従います。ここでは、データ型は「XML」に設定され、意味は「XML」に設定されてXMLドキュメントを含めます。
URL
URL
Zero or One. URL. A reference to the XML schema of the XML document included. The URL data type is defined in [RFC5070], Section 2.15, as "xs:anyURI" in the schema. The schemaLocation for IODEF is already included in the RID schema, so this is not necessary to include a URL for IODEF documents. The list of registered schemas for inclusion will be maintained by IANA.
ゼロまたは1。URL。XMLドキュメントのXMLスキーマへの参照が含まれています。URLデータ型は、スキーマの「XS：Anyuri」として[RFC5070]、セクション2.15で定義されています。IODEFの回路図はすでにRIDスキーマに含まれているため、IODEFドキュメントのURLを含めるためにこれは必要ありません。インクルージョンのための登録スキーマのリストは、IANAによって維持されます。
Signature
サイン
Zero to many. The Signature uses the iodef:ExtensionType class to enable this element to contain a detached or enveloped signature. This class follows the guidelines in [RFC5070] Section 5 where the data type is set to 'xml' and meaning is set to 'xml' to include an XML document. This element is used to encapsulate the detached signature based on the iodef: RecordItem class within the IODEF document to verify the originator of the message or to include the enveloped signature. If other schemas are used instead of IODEF, they MUST provide guidance on what class to use if a detached signature is provided for this purpose.
多くのゼロ。署名は、IODEF：ExtensionTypeクラスを使用して、この要素が分離または包み込まれた署名を含めることを可能にします。このクラスは、[RFC5070]セクション5のガイドラインに従います。ここでは、データ型が「XML」に設定され、意味は「XML」に設定されてXMLドキュメントを含めます。この要素は、IODEF：IODEFドキュメント内のIODEF：RecordITemクラスに基づいて分離された署名をカプセル化するために使用され、メッセージのオリジネーターを検証するか、包み込まれた署名を含めます。IODEFの代わりに他のスキーマが使用されている場合、この目的のために分離された署名が提供されている場合、使用するクラスに関するガイダンスを提供する必要があります。
The ReportSchema class has four attributes:
Reportschemaクラスには4つの属性があります。
Version
バージョン
OPTIONAL. One. The Version attribute is the version number of the specified XML schema. That schema must be an approved version of IODEF or a schema registered with IANA for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.
オプション。1。バージョン属性は、指定されたXMLスキーマのバージョン番号です。そのスキーマは、IODEFの承認版またはIANAに登録されたスキーマでなければなりません。IODEF以外のスキーマを管理するためのIANAレジストリは、セクション12で指定されています。
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
ext-Version
ext-version
OPTIONAL. One. The ext-Version attribute is the version number of the included XML schema. This attribute is used if a schema other than IODEF or an IANA-registered schema that has been added to the enumerated list for Version is included.
オプション。1。ext-version属性は、含まれるXMLスキーマのバージョン番号です。この属性は、バージョンの列挙リストに追加されたIODEFまたはIANA登録スキーマ以外のスキーマが含まれている場合に使用されます。
XMLSchemaID
xmlschemaid
OPTIONAL. One. The XMLSchemaID attribute is the identifier, the defined namespace [XMLNames], of the XML schema of the XML document included. The XMLSchemaID and Version specify the format of the XMLDocument element. The only permitted values, include the namespace for IODEF [RFC5070], "urn:ietf:params:xml:ns:iodef-1.0", any future IETF-approved versions of IODEF, and any namespace included in the IANA-managed list of registered schemas for use with RID. The IANA registry for managing schemas other than IODEF is specified in Section 12.
オプション。1。XMLSchemaid属性は、XMLドキュメントのXMLスキーマの識別子、定義された名前空間[XMLNames]です。xmlschemaidとバージョンは、xmldocument要素の形式を指定します。許可された唯一の値には、IODEF [RFC5070]の名前空間、「urn：ietf：params：xml：ns：iodef-1.0」、IETFが承認したバージョンのIODEF、およびIANA管理リストのIANA管理リストに含まれる任意の名前スペースが含まれます。RIDで使用する登録スキーマ。IODEF以外のスキーマを管理するためのIANAレジストリは、セクション12で指定されています。
ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
ext-XMLSchemaID
ext-xmlschemaid
OPTIONAL. One. The ext-XMLSchemaID attribute is the identifier (defined namespace) of the XML schema of the XML document included. The ext-XMLSchemaID and ext-Version specify the format of the XMLDocument element and are used if the included schema is not IODEF version 1.0 or an IANA-registered schema that has been added to the enumerated list for XMLSchemaID.
オプション。1。ext-xmlschemaid属性は、XMLドキュメントのXMLスキーマの識別子（定義された名前空間）です。ext-xmlschemaidとext-versionは、xmldocument要素の形式を指定し、xmlschemaidの列挙リストに追加されたIODEFバージョン1.0またはIANA登録スキーマではない場合に使用されます。
The RequestStatus class is an aggregate class in the RID class.
RequestStatusクラスは、RIDクラスの集計クラスです。
+--------------------------------+
| RequestStatus |
+--------------------------------+
| |
| ENUM restriction |
| ENUM AuthorizationStatus |
| ENUM Justification |
| STRING ext-AuthorizationStatus |
| STRING ext-Justification |
| |
+--------------------------------+
Figure 6: The RequestStatus Class
図6：RequestStatusクラス
The RequestStatus class has five attributes:
RequestStatusクラスには5つの属性があります。
restriction
制限
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere. This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示します。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
AuthorizationStatus
AuthorizationStatus
One. REQUIRED. ENUM. The listed values are used to provide a response to the requesting CSIRT of the status of a Request, Report, or Query.
1。必要。列挙。リストされた値は、リクエスト、レポート、またはクエリのステータスの要求CSIRTへの応答を提供するために使用されます。
1. Approved. The trace was approved and will begin in the current SP.
1. 承認済み。トレースは承認され、現在のspから始まります。
2. Denied. The trace was denied in the current SP. The next closest SP can use this message to filter traffic from the upstream SP using the example packet to help mitigate the effects of the attack as close to the source as possible. The Acknowledgement message must be passed back to the originator and a Result message must be used from the closest SP to the source in order to indicate actions taken in the IODEF History class.
2. 拒否された。トレースは現在のspで拒否されました。次に近いSPは、このメッセージを使用して、サンプルパケットを使用して上流のSPからトラフィックをフィルタリングして、攻撃の効果を可能な限りソースに近づけるのを緩和することができます。確認メッセージはオリジネーターに渡す必要があり、IODEF Historyクラスで実行されたアクションを示すために、結果メッセージをソースに最も近いSPから使用する必要があります。
3. Pending. Awaiting approval; a timeout period has been reached, which resulted in this Pending status and Acknowledgement message being generated.
3. 保留中。承認待ち;タイムアウト期間に達したため、この保留中のステータスと承認メッセージが生成されました。
4. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
4. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
Justification
正当化
OPTIONAL. ENUM. Provides a reason for a Denied or Pending message.
オプション。列挙。拒否または保留中のメッセージの理由を提供します。
1. SystemResource. A resource issue exists on the systems that would be involved in the request.
1. SystemResource。リクエストに関与するシステムには、リソースの問題が存在します。
2. Authentication. The enveloped digital signature [RFC3275] failed to validate.
2. 認証。包絡されたデジタル署名[RFC3275]は検証に失敗しました。
3. AuthenticationOrigin. The detached digital signature for the original requestor on the RecordItem entry failed to validate.
3. Authenticationorigin。RecordItemエントリの元のRequestorのデタッチされたデジタル署名は、検証に失敗しました。
4. Encryption. The recipient was unable to decrypt the request, report, or query.
4. 暗号化。受信者は、リクエスト、レポート、またはクエリを復号化することができませんでした。
5. UnrecognizedFormat. The format of the provided document was unrecognized.
5. 認識されていないフォーム。提供されたドキュメントの形式は認識されていませんでした。
6. CannotProcess. The document could not be processed. Reasons may include legal or policy decisions. Resolution may require communication outside of this protocol to resolve legal or policy issues. No further messages SHOULD be sent until resolved.
6. 処理できません。ドキュメントを処理できませんでした。理由には、法的または政策決定が含まれる場合があります。解決は、法的または政策の問題を解決するために、このプロトコル以外のコミュニケーションを必要とする場合があります。解決するまで、それ以上のメッセージを送信する必要はありません。
7. Other. There were other reasons this request could not be processed.
7. 他の。この要求を処理できない他の理由がありました。
8. ext-value. An escape value used to extend this attribute. See IODEF [RFC5070], Section 5.1.
8. ext-value。この属性を拡張するために使用されるエスケープ値。IODEF [RFC5070]、セクション5.1を参照してください。
AuthorizationStatus-ext
AuthorizationStatus-Ext
OPTIONAL. STRING. A means by which to extend the AuthorizationStatus attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。AuthorizationStatus属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
Justification-ext
正当化 - 伸び
OPTIONAL. STRING. A means by which to extend the Justification attribute. See IODEF [RFC5070], Section 5.1.
オプション。ストリング。正当化属性を拡張する手段。IODEF [RFC5070]、セクション5.1を参照してください。
The IncidentSource class is an aggregate class in the RID class.
Incidentsourceクラスは、RIDクラスの集計クラスです。
+-------------------+
| IncidentSource |
+-------------------+
| |
| ENUM restriction |
| |<>-------------[ SourceFound ]
| |
| |<>---{0..*}----[ Node ]
| |
+-------------------+
Figure 7: The IncidentSource Class
図7：Incidentsourceクラス
The elements that constitute the IncidentSource class follow:
インシデントソースクラスを構成する要素は次のとおりです。
SourceFound
ソースファウンド
One. BOOLEAN. The Source class indicates if a source was identified. If the source was identified, it is listed in the Node element of this class.
1。ブール。ソースクラスは、ソースが識別されたかどうかを示します。ソースが識別された場合、このクラスのノード要素にリストされます。
True. Source of incident was identified.
真実。インシデントの原因が特定されました。
False. Source of incident was not identified.
間違い。インシデントの原因は特定されていません。
Node
ノード
Zero or many. The Node class is used to identify a system identified as part of an incident. If this element is used, the Address element of the Node element MUST contain the IP address of the system. If the NodeName element of the Node class is used, it contains a DNS domain name that has been checked to ensure that it resolved to that IP address when the check was performed. See Section 11 of this document for internationalization considerations for NodeName. The base definition of this class from the IODEF ([RFC5070], Section 3.16) can be expanded to include other identifiers.
ゼロまたは多く。ノードクラスは、インシデントの一部として識別されたシステムを識別するために使用されます。この要素を使用する場合、ノード要素のアドレス要素にシステムのIPアドレスを含める必要があります。ノードクラスのnodename要素が使用されている場合、チェックされた場合にチェックされたDNSドメイン名が含まれています。Nodenameの国際化に関する考慮事項については、このドキュメントのセクション11を参照してください。IODEF（[RFC5070]、セクション3.16）のこのクラスの基本定義は、他の識別子を含めるように拡張できます。
The IncidentSource class has one attribute:
IncidentSourceクラスには1つの属性があります。
restriction
制限
OPTIONAL. ENUM. This attribute indicates the disclosure guidelines to which the sender expects the recipient to adhere.This guideline provides no real security since it is the choice of the recipient of the document to honor it. This attribute follows the same guidelines as "restriction" used in IODEF.
オプション。列挙。この属性は、送信者が受信者が付着することを期待する開示ガイドラインを示しています。このガイドラインは、ドキュメントの受信者の選択であるため、実際のセキュリティを提供しません。この属性は、IODEFで使用される「制限」と同じガイドラインに従います。
The RID schema declares a namespace of "urn:ietf:params:xml:ns:iodef-rid-2.0" and registers it per [RFC3688]. Each IODEF-RID document MUST use the "iodef-rid-2.0" namespace in the top-level element RID-Document. It can be referenced as follows:
RIDスキーマは、「urn：ietf：params：xml：ns：iodef-rid-2.0」の名前空間を宣言し、[rfc3688]に従って登録します。各IODEF-RIDドキュメントは、トップレベルの要素RIDドキュメントの「IODEF-RID-2.0」名前空間を使用する必要があります。次のように参照できます。
<RID-Document version="2.0" lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:xsi="http://www.w3c.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0.xsd">
RID documents MUST begin with an XML declaration and MUST specify the XML version used; also, the use of UTF-8 encoding is REQUIRED ([RFC3470], Section 4.4). RID conforms to all XML data encoding conventions and constraints.
RIDドキュメントは、XML宣言から開始する必要があり、使用されるXMLバージョンを指定する必要があります。また、UTF-8エンコードの使用が必要です（[RFC3470]、セクション4.4）。RIDは、規則と制約をエンコードするすべてのXMLデータに準拠しています。
The XML declaration with no character encoding will read as follows:
文字エンコードなしのXML宣言は、次のように読み取られます。
<?xml version="1.0" encoding="UTF-8"?>
The following characters have special meaning in XML and MUST be escaped with their entity reference equivalent: "&", "<", ">", "\"" (double quotation mark), and "'" (apostrophe). These entity references are "&", "<", ">", """, and "'", respectively.
次の文字はXMLで特別な意味を持ち、エンティティリファレンスに相当するもので逃げる必要があります： "＆"、 "<"、 ">"、 "\" "（二重引用符）、および「 '"（アポストロフィ）。これらのエンティティ参照は、それぞれ「＆amp;」、 "＆lt;"、 "＆gt;"、 "＆quot;"、および「＆apos;」です。
In order to support the changing activity of CSIRTS, the RID schema can include an IODEF or other data model. The IODEF is also extensible, enabling the schemas to evolve along with the needs of CSIRTs. This section discusses how to include the IODEF XML document or other XML documents to leverage the security and trust
CSIRTの変化するアクティビティをサポートするために、RIDスキーマにはIODEFまたはその他のデータモデルを含めることができます。IODEFも拡張可能であり、CSIRTのニーズとともにスキーマが進化できるようにします。このセクションでは、IODEF XMLドキュメントまたはその他のXMLドキュメントを含める方法について説明します。
relationships established through the use of RID. These techniques are designed so that adding new data will not require a change to the RID schema. This approach also supports the exchange of private XML documents relevant only to a closed consortium. XML documents can be included through the ReportSchema class in the RIDPolicy class. The XMLDocument attribute is set to 'xml' to allow for the inclusion of full IODEF or other XML documents. The following guidelines MUST be followed:
RIDの使用によって確立された関係。これらの手法は、新しいデータを追加してもRIDスキーマの変更を必要としないように設計されています。このアプローチは、閉じたコンソーシアムにのみ関連するプライベートXMLドキュメントの交換もサポートしています。XMLドキュメントは、RidpolicyクラスのReportschemaクラスを通じて含めることができます。XMLDocument属性は「XML」に設定されており、完全なIODEFまたは他のXMLドキュメントを含めることができます。次のガイドラインに従う必要があります。
1. The included schema MUST define a separate namespace, such as the declared namespace for IODEF of "urn:ietf:params:xml:ns:iodef-1.0".
1. 含まれるスキーマは、「urn：ietf：params：xml：ns：iodef-1.0」のiodefの宣言された名前空間など、個別の名前空間を定義する必要があります。
2. When a parser encounters an included XML document it does not understand, the included document MUST be ignored (and not processed), but the remainder of the document MUST be processed. Parsers will be able to identify the XML documents for which they have no processing logic through the namespace declaration. Parsers that encounter an unrecognized element in a namespace that they do support SHOULD reject the document as a syntax error.
2. パーサーが含まれていないXMLドキュメントに遭遇する場合、含まれているドキュメントは無視する必要があります（処理されません）が、ドキュメントの残りを処理する必要があります。パーサーは、名前空間宣言を介して処理ロジックがないXMLドキュメントを識別できます。サポートする名前空間で認識されていない要素に遭遇したパーサーは、構文エラーとしてドキュメントを拒否する必要があります。
3. Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema.
3. セキュリティへの影響により、実行時にスキーマをダウンロードしないでください。また、スキーマの解決可能な場所を提供するためにドキュメントを含めては不要にしてはなりません。
The examples included in Section 7 demonstrate how an IODEF document is included. The included schema of IODEF is represented in ReportSchema as follows:
セクション7に含まれる例は、IODEFドキュメントがどのように含まれているかを示しています。IODEFの含まれるスキーマは、次のようにReportschemaに表されます。
Version: "1.0"
バージョン：「1.0」
XMLSchemaID: "urn:ietf:params:xml:ns:iodef-1.0"
URL: "http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"
The URL is optionally included for IODEF since it is already in the RID schema, and the schemaLocation is defined.
URLは既にRIDスキーマにあるため、IODEFにはオプションで含まれており、回路図は定義されています。
XML schemas may be registered for inclusion in a RID message. This may include schemas other than IODEF or updated versions of IODEF. The registered IANA information for additional schemas MUST include the specification name, version, specification Uniform Resource Identifier (URI), and namespace. The following provides an example of the necessary information for additional schemas beyond IODEF.
XMLスキーマは、RIDメッセージに含めるために登録される場合があります。これには、IODEF以外のスキーマまたはIODEFの更新バージョンが含まれる場合があります。追加のスキーマに関する登録されたIANA情報には、仕様名、バージョン、仕様の均一なリソース識別子（URI）、および名前空間が含まれている必要があります。以下は、IODEFを超えた追加のスキーマに必要な情報の例を示しています。
Example Name (XXXX)
例名（xxxx）
Schema Name: XXXX_1.1
Version: 1.1
Namespace: <registered namespace>
Specification URI: http://www.example.com/XXXX
The version attribute of the ReportSchema class is populated with the approved versions of IODEF or any additional schemas registered by IANA; see Section 12.
Reportschemaクラスのバージョン属性には、承認されたバージョンのIODEFまたはIANAが登録した追加のスキーマが埋め込まれています。セクション12を参照してください。
The XMLSchemaID of the ReportSchema class is populated with the namespace of the included schema. The attribute enumeration values include the namespace for IODEF and any schema registered by IANA; see Section 12.
ReportschemaクラスのXMLSchemaidには、含まれているスキーマの名前空間が入力されています。属性の列挙値には、IODEFの名前空間とIANAが登録したスキーマが含まれます。セクション12を参照してください。
The URL element of the ReportSchema class is populated with the Specification URI value of the included schema.
ReportschemaクラスのURL要素には、含まれているスキーマの仕様URI値が入力されています。
The IODEF model is followed as specified in [RFC5070] for each of the RID message types. The RID schema is used in combination with IODEF documents to facilitate RID communications. Each message type varies slightly in format and purpose; hence, the requirements vary and are specified for each. All classes, elements, attributes, etc., that are defined in the IODEF-Document are valid in the context of a RID message; however, some listed as optional in IODEF are mandatory for RID as listed for each message type. The IODEF model MUST be fully implemented for RID messages that include IODEF payloads to ensure proper parsing of those messages.
IODEFモデルは、RIDメッセージタイプのそれぞれについて[RFC5070]で指定されているように追跡されます。RIDスキーマは、IODEFドキュメントと組み合わせて使用され、RID通信を促進します。各メッセージタイプの形式と目的はわずかに異なります。したがって、要件は異なり、それぞれに対して指定されます。IODEF-Documentで定義されているすべてのクラス、要素、属性などは、RIDメッセージのコンテキストで有効です。ただし、IODEFでオプションとしてリストされているものは、各メッセージタイプにリストされているRIDに必須です。IODEFモデルは、IODEFペイロードを含むRIDメッセージに対して完全に実装する必要があります。
Note: The implementation of RID may automate the ability to fill in the content required for each message type from packet input, incident data, situational awareness information, or default values such as those used in the EventData class.
注：RIDの実装は、パケット入力、インシデントデータ、状況認識情報、またはEventDataクラスで使用されているものなどのデフォルト値から各メッセージタイプに必要なコンテンツを入力する機能を自動化する場合があります。
Description: This message type is used to request assistance in a computer security investigation. The investigation request may be directed to another party that can assist with forensics and continue the investigation (the incident may have originated on the SP network to which the Request was sent), or it may be directed to an SP to trace the traffic from an unknown source. The Request message with MsgType set to 'InvestigationRequest' may leverage the existing bilateral peer relationships in order to notify the SP closest to the source of the valid traffic that some event occurred, which may be a
説明：このメッセージタイプは、コンピューターセキュリティ調査で支援を要求するために使用されます。調査要求は、法医学を支援し、調査を継続できる別の当事者に向けられる場合があります（リクエストが送信されたSPネットワークでインシデントが発生した可能性があります）、またはSPに向けてトラフィックを追跡するために指示される場合があります。不明なソース。「調査リケスト」に設定されたMSGTypeを使用した要求メッセージは、いくつかのイベントが発生した有効なトラフィックのソースに最も近いSPに通知するために、既存の二国間ピア関係を活用する場合があります。
security-related incident. A Request message with the MsgType set to 'TraceRequest' may be sent to an upstream peer to trace back through the network to locate the source of malicious traffic. The following information is REQUIRED for Request messages and is provided through the following data structures:
セキュリティ関連のインシデント。「Tracerequest」に設定されたMSGTypeを使用したリクエストメッセージを上流のピアに送信して、ネットワークをトレースして悪意のあるトラフィックのソースを見つけることができます。リクエストメッセージには次の情報が必要であり、次のデータ構造を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy
リドポリック
RID message type, IncidentID, and destination policy information
メッセージタイプ、IncisidID、および宛先ポリシー情報をRID
IODEF Information:
IODEF情報：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID).
インシデント識別子（インシデントクラス、IncisisID）。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination.
システムクラスは、ソースと宛先の両方をリストするために使用されます。
Expectation class should be used to request any specific actions to be taken close to the source.
期待クラスは、ソースの近くで取得する特定のアクションを要求するために使用する必要があります。
Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to 'infrastructure'.
ネストされたRIDシステムのパス情報。IODEFEventDataを使用してTRACEで使用されているリクエストオリジネーターから始まり、カテゴリを「インフラストラクチャ」に設定します。
Event, Record, and RecordItem classes to include example packets and other information related to the incident. Note: Event information included here requires a second instance of EventData in addition to that used to convey SP path contact information.
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットやその他の情報を含めるためのクラス。注：ここに含まれるイベント情報には、SPパスの連絡先情報を伝えるために使用されるものに加えて、EventDataの2番目のインスタンスが必要です。
Standards for encryption and digital signatures [RFC3275] [XMLsig] [XMLencrypt]:
暗号化およびデジタル署名の標準[RFC3275] [XMLSIG] [XMLENCRYPT]：
Digital signature from initiating CSIRT or provider system sending the RID message, passed to all systems receiving the Request using a detached XML digital signature on a RecordItem entry, placed in an instance of the Signature element.
csirtまたはプロバイダーシステムの開始からのデジタル署名RIDメッセージを送信し、署名要素の例に配置された録音エントリでデタッチされたXMLデジタル署名を使用してリクエストを受信するすべてのシステムに渡されました。
Digital signature of sending CSIRT or SP for authenticity of the RID message, from the CSIRT or provider creating this message using an enveloped XML digital signature on the IODEF document, placed in an instance of the Signature element.
CSIRTまたはSPを送信するデジタルシグネチャーRIDメッセージの信頼性、CSIRTまたはプロバイダーから、署名要素のインスタンスに配置されたIODEFドキュメントに包まれたXMLデジタル署名を使用して、このメッセージを作成します。
XML encryption as required by policy, agreements, and data markers.
XML暗号化は、ポリシー、契約、およびデータマーカーで要求されます。
Security requirements include the ability to encrypt [XMLencrypt] the contents of the Request message using the public key of the destination RID system. The incident number increases whether the Request message has the MsgDestination set to 'InvestigationRequest' or 'TraceRequest' in order to ensure uniqueness within the system. The relaying peers also append their Autonomous System (AS) or RID system information using the path information as the Request message was relayed through SPs. This enables the response (Result message) to utilize the same path and trust relationships for the return message, indicating any actions taken. The request is recorded in the state tables of both the initiating and destination SP RID systems. The destination SP is responsible for any actions taken as a result of the request in adherence to any service level agreements or policies. The SP MUST confirm that the traffic actually originated from the suspected system before taking any action and confirm the reason for the request. The request may be sent directly to a known RID system or routed by the source address of the attack using the MsgDestination of RIDPolicy set to 'SourceOfIncident'. Note: Any intermediate parties in a TraceRequest MUST be able to view RIDPolicy information of responding message types in order to properly direct RID messages.
セキュリティ要件には、宛先RIDシステムの公開キーを使用して、[XMLENCRYPT]のコンテンツを要求メッセージの内容を暗号化する機能が含まれます。インシデント番号は、リクエストメッセージにMSGDestinationが「調査のリケスト」または「Tracerequest」に設定されているかどうかにかかわらず、システム内の一意性を確保するために増加します。リレーンピアは、リクエストメッセージがSPSを介して中継されたため、パス情報を使用して自律システム（AS）またはRIDシステム情報を追加します。これにより、応答（結果メッセージ）が同じパスを利用し、リターンメッセージに信頼関係を利用し、実行されたアクションを示します。リクエストは、開始および宛先SP RIDシステムの両方の状態表に記録されます。宛先SPは、サービスレベルの契約またはポリシーを順守する要求の結果として取られたアクションについて責任を負います。 SPは、行動を起こす前にトラフィックが実際に疑わしいシステムから発生したことを確認し、要求の理由を確認する必要があります。リクエストは、既知のRIDシステムに直接送信されるか、攻撃のソースアドレスによってルーティングされる場合があります。注：TraceRequestの中間関係者は、RIDメッセージを適切に指示するために、応答するメッセージタイプのRidpolicy情報を表示できる必要があります。
A DDoS attack can have many sources, resulting in multiple traces to locate the sources of the attack. It may be valid to continue multiple traces for a single attack. The path information enables the administrators to determine if the exact trace already passed through a single network. The Incident Identifier must also be used to identify multiple Requests from a single incident. If a single Request results in divergent paths of Requests, a separate instance number MUST be used under the same IncidentID. The IncidentID instance number of IODEF can be used to correlate related incident data that is part of a larger incident.
DDOS攻撃には多くのソースがある可能性があり、その結果、攻撃のソースを見つけるための複数の痕跡が発生する可能性があります。単一の攻撃に対して複数のトレースを継続することは有効です。パス情報により、管理者は、正確なトレースがすでに単一のネットワークを通過しているかどうかを判断できます。インシデント識別子は、単一のインシデントからの複数の要求を識別するためにも使用する必要があります。単一のリクエストがリクエストの発散パスをもたらす場合、同じIncisidの下で個別のインスタンス番号を使用する必要があります。IDESISIDインスタンスのIODEFの数を使用して、より大きなインシデントの一部である関連するインシデントデータを相関させることができます。
Description: The Acknowledgement is also used to provide a status to any message type and to provide a Justification if the message could not be processed for any reason. This message is sent to the initiating RID system from the next upstream provider's application or system designated for accepting RID communications to provide information on the request status in the current SP.
説明：謝辞は、メッセージタイプにステータスを提供し、何らかの理由でメッセージを処理できなかった場合に正当化を提供するためにも使用されます。このメッセージは、現在のSPのリクエストステータスに関する情報を提供するためにRID通信を受け入れるために指定された次のアップストリームプロバイダーのアプリケーションまたはシステムから開始RIDシステムに送信されます。
The following information is REQUIRED for Acknowledgement messages and is provided through the following data structures:
確認メッセージには次の情報が必要であり、次のデータ構造を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy
リドポリック
RID message type, IncidentID, and destination policy information
メッセージタイプ、IncisidID、および宛先ポリシー情報をRID
RequestStatus class:
RequestStatusクラス：
Status of Request
リクエストのステータス
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]、[XMLENCRYPT]：
Digital signature of responding CSIRT or provider for authenticity of Trace Status Message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
封筒またはプロバイダーから、トレースステータスメッセージの信頼性を得るための応答CSIRTまたはプロバイダーのデジタル署名。封筒のXMLデジタル署名を使用してこのメッセージを作成します。
XML encryption as required by policy, agreements, and data markers.
XML暗号化は、ポリシー、契約、およびデータマーカーで要求されます。
A message is sent back to the initiating CSIRT or provider's system; it accepts RID communications of the trace as status notification. This message verifies that the next RID system in the path has received the message from the previous system in the path. This message also verifies that the trace is now continuing, has stopped, or is pending in the next upstream CSIRT or provider's RID system. The Pending status is automatically generated after a 2-minute timeout without system-predefined or administrator action to approve or disapprove the trace continuance. If a Request is denied, the originator and sending peer (if they are not the same) MUST both receive the message. This provides the sending peer with the option to take action to stop or mitigate the traffic as close to the source as possible.
メッセージが開始CSIRTまたはプロバイダーのシステムに送信されます。ステータス通知としてTRACEのRID通信を受け入れます。このメッセージは、パス内の次のRIDシステムがパスの以前のシステムからメッセージを受信したことを確認します。また、このメッセージは、トレースが継続している、停止している、または次の上流のCSIRTまたはプロバイダーのRIDシステムで保留中であることを確認します。保留中のステータスは、トレースの継続を承認または不承認にするために、システム予測または管理者アクションなしで2分間のタイムアウトの後に自動的に生成されます。リクエストが拒否された場合、オリジネーターとピアの送信（それらが同じではない場合）は両方ともメッセージを受信する必要があります。これにより、送信ピアに、可能な限りソースに近いトラフィックを停止または軽減するためのアクションを実行するオプションを提供します。
Description: This message indicates that the trace or investigation has been completed and provides the result. The Result message includes information on whether or not a source was found, and the source information is provided through the IncidentSource class. The Result information MUST go back to the originating RID system that began the investigation or trace. A provider may use any number of incident-handling data sources to ascertain the true source of an attack. All of the possible information sources may or may not be readily tied into the RID communications system.
説明：このメッセージは、トレースまたは調査が完了したことを示し、結果を提供します。結果メッセージには、ソースが見つかったかどうかに関する情報が含まれており、ソース情報はIncidentsourceクラスを通じて提供されます。結果情報は、調査またはトレースを開始した発信元のRIDシステムに戻る必要があります。プロバイダーは、攻撃の真のソースを確認するために、任意の数のインシデント処理データソースを使用できます。考えられる情報源はすべて、RID通信システムに容易に結び付けられる場合とそうでない場合があります。
The following information is REQUIRED for Result messages and will be provided through the following data structures:
結果メッセージには次の情報が必要であり、次のデータ構造を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy
リドポリック
RID message type, IncidentID, and destination policy information
メッセージタイプ、IncisidID、および宛先ポリシー情報をRID
Incident Source
インシデントソース
The IncidentSource class of the RID schema is used to note if a source was identified and provide the source address(es) or other Node information.
RIDスキーマのIncidentSourceクラスは、ソースが識別されたかどうかに注意し、ソースアドレスまたはその他のノード情報を提供するために使用されます。
IODEF Information:
IODEF情報：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID).
インシデント識別子（インシデントクラス、IncisisID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the response is specific to an instance of an incident.
トレース番号は、単一のインシデントの複数のトレースに使用されます。応答がインシデントのインスタンスに固有の場合は、含める必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack and must note if the traffic is spoofed, thus requiring in RID an upstream Request set to 'TraceRequest'.
システムクラスは、攻撃で使用されるソース情報と宛先情報の両方をリストするために使用され、トラフィックがスプーフィングされているかどうかを記録する必要があるため、「TraceRequest」に設定された上流のリクエストを取り除く必要があります。
History class "atype" attribute is used to note any actions taken.
履歴クラス「ATYPE」属性は、実行されたアクションに注意して使用されます。
History class also notes any other background information including notes about the Confidence level or rating of the result information.
履歴クラスはまた、結果情報の信頼レベルや評価に関するメモを含む他の背景情報にも注目しています。
Path information of nested RID systems, beginning with the request originator used in the trace using IODEF EventData with category set to 'infrastructure'. The last SP listed is the SP that located the source of the traffic (the provider sending the Result message).
ネストされたRIDシステムのパス情報。IODEFEventDataを使用してTRACEで使用されているリクエストオリジネーターから始まり、カテゴリを「インフラストラクチャ」に設定します。リストされている最後のSPは、トラフィックのソースを見つけたSPです（プロバイダーが結果メッセージを送信）。
Event, Record, and RecordItem classes to include example packets and other information related to the incident (optional). Note: Event information included here requires a second instance of EventData in addition to that used to convey SP path contact information.
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットとその他の情報を含める（オプション）。注：ここに含まれるイベント情報には、SPパスの連絡先情報を伝えるために使用されるものに加えて、EventDataの2番目のインスタンスが必要です。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]、[XMLENCRYPT]：
Digital signature of source CSIRT or provider for authenticity of Result message, from the CSIRT or provider creating this message using an enveloped XML digital signature.
封入されたXMLデジタル署名を使用してこのメッセージを作成するCSIRTまたはプロバイダーから、結果メッセージの信頼性のためのソースCSIRTまたはプロバイダーのデジタル署名。
XML encryption as required by policy, agreements, and data markers.
XML暗号化は、ポリシー、契約、およびデータマーカーで要求されます。
A message is sent back to the initiating CSIRT or provider's RID system to notify the CSIRT that the source has been located. The actual source information may or may not be included, depending on the policy of the network in which the client or host is attached. Any action taken by the SP to act upon the discovery of the source of a trace should be included. The SP may be able to automate the adjustment of filters at their border router to block outbound access for the machine(s) discovered as a part of the attack. The filters may be comprehensive and block all Internet access until the host has taken the appropriate action to resolve any security issues. The SP may be limited in their options for filtering due to agreements or other restrictions resulting in less comprehensive filters, such as rate-limiting the ingress traffic as close to the source as possible.
メッセージが開始CSIRTまたはプロバイダーのRIDシステムに送信され、ソースが配置されていることをCSIRTに通知します。クライアントまたはホストが添付されているネットワークのポリシーに応じて、実際のソース情報は含まれている場合と含まれない場合があります。痕跡の原因の発見に基づいて行動するためにSPが取ったアクションを含める必要があります。SPは、ボーダールーターでのフィルターの調整を自動化して、攻撃の一部として発見されたマシンのアウトバウンドアクセスをブロックできる場合があります。フィルターは包括的であり、ホストがセキュリティの問題を解決するための適切なアクションを実行するまで、すべてのインターネットアクセスをブロックする場合があります。SPは、契約またはその他の制限により、包括的なフィルターを可能な限りソースに近づけるように包括的なフィルターを獲得するため、フィルタリングのオプションが制限される場合があります。
Security and privacy requirements discussed in Section 9 MUST be taken into account.
セクション9で説明するセキュリティとプライバシーの要件を考慮する必要があります。
Note: The History class has been expanded in IODEF to accommodate all of the possible actions taken as a result of a RID Request using the "iodef:atype", or action type, attribute. The History class should be used to note all actions taken close to the source of a trace or incident using the most appropriate option for the type of action along with a description. The "atype" attribute in the Expectation class can also be used to request an appropriate action when a Request is made.
Description: This message or document is sent to a RID system to provide a report of a security incident. This message does not require any actions to be taken, except to file the report on the receiving RID system or associated database.
説明：このメッセージまたはドキュメントは、セキュリティインシデントのレポートを提供するためにRIDシステムに送信されます。このメッセージは、受信RIDシステムまたは関連データベースに関するレポートを提出することを除き、アクションを実行する必要はありません。
The following information is REQUIRED for Report messages and will be provided through the following data structures:
レポートメッセージには次の情報が必要であり、次のデータ構造を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy RID message type, IncidentID, and destination policy information
Ridpolicy RIDメッセージタイプ、IncisidID、および宛先ポリシー情報
The following data is RECOMMENDED if available and can be provided through the following data structures:
利用可能な場合は、次のデータが推奨され、次のデータ構造を通じて提供できます。
IODEF Information:
IODEF情報：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID).
インシデント識別子（インシデントクラス、IncisisID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the Report is specific to an instance of an incident.
トレース番号は、単一のインシデントの複数のトレースに使用されます。レポートがインシデントのインスタンスに固有の場合は、含める必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack.
システムクラスは、攻撃で使用されるソース情報と宛先情報の両方をリストするために使用されます。
Event, Record, and RecordItem classes are used to include example packets and other information related to the incident (optional).
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットやその他の情報を含めるために使用されます（オプション）。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]、[XMLENCRYPT]：
Digital signature from initiating RID system, passed to all systems receiving the report using an enveloped XML digital signature, placed in an instance of the Signature element.
RIDシステムの開始からのデジタル署名は、署名要素のインスタンスに配置された包括的なXMLデジタル署名を使用して、レポートを受信するすべてのシステムに渡されました。
XML encryption as required by policy, agreements, and data markers.
XML暗号化は、ポリシー、契約、およびデータマーカーで要求されます。
Security requirements include the ability to encrypt [XMLencrypt] the contents of the Report message using the public key of the destination RID system. Senders of a Report message should note that the information may be used to correlate security incident information for the purpose of trending, pattern detection, etc., and may be shared with other parties unless otherwise agreed upon with the receiving RID system. Therefore, sending parties of a Report
セキュリティ要件には、宛先RIDシステムの公開キーを使用して、レポートメッセージの内容を暗号化する機能が含まれます。レポートメッセージの送信者は、情報がトレンド、パターン検出などを目的としてセキュリティインシデント情報を相関させるために使用される可能性があることに注意する必要があり、受信RIDシステムと特に合意されていない限り、他の関係者と共有される場合があります。したがって、報告書のパーティーを送信します
message may obfuscate or remove destination addresses or other sensitive information before sending a Report message. A Report message may be sent either to file an incident report or to respond to a Query, and data sensitivity must be considered in both cases. The SP path information is not necessary for this message, as it will be communicated directly between two trusted RID systems.
メッセージは、レポートメッセージを送信する前に、宛先アドレスまたはその他の機密情報を難読化または削除する場合があります。レポートメッセージは、インシデントレポートを提出するか、クエリに応答するために送信される場合があり、両方の場合にデータの感度を考慮する必要があります。SPパス情報は、このメッセージには2つの信頼できるRIDシステム間で直接伝達されるため、必要ありません。
Description: The Query message is used to request incident information from a trusted RID system. The request can include the incident number, if known, or detailed information about the incident. If the incident number is known, the Report message containing the incident information can easily be returned to the trusted requestor using automated methods. If an example packet or other unique information is included in the Query, the return report may be automated; otherwise, analyst intervention may be required.
説明：クエリメッセージは、信頼できるRIDシステムからインシデント情報を要求するために使用されます。リクエストには、既知の場合、インシデント番号、またはインシデントに関する詳細情報を含めることができます。インシデント番号がわかっている場合、インシデント情報を含むレポートメッセージは、自動化された方法を使用して信頼できる要求者に簡単に返すことができます。例のパケットまたはその他の一意の情報がクエリに含まれている場合、返品レポートを自動化することができます。それ以外の場合、アナリストの介入が必要になる場合があります。
The following information is REQUIRED for a Query message and is provided through the following data structures:
クエリメッセージには次の情報が必要であり、次のデータ構造を通じて提供されます。
RID Information:
情報を削除：
RIDPolicy
リドポリック
RID message type, IncidentID, and destination policy information
メッセージタイプ、IncisidID、および宛先ポリシー情報をRID
IODEF Information (optional):
IODEF情報（オプション）：
Timestamps (DetectTime, StartTime, EndTime, ReportTime).
タイムスタンプ（検出時間、開始時、終了時、レポートタイム）。
Incident Identifier (Incident class, IncidentID).
インシデント識別子（インシデントクラス、IncisisID）。
Trace number is used for multiple traces of a single incident; it MUST be included if the Query is an instance of an incident.
トレース番号は、単一のインシデントの複数のトレースに使用されます。クエリがインシデントのインスタンスである場合は、含める必要があります。
Confidence rating of security incident (Impact and Confidence class).
セキュリティインシデントの信頼評価（インパクトと信頼クラス）。
System class is used to list both the Source and Destination Information used in the attack.
システムクラスは、攻撃で使用されるソース情報と宛先情報の両方をリストするために使用されます。
Event, Record, and RecordItem classes are used to include example packets and other information related to the incident (optional).
イベント、レコード、および記録クラスは、インシデントに関連するサンプルパケットやその他の情報を含めるために使用されます（オプション）。
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:
暗号化およびデジタル署名の標準[RFC3275]、[XMLSIG]、[XMLENCRYPT]：
Digital signature from the CSIRT or SP initiating the RID message, passed to all systems receiving the Query using an enveloped XML digital signature, placed in an instance of the Signature element.
CSIRTまたはSPからのデジタル署名は、RIDメッセージを開始し、署名要素のインスタンスに配置された包括的なXMLデジタル署名を使用してクエリを受信するすべてのシステムに渡されました。
XML encryption as required by policy, agreements, and data markers.
XML暗号化は、ポリシー、契約、およびデータマーカーで要求されます。
The proper response to the Query message is a Report message. Multiple incidents may be returned for a single query if an incident type is requested. In this case, the receiving system sends an IODEF document containing multiple incidents or all instances of an incident. The system sending the reply may preset a limit to the number of documents returned in one report. The recommended limit is 5, to prevent the documents from becoming too large. Other transfer methods may be better suited than RID for large transfers of data. The Confidence rating may be used in the Query message to select only incidents with an equal or higher Confidence rating than what is specified. This may be used for cases when information is gathered on a type of incident but not on specifics about a single incident. Source and Destination Information may not be needed if the Query is intended to gather data about a specific type of incident.
クエリメッセージに対する適切な応答は、レポートメッセージです。インシデントタイプが要求されている場合、単一のクエリに対して複数のインシデントが返される場合があります。この場合、受信システムは、複数のインシデントまたはインシデントのすべてのインスタンスを含むIODEFドキュメントを送信します。返信を送信するシステムは、1つのレポートで返されるドキュメントの数に制限を事前に設定する場合があります。推奨される制限は5です。ドキュメントが大きくなりすぎないようにします。他の転送方法は、大量のデータをRIDよりも適している場合があります。信頼評価は、クエリメッセージで使用されて、指定されているものよりも等しいまたはそれ以上の信頼評価を持つインシデントのみを選択できます。これは、インシデントの種類で情報が収集されたが、単一のインシデントに関する詳細ではない場合に使用できます。クエリが特定のタイプのインシデントに関するデータを収集することを意図している場合、ソースおよび宛先情報は必要ない場合があります。
The following section outlines the communication flows for RID and also provides examples of messages.
次のセクションでは、RIDの通信フローの概要を説明し、メッセージの例も提供します。
The possible set of message exchanges include:
メッセージ交換の可能なセットには次のものがあります。
o Request: Asynchronous Request for assistance and/or action to be taken, MAY involve multiple systems and iterative Requests
o リクエスト：行われる支援および/または行動の非同期リクエストには、複数のシステムと反復リクエストが含まれる場合があります
MsgType set to 'InvestigationRequest' or 'TraceRequest'
msgtype 'resectrequest'または 'tracerequest'に設定されています
Possible responses:
可能な応答：
+ Acknowledgement (OPTIONAL for InvestigationRequest)
+ 謝辞（調査リクエストのためのオプション）
+ Result (REQUIRED unless Acknowledgement was set to 'no')
+ 結果（承認が「いいえ」に設定されていない限り必要です）
+ Report (OPTIONAL; zero or more; Report can be sent unsolicited)
+ レポート（オプション;ゼロ以上;レポートは未承諾で送信できます）
o Query: Synchronous request for information
o クエリ：情報の同期リクエスト
MsgType set to 'Query'
msgtype「query」に設定されています
Possible responses:
可能な応答：
+ Acknowledgement (OPTIONAL if yes; REQUIRED if no Report will be sent)
+ 謝辞（オプションはYESの場合;レポートが送信されない場合は必須）
+ Report (REQUIRED unless Acknowledgement was set to 'no')
+ レポート（承認が「いいえ」に設定されていない限り必要）
o Report: Asynchronous information report; may be pushed to systems or may be a response to a Query
o レポート：非同期情報レポート。システムにプッシュされる可能性があるか、クエリへの応答である場合があります
MsgType set to 'Report'
「レポート」に設定されているmsgtype
Possible responses:
可能な応答：
+ Acknowledgement (OPTIONAL)
+ 謝辞（オプション）
Processing considerations for the IODEF document and any IODEF included elements or attributes MUST follow the guidelines specified in [RFC5070], Section 4. [RFC3023] and [RFC3470] specify requirements and best practices for the use of XML in IETF application protocols. RID and IODEF documents MUST be well-formed (see [RFC3470], Section 4.1) and MUST be validated against the appropriate schema. Internal or external DTD subsets are prohibited in RID; see [RFC3023], Section 3.
IODEFドキュメントおよびIODEFに含まれる要素または属性の考慮事項の処理は、[RFC5070]、セクション4、[RFC3023]および[RFC3470]で指定されたガイドラインに従う必要があります。RIDおよびIODEFドキュメントは、適切に形成されている必要があり（[RFC3470]、セクション4.1を参照）、適切なスキーマに対して検証する必要があります。内部または外部のDTDサブセットは、RIDで禁止されています。[RFC3023]、セクション3を参照してください。
Comments can be ignored by conform ant processors for RID or IODEF documents (see [RFC3470], Section 4.6) and are included below for informational purposes only. The first example demonstrates the use of a detached digital signature. Subsequent examples do not include the detached signature required for some message types. The signature is applied after the message is created as demonstrated in the first example.
コメントは、RIDまたはIODEFドキュメント（[RFC3470]を参照、セクション4.6を参照）のANTプロセッサでは無視でき、情報目的のみを以下に含めます。最初の例は、分離したデジタル署名の使用を示しています。その後の例には、一部のメッセージタイプに必要な分離署名が含まれていません。最初の例で示されているように、メッセージが作成された後に署名が適用されます。
Note: For each example listed below, [RFC5735] addresses were used. Assume that each IP address listed is actually a separate network range held by different SPs. Addresses were used from /27 network ranges.
注：以下にリストする各例で、[RFC5735]アドレスが使用されました。リストされている各IPアドレスは、実際には異なるSPSが保持している個別のネットワーク範囲であると仮定します。アドレスは /27ネットワーク範囲から使用されました。
The diagram below outlines the RID Request communication flow for a TraceRequest between RID systems on different networks tracing an attack. The Request message with MsgDestination set to
以下の図は、攻撃をトレースするさまざまなネットワーク上のRIDシステム間のトレイセレックのためのRID要求通信フローの概要を示しています。msgdestinationを使用したリクエストメッセージ
'TraceRequest' is represented in the diagram by "TraceRequest". SP-1, SP-2, and SP-3 represent service providers that are involved in the example trace communication flow.
「Tracerequest」は、「TracereQuest」によって図に表されています。SP-1、SP-2、およびSP-3は、トレース通信フローの例に関与するサービスプロバイダーを表します。
Attack Dest SP-1 SP-2 SP-3 Attack Src
攻撃DEST SP-1 SP-2 SP-3攻撃SRC
1. Attack | Attack reported | detected
1. 攻撃|攻撃が報告されました|検出されました
2. Initiate trace
2. トレースを開始します
3. Locate origin through upstream SP
3. 上流のspを介して原点を見つけます
4. o---TraceRequest----->
4. o --- tracerequest ----->
5. Trace Initiated
5. トレースが開始されました
6. <---Acknowledgement--o
6. <---承認 - o
7. Locate origin through upstream SP
7. 上流のspを介して原点を見つけます
8. o---TraceRequest--->
8. o --- tracerequest --->
9. Trace Initiated
9. トレースが開始されました
10. <----------Acknowledgement----o
<-Acknowledgement-o
11. Locate attack source on network X
11. ネットワークxの攻撃ソースを見つけます
12. <------------Result----------------o
13. o- - - - -Acknowledgement- - - - - >
13. o----- cooknowledgement---->
Figure 8: TraceRequest Communication Flow
図8：TraceRequest通信フロー
Before a trace is initiated, the RID system should verify that an instance of the trace or a similar request is not active. The traces may be resource intensive; therefore, providers need to be able to detect potential abuse of the system or unintentional resource
トレースを開始する前に、RIDシステムは、トレースまたは同様のリクエストのインスタンスがアクティブでないことを確認する必要があります。トレースはリソース集中的なものである可能性があります。したがって、プロバイダーは、システムの潜在的な乱用または意図しないリソースを検出できる必要があります
drains. Information such as the Source and Destination Information, associated packets, and the incident may be desirable to maintain for a period of time determined by administrators.
The communication flow demonstrates that an Acknowledgement message is sent to both the downstream peer and the original requestor. If a Request in a traceback is denied, the downstream peer has the option to take an action and respond with a Result message. The originator of the request may follow up with the downstream peer of the SP involved using a Request with the MsgType set to 'InvestigationRequest' to ensure that an action is taken if no response is received. Nothing precludes the originator of the request from initiating a new Request with the MsgType set to 'TraceRequest' thereby bypassing the SP that denied the request, if a trace is needed beyond that point. Another option may be for the initiator to send an 'InvestigationRequest' to an SP upstream of the SP that denied the request. This action assumes enough information was gathered to discern the true source of the attack traffic from the incident-handling information.
通信フローは、謝辞メッセージが下流のピアと元の要求者の両方に送信されることを示しています。トレースバックのリクエストが拒否された場合、下流のピアにはアクションを実行し、結果メッセージで応答するオプションがあります。リクエストのオリジネーターは、SPの下流のピアでフォローアップすることができます。これには、MSGTypeセットが「調査」に設定されたリクエストを使用して、応答がない場合にアクションが実行されるようにすることができます。そのポイントを超えてトレースが必要な場合、MSGTypeが「TraceRequest」に設定されたMSGTypeセットで新しいリクエストを開始することを妨げるものはありません。別のオプションは、イニシエーターがリクエストを拒否したSPの上流のSPに「調査リケスト」を送信することです。このアクションは、インシデント処理情報からの攻撃トラフィックの真のソースを識別するのに十分な情報が収集されたと仮定しています。
The proper response to a TraceRequest is an Acknowledgement message. The Acknowledgement message lets the requestor know if the trace will continue through the next upstream network. If there is a problem with the request, such as a failure to validate the digital signature or decrypt the request, an Acknowledgement message MUST be sent to the requestor and the downstream peer (if they are not one and the same) providing the reason why the message could not be processed. Assuming that the trace continued, additional TraceRequests with the response of an Acknowledgement message would occur, thereby passing the request upstream in the path to the source of the traffic related to the incident. Once a source is found, a Result message is sent to the originator of the trace, as determined by the SP path information provided through the document instance of EventData, where contact is set to 'infrastructure'. The SP path information is also used when sending the Acknowledgement messages to the first entry (the trace originator) and the last nested entry (the downstream peer). The Result message is encrypted [XMLencrypt] for the originator providing information about the incident source and any actions taken. If the originator fails to decrypt or authenticate the Result message, an Acknowledgement message is sent in response; otherwise, no return message is sent. The final Acknowledgement to the Result message is depicted as optional in the diagram above. If an Acknowledgement message is sent with the RequestStatus set to Denied, a downstream peer receiving this message may choose to take action to stop or mitigate the traffic at that point in the network, as close to the source as possible. If the downstream peer chooses this option, it would send a Result message to the trace originator.
TraceRequestへの適切な応答は、謝辞メッセージです。謝辞メッセージにより、リクエスターは、次のアップストリームネットワークを介してトレースが続くかどうかを知ることができます。デジタル署名の検証やリクエストの復号化など、リクエストに問題がある場合は、依頼者と下流のピアに確認メッセージを送信する必要があります（それらが1つでない場合）。メッセージを処理できませんでした。トレースが続くと仮定すると、確認メッセージの応答を伴う追加のトレイセレックが発生し、それにより、インシデントに関連するトラフィックのソースへのパスで上流のリクエストを渡します。ソースが見つかったら、結果メッセージがトレースの発信元に送信されます。これは、連絡先が「インフラストラクチャ」に設定されているEventDataのドキュメントインスタンスを介して提供されるSPパス情報によって決定されます。 SPパス情報は、最初のエントリ（トレースオリジネーター）と最後のネストされたエントリ（下流のピア）に確認メッセージを送信するときにも使用されます。結果メッセージは、インシデントソースと取得したアクションに関する情報を提供するオリジネーターに対して暗号化された[xmlencrypt]です。オリジネーターが結果メッセージの復号化または認証に失敗した場合、それに応じて確認メッセージが送信されます。それ以外の場合、返品メッセージは送信されません。結果メッセージに対する最終的な承認は、上記の図にオプションとして描かれています。 requestStatusが拒否されるように設定された承認メッセージが送信された場合、このメッセージを受け取る下流のピアは、可能な限りソースに近いネットワークのその時点でトラフィックを停止または軽減するためのアクションを実行することを選択できます。ダウンストリームピアがこのオプションを選択した場合、結果メッセージがTrace Originatorに送信されます。
The example listed is of a Request message with MsgDestination set to 'TraceRequest' based on the incident report example from the IODEF document. The RID classes were included as appropriate for a Request message of this type using the RIDPolicy class. The example given is that of a CSIRT reporting a DoS attack in progress to the upstream SP. The request asks the next SP to continue the trace and have the traffic mitigated closer to the source of the traffic. The example Request message is the first step of a TraceRequest as depicted in the previous diagram, where 'Attack Dest' is represented by 192.0.2.67 (and SP-1). The 'Attack Src' is later identified in the Result message example as 192.0.2.37 and initially as tracing closer to 192.0.2.35. SP-1 is identified in the Request as CSIRT-FOR-OUR-DOMAIN, and SP-2 is identified in the RID document for the Request as the 'RIDSystem' in 'MsgDestination' as 192.0.2.3 using the Node class. SP-3 is later used in the Result message and the administrator is identified as 'Admin-contact@10.1.1.2' as they searched for 192.0.2.35; the administrator may be different than the constituency contact (an additional Request with MsgDestination set to 'TraceRequest' occurred between SP-2 to SP-3 that is not included). SP-3 is the service provider for 192.0.2.32/27 and was able to take the action to rate-limit their traffic. The SP-1, SP-2, and SP-3 information would be replaced with the appropriate (and valid) email and other contact information in real usages. The Node class enables multiple methods to identify a system, such as a fully qualified domain name or the IP address to be provided for the SP. Any mapping of existing relationships from the SP Node information to the name, contact, digital signature verification information and other identifying or trust information is provided at the application layer to support end users of the incident management system. A packet is provided in this example to enable any traces to be performed by SP-2 and SP-3 to perform traces to the attack source before taking the requested action to 'rate-limit' the traffic. The subnet of 192.0.2.0 uses a 27-bit mask in the examples below.
リストされている例は、IODEFドキュメントのインシデントレポートの例に基づいて「tracerequest」に設定されたmsgdestinationを使用した要求メッセージのものです。 RIDPolicyクラスを使用して、このタイプのリクエストメッセージに適切なRIDクラスが含まれていました。与えられた例は、上流spに進行中のDOS攻撃を報告するCSIRTの例です。リクエストは、次のSPにトレースを継続し、トラフィックをトラフィックのソースに近づけるように要求します。例の要求メッセージは、前の図に描かれているTraceRequestの最初のステップであり、「攻撃運命」は192.0.2.67（およびSP-1）で表されます。 「攻撃SRC」は、結果メッセージの例で192.0.2.37として後で識別され、最初は192.0.2.35に近いトレースとして識別されます。 SP-1はリクエストでdomain-for-domainとして識別され、SP-2は、ノードクラスを使用して192.0.2.3として「msgdestination」の「Msgdestination」の「Ridguretystem」としてリクエストのRIDドキュメントで識別されます。 SP-3は結果メッセージで使用され、管理者は192.0.2.35を検索したときに「admin-contact@10.1.1.1.2」として識別されます。管理者は、選挙区の連絡先とは異なる場合があります（SP-2からSP-3の間に「TraceRequest」に設定されたMSGDestinationを含む追加のリクエストは含まれていません）。 SP-3は192.0.2.32/27のサービスプロバイダーであり、トラフィックを評価するためにアクションを実行することができました。 SP-1、SP-2、およびSP-3の情報は、実際の使用法で適切な（および有効な）電子メールおよびその他の連絡先情報に置き換えられます。ノードクラスでは、複数のメソッドがSPのために提供される完全に適格なドメイン名やIPアドレスなどのシステムを識別することができます。 SPノード情報から名前、連絡先、デジタル署名検証情報、およびその他の識別または信頼情報への既存の関係のマッピングは、インシデント管理システムのエンドユーザーをサポートするためにアプリケーションレイヤーに提供されます。この例では、要求されたアクションをトラフィックに「rate-limit」に実行する前に、攻撃ソースにトレースを実行できるようにトレースを実行できるように、この例にパケットが提供されています。 192.0.2.0のサブネットは、以下の例で27ビットマスクを使用しています。
In the following example, use of [XMLsig] to generate digital signatures follows the guidance of [XMLsig] 1.0. Version 1.1 of [XMLsig] supports additional digest algorithms. Reference [RFC4051] for URIs intended for use with XML digital signatures, encryption, and canonicalization. SHA-1 SHOULD NOT be used; see [RFC6194] for further details.
次の例では、[XMLSIG]を使用してデジタル署名を生成すると、[XMLSIG] 1.0のガイダンスに従います。[XMLSIG]のバージョン1.1は、追加のダイジェストアルゴリズムをサポートしています。XMLデジタル署名、暗号化、および標準化で使用することを目的としたURIの参照[RFC4051]。SHA-1を使用しないでください。詳細については、[RFC6194]を参照してください。
Note: Due to the limit of 72 characters per line, some line breaks were added in the examples and schemas in this document.
注：1行あたり72文字の制限により、このドキュメントの例とスキーマにいくつかのラインブレークが追加されました。
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<iodef-rid:RID lang="en-US"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:iodef-rid-2.0">
<iodef-rid:RIDPolicy MsgDestination="RIDSystem" MsgType="TraceRequest">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<IODEF-Document lang="en">
<iodef:Incident purpose="traceback" restriction="need-to-know">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>
Host involved in DoS attack
</iodef:Description>
<iodef:Assessment>
<iodef:Impact completion="failed" severity="low"
type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>38765</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation action="rate-limit-host" severity="high">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>
2001-09-14T08:19:01+00:00
</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
<!-- Start of detached XML signature included in RID -->
<iodef-rid:Signature dtype="xml" meaning="xml">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
Id="dsig-123456">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
<XPath xmlns="http://www.w3.org/2002/06/xmldsig-filter2"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dsig-trans="http://www.w3.org/2002/06/xmldsig-filter2"
Filter="intersect">
//dsig:Signature[@Id = 'dsig-123456']/
ancestor::iodef-rid:ReportSchema/
iodef-rid:XMLDocument/IODEF-Document[1]/iodef:Incident[1]/
iodef:EventData[1]/iodef:Record[1]/iodef:RecordData[1]/
iodef:RecordItem[1]</XPath></Transform></Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>
NQuIhPjdZuZJnPi/hW62dwJT1dR+vqcZV8mpemCVN5g=
</DigestValue>
</Reference></SignedInfo>
<SignatureValue>
lnq/ePQ4AVpxCR0ifCp9sMsW0r/AdT3C2GR/zaN1V+hZ/NApOygUjMzTCQnx+RvGPNkO/RVq
BEIDgZQUEnQZn/uSbmr0tQ6xpBfaxF1DCosLgiZy+2jFzpXrwoN/jHNgtxR/9QLW9mZ+I7V6
LEEJ73Kut+d0naTGHlyi64ab2PqsVuRXQ4pXUKbhMkhzeTIqvFLK93KGfsIMd6Cb+n2u/ABy
Lkc+gflJYUWVP4DxkQ4cyex6hM6RYTRUSr7jVD9K4d8KFP2g85i69YLtSu01W1Np0afpJ4a9
MK0E7ISMNRmC8wIklCAsSXiBRqyaEwaSy/clybI0vCTPqGOYh3/SZg==
</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue>
<Modulus>
z8adrX9m0S8OxIxN+fui33wiz4ZYgb4xPbR9MS5pOp1A8kVpH5Ew3N6O3/dMs2a4diIxyGLV
h0r86QXWH/W6T2IC2ny+hi+jWRwXrvgTY3ZAFgePvz2OdRhVN/cUbOto4Pa4I2mVZWW+/Q0F
n7YpqPBDDxlGq/xyFPuYq/4y7Y+Ah+vHO2ZSaiQjbj8F38XrGhwlcbFVyK8AmxK3z0zWwX86
uMEqVCjW6s6j2KAWdbAjEpgZHlJY87i/DqnFgxfmdg3oru+YeiEPVRY8hyQpYbtgryveZOHT
gnCHmS/53U9jSS0cyb/ADuj1upfyNoOiMMgQr7Olhc5pTvuWAl4Fnw==</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
</iodef-rid:Signature>
<!-- End of detached XML signature included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The example Acknowledgement message is in response to the Request message listed above. The SP that received the request is responding to approve the trace continuance in their network.
例の確認メッセージは、上記のリクエストメッセージに応じています。リクエストを受け取ったSPは、ネットワーク内のトレースの継続を承認するために応答しています。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Approved"/>
</iodef-rid:RID>
The example Result message is in response to the Request listed above. This message type only comes after an Acknowledgement within the Request flow of messages where a TraceRequest is in progress. It may be a direct response to a Request with the MsgType set to 'InvestigationRequest'. This message provides information about the source of the attack and the actions taken to mitigate the traffic. The Result message is typically the last message in a Request flow; however, an Acknowledgement MAY follow if there are any issues receiving or processing the Result.
結果メッセージの例は、上記のリクエストに応じています。このメッセージタイプは、TracereQuestが進行中のメッセージの要求フロー内での確認の後にのみ発生します。これは、MSGTypeが「調査リクエスト」に設定されたリクエストに対する直接的な応答かもしれません。このメッセージは、攻撃の原因とトラフィックを軽減するために取られたアクションに関する情報を提供します。結果メッセージは、通常、要求フロー内の最後のメッセージです。ただし、結果を受け取ったり処理したりする問題がある場合、謝辞が続く場合があります。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Result"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="traceback">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-02T22:49:24+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-02T22:19:24+00:00</iodef:StartTime>
<iodef:ReportTime>2004-02-02T23:20:24+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed"
type="dos"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@192.0.2.35</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Admin-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
<iodef:EventData>
<iodef:Contact role="admin" type="organization">
<iodef:ContactName>Admin-contact for 192.0.2.3
</iodef:ContactName>
<iodef:Email>Admin-contact@192.0.2.3</iodef:Email>
</iodef:Contact>
<iodef:Flow>
<iodef:System category="intermediate">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3
</iodef:Address>
</iodef:Node>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
</iodef:EventData>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>38765</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="rate-limit-host">
<iodef:Description>
Rate-limit traffic close to source
</iodef:Description>
</iodef:Expectation>
<iodef:Record>
<iodef:RecordData>
<iodef:Description>
The IPv4 packet included was used in the described attack
</iodef:Description>
<iodef:RecordItem dtype="ipv4-packet">450000522ad9
0000ff06c41fc0a801020a010102976d0050103e020810d9
4a1350021000ad6700005468616e6b20796f7520666f7220
6361726566756c6c792072656164696e6720746869732052
46432e0a
</iodef:RecordItem>
</iodef:RecordData>
</iodef:Record>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T22:53:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#207-1
</iodef:IncidentID>
<iodef:Description>
Notification sent to next upstream SP closer to 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-02T23:07:21+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-SP3">
CSIRT-FOR-SP3#3291-1
</iodef:IncidentID>
<iodef:Description>
Host rate-limited for 24 hours
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
<iodef-rid:IncidentSource>
<iodef-rid:SourceFound>true</iodef-rid:SourceFound>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.37</iodef:Address>
</iodef:Node>
</iodef-rid:IncidentSource>
</iodef-rid:RID>
The diagram below outlines a RID Request communication flow between RID systems on different networks for a security incident with a known source address. Therefore, MsgDestination is set to 'InvestigationRequest' for the Request message and is included in the diagram below as "Investigation". The proper response to a Request with the MsgDestination set to 'InvestigationRequest' is a Result message. If there is a problem with the Request, such as a failure to validate the digital signature or decrypt the Request, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
以下の図は、既知のソースアドレスを備えたセキュリティインシデントのために、さまざまなネットワーク上のRIDシステム間のRID要求通信フローの概要を示しています。したがって、msgdestinationはリクエストメッセージの「調査のリケスト」に設定され、以下の図に「調査」として含まれています。「調査のリケスト」に設定されたMSGDESTINATIONを使用したリクエストに対する適切な応答は、結果メッセージです。デジタル署名の検証やリクエストの復号化など、リクエストに問題がある場合は、承認メッセージがリクエスターに送信されます。確認メッセージは、メッセージを処理できない理由を提供する必要があります。
Attack Dest SP-1 SP-2 Attack Src
攻撃DEST SP-1 SP-2攻撃SRC
1. Attack | Attack reported | detected
1. 攻撃|攻撃が報告されました|検出されました
2. Determine source of security incident
2. セキュリティインシデントのソースを決定します
3. o---Investigation---->
3. o ---調査---->
4. Research incident and determine appropriate actions to take
4. 事件を調査し、適切な行動を決定する
5. <-------Result-------o
Figure 9: Investigation Request Communication Flow
図9：調査リクエスト通信フロー
The following example only includes the RID-specific details. The IODEF and security measures are similar to the TraceRequest, with the exception that the source is known, the receiving RID system is known to be close to the source, and the MsgDestination is set to 'InvestigationRequest'. The source known is indicated in the IODEF document, which allows for incident sources to be listed as spoofed, if appropriate.
次の例には、RID固有の詳細のみが含まれています。IODEFとセキュリティ対策はTraceRequestに似ていますが、ソースがわかっていることを除いて、受信RIDシステムはソースに近いことが知られており、MSGDESTINATIONは「調査の再クエスト」に設定されています。既知のソースは、IODEFドキュメントに示されています。これにより、必要に応じて、インシデントソースをスプーフィングとしてリストすることができます。
This flow does not include a Result message because the request is denied as shown in the Acknowledgement response.
このフローには、承認応答に示されているようにリクエストが拒否されるため、結果メッセージは含まれません。
SP-1 is represented by CERT-FOR-OUR-DOMAIN and 192.0.2.67. SP-2 is identified by 192,0.2.98. In this example, SP-2 is the service provider for systems on the 192.0.2.32/27 subnet. The contact for the host 192.0.2.35 is known at the start of the request as 'Constituency-contact@10.1.1.2'.
SP-1は、ドメインの証明書と192.0.2.67で表されます。SP-2は192,0.2.98までに識別されます。この例では、SP-2は192.0.2.32/27サブネットのシステムのサービスプロバイダーです。ホスト192.0.2.35の連絡先は、リクエストの開始時に「Constituency-contact@10.1.1.2」として知られています。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="InvestigationRequest"
MsgDestination="SourceOfIncident">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.98</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema Version="1.0">
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="other">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T08:13:33+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T08:13:31+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T08:13:33+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T08:13:35+00:00</iodef:ReportTime>
<iodef:Description>Host involved in DoS attack</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="low" completion="failed" type="recon"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>41421</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>80</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
<iodef:Expectation severity="high" action="investigate">
<iodef:Description>
Investigate whether source has been compromised
</iodef:Description>
</iodef:Expectation>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="block-host">
<iodef:DateTime>2004-02-05T08:19:01+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
<iodef:Description>
Investigation request sent to SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The example Acknowledgement message is in response to the Request listed above. The SP that received the request was unable to validate the digital signature used to authenticate the sending RID system.
例の確認メッセージは、上記のリクエストに応じています。リクエストを受け取ったSPは、送信RIDシステムの認証に使用されるデジタル署名を検証することができませんでした。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Acknowledgement"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="IntraConsortium"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#208-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
<iodef-rid:RequestStatus AuthorizationStatus="Denied"
Justification="Authentication"/>
</iodef-rid:RID>
The diagram below outlines the RID Report communication flow between RID systems on different SPs.
以下の図は、異なるSPSのRIDシステム間のRIDレポート通信フローの概要を示しています。
SP-1 SP-2
SP-1 SP-2
1. Generate incident information and prepare Report message
1. インシデント情報を生成し、レポートメッセージを準備します
2. o-------Report------->
2. o -------レポート------->
3. File report in database
3. データベースのファイルレポート
Figure 10: Report Communication Flow
図10：通信フローを報告します
The Report communication flow is used to provide information on incidents. Incident information may be shared between CSIRTs or other entities using this format. When a report is received, the RID system must verify that the report has not already been filed. The incident number and incident data, such as the hexadecimal packet and incident class information, can be used to compare with existing database entries. The Report message typically does not have a response. If there is a problem with the Report message, such as a failure to validate the digital signature [RFC3275] or decrypt the request, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
レポート通信フローは、インシデントに関する情報を提供するために使用されます。この形式を使用して、CSIRTまたは他のエンティティの間でインシデント情報を共有できます。レポートが受信された場合、RIDシステムは、レポートがまだ提出されていないことを確認する必要があります。16進パケットやインシデントクラス情報などのインシデント番号とインシデントデータを使用して、既存のデータベースエントリと比較できます。レポートメッセージには通常、応答がありません。レポートメッセージに問題がある場合、デジタル署名の検証[RFC3275]やリクエストを復号化するなど、承認メッセージがリクエスターに送信されます。確認メッセージは、メッセージを処理できない理由を提供する必要があります。
The following example only includes the RID-specific details. This report is an unsolicited Report message that includes an IPv4 packet. The IODEF document and digital signature is similar to the Request example with MsgDestination set to 'TraceRequest'.
次の例には、RID固有の詳細のみが含まれています。このレポートは、IPv4パケットを含む未承諾レポートメッセージです。IODEFドキュメントとデジタル署名は、MSGDestinationが「TraceRequest」に設定された要求例に似ています。
This example is a message sent from SP-1, CERT-FOR-OUR-DOMAIN at 192.0.2.67, to SP-2 at 192.0.2.130 for informational purposes on an attack that took place.
この例は、SP-1、192.0.2.67のドメインの証明書、192.0.2.130のSP-2に送信されたメッセージです。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Report" MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.130</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<!-- IODEF-Document included in RID -->
<iodef-rid:ReportSchema>
<iodef-rid:XMLDocument dtype="xml" meaning="xml">
<iodef:IODEF-Document lang="en">
<iodef:Incident restriction="need-to-know" purpose="reporting">
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:DetectTime>2004-02-05T10:21:08+00:00</iodef:DetectTime>
<iodef:StartTime>2004-02-05T10:21:05+00:00</iodef:StartTime>
<iodef:EndTime>2004-02-05T10:35:00+00:00</iodef:EndTime>
<iodef:ReportTime>2004-02-05T10:27:38+00:00</iodef:ReportTime>
<iodef:Description>Host illicitly accessed admin account
</iodef:Description>
<iodef:Assessment>
<iodef:Impact severity="high" completion="succeeded"
type="admin"/>
<iodef:Confidence rating="high"/>
</iodef:Assessment>
<iodef:Contact role="creator" type="organization">
<iodef:ContactName>Constituency-contact for 192.0.2.35
</iodef:ContactName>
<iodef:Email>Constituency-contact@10.1.1.2</iodef:Email>
</iodef:Contact>
<iodef:EventData>
<iodef:Flow>
<iodef:System category="source">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.35
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>32821</iodef:Port>
</iodef:Service>
</iodef:System>
<iodef:System category="target">
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.67
</iodef:Address>
</iodef:Node>
<iodef:Service ip_protocol="6">
<iodef:Port>22</iodef:Port>
</iodef:Service>
</iodef:System>
</iodef:Flow>
</iodef:EventData>
<iodef:History>
<iodef:HistoryItem action="rate-limit-host">
<iodef:DateTime>2004-02-05T10:28:00+00:00</iodef:DateTime>
<iodef:IncidentID name="CSIRT-FOR-OUR-DOMAIN">
CSIRT-FOR-OUR-DOMAIN#209-1
</iodef:IncidentID>
<iodef:Description>
Incident report sent to SP for 192.0.2.35
</iodef:Description>
</iodef:HistoryItem>
</iodef:History>
</iodef:Incident>
</iodef:IODEF-Document>
</iodef-rid:XMLDocument>
<!-- End of IODEF-Document included in RID -->
</iodef-rid:ReportSchema>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
The diagram below outlines the RID Query communication flow between RID systems on different networks.
以下の図は、異なるネットワーク上のRIDシステム間のRIDクエリ通信フローの概要を示しています。
SP-1 SP-2
SP-1 SP-2
1. Generate a request for information on a specific incident number or incident type
1. 特定のインシデント番号またはインシデントタイプに関する情報のリクエストを生成する
2. o-------Query------->
2. o -------クエリ------->
3. Verify policy information and determine if matches exist for requested information
3. ポリシー情報を確認し、要求された情報に対して一致するかどうかを判断する
4. <-------Report------o
5. Associate report to request by incident number or type and file report(s).
5. インシデント番号またはタイプおよびファイルレポートによるリクエストへの関連レポート。
Figure 11: Query Communication Flow
図11：クエリ通信フロー
The Query message communication receives a response of a Report message. If the Report message is empty, the responding host did not
クエリメッセージ通信は、レポートメッセージの応答を受信します。レポートメッセージが空の場合、応答するホストは
have information available to share with the requestor. The incident number and responding RID system, as well as the transport, assist in the association of the request and response since a report can be filed and is not always solicited. If there is a problem with the Query message, such as a failure to validate the digital signature or decrypt the request, an Acknowledgement message is sent to the requestor. The Acknowledgement message should provide the reason why the message could not be processed.
リクエスターと共有できる情報があります。インシデント番号と応答RIDシステム、およびトランスポートは、レポートを提出することができ、常に勧誘されるとは限らないため、要求と対応の関連付けを支援します。デジタル署名の検証やリクエストの復号化など、クエリメッセージに問題がある場合、承認メッセージがリクエスターに送信されます。確認メッセージは、メッセージを処理できない理由を提供する必要があります。
The Query request may be received in several formats as a result of the type of query being performed. If the incident number is the only information provided, the IODEF document and IP packet data may not be needed to complete the request. However, if a type of incident is requested, the incident number remains NULL, and the IP packet data will not be included in the IODEF RecordItem class; the other incident information is the main source for comparison. In the case in which an incident number may not be the same between CSIRTs, the incident number and/or IP packet information can be provided and used for comparison on the receiving RID system to generate (a) Report message(s).
クエリリクエストは、実行されているクエリのタイプの結果として、いくつかの形式で受信される場合があります。インシデント番号が提供された唯一の情報である場合、リクエストを完了するためにIODEFドキュメントとIPパケットデータは必要ない場合があります。ただし、インシデントのタイプが要求された場合、インシデント番号はNULLのままであり、IPパケットデータはIODEF RecordItemクラスに含まれません。他のインシデント情報は、比較の主な情報源です。インシデント番号がCSIRTの間で同じではない場合、インシデント番号および/またはIPパケット情報を提供し、受信RIDシステムの比較に使用して（a）レポートメッセージを生成できます。
This query is sent to 192.0.2.3, inquiring about the incident with the identifier CERT-FOR-OUR-DOMAIN#210-1. The Report will be provided to the requestor identified and verified through the authentication and digital signature information provided in the RID message. An example Report is provided above.
このクエリは192.0.2.3に送信され、識別子の証明書＃210-1でインシデントについて問い合わせます。レポートは、RIDメッセージで提供される認証およびデジタル署名情報を通じて特定され、検証されたリクエスターに提供されます。上記の例のレポートを示します。
<iodef-rid:RID lang="en"
xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0">
<iodef-rid:RIDPolicy MsgType="Query"
MsgDestination="RIDSystem">
<iodef-rid:PolicyRegion region="PeerToPeer"/>
<iodef:Node>
<iodef:Address category="ipv4-addr">192.0.2.3</iodef:Address>
</iodef:Node>
<iodef-rid:TrafficType type="Attack"/>
<iodef:IncidentID name="CERT-FOR-OUR-DOMAIN">
CERT-FOR-OUR-DOMAIN#210-1
</iodef:IncidentID>
</iodef-rid:RIDPolicy>
</iodef-rid:RID>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:iodef-rid="urn:ietf:params:xml:ns:iodef-rid-2.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="urn:ietf:params:xml:ns:iodef-rid-2.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:iodef-1.0"
schemaLocation="http://www.iana.org/assignments/xml-registry/schema/
iodef-1.0.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/
xmldsig-core-schema.xsd"/>
<!-- ****************************************************************
*********************************************************************
*** Real-time Inter-network Defense - RID XML Schema ***
*** Namespace - iodef-rid, April 2012 ***
*** The namespace is defined to support transport of IODEF ***
*** documents for exchanging incident information. ***
*********************************************************************
-->
<!--RID messages act as an envelope for IODEF and RID documents
to support the exchange of incident information-->
<!--
====== Real-Time Inter-network Defense - RID ======
==== Suggested definition for RID messaging ======
-->
- >
<xs:annotation>
<xs:documentation>XML Schema wrapper for IODEF</xs:documentation>
</xs:annotation>
<xs:element name="RID" type="iodef-rid:RIDType"/>
<xs:complexType name="RIDType">
<xs:sequence>
<xs:element ref="iodef-rid:RIDPolicy" minOccurs="0"/>
<xs:element ref="iodef-rid:RequestStatus" minOccurs="0"/>
<xs:element ref="iodef-rid:IncidentSource" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="lang"
type="xs:language" use="required"/>
</xs:complexType>
<!--Used in Acknowledgement Message for RID-->
<xs:element name="RequestStatus" type="iodef-rid:RequestStatusType"/>
<xs:complexType name="RequestStatusType">
<xs:attribute name="AuthorizationStatus" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Approved"/>
<xs:enumeration value="Denied"/>
<xs:enumeration value="Pending"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-AuthorizationStatus"
type="xs:string" use="optional"/>
<xs:attribute name="Justification">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="SystemResource"/>
<xs:enumeration value="Authentication"/>
<xs:enumeration value="AuthenticationOrigin"/>
<xs:enumeration value="Encryption"/>
<xs:enumeration value="UnrecognizedFormat"/>
<xs:enumeration value="CannotProcess"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Justification"
type="xs:string" use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<!--Incident Source Information for Result Message-->
<xs:element name="IncidentSource" type="iodef-rid:IncidentSourceType"/>
<xs:complexType name="IncidentSourceType">
<xs:sequence>
<xs:element ref="iodef-rid:SourceFound"/>
<xs:element ref="iodef:Node" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:element name="SourceFound" type="xs:boolean"/>
<!--
====== Real-Time Inter-network Defense Policy - RIDPolicy ======
====== Definition for RIDPolicy for messaging
-->
<xs:annotation>
<xs:documentation>RID Policy used for transport of
messages</xs:documentation>
</xs:annotation>
<!-- RIDPolicy information with setting information listed in RID
documentation -->
<xs:element name="RIDPolicy" type="iodef-rid:RIDPolicyType"/>
<xs:complexType name="RIDPolicyType">
<xs:sequence>
<xs:element ref="iodef-rid:PolicyRegion" maxOccurs="unbounded"/>
<xs:element ref="iodef:Node"/>
<xs:element ref="iodef-rid:TrafficType" maxOccurs="unbounded"/>
<xs:element ref="iodef:IncidentID" minOccurs="0"/>
<xs:element ref="iodef-rid:ReportSchema" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="MsgType" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="TraceRequest"/>
<xs:enumeration value="Acknowledgement"/>
<xs:enumeration value="Result"/>
<xs:enumeration value="InvestigationRequest"/>
<xs:enumeration value="Report"/>
<xs:enumeration value="Query"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgType" type="xs:string" use="optional"/>
<xs:attribute name="MsgDestination" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="RIDSystem"/>
<xs:enumeration value="SourceOfIncident"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-MsgDestination" type="xs:string"
use="optional"/>
<xs:attribute name="restriction" type="iodef:restriction-type"/>
</xs:complexType>
<xs:element name="PolicyRegion">
<xs:complexType>
<xs:attribute name="region" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="ClientToSP"/>
<xs:enumeration value="SPToClient"/>
<xs:enumeration value="IntraConsortium"/>
<xs:enumeration value="PeerToPeer"/>
<xs:enumeration value="BetweenConsortiums"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-region"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="TrafficType">
<xs:complexType>
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="Attack"/>
<xs:enumeration value="Network"/>
<xs:enumeration value="Content"/>
<xs:enumeration value="DataWithHandlingRequirements"/>
<xs:enumeration value="AudienceRestriction"/>
<xs:enumeration value="Other"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-type"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<!--Used to include an enveloped XML document in RID-->
<xs:element name="ReportSchema" type="iodef-rid:ReportSchemaType"/>
<xs:complexType name="ReportSchemaType">
<xs:sequence>
<xs:element ref="iodef-rid:XMLDocument" minOccurs="1"
maxOccurs="1"/>
<xs:element ref="iodef-rid:URL" minOccurs="0"
maxOccurs="1"/>
<xs:element ref="iodef-rid:Signature" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-Version"
type="xs:string" use="optional"/>
<xs:attribute name="XMLSchemaID" use="optional">
<xs:simpleType>
<xs:restriction base="xs:anyURI">
<xs:whiteSpace value="collapse"/>
<xs:enumeration value="urn:ietf:params:xml:ns:iodef-1.0"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="ext-XMLSchemaID"
type="xs:string" use="optional"/>
</xs:complexType>
<xs:element name="XMLDocument"
type="iodef:ExtensionType"/>
<xs:element name="URL"
type="xs:anyURI"/>
<xs:element name="Signature"
type="iodef:ExtensionType"/>
</xs:schema>
RID leverages existing security standards and data markings in RIDPolicy to achieve the required levels of security for the exchange of incident information. The use of standards includes TLS and the XML security features of encryption [XMLencrypt] and digital signatures [RFC3275] [XMLsig]. The standards provide clear methods to ensure that messages are secure, authenticated, and authorized; meet policy and privacy guidelines; and maintain integrity. XML
RIDは、既存のセキュリティ基準とRidpolicyのデータマークを活用して、インシデント情報の交換に必要なレベルのセキュリティを実現します。標準の使用には、暗号化[XMLENCRYPT]およびデジタル署名[RFC3275] [XMLSIG]のTLSとXMLセキュリティ機能が含まれます。標準は、メッセージが安全で認証され、許可されるようにするための明確な方法を提供します。ポリシーとプライバシーのガイドラインを満たす。整合性を維持します。XML
Signature Best Practices [XMLSigBP] should be referenced by implementers for information on improving security to mitigate attacks.
署名のベストプラクティス[XMLSIGBP]は、攻撃を緩和するためのセキュリティの改善に関する情報については、実装者が参照する必要があります。
As specified in the relevant sections of this document, the XML digital signature [RFC3275] and XML encryption [XMLencrypt] are used in the following cases:
このドキュメントの関連セクションで指定されているように、XMLデジタル署名[RFC3275]およびXML暗号化[XMLENCRYPT]は、次の場合に使用されます。
XML Digital Signature
XMLデジタル署名
o The originator of a Request MUST use a detached signature to sign at least one of the original elements contained in the RecordItem class to provide authentication to all upstream participants in the trace or those involved in the investigation. All instances of RecordItem provided by the originator may be individually signed, and additional RecordItem entries by upstream peers in the trace or investigation may be signed by the peer adding the data, while maintaining the original RecordItem entry(s) and detached signature(s) from the original requestor. It is important to note that the data is signed at the RecordItem level. Since multiple RecordItems may exist within an IODEF document and may originate from different sources, the signature is applied at the RecordItem level to enable the use of an XML detached signature. Exclusive canonicalization [XMLCanon] is REQUIRED for the detached signature and not the references, as the XML document generated is then included in the RID message within the Signature element of the ReportSchema class. This signature MUST be passed to all recipients of the Request message.
o リクエストの創始者は、分離した署名を使用して、RecordItemクラスに含まれる元の要素の少なくとも1つに署名して、トレースまたは調査に関与するすべての上流の参加者に認証を提供する必要があります。 Originatorが提供するRecordITEMのすべてのインスタンスは個別に署名され、トレースまたは調査の上流のピアによる追加の記録エントリは、ピアがデータを追加しながら、元のRecordITemエントリと独立した署名を維持しながら、署名することができます。元の要求者から。データは記録レベルで署名されていることに注意することが重要です。 IODEFドキュメント内に複数の録音が存在し、異なるソースから発生する可能性があるため、XMLデタッチされた署名の使用を有効にするために、署名が記録レベルで適用されます。生成されたXMLドキュメントがReportschemaクラスの署名要素内のRIDメッセージに含まれるため、参照ではなく、独占標準化[Xmlcanon]が必要です。この署名は、リクエストメッセージのすべての受信者に渡す必要があります。
o If a Request does not include a RecordItem entry, a timestamp MUST be used to ensure there is data to be signed for the multi-hop authentication use case. The DateTime element of the iodef: RecordData class ([RFC5070], Section 3.19.1) is used for this purpose.
o リクエストにRecordITemエントリが含まれていない場合、マルチホップ認証ユースケースに署名するデータがあることを確認するためにタイムスタンプを使用する必要があります。IODEFのDateTime要素：RecordDataクラス（[RFC5070]、セクション3.19.1）は、この目的に使用されます。
o For all message types, the full IODEF-RID document MUST be signed using an enveloped signature by the sending peer to provide authentication and integrity to the receiving RID system. The signature is placed in an instance of the Signature element.
o すべてのメッセージタイプについて、IODEF-RIDの完全なドキュメントは、送信ピアによる封筒の署名を使用して署名して、受信RIDシステムに認証と整合性を提供する必要があります。署名は、署名要素のインスタンスに配置されます。
o XML Signature Best Practices [XMLSigBP] guidance SHOULD be followed to prevent or mitigate security risks. Examples include the recommendation to authenticate a signature prior to processing (executing potentially dangerous operations) and the recommendation to limit the use of URIs since they may enable cross-site scripting attacks or access to local information.
o XML Signature Best Practices [XMLSIGBP]ガイダンスに従って、セキュリティリスクを防止または軽減する必要があります。例には、処理前（潜在的に危険な操作の実行）の前に署名を認証するための推奨事項と、クロスサイトスクリプティング攻撃やローカル情報へのアクセスを可能にする可能性があるため、URIの使用を制限する推奨事項が含まれます。
o XML Path Language (XPath) 2.0 [XMLPath] MUST be followed to specify the portion of the XML document to be signed. XPath is used to specify a location within an XML document. Best practice recommendations for using XPath [XMLSigBP] SHOULD be referenced to reduce the risk of denial-of-service attacks. The use of XSLT transforms MUST be restricted according to security guidance in [XMLSigBP].
o XML PATH言語（XPATH）2.0 [XMLPATH]に従って、署名するXMLドキュメントの部分を指定する必要があります。XPathは、XMLドキュメント内の場所を指定するために使用されます。XPath [XMLSIGBP]を使用するためのベストプラクティスの推奨事項は、サービス拒否攻撃のリスクを減らすために参照する必要があります。XSLT変換の使用は、[XMLSIGBP]のセキュリティガイダンスに従って制限する必要があります。
XML Encryption
XML暗号化
o The IODEF-RID document MAY be encrypted to provide an extra layer of security between peers so that not only the message is encrypted for transport. This behavior would be agreed upon between peers or a consortium, or determined on a per-message basis, depending on security requirements. It should be noted that there are cases for transport where the RIDPolicy class needs to be presented in clear text, as detailed in the transport document [RFC6546].
o IODEF-RIDドキュメントは、輸送用にメッセージが暗号化されるだけでなく、ピア間のセキュリティの追加レイヤーを提供するために暗号化されている場合があります。この振る舞いは、ピアまたはコンソーシアムの間で合意されるか、セキュリティ要件に応じて、1人あたりベースで決定されます。輸送文書[RFC6546]に詳述されているように、輸送クラスを明確なテキストで提示する必要がある場合は、輸送の場合があることに注意する必要があります。
o A Request, or any other message type that may be relayed through RID systems before reaching the intended destination as a result of trust relationships, MAY be encrypted specifically for the intended recipient. This may be necessary if the RID network is being used for message transfer, the intermediate parties do not need to have knowledge of the request contents, and a direct communication path does not exist. In that case, the RIDPolicy class is used by intermediate parties and as such, RIDPolicy is maintained in clear text.
o 信頼関係の結果として意図した目的地に到達する前にRIDシステムを介して中継される可能性のあるリクエスト、またはその他のメッセージタイプは、意図した受信者専用に暗号化される場合があります。これは、RIDネットワークがメッセージ転送に使用されている場合、中間当事者は要求コンテンツの知識を持つ必要がなく、直接通信パスが存在しない場合に必要になる場合があります。その場合、Ridpolicyクラスは中間者によって使用されているため、Ridpolicyは明確なテキストに維持されます。
o The action taken in the Result message may be encrypted using the key of the request originator. In that case, the intermediate parties can view the RIDPolicy information and know the trace has been completed and do not need to see the action. If the use of encryption were limited to sections of the message, the History class information would be encrypted. Otherwise, it is RECOMMENDED to encrypt the entire IODEF-RID document and use an enveloped signature for the originator of the request. The existence of the Result message for an incident would tell any intermediate parties used in the path of the incident investigation that the incident handling has been completed.
o 結果メッセージで実行されるアクションは、リクエストオリジネーターのキーを使用して暗号化される場合があります。その場合、中間当事者はリッピング情報を表示し、トレースが完了したことを知ることができ、アクションを確認する必要はありません。暗号化の使用がメッセージのセクションに制限されていた場合、履歴クラス情報が暗号化されます。それ以外の場合は、IODEF-RIDドキュメント全体を暗号化し、リクエストのオリジネーターに封筒の署名を使用することをお勧めします。インシデントの結果メッセージの存在は、インシデント調査の経路で使用された中間当事者に、インシデント処理が完了したことを伝えるでしょう。
o The iodef:restriction attribute sets expectations for the privacy of an incident and is defined in Section 3.2 of RFC 5070. Following the guidance for XML encryption in the Security Requirements section, the iodef:restriction attribute can be set in any of the RID classes to define restrictions and encryption requirements for the exchange of incident information. The restriction options enable encryption capabilities for the
o IODEF：制限属性は、インシデントのプライバシーに対する期待を設定し、RFC 5070のセクション3.2で定義されています。セキュリティ要件セクションのXML暗号化のガイダンスに従って、IODEF：制限属性はRIDクラスのいずれかで設定できます。インシデント情報の交換の制限と暗号化要件を定義します。制限オプションにより、暗号化機能が可能になります
complete exchange of an IODEF document (including any extensions), within specific classes of IODEF, or IODEF extensions, where more limited restrictions are desired. The restriction attribute is contained in each of the RID classes and MUST be used in accordance with confidentiality expectations for either sections of the IODEF document or the complete IODEF document. Consortiums and organizations should consider this guidance when creating exchange policies.
IODEFの特定のクラス内のIODEFドキュメント（任意の拡張機能を含む）の完全な交換、またはより限定的な制限が望まれるIODEF拡張機能。制限属性は、各RIDクラスに含まれており、IODEFドキュメントのセクションまたは完全なIODEFドキュメントのいずれかのセクションの機密性の期待に従って使用する必要があります。コンソーシアムと組織は、交換ポリシーを作成する際にこのガイダンスを考慮する必要があります。
o Expectations based on how restriction is set:
o 制限の設定方法に基づく期待：
* If restriction is set to 'private', the class or document MUST be encrypted for the recipient using XML encryption and the public key of the recipient. See Section 9.3 for a discussion on public key infrastructure (PKI) and other security requirements.
* 制限が「プライベート」に設定されている場合、XML暗号化と受信者の公開鍵を使用して、レシピエントに対してクラスまたはドキュメントを暗号化する必要があります。公開キーインフラストラクチャ（PKI）およびその他のセキュリティ要件についての議論については、セクション9.3を参照してください。
* If restriction is set to 'need-to-know', the class or document MUST be encrypted to ensure only those with need-to-know access can decrypt the data. The document can either be encrypted for each individual for which access is intended or be encrypted with a single group key. The method used SHOULD adhere to any certificate policy and practices agreements between entities for the use of RID. A group key in this instance refers to a single key (symmetric) that is used to encrypt the block of data. The users with need-to-know access privileges may be given access to the shared key via a secure distribution method, for example, providing access to the symmetric key encrypted with each of the user's public keys.
* 制限が「知る必要がある」ように設定されている場合、クラスまたはドキュメントを暗号化して、知識が必要な人のみがデータを復号化できるようにする必要があります。ドキュメントは、アクセスが意図されている個人ごとに暗号化されるか、単一のグループキーで暗号化されます。使用される方法は、RIDを使用するために、エンティティ間の証明書ポリシーと慣行契約を順守する必要があります。このインスタンスのグループキーは、データのブロックを暗号化するために使用される単一のキー（対称）を指します。知識が必要なアクセス権限を持つユーザーには、安全な配布方法を介して共有キーへのアクセスが与えられる場合があります。たとえば、ユーザーの各パブリックキーに暗号化された対称キーへのアクセスを提供します。
* If restriction is set to 'public', the class or document MUST be sent in clear text. This setting can be critical if certain sections of a document or an entire document are to be shared without restrictions. This provides flexibility within an incident to share certain information freely where appropriate.
* 制限が「公開」に設定されている場合、クラスまたはドキュメントを明確なテキストで送信する必要があります。この設定は、ドキュメントの特定のセクションまたはドキュメント全体が制限なしに共有される場合に重要です。これにより、インシデント内で柔軟性が提供され、必要に応じて特定の情報を自由に共有します。
* If restriction is set to 'default', the information can be shared according to an information disclosure policy pre-arranged by the communicating parties.
* 制限が「デフォルト」に設定されている場合、情報は、通信当事者によって事前に配置された情報開示ポリシーに従って共有できます。
o Expectations based on placement of the restriction setting:
o 制限設定の配置に基づく期待：
* If restriction is set within one of the RID classes, the restriction applies to the entire IODEF document.
* RIDクラスのいずれか内で制限が設定されている場合、制限はIODEFドキュメント全体に適用されます。
* If restriction is set within individual IODEF classes, the restriction applies to the specific IODEF class and the children of that class.
* 個々のIODEFクラス内で制限が設定されている場合、制限は特定のIODEFクラスとそのクラスの子供に適用されます。
The formation of policies is a very important aspect of using a messaging system like RID to exchange potentially sensitive information. Many considerations should be involved for peering parties, and some guidelines to protect the data, systems, and transport are covered in this section. Policies established should provide guidelines for communication methods, security, and fall-back procedures. See Sections 9.4 and 9.5 for additional information on consortiums and PKI considerations.
ポリシーの形成は、潜在的に機密情報を交換するために、ridのようなメッセージングシステムを使用することの非常に重要な側面です。ピアリングパーティーには多くの考慮事項が含まれるべきであり、このセクションでは、データ、システム、および輸送を保護するためのいくつかのガイドラインについて説明します。確立されたポリシーは、コミュニケーション方法、セキュリティ、およびフォールバック手順に関するガイドラインを提供する必要があります。コンソーシアムとPKIの考慮事項に関する追加情報については、セクション9.4および9.5を参照してください。
The security considerations for the storage and exchange of information in RID messaging may include adherence to local, regional, or national regulations in addition to the obligations to protect client information during an investigation. RIDPolicy is a necessary tool for listing the requirements of messages to provide a method to categorize data elements for proper handling. Controls are also provided for the sending entity to protect messages from third parties through XML encryption.
RIDメッセージングにおける情報の保存と交換に関するセキュリティ上の考慮事項には、調査中にクライアント情報を保護する義務に加えて、地域、地域、または国家規制の遵守が含まれる場合があります。Ridpolicyは、適切な処理のためにデータ要素を分類する方法を提供するためのメッセージの要件をリストするための必要なツールです。また、XML暗号化を介してサードパーティからのメッセージを保護するための送信エンティティ向けのコントロールも提供されています。
RID provides a method to exchange incident-handling requests and Report messages between entities. Administrators have the ability to base decisions on the available resources and other factors of their network and maintain control of incident investigations within their own network. Thus, RID provides the ability for participating networks to manage their own security controls, leveraging the information listed in RIDPolicy.
RIDは、インシデント処理リクエストを交換し、エンティティ間でメッセージをレポートする方法を提供します。管理者は、ネットワークの利用可能なリソースやその他の要因に基づいて決定を下し、独自のネットワーク内のインシデント調査の制御を維持する能力を持っています。したがって、RIDは、Ridpolicyにリストされている情報を活用して、参加ネットワークが独自のセキュリティ制御を管理する機能を提供します。
RID is used to transfer or exchange XML documents in an IODEF format or using another IANA-registered format. Implementations SHOULD NOT download schemas at runtime due to the security implications, and included documents MUST NOT be required to provide a resolvable location of their schema.
RIDは、IODEF形式でXMLドキュメントを転送または交換するため、または別のIANA登録形式の使用に使用されます。セキュリティへの影響により、実行時にスキーマをダウンロードしないでください。また、スキーマの解決可能な場所を提供するためにドキュメントを含めては不要にしてはなりません。
A transport specification is defined in a separate document [RFC6546]. The specified transport protocols MUST use encryption to provide an additional level of security and integrity, while supporting mutual authentication through bidirectional certificate usage. Any subsequent transport method defined should take advantage of existing standards for ease of implementation and integration of RID systems. Session encryption for the transport of RID messages is enforced in the transport specification. The privacy and security considerations are addressed fully in RID to protect sensitive portions of documents and to provide a method to authenticate the messages. Therefore, RID messages do not rely on the security provided by the transport layer alone. The encryption requirements and considerations for RID messages are discussed in Section 9.1 of this document.
輸送仕様は、別のドキュメント[RFC6546]で定義されています。指定された輸送プロトコルは、暗号化を使用して追加のレベルのセキュリティと整合性を提供する必要があり、双方向の証明書の使用を通じて相互認証をサポートする必要があります。定義された後続の輸送方法は、RIDシステムの実装と統合の容易さのために既存の標準を活用する必要があります。RIDメッセージの輸送用のセッション暗号化は、輸送仕様で実施されます。プライバシーとセキュリティの考慮事項は、ドキュメントの機密部分を保護し、メッセージを認証する方法を提供するために、RIDで完全に対処されます。したがって、RIDメッセージは、輸送層のみが提供するセキュリティに依存しません。RIDメッセージの暗号化の要件と考慮事項については、このドキュメントのセクション9.1で説明します。
Consortiums may vary their selected transport mechanisms and thus decide upon a mutual protocol to use for transport when communicating with peers in a neighboring consortium using RID. RID systems MUST implement and deploy HTTPS as defined in the transport document [RFC6546] and optionally MAY support other protocols such as the Blocks Extensible Exchange Protocol (BEEP) [RFC3080]. Bindings would need to be defined to enable support for other transport protocols.
コンソーシアムは、選択された輸送メカニズムを変化させる可能性があるため、RIDを使用して近隣のコンソーシアムのピアと通信するときに、輸送に使用する相互プロトコルを決定します。RIDシステムは、トランスポートドキュメント[RFC6546]で定義されているようにHTTPSを実装および展開する必要があり、オプションでは、ブロック拡張可能な交換プロトコル（BEEP）[RFC3080]などの他のプロトコルをサポートする場合があります。他の輸送プロトコルのサポートを可能にするために、バインディングを定義する必要があります。
Systems used to send authenticated RID messages between networks MUST use a secured system and interface to connect to a border network's RID systems. Each connection to a RID system MUST meet the security requirements agreed upon through the consortium regulations, peering, or SLAs. The RID system MUST listen for and send RID messages on only the designated port, which also MUST be over an encrypted tunnel meeting the minimum requirement of algorithms and key lengths established by the consortium, peering, or SLA. The selected cryptographic algorithms for symmetric encryption, digital signatures, and hash functions MUST meet minimum security levels of the times. The encryption strength MUST adhere to import and export regulations of the involved countries for data exchange.
ネットワーク間で認証されたRIDメッセージを送信するために使用されるシステムは、セキュリティ済みのシステムとインターフェイスを使用して、Border NetworkのRIDシステムに接続する必要があります。RIDシステムへの各接続は、コンソーシアム規制、ピアリング、またはSLAを通じて合意されたセキュリティ要件を満たす必要があります。RIDシステムは、指定されたポートのみでRIDメッセージをリッスンして送信する必要があります。これは、コンソーシアム、ピアリング、またはSLAによって確立されたアルゴリズムの最小要件と主要な長さを満たす暗号化されたトンネルを超えている必要があります。対称暗号化、デジタル署名、およびハッシュ関数のための選択された暗号化アルゴリズムは、時間の最小セキュリティレベルを満たす必要があります。暗号化強度は、データ交換のために、関係国の規制を輸入および輸出することを遵守する必要があります。
Out-of-band communications dedicated to SP interaction for RID messaging would provide additional security as well as guaranteed bandwidth during a denial-of-service attack. For example, an out-of-band channel may consist of logical paths defined over the existing network. Out-of-band communications may not be practical or possible between service providers, but provisions should be considered to protect the incident management systems used for RID messaging. Methods to protect the data transport may also be provided through session encryption.
RIDメッセージングのSP相互作用に専念するバンド外通信は、サービス拒否攻撃中に追加のセキュリティと保証された帯域幅を提供します。たとえば、バンド外チャネルは、既存のネットワーク上で定義された論理パスで構成されている場合があります。帯域外の通信は、サービスプロバイダー間で実用的または可能ではない場合がありますが、RIDメッセージングに使用されるインシデント管理システムを保護するための規定を検討する必要があります。データ輸送を保護する方法は、セッション暗号化を介して提供される場合があります。
It is RECOMMENDED that RID, the XML security functions, and transport protocols properly integrate with a PKI managed by the consortium, federate PKIs within a consortium, or use a PKI managed by a trusted third party. Entities MAY use shared keys as an alternate solution, although this may limit the ability to validate certificates and could introduce risk. For the Internet, a few examples of existing efforts that could be leveraged to provide the supporting PKI include the Regional Internet Registry's (RIR's) PKI hierarchy, vendor issued certificates, or approved issuers of Extended Validation (EV) Certificates. Security and privacy considerations related to consortiums are discussed in Sections 9.4 and 9.5.
RID、XMLセキュリティ機能、および輸送プロトコルは、コンソーシアムが管理するPKI、コンソーシアム内のPKIをフェデレートする、または信頼できる第三者が管理するPKIを使用することをお勧めします。エンティティは、代替ソリューションとして共有キーを使用する場合がありますが、これにより証明書を検証する能力が制限され、リスクを導入する可能性があります。インターネットの場合、サポートPKIを提供するために活用できる既存の取り組みのいくつかの例には、地域のインターネットレジストリ（RIR）のPKI階層、ベンダーが発行した証明書、または承認された拡張検証（EV）証明書が含まれます。コンソーシアムに関連するセキュリティとプライバシーの考慮事項については、セクション9.4および9.5で説明します。
The use of PKI between entities or by a consortium SHOULD adhere to any applicable certificate policy and practices agreements for the use of RID. [RFC3647] specifies a commonly used format for
エンティティ間またはコンソーシアムによるPKIの使用は、RIDの使用に関する該当する証明書ポリシーと慣行契約を遵守する必要があります。[RFC3647]は、一般的に使用される形式を指定します
certificate policy (CP) and certification practices statements (CPS). Systems with predefined relationships for RID include those who peer directly or through a consortium with agreed-upon appropriate use agreements. The agreements to trust other entities may be based on assurance levels that could be determined by a comparison of the CP, CPS, and/or RID operating procedures. The initial comparison of policies and the ability to audit controls provide a baseline assurance level for entities to form and maintain trust relationships. Trust relationships may also be defined through a bridged or hierarchical PKI in which both peers belong. If shared keys or keys issued from a common CA are used, the verification of controls to determine the assurance level to trust other entities may be limited to the RID policies and operating procedures.
証明書ポリシー（CP）および認定慣行声明（CPS）。RIDの事前定義された関係を持つシステムには、合意された適切な使用契約を備えたコンソーシアムを通じて、直接ピアを覗く人が含まれます。他のエンティティを信頼するための契約は、CP、CPS、および/またはRID運用手順の比較によって決定できる保証レベルに基づいている場合があります。ポリシーの最初の比較とコントロールを監査する能力は、エンティティが信頼関係を形成し維持するためのベースライン保証レベルを提供します。信頼関係は、両方のピアが属する橋渡しまたは階層的なPKIを介して定義される場合があります。共通のCAから発行された共有キーまたはキーが使用されている場合、他のエンティティを信頼する保証レベルを決定するためのコントロールの検証は、RIDポリシーと運用手順に限定される場合があります。
XML security functions utilized in RID require a trust center such as a PKI for the distribution of credentials to provide the necessary level of security for this protocol. Layered transport protocols also utilize encryption and rely on a trust center. Public key certificate pairs issued by a trusted Certification Authority (CA) MAY be used to provide the necessary level of authentication and encryption for the RID protocol. The CA used for RID messaging must be trusted by all involved parties and may take advantage of similar efforts, such as the Internet2 federated PKI or the ARIN/RIR effort to provide a PKI to service providers. The PKI used for authentication also provides the necessary certificates needed for encryption used for the RID transport protocol [RFC6546].
RIDで利用されるXMLセキュリティ関数には、このプロトコルに必要なレベルのセキュリティを提供するために、資格情報の分布のためにPKIなどの信託センターが必要です。階層化された輸送プロトコルは、暗号化を利用し、信託センターに依存します。信頼できる認証機関（CA）によって発行された公開鍵の証明書ペアを使用して、RIDプロトコルに必要なレベルの認証と暗号化を提供することができます。RIDメッセージングに使用されるCAは、すべての関係者によって信頼されている必要があり、インターネット2フェデレートPKIやサービスプロバイダーにPKIを提供するARIN/RIRの取り組みなど、同様の努力を利用することができます。認証に使用されるPKIは、RID輸送プロトコル[RFC6546]に使用される暗号化に必要な必要な証明書も提供します。
Hosts receiving a RID message MUST be able to verify that the sender of the request is valid and trusted. Using digital signatures on a hash of the RID message with an X.509 version 3 certificate issued by a trusted party MUST be used to authenticate the request. The X.509 version 3 specifications as well as the digital signature specifications and path validation standards set forth in [RFC5280] MUST be followed in order to interoperate with a PKI designed for similar purposes. Full path validation verifies the chaining relationship to a trusted root and also performs a certificate revocation check. The use of digital signatures in RID XML messages MUST follow the World Wide Web Consortium (W3C) recommendations for signature syntax and processing when either the XML encryption [XMLencrypt] or digital signature [XMLsig] [RFC3275] is used within a document.
RIDメッセージを受信するホストは、リクエストの送信者が有効で信頼されていることを確認できる必要があります。信頼できる当事者によって発行されたX.509バージョン3証明書を使用して、RIDメッセージのハッシュにデジタル署名を使用することを使用して、リクエストを認証する必要があります。X.509バージョン3の仕様と、[RFC5280]に記載されているデジタル署名仕様とパス検証標準に従って、同様の目的で設計されたPKIと相互運用する必要があります。フルパス検証は、信頼できるルートとのチェーン関係を検証し、証明書の取り消しチェックも実行します。XML暗号化[XMLENCRYPT]またはデジタル署名[XMLSIG] [RFC3275]のいずれかがドキュメント内で使用される場合、署名の構文と処理のためのWorld Wide Webコンソーシアム（W3C）の推奨事項に従う必要があります。
It might be helpful to define an extension to the authentication scheme that uses attribute certificates [RFC5755] in such a way that an application could automatically determine whether human intervention is needed to authorize a request; however, the specification of such an extension is out of scope for this document.
リクエストを承認するために人間の介入が必要かどうかをアプリケーションが自動的に判断できるように、属性証明書[RFC5755]を使用する認証スキームの拡張機能を定義することが役立つ場合があります。ただし、このような拡張機能の仕様は、このドキュメントの範囲外です。
The use of pre-shared keys may be considered for authentication at the transport layer. If this option is selected, the specifications set forth in "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)" [RFC4279] MUST be followed. Transport specifications are detailed in a separate document [RFC6546].
事前に共有キーの使用は、輸送層での認証のために考慮される場合があります。このオプションが選択されている場合、「輸送層セキュリティ（TLS）の事前に共有キー暗号網」に記載されている仕様[RFC4279]に従う必要があります。輸送仕様は、別のドキュメント[RFC6546]で詳しく説明されています。
The use of multi-hop authentication in a Request is used when a Request is sent to multiple entities or SPs in an iterative manner. Multi-hop authentication is REQUIRED in Requests that involve multiple SPs where Requests are forwarded iteratively through peers. Bilateral trust relationships MAY be used between peers; multi-hop authentication MUST be used for cases where the originator of a message is authenticated several hops into the message flow.
リクエストでのマルチホップ認証の使用は、リクエストが複数のエンティティまたはSPSに反復的に送信されると使用されます。マルチホップ認証は、リクエストがピアを通じて繰り返し転送される複数のSPSを含むリクエストで必要です。両側の信頼関係は、ピア間で使用される場合があります。メッセージのオリジネーターがメッセージフローにいくつかのホップを認証される場合には、マルチホップ認証を使用する必要があります。
For practical reasons, SPs may want to prioritize incident-handling events based upon the immediate peer for a Request, the originator of a request, and the listed Confidence rating for the incident. In order to provide a higher assurance level of the authenticity of a Request, the originating RID system is included in the Request along with contact information and the information of all RID systems in the path the trace has taken. This information is provided through the IODEF EventData class, which nests the list of systems and contacts involved in a trace, while setting the category attribute to "infrastructure".
実際的な理由から、SPSは、リクエストのために即時のピアに基づいて、要求の発信者、およびインシデントのリストされた信頼評価に基づいて、インシデント処理イベントに優先順位を付けたい場合があります。リクエストの信頼性のより高い保証レベルを提供するために、リクエストシステムは、連絡先情報と、トレースがとったパス内のすべてのRIDシステムの情報とともに要求に含まれています。この情報は、「インフラストラクチャ」にカテゴリ属性を設定しながら、トレースに関与するシステムと連絡先のリストをネストするIODEF EventDataクラスを通じて提供されます。
To provide multi-hop authentication, the originating RID system MUST include a digital signature in the Request sent to all systems in the upstream path. The digital signature from the RID system is performed on the RecordItem class of the IODEF following the XML digital signature specifications from W3C [XMLsig] using a detached signature. The signature MUST be passed to all parties that receive a Request, and each party MUST be able to perform full path validation on the digital signature [RFC5280]. In order to accommodate that requirement, the RecordItem data MUST remain unchanged as a request is passed along between providers and is the only element for which the signature is applied. If additional RecordItems are included in the document at upstream peers, the initial RecordItem entry MUST still remain with the detached signature. The subsequent RecordItem elements may be signed by the peer adding the incident information for the investigation. A second
マルチホップ認証を提供するには、起源のRIDシステムには、上流パスのすべてのシステムに送信されるリクエストにデジタル署名を含める必要があります。RIDシステムからのデジタル署名は、Depched Signatureを使用してW3C [XMLSIG]からのXMLデジタル署名仕様に続くIODEFのRecordITEMクラスで実行されます。署名はリクエストを受け取るすべての関係者に渡す必要があり、各当事者はデジタル署名[RFC5280]でフルパス検証を実行できる必要があります。その要件に対応するために、記録データはプロバイダー間でリクエストが渡され、署名が適用される唯一の要素であるため、変更されていないままでなければなりません。上流のピアのドキュメントに追加の録音が含まれている場合、初期記録のエントリはまだ分離された署名に留まる必要があります。後続の記録要素は、調査のためにインシデント情報を追加するピアによって署名される場合があります。2番目
benefit to this requirement is that the integrity of the filter used is ensured as it is passed to subsequent SPs in the upstream trace of the incident. The trusted PKI also provides the keys used to digitally sign the RecordItem class for a Request to meet the requirement of authenticating the original request. Any host in the path of the trace should be able to verify the digital signature using the trusted PKI.
この要件の利点は、インシデントの上流トレースでその後のSPSに渡されると、使用されるフィルターの完全性が確保されることです。信頼できるPKIは、元のリクエストを認証する要件を満たすリクエストのために、RecordItemクラスにデジタル的に署名するために使用されるキーを提供します。トレースのパスにあるホストは、信頼できるPKIを使用してデジタル署名を検証できる必要があります。
In the case in which an enterprise using RID sends a Request to its provider, the signature from the enterprise MUST be included in the initial request. The SP may generate a new request to send upstream to members of the SP consortium to continue the investigation. If the original request is sent, the originating SP, acting on behalf of the enterprise network under attack, MUST also digitally sign, with an enveloped signature, the full IODEF document to assure the authenticity of the Request. An SP that offers RID as a service may be using its own PKI to secure RID communications between its RID system and the attached enterprise networks. SPs participating in the trace MUST be able to determine the authenticity of RID requests.
RIDを使用しているエンタープライズがプロバイダーにリクエストを送信する場合、企業からの署名を最初のリクエストに含める必要があります。SPは、調査を継続するためにSPコンソーシアムのメンバーに上流を送信するという新しいリクエストを生成する場合があります。元のリクエストが送信された場合、攻撃中のエンタープライズネットワークに代わって行動する発信元SPは、封筒の署名を使用してデジタル的に署名する必要があります。サービスとしてRIDを提供するSPは、独自のPKIを使用して、RIDシステムと添付のエンタープライズネットワーク間のRID通信を保護する場合があります。トレースに参加するSPSは、RID要求の信頼性を決定できる必要があります。
Consortiums are an ideal way to establish a communication web of trust for RID messaging. It should be noted that direct relationships may be ideal for some communications, such as those between a provider of incident information and a subscriber of the incident reports. The consortium could provide centralized resources, such as a PKI, and established guidelines and control requirements for use of RID. The consortium may assist in establishing trust relationships between the participating SPs to achieve the necessary level of cooperation and experience-sharing among the consortium entities. This may be established through PKI certificate policy [RFC3647] reviews to determine the appropriate trust levels between organizations or entities. The consortium may also be used for other purposes to better facilitate communication among SPs in a common area (Internet, region, government, education, private networks, etc.).
コンソーシアムは、RIDメッセージングのための信頼のコミュニケーションウェブを確立する理想的な方法です。直接的な関係は、インシデント情報のプロバイダーとインシデントレポートの加入者との間のコミュニケーションなど、一部の通信に理想的であることに注意する必要があります。コンソーシアムは、PKIなどの集中リソースを提供し、RIDの使用に関するガイドラインと制御要件を確立することができます。コンソーシアムは、参加しているSPS間の信頼関係を確立して、コンソーシアムエンティティ間の必要なレベルの協力と経験共有を達成するのに役立ちます。これは、PKI証明書ポリシー[RFC3647]レビューを通じて確立され、組織またはエンティティ間の適切な信頼レベルを決定することができます。コンソーシアムは、他の目的にも使用され、共通エリア（インターネット、地域、政府、教育、民間ネットワークなど）のSPS間のコミュニケーションをより促進することもできます。
Using a PKI to distribute certificates used by RID systems provides an already established method to link trust relationships between consortiums that peer with SPs belonging to a separate consortium. In other words, consortiums could peer with other consortiums to enable communication of RID messages between the participating SPs. The PKI along with Memorandums of Agreement could be used to link border directories to share public key information in a bridge, a hierarchy, or a single cross-certification relationship.
PKIを使用してRIDシステムで使用される証明書を配布すると、別のコンソーシアムに属するSPSと協力するコンソーシアム間の信頼関係をリンクするためのすでに確立された方法が提供されます。言い換えれば、コンソーシアムは他のコンソーシアムと覗き込んで、参加しているSPS間のRIDメッセージの通信を可能にすることができます。PKIは、覚書と同意の覚書を使用して、ボーダーディレクトリをリンクして、橋の公開情報、階層、または単一の相互認定関係を共有することができます。
Consortiums also need to establish guidelines for each participating SP to adhere to. The RECOMMENDED guidelines include:
コンソーシアムは、参加する各SPのガイドラインを確立する必要があります。推奨されるガイドラインには以下が含まれます。
o Physical and logical practices to protect RID systems;
o RIDシステムを保護するための物理的および論理的実践。
o Network- and application-layer protection for RID systems and communications;
o RIDシステムと通信のためのネットワークおよびアプリケーション層保護。
o Proper use guidelines for RID systems, messages, and requests; and
o RIDシステム、メッセージ、およびリクエストの適切な使用ガイドライン。と
o A PKI, certificate policy, and certification practices statement to provide authentication, integrity, and privacy.
o PKI、証明書ポリシー、および認証慣行の声明は、認証、整合性、プライバシーを提供します。
The functions described for a consortium's role parallel those of a PKI federation. The PKI federations that currently exist are responsible for establishing security guidelines and PKI trust models. The trust models are used to support applications to share information using trusted methods and protocols.
コンソーシアムの役割について説明した機能は、PKI連合の役割と並行しています。現在存在するPKI連合は、セキュリティガイドラインとPKIトラストモデルの確立に責任があります。信頼モデルは、信頼できる方法とプロトコルを使用して情報を共有するためのアプリケーションをサポートするために使用されます。
A PKI can also provide the same level of security for communication between an end entity (enterprise, educational, or government customer network) and the SP.
PKIは、最終エンティティ（エンタープライズ、教育、または政府の顧客ネットワーク）とsp。
Privacy issues raise many concerns when information-sharing is required to achieve the goal of stopping or mitigating the effects of a security incident. The RIDPolicy class is used to automate the enforcement of the privacy concerns listed within this document. The privacy and system use concerns for the system communicating RID messages and other integrated components include the following:
プライバシーの問題は、セキュリティインシデントの影響を停止または緩和するという目標を達成するために情報共有が必要な場合、多くの懸念を引き起こします。Ridpolicyクラスは、このドキュメントにリストされているプライバシーの懸念の施行を自動化するために使用されます。プライバシーとシステムは、RIDメッセージやその他の統合コンポーネントを通信するシステムに懸念を使用します。
Service Provider Concerns:
サービスプロバイダーの懸念：
o Privacy of data monitored and/or stored on Intrusion Detection Systems (IDSs) for attack detection.
o 攻撃検出のために侵入検知システム（IDSS）に監視および/または保存されたデータのプライバシー。
o Privacy of data monitored and stored on systems used to trace traffic across a single network.
o 単一のネットワーク全体のトラフィックを追跡するために使用されるシステムに監視および保存されたデータのプライバシー。
o Privacy of incident information stored on incident management systems participating in RID communications.
o RIDコミュニケーションに参加しているインシデント管理システムに保存されているインシデント情報のプライバシー。
Customer Attached Networks Participating in RID with SP:
SPでRIDに参加している顧客添付ネットワーク：
o Customer networks may include enterprise, educational, government, or other networks attached to an SP participating in RID. Customers should review data handling policies to understand how
o 顧客ネットワークには、RIDに参加しているSPに添付された企業、教育、政府、またはその他のネットワークが含まれる場合があります。顧客はデータ処理ポリシーを確認して、その方法を理解する必要があります
data will be protected by a service provider. This information will enable customers to decide what types of data at what sensitivity level can be shared with service providers. This information could be used at the application layer to establish sharing profiles for entities and groups; see Section 9.6.
データはサービスプロバイダーによって保護されます。この情報により、顧客はサービスプロバイダーと共有できる感度レベルでどのタイプのデータを決定できます。この情報は、アプリケーションレイヤーで使用され、エンティティとグループの共有プロファイルを確立できます。セクション9.6を参照してください。
o Customers should request information on the security and privacy considerations in place by their SP and the consortium of which the SP is a member. Customers should understand if their data were to be forwarded, how it might be sanitized and how it will be protected. In advance of sharing data with their SP, customers should also understand if limitations can be placed on how it will be used.
o 顧客は、SPとSPがメンバーであるコンソーシアムにより、セキュリティとプライバシーの考慮事項に関する情報を要求する必要があります。顧客は、データが転送されるかどうか、どのように消毒されるか、どのように保護されるかを理解する必要があります。SPとデータを共有する前に、顧客はそれがどのように使用されるかに制限があるかどうかも理解する必要があります。
o Customers should be aware that their data can and will be sent to other SPs in order to complete a trace unless an agreement stating otherwise is made in the service level agreements between the customer and SP. Customers considering privacy options may limit the use of this feature if they do not want the data forwarded.
o 顧客は、顧客とSPの間のサービスレベル契約で特に契約が行われない限り、トレースを完了するために、他のSPSにデータを送信できることを認識する必要があります。プライバシーオプションを検討する顧客は、データを転送したくない場合、この機能の使用を制限する場合があります。
Parties Involved in the Attack:
攻撃に関与する当事者：
o Privacy of the identity of a host involved in an attack or any indicators of compromise.
o 攻撃に関与するホストのアイデンティティのプライバシーまたは妥協の指標。
o Privacy of information such as the source and destination used for communication purposes over the monitored or RID-connected network(s).
o 監視されているまたはRID接続されたネットワークを介した通信目的で使用されるソースや目的地などの情報のプライバシー。
o Protection of data from being viewed by intermediate parties in the path of an Request request should be considered.
o リクエストリクエストのパスで中間当事者によって表示されることからのデータの保護を考慮する必要があります。
Consortium Considerations:
コンソーシアムの考慮事項：
o System use restrictions for security incident handling within the local region's definitions of appropriate traffic. When participating in a consortium, appropriate use guidelines should be agreed upon and entered into contracts.
o システムは、地域の適切なトラフィックの定義内でセキュリティインシデント処理に制限を使用します。コンソーシアムに参加する場合、適切な使用ガイドラインを合意し、契約を締結する必要があります。
o System use prohibiting the consortium's participating SPs from inappropriately tracing traffic to locate sources or mitigate traffic unlawfully within the jurisdiction or region.
o コンソーシアムの参加SPSが不適切にトラフィックを追跡することを禁止するシステムの使用は、ソースを見つけたり、管轄権または地域内でトラフィックを違法に緩和したりします。
Inter-Consortium Considerations:
コンソーシア間の考慮事項：
o System use between peering consortiums should consider any government communication regulations that apply between those two regions, such as encryption export and import restrictions.
o ピアリングコンソーシアム間のシステムの使用は、暗号化や輸入制限など、これら2つの地域間に適用される政府のコミュニケーション規制を考慮する必要があります。
o System use between consortiums SHOULD NOT request traffic traces and actions beyond the scope intended and permitted by law or inter-consortium agreements.
o コンソーシアム間のシステムの使用は、法律またはコンソーシアム間契約によって意図および許可されている範囲を超えて、トラフィックトレースとアクションを要求すべきではありません。
o System use between consortiums should consider national boundary issues and request limits in their appropriate system use agreements. Appropriate use should include restrictions to prevent the use of the protocol for limiting or restricting traffic that is otherwise permitted within the country in which the peering consortium resides.
o コンソーシアム間のシステムの使用は、適切なシステム使用契約の国家境界の問題と要求制限を考慮する必要があります。適切な使用には、ピアリングコンソーシアムが存在する国内で許可されているトラフィックを制限または制限するためのプロトコルの使用を防ぐための制限を含める必要があります。
The security and privacy considerations listed above are for the consortiums, SPs, and enterprises to agree upon. The agreed-upon policies may be facilitated through use of the RIDPolicy class and application-layer options. Some privacy considerations are addressed through the RID guidelines for encryption and digital signatures as described in Section 9.1.
上記のセキュリティとプライバシーの考慮事項は、コンソーシアム、SPS、および企業が同意することです。合意されたポリシーは、Ridpolicyクラスとアプリケーションレイヤーオプションを使用することにより促進される場合があります。いくつかのプライバシーに関する考慮事項は、セクション9.1で説明されているように、暗号化およびデジタル署名に関するRIDガイドラインを通じて対処されています。
RID is useful in determining the true source of an incident that traverses multiple networks or to communicate security incidents and automate the response. The information obtained from the investigation may determine the identity of the source host or the SP used by the source of the traffic. It should be noted that the trace mechanism used across a single SP may also raise privacy concerns for the clients of the network. Methods that may raise concern include those that involve storing packets for some length of time in order to trace packets after the fact. Monitoring networks for intrusions and for tracing capabilities also raises concerns for potentially sensitive valid traffic that may be traversing the monitored network. IDSs and single-network tracing are outside of the scope of this document, but the concern should be noted and addressed within the use guidelines of the network. Some IDSs and single-network trace mechanisms attempt to properly address these issues. RID is designed to provide the information needed by any single-network trace mechanism. The provider's choice of a single trace mechanism depends on resources, existing solutions, and local legislation. Privacy concerns in regard to the single-network trace must be dealt with at the client-to-SP level and are out of scope for RID messaging.
RIDは、複数のネットワークを通過するインシデントの真のソースを決定したり、セキュリティインシデントを通信して応答を自動化するのに役立ちます。調査から得られた情報は、ソースホストまたはトラフィックのソースが使用するSPのIDを決定する場合があります。単一のSPで使用されるトレースメカニズムは、ネットワークのクライアントにプライバシーの懸念を引き起こす可能性があることに注意する必要があります。懸念を引き起こす可能性のある方法には、事実の後にパケットを追跡するために、ある程度の長さのパケットを保存することを含むものが含まれます。侵入やトレース機能の監視ネットワークは、監視されているネットワークを通過する可能性のある潜在的に敏感な有効なトラフィックに対する懸念をもたらします。 IDSSと単一ネットワークのトレースは、このドキュメントの範囲外ですが、ネットワークの使用ガイドライン内で懸念を記録し、対処する必要があります。一部のIDSSおよび単一ネットワークトレースメカニズムは、これらの問題に適切に対処しようとします。 RIDは、単一ネットワークのトレースメカニズムに必要な情報を提供するように設計されています。単一のトレースメカニズムのプロバイダーの選択は、リソース、既存のソリューション、およびローカル法に依存します。単一ネットワークのトレースに関するプライバシーの懸念は、クライアントからSPレベルで対処する必要があり、RIDメッセージングの範囲外です。
The identity of the true source of an attack being traced through RID could be sensitive. The true identity listed in a Result message can be protected through the use of encryption [XMLencrypt] enveloping the IODEF document and RID Result information, using the public encryption key of the originating SP. Alternatively, the action taken may be listed without the identity being revealed to the originating SP. The ultimate goal of the RID communication system is to stop or mitigate attack traffic, not to ensure that the identity of the attack traffic is known to involved parties. The SP that
Ridを通して追跡される攻撃の真のソースのアイデンティティは、敏感になる可能性があります。結果メッセージにリストされている真のアイデンティティは、暗号化[XMLENCRYPT]を使用してIODEFドキュメントを包み込み、結果情報をRIDすることで保護できます。あるいは、採用されたアクションは、IDが発生するspに明らかにされることなくリストされる場合があります。RID通信システムの究極の目標は、攻撃トラフィックを停止または軽減することであり、攻撃トラフィックの身元が関係者に対して知られていることを保証することではありません。SPそれ
identifies the source should deal directly with the involved parties and proper authorities in order to determine the guidelines for the release of such information, if it is regarded as sensitive. In some situations, systems used in attacks are compromised by an unknown source and, in turn, are used to attack other systems. In that situation, the reputation of a business or organization may be at stake, and the action taken may be the only additional information reported in the Result message to the originating system. If the security incident is a minor incident, such as a zombie system used in part of a large-scale DDoS attack, ensuring the system is taken off the network until it has been fixed may be sufficient. The decision is left to the system users and consortiums to determine appropriate data to be shared given that the goal of the specification is to provide the appropriate technical options to remain compliant. The textual descriptions should include details of the incident in order to protect the reputation of the unknowing attacker and prevent the need for additional investigation. Local, state, or national laws may dictate the appropriate reporting action for specific security incidents.
情報源は、敏感であると見なされている場合、そのような情報のリリースのガイドラインを決定するために、関与する当事者および適切な当局と直接対処する必要があると特定します。状況によっては、攻撃で使用されるシステムは未知のソースによって危険にさらされ、他のシステムを攻撃するために使用されます。そのような状況では、ビジネスまたは組織の評判が危機にatしている可能性があり、結果メッセージで報告された唯一の追加情報である可能性があります。セキュリティインシデントが、大規模なDDOS攻撃の一部で使用されるゾンビシステムなどの軽微なインシデントである場合、修正されるまでシステムが十分になるまでネットワークから外れていることを確認してください。この決定は、システムユーザーとコンソーシアムに委ねられ、適切なデータを適切な技術オプションを提供するための適切な技術オプションを提供することであることを考慮して、共有される適切なデータを決定します。テキストの説明には、知らない攻撃者の評判を保護し、追加の調査の必要性を防ぐために、事件の詳細を含める必要があります。地方、州、または国の法律は、特定のセキュリティインシデントに対する適切な報告訴訟を決定する場合があります。
Privacy becomes an issue whenever sensitive data traverses a network. For example, if an attack occurred between a specific source and destination, then every SP in the path of the trace becomes aware that the cyber attack occurred. In a targeted attack, it may not be desirable that information about two nation states that are battling a cyber war would become general knowledge to all intermediate parties. However, it is important to allow the traces to take place in order to halt the activity since the health of the networks in the path could also be at stake during the attack. This provides a second argument for allowing the Result message to only include an action taken and not the identity of the offending host. In the case of a Request or Report, where the originating SP is aware of the SP that will receive the request for processing, the free-form text areas of the document could be encrypted [XMLencrypt] using the public key of the destination SP to ensure that no other SP in the path can read the contents. The encryption is accomplished through the W3C [XMLencrypt] specification for encrypting an element.
機密データがネットワークを横断するたびに、プライバシーが問題になります。たとえば、特定のソースと宛先の間で攻撃が発生した場合、トレースの経路にあるすべてのSPがサイバー攻撃が発生したことを認識します。ターゲットを絞った攻撃では、サイバー戦争と戦っている2つの国家に関する情報がすべての中間当事者にとって一般的な知識になることは望ましくないかもしれません。ただし、パス内のネットワークの健康状態も攻撃中に危険にさらされる可能性があるため、アクティビティを停止するために痕跡を行うことが重要です。これは、結果メッセージに、問題のあるホストの身元ではなく、撮影されたアクションのみを含めるようにするための2番目の引数を提供します。リクエストまたはレポートの場合、発信元SPが処理のリクエストを受け取るSPを認識している場合、ドキュメントのフリーフォームテキスト領域を、宛先SPの公開鍵を使用して[XMLENCRYPT]暗号化できます。パス内の他のSPが内容を読み取れないことを確認してください。暗号化は、要素を暗号化するためのW3C [XMLENCRYPT]仕様を介して達成されます。
In some situations, all network traffic of a nation may be granted through a single SP. In that situation, options must support sending Result messages from a downstream peer of that SP. That option provides an additional level of abstraction to hide the identity and the SP of the identified source of the traffic. Legal action may override this technical decision after the trace has taken place, but that is out of the technical scope of this document.
状況によっては、国のすべてのネットワークトラフィックは、単一のspを通じて付与される場合があります。その状況では、オプションはそのspの下流のピアから結果メッセージの送信をサポートする必要があります。そのオプションは、識別されたトラフィックのソースのIDとSPを隠すための追加レベルの抽象化を提供します。法的措置は、トレースが行われた後にこの技術的決定を無効にする可能性がありますが、それはこの文書の技術的範囲から外れています。
Privacy concerns when using an Request message to request action close to the source of valid attack traffic need to be considered. Although the intermediate SPs may relay the request if there is no direct trust relationship to the closest SP to the source, the intermediate SPs do not require the ability to see the contents of the packet or the text description field(s) in the request. This message type does not require any action by the intermediate RID systems, except to relay the packet to the next SP in the path. Therefore, the contents of the request may be encrypted for the destination system. The intermediate SPs only need to know how to direct the request to the manager of the ASN in which the source IP address belongs.
リクエストメッセージを使用して有効な攻撃トラフィックのソースに近いアクションを要求する場合のプライバシーに関する懸念を考慮する必要があります。中間SPSは、ソースに最も近いSPとの直接的な信頼関係がない場合、リクエストを中継する場合がありますが、中間SPは、リクエストでパケットまたはテキスト説明フィールドを見る能力を必要としません。このメッセージタイプは、パスの次のSPにパケットを中継することを除いて、中間RIDシステムによるアクションを必要としません。したがって、リクエストの内容は、宛先システム用に暗号化される場合があります。中間SPSは、ソースIPアドレスが属するASNのマネージャーにリクエストを向ける方法を知る必要があります。
Traces must be legitimate security-related incidents and not used for purposes such as sabotage or censorship. An example of such abuse of the system includes a request to block or rate-limit legitimate traffic to prevent information from being shared between users on the Internet (restricting access to online versions of papers) or restricting access from a competitor's product in order to sabotage a business.
痕跡は、妨害や検閲などの目的には使用されていない正当なセキュリティ関連のインシデントでなければなりません。このようなシステムの不正行為の例には、インターネット上のユーザー間で情報が共有されるのを防ぐための正当なトラフィックをブロックまたはレートに制限する要求（オンラインバージョンの論文へのアクセスを制限する）または妨害するために競合他社の製品からのアクセスを制限するリクエストが含まれます。ビジネス。
Intra-consortium RID communications raise additional issues, especially when the peering consortiums reside in different regions or nations. Request messages and requested actions to mitigate or stop traffic must adhere to the appropriate use guidelines and yet prevent abuse of the system. First, the peering consortiums must identify the types of traffic that can be traced between the borders of the participating SPs of each consortium. The traffic traced should be limited to security-incident-related traffic. Second, the traces permitted within one consortium, if passed to a peering consortium, may infringe upon the peering consortium's freedom-of-information laws. An example would be a consortium in one country permitting a trace of traffic containing objectionable material, outlawed within that country. The RID trace may be a valid use of the system within the confines of that country's network border; however, it may not be permitted to continue across network boundaries where such content is permitted under law. By continuing the trace in another country's network, the trace and response could have the effect of improperly restricting access to data. A continued trace into a second country may break the laws and regulations of that nation. Any such traces MUST cease at the country's border.
特にピアリングコンソーシアムがさまざまな地域や国に存在する場合、Consortium Intry RID Communicationsは追加の問題を提起します。トラフィックを緩和または停止するためのメッセージと要求されたアクションは、適切な使用ガイドラインに準拠しているが、システムの乱用を防ぐ必要があります。第一に、ピアリングコンソーシアムは、各コンソーシアムの参加SPSの境界の間に追跡できるトラフィックの種類を特定する必要があります。トレースされたトラフィックは、セキュリティに関連するトラフィックに限定する必要があります。第二に、1つのコンソーシアム内で許可されている痕跡は、ピアリングコンソーシアムに渡された場合、ピアリングコンソーシアムの情報に基づく法律を侵害する可能性があります。例は、その国内で禁止されている、好ましくない資料を含む交通の痕跡を許可する1つの国のコンソーシアムです。 RIDトレースは、その国のネットワーク国境の範囲内のシステムの有効な使用である可能性があります。ただし、法律の下でそのようなコンテンツが許可されているネットワーク境界を越えて継続することは許可されない場合があります。他の国のネットワークのトレースを継続することにより、トレースと応答は、データへのアクセスを不適切に制限する効果をもたらす可能性があります。第二国への継続的な痕跡は、その国の法律と規制を破るかもしれません。そのような痕跡は、国の国境で止まらなければなりません。
The privacy concerns listed in this section address issues among the trusted parties involved in a trace within an SP, a RID consortium, and peering RID consortiums. Data used for RID communications must also be protected from parties that are not trusted. This protection is provided through the authentication and encryption of documents as
このセクションに記載されているプライバシーの懸念は、SP、Rid Consortium、Peering Ridコンソーシアム内の痕跡に関与する信頼できる当事者の間で問題に対処しています。RID通信に使用されるデータは、信頼されていない当事者からも保護する必要があります。この保護は、ドキュメントの認証と暗号化を通じて提供されます。
they traverse the path of trusted servers and through the local security controls in place for the incident management systems. Each RID system MUST perform a bidirectional authentication when sending a RID message and use the public encryption key of the upstream or downstream peer to send a message or document over the network. This means that the document is decrypted and re-encrypted at each RID system via TLS over a transport protocol such as [RFC6546]. The RID messages may be decrypted at each RID system in order to properly process the request or relay the information. Today's processing power is more than sufficient to handle the minimal burden of encrypting and decrypting relatively small typical RID messages.
彼らは、インシデント管理システムのために、信頼できるサーバーのパスを横断し、現地のセキュリティ制御を介して配置されます。各RIDシステムは、RIDメッセージを送信するときに双方向認証を実行し、上流または下流のピアのパブリック暗号化キーを使用して、ネットワーク上にメッセージまたはドキュメントを送信する必要があります。これは、[RFC6546]などの輸送プロトコルを介して、TLSを介して各RIDシステムでドキュメントが復号化され、再クリックされることを意味します。RIDメッセージは、要求を適切に処理するか、情報をリレーするために、各RIDシステムで復号化される場合があります。今日の処理能力は、暗号化と比較的小さな典型的なRIDメッセージの最小限の負担を処理するのに十分すぎるほどです。
The application layer can be used to establish workflows and rulesets specific to sharing profiles for entities or consortiums. The profiles can leverage sharing agreements to restrict data types or classifications of data that are shared. The level of information or classification of data shared with any entity may be based on protection levels offered by the receiving entity and periodic validation of those controls. The profile may also indicate how far information can be shared according to the entity and data type. The profile may also indicate whether requests to share data from an entity must go directly to that entity.
アプリケーションレイヤーを使用して、エンティティまたはコンソーシアムのプロファイルを共有することに固有のワークフローとルールセットを確立できます。プロファイルは、共有契約を活用して、共有されているデータのデータ型または分類を制限できます。任意のエンティティと共有されるデータの情報または分類は、受信エンティティによって提供される保護レベルとそれらのコントロールの定期的な検証に基づいている場合があります。プロファイルは、エンティティとデータ型に従って情報をどこまで共有できるかを示している場合があります。プロファイルは、エンティティからのデータを共有するリクエストがそのエンティティに直接移動する必要があるかどうかを示している場合があります。
In some cases, pre-defined sharing profiles will be possible. These include any use case where an agreement is in place in advance of sharing. Examples may be between clients and SPs, entities such as partners, or consortiums. There may be other cases when sharing profiles may not be established in advance, such as an organization dealing with an incident who requires assistance from an entity that it has not worked with before. An organization may want to establish sharing profiles specific to possible user groups to prepare for possible incident scenarios. The user groups could include business partners, industry peers, service providers, experts not part of a service provider, law enforcement, or regulatory reporting bodies.
場合によっては、事前に定義された共有プロファイルが可能になります。これらには、共有の前に契約が整っている場合の使用ケースが含まれます。例は、クライアントとSPS、パートナーなどのエンティティ、またはコンソーシアムの間にある場合があります。以前に協力していないエンティティからの支援を必要とするインシデントを扱う組織など、プロファイルを事前に確立しない場合がある場合は、他のケースがあります。組織は、可能なインシデントシナリオに備えるために、可能なユーザーグループに固有の共有プロファイルを確立したい場合があります。ユーザーグループには、ビジネスパートナー、業界のピア、サービスプロバイダー、サービスプロバイダー、法執行機関、または規制報告機関の一部ではない専門家が含まれます。
Workflows to approve transactions may be specific to sharing profiles and data types. Application developers should include capabilities to enable these decision points for users of the system.
トランザクションを承認するワークフローは、プロファイルとデータ型を共有することに固有の場合があります。アプリケーション開発者は、システムのユーザーにこれらの決定ポイントを有効にする機能を含める必要があります。
Any expectations between entities to preserve the weight and admissibility of evidence should be handled at the policy and agreement level. A sharing profile may include notes or an indicator for approvers in workflows to reflect if such agreements exist.
証拠の重みと許容性を維持するためのエンティティ間の期待は、ポリシーと契約レベルで処理されるべきです。共有プロファイルには、ワークフローの承認者がそのような契約が存在するかどうかを反映するためのメモまたは指標が含まれる場合があります。
RID has many security requirements and considerations built into the design of the protocol, several of which are described in the Security Requirements section. For a complete view of security, considerations include the availability, confidentiality, and integrity concerns for the transport, storage, and exchange of information.
RIDには、プロトコルの設計に組み込まれた多くのセキュリティ要件と考慮事項があり、そのいくつかはセキュリティ要件セクションで説明されています。セキュリティの完全な見解には、考慮事項には、輸送、保管、情報交換の可用性、機密性、および整合性の懸念が含まれます。
Protected tunnels between systems accepting RID communications are used to provide confidentiality, integrity, authenticity, and privacy for the data at the transport layer. Encryption and digital signatures are also used at the IODEF document level through RID options to provide confidentiality, integrity, authenticity, privacy and traceability of the document contents at the application layer. Trust relationships are based on PKI and the comparison/validation of security controls for the incident management systems communicating via RID. Trust levels can be established in cross-certification processes where entities compare PKI policies that include the specific management and handling of an entity's PKI and certificates issued under that policy. [RFC3647] defines an Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework that may be used in the comparison of policies to establish trust levels and agreements between entities, an entity and a consortium, and consortiums. The agreements SHOULD consider key management practices including the ability to perform path validation on certificates [RFC5280], key distribution techniques [RFC2585], and Certificate Authority and Registration Authority management practices.
RID通信を受け入れるシステム間の保護されたトンネルは、輸送層でのデータの機密性、完全性、信頼性、およびプライバシーを提供するために使用されます。暗号化とデジタル署名は、IODEFドキュメントレベルでRIDオプションを介して使用され、アプリケーションレイヤーのドキュメントコンテンツの機密性、整合性、信頼性、プライバシー、およびトレーサビリティを提供します。信頼関係は、PKIと、RIDを介して通信するインシデント管理システムのセキュリティ制御の比較/検証に基づいています。信頼レベルは、エンティティの特定の管理とエンティティのPKIの処理、およびそのポリシーに基づいて発行された証明書を含むPKIポリシーを比較する相互認証プロセスで確立できます。 [RFC3647]は、インターネットX.509の公開キーインフラストラクチャ証明書ポリシーと認証慣行のフレームワークを定義します。これは、エンティティ、エンティティとコンソーシアム、およびコンソーシアム間の信頼レベルと契約を確立するためのポリシーの比較に使用される可能性があります。契約では、証明書[RFC5280]、主要な配布手法[RFC2585]、および認証局と登録機関の管理慣行でパス検証を実行する能力を含む主要な管理慣行を考慮する必要があります。
The agreements between entities SHOULD also include a common understanding of the usage of RID security, policy, and privacy options discussed in both the Security Requirements and Security Considerations sections. The formality, requirements, and complexity of the agreements for the certificate policy, practices, supporting infrastructure, and the use of RID options SHOULD be decided by the entities or consortiums creating those agreements.
エンティティ間の契約には、セキュリティ要件とセキュリティに関する考慮事項の両方で議論されているRIDセキュリティ、ポリシー、およびプライバシーオプションの使用に関する一般的な理解も含める必要があります。証明書ポリシー、慣行、インフラストラクチャのサポート、およびRIDオプションの使用に関する契約の形式、要件、および複雑さは、それらの契約を作成するエンティティまたはコンソーシアムによって決定されるべきです。
The Node class identifies a host or network device. This document reuses the definition of Node from the IODEF specification [RFC5070], Section 3.16. However, that document did not clearly specify whether a NodeName could be an Internationalized Domain Name (IDN). RID systems MUST treat the NodeName class as a domain name slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName class. If they do so, the UTF-8 representation of the domain name MUST be used, i.e., all of the domain name's labels MUST be U-labels
ノードクラスは、ホストまたはネットワークデバイスを識別します。このドキュメントは、IODEF仕様[RFC5070]、セクション3.16からのノードの定義を再利用します。ただし、そのドキュメントでは、Nodenameが国際化されたドメイン名（IDN）になる可能性があるかどうかを明確に指定しませんでした。RIDシステムは、nodenameクラスをドメイン名スロット[RFC5890]として扱う必要があります。RIDシステムは、NodenameクラスでIDNSをサポートする必要があります。そうすると、ドメイン名のUTF-8表現を使用する必要があります。つまり、ドメイン名のすべてのラベルはUラベルでなければなりません
expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be used. An application communicating via RID can convert between A-labels and U-labels by using the Punycode encoding [RFC3492] for A-labels as described in the protocol specification for Internationalized Domain Names in Applications [RFC5891].
UTF-8またはNR-LDHラベル[RFC5890]で発現しています。Aラベルを使用してはなりません。RIDを介して通信するアプリケーションは、アプリケーション[RFC5891]の国際化ドメイン名のプロトコル仕様で説明されているように、Aラベルに[RFC3492]をエンコードする[RFC3492]を使用することにより、AラベルとUラベル間で変換できます。
This document uses URNs to describe XML namespaces and XML schemas [XMLschema] conforming to a registry mechanism described in [RFC3688].
このドキュメントでは、urnsを使用して、XMLネームスペースとXMLスキーマ[XMLSchema]を記述し、[RFC3688]に記載されているレジストリメカニズムに準拠しています。
Registration request for the iodef-rid namespace:
iodef-ridネームスペースの登録リクエスト：
URI: urn:ietf:params:xml:ns:iodef-rid-2.0
Registrant Contact: IESG.
登録者の連絡先：IESG。
XML: None. Namespace URIs do not represent an XML specification.
XML：なし。名前空間URIはXML仕様を表していません。
Registration request for the iodef-rid XML schema:
IODEF-RID XMLスキーマの登録リクエスト：
URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Registrant Contact: IESG.
登録者の連絡先：IESG。
XML: See Section 8, "RID Schema Definition", of this document.
XML：このドキュメントのセクション8「Rid Schema Definition」を参照してください。
The following registry has been created and is now managed by IANA:
次のレジストリが作成され、現在IANAによって管理されています。
Name of the registry: "XML Schemas Exchanged via RID"
レジストリの名前：「rid経由で交換されたxmlスキーマ」
Namespace details: A registry entry for an XML Schema Transferred via RID consists of:
名前空間の詳細：RIDを介して転送されるXMLスキーマのレジストリエントリは次のとおりです。
Schema Name: A short string that represents the schema referenced. This value is for reference only in the table. The version of the schema MUST be included in this string to allow for multiple versions of the same specification to be in the registry.
スキーマ名：参照されたスキーマを表す短い文字列。この値は、テーブル内でのみ参照用です。スキーマのバージョンをこの文字列に含めて、同じ仕様の複数のバージョンがレジストリにあることを可能にする必要があります。
Version: The version of the registered XML schema. The version is a string that SHOULD be formatted as numbers separated by a '.' (period) character.
バージョン：登録されたXMLスキーマのバージョン。バージョンは、 '。'で区切られた数字としてフォーマットする必要がある文字列です。（期間）文字。
Namespace: The namespace of the referenced XML schema. This is represented in the RID ReportSchema class in the XMLSchemaID attribute as an enumerated value is represented by a URN or URI.
名前空間：参照されたXMLスキーマの名前空間。これは、列挙された値としてXMLSchemaid属性のRID Reportschemaクラスで表されます。
Specification URI: A URI [RFC3986] from which the registered specification can be obtained. The specification MUST be publicly available from this URI.
仕様URI：登録仕様を取得できるURI [RFC3986]。仕様は、このURIから公開されている必要があります。
Reference: The reference to the document that describes the schema.
参照：スキーマを説明するドキュメントへの参照。
Information that must be provided to assign a new value: The above list of information.
新しい値を割り当てるために提供する必要がある情報：上記の情報リスト。
Fields to record in the registry: Schema Name, Version, Namespace, Specification URI, Reference
レジストリに記録するフィールド：スキーマ名、バージョン、名前空間、仕様URI、リファレンス
Initial registry contents: See Section 5.6.1.
初期レジストリの内容：セクション5.6.1を参照してください。
Allocation Policy: Expert Review [RFC5226] and Specification Required [RFC5226].
割り当てポリシー：専門家のレビュー[RFC5226]および仕様が必要である[RFC5226]。
The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to retrieve the XML schema specification from the provided URI in order to check the public availability of the specification and verify the correctness of the URI. An important responsibility of the Designated Expert is to ensure that the XML schema is appropriate for use in RID.
指定された専門家は、そのようなWGが存在する場合（たとえば、ワーキンググループのメーリングリストへの電子メールを介して）、マイル（マネージドインシデントの軽量交換）ワーキンググループまたはその後継者に相談することが期待されます。指定された専門家は、仕様の公開可用性を確認し、URIの正確性を確認するために、提供されたURIからXMLスキーマ仕様を取得することが期待されています。指定された専門家の重要な責任は、XMLスキーマがRIDでの使用に適していることを確認することです。
The following registry has been created and is now managed by IANA:
次のレジストリが作成され、現在IANAによって管理されています。
Name of the registry: "RID Enumeration List"
レジストリの名前：「RID列挙リスト」
The registry is intended to enable enumeration value additions to attributes in the iodef-rid XML schema.
レジストリは、IODEF-RID XMLスキーマの属性への列挙値の追加を有効にすることを目的としています。
Fields to record in the registry: Attribute Name, Attribute Value, Description, Reference
レジストリに記録するフィールド：属性名、属性値、説明、リファレンス
Initial registry content: none.
初期レジストリコンテンツ：なし。
Allocation Policy: Expert Review [RFC5226]
割り当てポリシー：エキスパートレビュー[RFC5226]
The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to review the request and validate the appropriateness of the enumeration for the attribute. If a specification is associated with the request, it MUST be reviewed by the Designated Expert.
指定された専門家は、そのようなWGが存在する場合（たとえば、ワーキンググループのメーリングリストへの電子メールを介して）、マイル（マネージドインシデントの軽量交換）ワーキンググループまたはその後継者に相談することが期待されます。指定された専門家は、要求を確認し、属性の列挙の適切性を検証することが期待されています。仕様がリクエストに関連付けられている場合、指定された専門家がレビューする必要があります。
Security incidents have always been difficult to trace as a result of spoofed sources, resource limitations, and bandwidth utilization problems. Incident response is often slow even when the IP address is known to be valid because of the resources required to notify the responsible party of the attack and then to stop or mitigate the attack traffic. Methods to identify and trace attacks near real time are essential to thwarting attack attempts. SPs need policies and automated methods to combat the hacker's efforts. SPs need automated monitoring and response capabilities to identify and trace attacks quickly without resource-intensive side effects. Integration with a centralized communication system to coordinate the detection, tracing, and identification of attack sources on a single network is essential. RID provides a way to integrate SP resources for each aspect of attack detection, tracing, and source identification and extends the communication capabilities among SPs. The communication is accomplished through the use of flexible IODEF XML-based documents passed between incident-handling systems or RID systems. A Request is communicated to an upstream SP and may result in an upstream trace or in an action to stop or mitigate the attack traffic. The messages are communicated among peers with security inherent to the RID messaging scheme provided through existing standards such as XML encryption and digital signatures. Policy information is carried in the RID message itself through the use of the RIDPolicy. RID provides the timely communication among SPs, which is essential for incident handling.
セキュリティインシデントは、スプーフィングされたソース、リソースの制限、帯域幅の利用問題の結果として、常に追跡することが困難でした。攻撃の責任者に通知し、攻撃トラフィックを停止または軽減するために必要なリソースのためにIPアドレスが有効であることが知られている場合でも、インシデント応答が遅くなることがよくあります。攻撃をリアルタイムに近づけて追跡する方法は、攻撃の試みを妨害するために不可欠です。 SPSには、ハッカーの努力に対抗するためのポリシーと自動化された方法が必要です。 SPSは、リソース集約的な副作用なしに攻撃を迅速に識別および追跡するための自動監視と応答機能が必要です。単一のネットワーク上の攻撃ソースの検出、追跡、および識別を調整するための集中通信システムとの統合が不可欠です。 RIDは、攻撃検出、トレース、ソース識別の各側面にSPリソースを統合し、SPS間の通信機能を拡張する方法を提供します。通信は、インシデント処理システムまたはRIDシステム間で渡される柔軟なIODEF XMLベースのドキュメントを使用することで実現されます。リクエストは上流のSPに伝えられ、上流のトレースまたは攻撃トラフィックを停止または軽減するアクションにつながる可能性があります。メッセージは、XML暗号化やデジタル署名などの既存の標準を通じて提供されるRIDメッセージングスキームに固有のセキュリティを持つピア間で伝えられます。ポリシー情報は、Ridpolicyを使用してRIDメッセージ自体に伝えられます。 RIDは、SPS間のタイムリーな通信を提供します。これは、インシデント処理に不可欠です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[RFC2585] Housley、R。およびP. Hoffman、「インターネットX.509公開キーインフラストラクチャ運用プロトコル：FTPおよびHTTP」、RFC 2585、1999年5月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake、D.、Reagle、J。、およびD. Solo、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、RFC 3275、2002年3月。
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3470] Hollenbeck、S.、Rose、M。、およびL. Masinter、「IETFプロトコル内の拡張マークアップ言語（XML）の使用に関するガイドライン」、BCP 70、RFC 3470、2003年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：Applications（IDNA）の国際化ドメイン名のUnicodeのブートストリングエンコーディング」、RFC 3492、2003年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC4051] Eastlake, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051] EastLake、D。、「追加のXMLセキュリティユニフォームリソース識別子（URIS）」、RFC 4051、2005年4月。
[RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC4279] Eronen、P。およびH. Tschofenig、「輸送層セキュリティのための事前共有キーヒルスーツ（TLS）」、RFC 4279、2005年12月。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「インシデントオブジェクト説明交換形式」、RFC 5070、2007年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開キーインフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646] Phillips、A。およびM. Davis、「言語を識別するためのタグ」、BCP 47、RFC 5646、2009年9月。
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010.
[RFC5755] Farrell、S.、Housley、R。、およびS. Turner、「認証のためのインターネット属性証明書プロファイル」、RFC 5755、2010年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、2010年8月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]クレンシン、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、2010年8月。
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.
[RFC6546] Trammell、B。、「HTTP/TLSを介したリアルタイムのネットワーク間防衛（RID）メッセージの輸送」、RFC 6546、2012年4月。
[XML1.0] Bray, T., Maler, E., Paoli, J., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0", W3C Recommendation XML 1.0, November 2008, <http://www.w3.org/TR/xml/>.
[XML1.0] Bray、T.、Maler、E.、Paoli、J.、Sperberg-Mcqueen、C。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0」、W3C推奨XML 1.0、2008年11月、<http://www.w3.org/tr/xml/>。
[XMLCanon] Boyer, J., "Canonical XML 1.0", W3C Recommendation 1.0, December 2001, <http://www.w3.org/TR/xml-c14n>.
[Xmlcanon] Boyer、J。、「Canonical XML 1.0」、W3C推奨1.0、2001年12月、<http://www.w3.org/tr/xml-c14n>。
[XMLPath] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, December 2010, <http://www.w3.org/TR/xpath20/>.
[XMLPATH] Berglund、A.、Boag、S.、Chamberlin、D.、Fernandez、M.、Kay、M.、Robie、J。、およびJ. Simeon、「XML Schema Part 1：Structures」、W3C推奨2番目版、2010年12月、<http://www.w3.org/tr/xpath20/>。
[XMLSigBP] Hirsch, F. and P. Datta, "XML-Signature Best Practices", W3C Recommendation, August 2011, <http://www.w3.org/TR/xmldsig-bestpractices/>.
[XMLSIGBP] Hirsch、F。およびP. Datta、「XML-Signature Best Practices」、W3C推奨、2011年8月、<http://www.w3.org/tr/xmldsig-bestpractices/>。
[XMLencrypt] Imaura, T., Dillaway, B., and E. Simon, "XML Encryption Syntax and Processing", W3C Recommendation, December 2002, <http://www.w3.org/TR/xmlenc-core/>.
[XMLENCRYPT] Imaura、T.、Dillaway、B。、およびE. Simon、「XML暗号化構文と処理」、W3C推奨、2002年12月、<http://www.w3.org/tr/xmlenc-core/>。
[XMLschema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation Second Edition, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[xmlschema]トンプソン、H。、ビーチ、D。、マロニー、M。、およびN.メンデルソン、「XMLスキーマパート1：構造」、W3C推奨第2版、2004年10月、<http://www.w3.org/tr/xmlschema-1/>。
[XMLsig] Bartel, M., Boyer, J., Fox, B., LaMaccia, B., and E. Simon, "XML-Signature Syntax and Processing", W3C Recommendation Second Edition, June 2008, <http://www.w3.org/TR/xmldsig-core/>.
[Xmlsig] Bartel、M.、Boyer、J.、Fox、B.、Lamaccia、B。、およびE. Simon、「XML-Signature Syntax and Processing」、W3C推奨第2版、2008年6月、<http：//www.w3.org/tr/xmldsig-core/>。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（AS）」、BCP 6、RFC 1930、1996年3月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[RFC3647] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「インターネットX.509公開キーインフラストラクチャ証明書ポリシーと認証慣行フレームワーク」、RFC 3647、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6045, November 2010.
[RFC6045] Moriarty、K。、「リアルタイム間のネットワーク間防衛（RID）」、RFC 6045、2010年11月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティ上の考慮事項」、RFC 6194、2011年3月。
[XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thomson, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation , December 2009, <http://www.w3.org/TR/xml-names/>.
[Xmlnames] Bray、T.、Hollander、D.、Layman、A.、Tobin、R.、およびH. Thomson、「XML 1.0の名前空間（第3版）」、W3C推奨、2009年12月、<http：//www.w3.org/tr/xml-names/>。
Many thanks to colleagues and the Internet community for reviewing and commenting on the document as well as providing recommendations to improve, simplify, and secure the protocol: Steve Bellovin, David Black, Harold Booth, Paul Cichonski, Robert K. Cunningham, Roman Danyliw, Yuri Demchenko, Sandra G. Dykes, Stephen Farrell, Katherine Goodier, Cynthia D. McLain, Thomas Millar, Jean-Francois Morfin, Stephen Northcutt, Damir Rajnovic, Tony Rutkowski, Peter Saint-Andre, Jeffrey Schiller, Robert Sparks, William Streilein, Richard Struse, Tony Tauber, Brian Trammell, Sean Turner, Iljitsch van Beijnum, and David Waltermire.
ドキュメントをレビューしてコメントし、プロトコルを改善、簡素化、保護するための推奨事項を提供してくれた同僚とインターネットコミュニティに感謝します：Steve Bellovin、David Black、Harold Booth、Paul Cichonski、Robert K. Cunningham、Roman Danyliw、ユーリ・デムチェンコ、サンドラ・G・ダイクス、スティーブン・ファレル、キャサリン・グッディア、シンシア・D・マクレイン、トーマス・ミラー、ジャン・フランコ・モーフィン、スティーブン・ノースカット、ダミール・ラジノビッチ、トニー・ラトコフスキー、ピーター・サン・アンドレリチャード・ストラーズ、トニー・タウバー、ブライアン・トラメル、ショーン・ターナー、イルジッチ・ヴァン・ベイナム、デビッド・ウォルターティール。
Author's Address
著者の連絡先
Kathleen M. Moriarty EMC Corporation 176 South Street Hopkinton, MA United States
Kathleen M. Moriarty EMC Corporation 176サウスストリートホプキントン、マサチューセッツ州米国
EMail: Kathleen.Moriarty@emc.com