[要約] RFC 7203は、IODEFの拡張であるサイバーセキュリティ情報の構造化に関するものであり、その目的はインシデントオブジェクトの記述と交換を容易にすることです。
Internet Engineering Task Force (IETF) T. Takahashi
Request for Comments: 7203 NICT
Category: Standards Track K. Landfield
ISSN: 2070-1721 McAfee
Y. Kadobayashi
NAIST
April 2014
An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information
構造化サイバーセキュリティ情報のためのインシデントオブジェクト記述交換フォーマット（IODEF）拡張
Abstract
概要
This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information.
このドキュメントは、RFC 5070で定義されたインシデントオブジェクト記述交換フォーマット（IODEF）を拡張して、組織のセキュリティ専門家の間で豊富なサイバーセキュリティ情報を交換し、その運用を容易にします。識別子やXMLベースの情報など、構造化された情報を一貫して埋め込むための明確なパターンを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7203.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7203で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Applicability ...................................................4
4. Extension Definition ............................................5
4.1. IANA Table for Structured Cybersecurity Information ........5
4.2. Extended Data Type: XMLDATA ................................6
4.3. Extending IODEF ............................................6
4.4. Basic Structure of the Extension Classes ...................8
4.5. Defining Extension Classes .................................9
4.5.1. AttackPattern .......................................9
4.5.2. Platform ...........................................10
4.5.3. Vulnerability ......................................11
4.5.4. Scoring ............................................11
4.5.5. Weakness ...........................................12
4.5.6. EventReport ........................................13
4.5.7. Verification .......................................14
4.5.8. Remediation ........................................15
5. Mandatory-to-Implement Features ................................15
5.1. An Example XML Document ...................................16
5.2. An XML Schema for the Extension ...........................18
6. Security Considerations ........................................20
6.1. Transport-Specific Concerns ...............................20
6.2. Protection of Sensitive and Private Information ...........21
6.3. Application and Server Security ...........................22
7. IANA Considerations ............................................22
8. Acknowledgments ................................................24
9. References .....................................................24
9.1. Normative References ......................................24
9.2. Informative References ....................................26
The number of incidents in cyber society is growing day by day. Incident information needs to be reported, exchanged, and shared among organizations in order to cope with the situation. IODEF is one of the tools already in use that enables such an exchange.
サイバー社会におけるインシデントの数は日々増加しています。状況に対処するために、インシデント情報を報告、交換、および組織間で共有する必要があります。 IODEFは、そのような交換を可能にするすでに使用されているツールの1つです。
To more efficiently run security operations, information exchanged between organizations needs to be machine readable. IODEF provides a means to describe the incident information, but it often needs to include various non-structured types of incident-related data in order to convey more specific details about what is occurring. Further structure within IODEF increases the machine-readability of the document, thus providing a means for better automating certain security operations.
セキュリティ操作をより効率的に実行するには、組織間で交換される情報が機械可読である必要があります。 IODEFはインシデント情報を説明する手段を提供しますが、発生していることに関するより具体的な詳細を伝えるために、構造化されていないさまざまなタイプのインシデント関連データを含める必要があることがよくあります。 IODEF内のさらなる構造により、ドキュメントの機械可読性が向上し、特定のセキュリティ操作をより自動化する手段が提供されます。
Within the security community there exist various means for specifying structured descriptions of cybersecurity information, such as [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF]. In this context, cybersecurity information encompasses a broad range of structured data representation types that may be used to assess or report on the security posture of an asset or set of assets. Such structured descriptions facilitate a better understanding of an incident while enabling more streamlined automated security operations. Because of this, it would be beneficial to embed and convey these types of information inside IODEF documents.
セキュリティコミュニティ内には、[CAPEC]、[CCE]、[CCSS]、[CEE]、[CPE]、[CVE]、[CVRF]、[CVSS]など、サイバーセキュリティ情報の構造化された説明を指定するためのさまざまな手段があります。 [CWE]、[CWSS]、[MAEC]、[OCIL]、[OVAL]、[SCAP]、および[XCCDF]。このコンテキストでは、サイバーセキュリティ情報には、1つまたは複数の資産のセキュリティ状況を評価または報告するために使用できる幅広い構造化データ表現タイプが含まれます。このような構造化された説明により、インシデントの理解が深まり、自動化されたセキュリティ操作がより合理化されます。このため、IODEFドキュメント内にこれらのタイプの情報を埋め込み、伝達することは有益です。
This document extends IODEF to embed and convey various types of structured information. Since IODEF defines a flexible and extensible format and supports a granular level of specificity, this document defines an extension to IODEF instead of defining a new report format. For clarity, and to eliminate duplication, only the additional structures necessary for describing the exchange of such structured information are provided.
このドキュメントは、IODEFを拡張して、さまざまなタイプの構造化情報を埋め込み、伝達します。 IODEFは柔軟で拡張可能な形式を定義し、詳細なレベルの特異性をサポートするため、このドキュメントでは、新しいレポート形式を定義する代わりにIODEFへの拡張を定義します。明確にするため、および重複を排除するために、そのような構造化された情報の交換を説明するために必要な追加の構造のみが提供されています。
The terminology used in this document follows the terminology defined in RFC 5070 [RFC5070].
このドキュメントで使用されている用語は、RFC 5070 [RFC5070]で定義されている用語に従います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
To maintain awareness of the continually changing security threat landscape, organizations need to exchange cybersecurity information, which includes the following information: attack pattern, platform information, vulnerability and weakness, countermeasure instruction, computer event logs, and severity assessments. IODEF provides a scheme to describe and exchange such information among interested parties. However, it does not define the detailed formats to specify such information.
絶え間なく変化するセキュリティ脅威の状況についての認識を維持するために、組織は次の情報を含むサイバーセキュリティ情報を交換する必要があります：攻撃パターン、プラットフォーム情報、脆弱性と脆弱性、対策命令、コンピューターイベントログ、および重大度評価。 IODEFは、関係者間でそのような情報を記述および交換するためのスキームを提供します。ただし、そのような情報を指定するための詳細な形式は定義していません。
There already exist structured and detailed formats for describing these types of information that can be used in facilitating such an exchange. They include [CAPEC], [CCE], [CCSS], [CEE], [CPE], [CVE], [CVRF], [CVSS], [CWE], [CWSS], [MAEC], [OCIL], [OVAL], [SCAP], and [XCCDF]. By embedding them into the IODEF document, the document can convey more detailed context information to the receivers, and the document can be easily reused.
そのような交換を容易にするために使用できるこれらのタイプの情報を記述するための構造化された詳細なフォーマットがすでに存在します。 [CAPEC]、[CCE]、[CCSS]、[CEE]、[CPE]、[CVE]、[CVRF]、[CVSS]、[CWE]、[CWSS]、[MAEC]、[OCIL]、 [OVAL]、[SCAP]、および[XCCDF]。それらをIODEFドキュメントに埋め込むことにより、ドキュメントはより詳細なコンテキスト情報をレシーバーに伝えることができ、ドキュメントは簡単に再利用できます。
The use of formats for structured information facilitates more advanced security operations on the receiver side. Since the information is machine readable, the data can be processed by computers, thus allowing better automation of security operations.
構造化情報にフォーマットを使用すると、受信側でのより高度なセキュリティ操作が容易になります。情報は機械で読み取り可能であるため、データをコンピューターで処理できるため、セキュリティ操作の自動化が向上します。
For instance, an organization wishing to report a security incident wants to describe what vulnerability was exploited. In this case, the sender can simply use IODEF, where an XML-based [XML1.0] attack pattern record that follows the syntax and vocabulary defined by an industry specification is embedded, instead of describing everything in free-form text. The receiver can identify the needed details of the attack pattern by looking up some of the XML tags defined by the specification. The receiver can accumulate the attack pattern record in its database and could distribute it to the interested parties as needed, all without requiring human intervention.
たとえば、セキュリティインシデントを報告したい組織は、どの脆弱性が悪用されたかを説明したいと考えています。この場合、送信者はIODEFを簡単に使用できます。自由形式のテキストですべてを記述する代わりに、業界仕様で定義された構文と語彙に従うXMLベースの[XML1.0]攻撃パターンレコードが埋め込まれます。受信者は、仕様で定義されているXMLタグの一部を検索することにより、必要な攻撃パターンの詳細を特定できます。受信者は攻撃パターンのレコードをデータベースに蓄積し、必要に応じて関係者に配布することができます。すべて人の介入は不要です。
In another example, an administrator is investigating an incident and has detected a configuration problem that he wishes to share with a partner organization to prevent the same event from occurring at the partner organization. To confirm that the configuration was in fact vulnerable, he uses an internal repository to access configuration information that was gathered prior to the initial attack and that is specific to a new vulnerability alert. He uses this information to automatically generate an XML-based software configuration description, embed it in an IODEF document, and send the resulting IODEF document to the partner organization.
別の例では、管理者がインシデントを調査しており、パートナー組織と共有して同じイベントがパートナー組織で発生しないようにしたい構成の問題を検出しました。構成が実際に脆弱であることを確認するために、彼は内部リポジトリを使用して、最初の攻撃の前に収集された、新しい脆弱性アラートに固有の構成情報にアクセスします。彼はこの情報を使用して、XMLベースのソフトウェア構成記述を自動的に生成し、それをIODEFドキュメントに埋め込み、結果のIODEFドキュメントをパートナー組織に送信します。
This document extends IODEF to embed structured information by introducing new classes that can be embedded consistently inside an IODEF document as element contents of the AdditionalData and RecordItem classes [RFC5070].
このドキュメントは、IODEFを拡張して、IODEFドキュメント内に一貫して埋め込むことができる新しいクラスを、AdditionalDataクラスとRecordItemクラス[RFC5070]の要素コンテンツとして導入することにより、構造化情報を埋め込むようにしています。
This extension embeds structured cybersecurity information (SCI) defined by other specifications. The list of supported specifications is managed by IANA, and this document defines the needed fields for the list's entry.
この拡張機能は、他の仕様で定義された構造化サイバーセキュリティ情報（SCI）を埋め込みます。サポートされている仕様のリストはIANAによって管理されており、このドキュメントではリストのエントリに必要なフィールドを定義しています。
Each entry for each specification has the namespace [XMLNames], specification name, version, reference URI, and applicable classes. Arbitrary URIs that may help readers understand the specification could be embedded inside the Reference URI field, but it is recommended that a standard/informational URI describing the specification be prepared and embedded here.
各仕様の各エントリには、名前空間[XMLNames]、仕様名、バージョン、参照URI、および適用可能なクラスがあります。読者が仕様を理解するのに役立つ可能性のある任意のURIは、参照URIフィールド内に埋め込むことができますが、仕様を説明する標準/情報URIを用意し、ここに埋め込むことをお勧めします。
The initial IANA table has only one entry, as follows:
次のように、初期IANAテーブルには1つのエントリしかありません。
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Version: 1.2
Reference URI: <http://standards.ieee.org/develop
/indconn/icsg/mmdef.html>,
<http://grouper.ieee.org/groups
/malware/malwg/Schema1.2/>
Applicable Classes: AttackPattern
Note that the specification was developed by The Institute of Electrical and Electronics Engineers, Incorporated (IEEE), through the Industry Connections Security Group (ICSG) of its Standards Association.
仕様は、米国電気電子技術者協会（IEEE）がその標準化協会の業界接続セキュリティグループ（ICSG）を通じて開発したことに注意してください。
The table is managed by IANA, following the allocation policy specified in Section 7.
テーブルは、セクション7で指定された割り当てポリシーに従って、IANAによって管理されます。
The SpecID attributes of extension classes (Section 4.5) must allow the values of the specifications' namespace fields, but implementations are otherwise not required to support all specifications of the IANA table and may choose which specifications to support. However, at a minimum, the specification listed in the initial IANA table needs to be supported, as described in Section 5. If an implementation received data that it does not support, it may expand its functionality by looking up the IANA table or notify the sender of its inability to parse the data. Note that the lookup could be done manually or automatically, but automatic download of data from IANA's website is not recommended, since it is not designed for mass retrieval of data by multiple devices.
拡張クラス（セクション4.5）のSpecID属性は、仕様の名前空間フィールドの値を許可する必要がありますが、それ以外の場合、実装はIANAテーブルのすべての仕様をサポートする必要はなく、サポートする仕様を選択できます。ただし、セクション5で説明されているように、少なくとも、初期IANAテーブルにリストされている仕様がサポートされている必要があります。実装がサポートしていないデータを受け取った場合、IANAテーブルを検索するか、データを解析できないことの送信者。ルックアップは手動または自動で実行できますが、IANAのWebサイトからのデータの自動ダウンロードは、複数のデバイスによるデータの大量取得を目的として設計されていないため、お勧めできません。
This extension inherits all of the data types defined in the IODEF data model. One data type is added: XMLDATA. Embedded XML data is represented by the XMLDATA data type. This type is defined as the extension to the iodef:ExtensionType [RFC5070], whose dtype attribute is set to "xml".
この拡張機能は、IODEFデータモデルで定義されているすべてのデータ型を継承します。 1つのデータ型が追加されます：XMLDATA。埋め込みXMLデータは、XMLDATAデータ型で表されます。このタイプはiodef：ExtensionType [RFC5070]の拡張として定義され、そのdtype属性は「xml」に設定されています。
This document defines eight extension classes, namely AttackPattern, Platform, Vulnerability, Scoring, Weakness, EventReport, Verification, and Remediation. Figure 1 describes the relationships between the IODEF Incident class [RFC5070] and the newly defined classes. It is expressed in Unified Modeling Language (UML) syntax per RFC 5070 [RFC5070]. The UML representation is for illustrative purposes only; elements are specified in XML as defined in Section 5.2.
このドキュメントでは、AttackPattern、Platform、Vulnerability、Scoring、Weakness、EventReport、Verification、およびRemediationという8つの拡張クラスを定義しています。図1は、IODEFインシデントクラス[RFC5070]と新しく定義されたクラスの関係を示しています。これは、RFC 5070 [RFC5070]に基づく統一モデリング言語（UML）構文で表されます。 UML表現は、例示のみを目的としています。要素は、セクション5.2で定義されているようにXMLで指定されます。
+---------------+
| Incident |
+---------------+
| ENUM purpose |<>---------[IncidentID]
| STRING |<>--{0..1}-[AlternativeID]
| ext-purpose |<>--{0..1}-[RelatedActivity]
| ENUM lang |<>--{0..1}-[DetectTime]
| ENUM |<>--{0..1}-[StartTime]
| restriction |<>--{0..1}-[EndTime]
| |<>---------[ReportTime]
| |<>--{0..*}-[Description]
| |<>--{1..*}-[Assessment]
| |<>--{0..*}-[Method]
| | |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[AttackPattern]
| | |<>--{0..*}-[Vulnerability]
| | |<>--{0..*}-[Weakness]
| |<>--{1..*}-[Contact]
| |<>--{0..*}-[EventData]
| | |<>--{0..*}-[Flow]
| | | |<>--{1..*}-[System]
| | | |<>--{0..*}-[AdditionalData]
| | | |<>--{0..*}-[Platform]
| | |<>--{0..*}-[Expectation]
| | |<>--{0..1}-[Record]
| | |<>--{1..*}-[RecordData]
| | |<>--{1..*}-[RecordItem]
| | |<>--{0..*}-[EventReport]
| |<>--{0..1}-[History]
| |<>--{0..*}-[AdditionalData]
| | |<>--{0..*}-[Verification]
| | |<>--{0..*}-[Remediation]
+---------------+
Figure 1: Incident Class
図1：インシデントクラス
Figure 2 shows the basic structure of the extension classes. Some of the extension classes have extra elements as defined in Section 4.5, but the basic structure is the same.
図2は、拡張クラスの基本構造を示しています。セクション4.5で定義されているように、一部の拡張機能クラスには追加の要素がありますが、基本的な構造は同じです。
+---------------------+
| New Class Name |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 2: Basic Structure
図2：基本構造
Three attributes are defined as indicated below:
以下に示すように、3つの属性が定義されています。
SpecID: REQUIRED. ENUM. A specification's identifier that specifies the format of structured information. The value should be chosen from the namespaces [XMLNames] listed in the IANA table (Section 4.1) or "private". The value "private" is prepared for conveying structured information based on a format that is not listed in the table. This is usually used for conveying data formatted according to an organization's private schema. When the value "private" is used, ext-SpecID element MUST be used.
SpecID：必須。 ENUM。構造化情報の形式を指定する仕様の識別子。値は、IANAテーブル（セクション4.1）にリストされている名前空間[XMLNames]または「プライベート」から選択する必要があります。 「private」という値は、表にリストされていないフォーマットに基づいて構造化された情報を伝達するために用意されています。これは通常、組織のプライベートスキーマに従ってフォーマットされたデータを伝達するために使用されます。値「private」を使用する場合は、ext-SpecID要素を使用する必要があります。
ext-SpecID: OPTIONAL. STRING. A specification's identifier that specifies the format of structured information. This is usually used to support a private schema that is not listed in the IANA table (Section 4.1). This attribute MUST be used only when the value of the SpecID element is "private."
ext-SpecID：オプション。ストリング。構造化情報の形式を指定する仕様の識別子。これは通常、IANAテーブル（セクション4.1）にリストされていないプライベートスキーマをサポートするために使用されます。この属性は、SpecID要素の値が「プライベート」の場合にのみ使用する必要があります。
ContentID: OPTIONAL. STRING. An identifier of structured information. Depending on the extension classes, the content of the structured information differs. This attribute enables IODEF documents to convey the identifier of the structured information instead of conveying the information itself.
ContentID：オプション。ストリング。構造化された情報の識別子。拡張クラスによって、構造化情報の内容は異なります。この属性により、IODEFドキュメントは、情報自体を伝達するのではなく、構造化情報の識別子を伝達できます。
Likewise, two elements are defined as indicated below:
同様に、2つの要素は次のように定義されます。
RawData: Zero or more. XMLDATA. An XML document of structured information. This is a complete document that is formatted according to the specification and its version identified by the SpecID/ext-SpecID. When this element is used, writers/senders MUST ensure that the namespace specified by SpecID/ext-SpecID and the schema of the XML are consistent; if not, the namespace identified by SpecID SHOULD be preferred, and the inconsistency SHOULD be logged so a human can correct the problem.
RawData：ゼロ以上。 XMLDATA。構造化された情報のXMLドキュメント。これは、SpecID / ext-SpecIDで識別される仕様とそのバージョンに従ってフォーマットされた完全なドキュメントです。この要素を使用する場合、ライター/送信者は、SpecID / ext-SpecIDで指定された名前空間とXMLのスキーマが一貫していることを確認する必要があります。そうでない場合は、SpecIDで識別されるネームスペースを優先してください。また、人間が問題を修正できるように、不整合をログに記録する必要があります（SHOULD）。
Reference: Zero or more of iodef:Reference [RFC5070]. A reference to structured information. This element allows an IODEF document to include a link to structured information instead of directly embedding it into a RawData element.
参照：ゼロ以上のiodef：Reference [RFC5070]。構造化された情報への参照。この要素により、IODEFドキュメントは、RawData要素に直接埋め込むのではなく、構造化された情報へのリンクを含めることができます。
Though ContentID is an optional attribute, and RawData and Reference are optional elements, one of them MUST be used to convey structured information. Note that, in order to avoid confusing the receiver, only one of them SHOULD be used.
ContentIDはオプションの属性であり、RawDataとReferenceはオプションの要素ですが、構造化された情報を伝達するためにそれらの1つを使用する必要があります。レシーバーの混乱を避けるために、そのうちの1つだけを使用する必要があることに注意してください。
This document defines eight extension classes, as described in the subsections that follow.
このドキュメントでは、以下のサブセクションで説明するように、8つの拡張クラスを定義します。
An AttackPattern is an extension class to the Incident.Method.AdditionalData element with a dtype of "xml". It describes attack patterns of incidents or events. It is RECOMMENDED that the Method class [RFC5070] contain the extension elements whenever available. An AttackPattern class is structured as follows:
AttackPatternは、dtypeが "xml"のIncident.Method.AdditionalData要素の拡張クラスです。インシデントまたはイベントの攻撃パターンについて説明します。 Methodクラス[RFC5070]には、利用可能な場合は常に拡張要素が含まれることが推奨されます。 AttackPatternクラスは次のように構成されています。
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
Figure 3: AttackPattern Class
図3：AttackPatternクラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of attack pattern information. See Section 4.4.
ContentID：オプション。ストリング。攻撃パターン情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of attack pattern information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。攻撃パターン情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to attack pattern information. See Section 4.4.
参照：ゼロ以上。攻撃パターン情報への参照。セクション4.4を参照してください。
Platform: Zero or more. An identifier of the software platform involved in the specific attack pattern. See Section 4.5.2.
プラットフォーム：ゼロ以上。特定の攻撃パターンに関与するソフトウェアプラットフォームの識別子。セクション4.5.2を参照してください。
A Platform is an extension class that identifies a software platform. It is RECOMMENDED that the AttackPattern, Vulnerability, Weakness, and System [RFC5070] classes contain the extension elements whenever available. A Platform element is structured as follows:
プラットフォームは、ソフトウェアプラットフォームを識別する拡張クラスです。 AttackPattern、Vulnerability、Weakness、およびSystem [RFC5070]クラスには、利用可能な場合は常に拡張要素が含まれていることが推奨されます。 Platform要素は次のように構成されています。
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 4: Platform Class
図4：プラットフォームクラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of platform information. See Section 4.4.
ContentID：オプション。ストリング。プラットフォーム情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of platform information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。プラットフォーム情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to platform information. See Section 4.4.
参照：ゼロ以上。プラットフォーム情報への参照。セクション4.4を参照してください。
A Vulnerability is an extension class to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes the vulnerabilities that are exposed or were exploited in incidents. It is RECOMMENDED that the Method class contain the extension elements whenever available. A Vulnerability element is structured as follows:
脆弱性は、dtypeが「xml」のIncident.Method.AdditionalData要素の拡張クラスです。拡張機能は、インシデントで公開または悪用された脆弱性を説明します。可能な場合は常に、Methodクラスに拡張要素を含めることをお勧めします。 Vulnerability要素は次のように構成されています。
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 5: Vulnerability Class
図5：脆弱性クラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of vulnerability information. See Section 4.4.
ContentID：オプション。ストリング。脆弱性情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of vulnerability information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。脆弱性情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to vulnerability information. See Section 4.4.
参照：ゼロ以上。脆弱性情報への参照。セクション4.4を参照してください。
Platform: Zero or more. An identifier of the software platform affected by the vulnerability. See Section 4.5.2.
プラットフォーム：ゼロ以上。脆弱性の影響を受けるソフトウェアプラットフォームの識別子。セクション4.5.2を参照してください。
Scoring: Zero or more. An indicator of the severity of the vulnerability. See Section 4.5.4.
採点：ゼロ以上。脆弱性の重大度の指標。セクション4.5.4を参照してください。
A Scoring is an extension class that describes the severity scores in terms of security. It is RECOMMENDED that the Vulnerability and Weakness classes contain the extension elements whenever available.
スコアリングは、セキュリティの観点から重大度スコアを記述する拡張クラスです。 VulnerabilityクラスとWeaknessクラスには、利用可能な場合は常に拡張要素が含まれていることをお勧めします。
A Scoring class is structured as follows:
Scoringクラスは次のように構成されています。
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 6: Scoring Class
図6：スコアリングクラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of a score set. See Section 4.4.
ContentID：オプション。ストリング。スコアセットの識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of a score set. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。スコアセットのXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to a score set. See Section 4.4.
参照：ゼロ以上。スコアセットへの参照。セクション4.4を参照してください。
A Weakness is an extension class to the Incident.Method.AdditionalData element with a dtype of "xml". The extension describes the weakness types that are exposed or were exploited in incidents. It is RECOMMENDED that the Method class contain the extension elements whenever available. A Weakness element is structured as follows:
弱点は、dtypeが「xml」のIncident.Method.AdditionalData要素の拡張クラスです。拡張機能は、インシデントで公開された、または悪用された脆弱性のタイプを示します。可能な場合は常に、Methodクラスに拡張要素を含めることをお勧めします。 Weakness要素は次のように構成されています。
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
Figure 7: Weakness Class
図7：弱点クラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of weakness information. See Section 4.4.
ContentID：オプション。ストリング。弱点情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of weakness information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。弱点情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to weakness information. See Section 4.4.
参照：ゼロ以上。弱点情報への参照。セクション4.4を参照してください。
Platform: Zero or more. An identifier of the software platform affected by the weakness. See Section 4.5.2.
プラットフォーム：ゼロ以上。脆弱性の影響を受けるソフトウェアプラットフォームの識別子。セクション4.5.2を参照してください。
Scoring: Zero or more. An indicator of the severity of the weakness. See Section 4.5.4.
採点：ゼロ以上。弱さの深刻度の指標。セクション4.5.4を参照してください。
An EventReport is an extension class to the Incident.EventData.Record.RecordData.RecordItem element with a dtype of "xml". The extension embeds structured event reports. It is RECOMMENDED that the RecordItem class contain the extension elements whenever available. An EventReport element is structured as follows:
EventReportは、dtypeが「xml」のIncident.EventData.Record.RecordData.RecordItem要素の拡張クラスです。拡張機能は、構造化されたイベントレポートを埋め込みます。 RecordItemクラスには、利用可能な場合は常に拡張要素を含めることをお勧めします。 EventReport要素は次のように構成されています。
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 8: EventReport Class
図8：EventReportクラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of an event report. See Section 4.4.
ContentID：オプション。ストリング。イベントレポートの識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of an event report. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。イベントレポートのXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to an event report. See Section 4.4.
参照：ゼロ以上。イベントレポートへの参照。セクション4.4を参照してください。
A Verification is an extension class to the Incident.AdditionalData element with a dtype of "xml". The extension elements describe information on verifying security, e.g., a checklist, to cope with incidents. It is RECOMMENDED that the Incident class contain the extension elements whenever available. A Verification class is structured as follows:
Verificationは、dtypeが「xml」のIncident.AdditionalData要素の拡張クラスです。拡張要素は、インシデントに対処するためのチェックリストなど、セキュリティの検証に関する情報を記述します。 Incidentクラスには、利用可能な場合は常に拡張要素が含まれることをお勧めします。検証クラスは次のように構成されています。
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
Figure 9: Verification Class
図9：検証クラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of verification information. See Section 4.4.
ContentID：オプション。ストリング。検証情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of verification information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。検証情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to verification information. See Section 4.4.
参照：ゼロ以上。検証情報への参照。セクション4.4を参照してください。
A Remediation is an extension class to the Incident.AdditionalData element with a dtype of "xml". The extension elements describe incident remediation information, including instructions. It is RECOMMENDED that the Incident class contain the extension elements whenever available. A Remediation class is structured as follows:
Remediationは、dtypeが「xml」のIncident.AdditionalData要素の拡張クラスです。拡張要素は、指示を含むインシデント修復情報を記述します。 Incidentクラスには、利用可能な場合は常に拡張要素が含まれることをお勧めします。 Remediationクラスは次のように構成されています。
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
Figure 10: Remediation Class
図10：修復クラス
This class has the following attributes:
このクラスには次の属性があります。
SpecID: REQUIRED. ENUM. See Section 4.4.
SpecID：必須。 ENUM。セクション4.4を参照してください。
ext-SpecID: OPTIONAL. STRING. See Section 4.4.
ext-SpecID：オプション。ストリング。セクション4.4を参照してください。
ContentID: OPTIONAL. STRING. An identifier of remediation information. See Section 4.4.
ContentID：オプション。ストリング。修復情報の識別子。セクション4.4を参照してください。
Likewise, this class has the following elements:
同様に、このクラスには次の要素があります。
RawData: Zero or more. XMLDATA. An XML document of remediation information. See Section 4.4.
RawData：ゼロ以上。 XMLDATA。修復情報のXMLドキュメント。セクション4.4を参照してください。
Reference: Zero or more. A reference to remediation information. See Section 4.4.
参照：ゼロ以上。修復情報への参照。セクション4.4を参照してください。
Implementations compliant with this document MUST be capable of sending and receiving the extended IODEF documents that contain XML documents conforming to the specification listed in the initial IANA table described in Section 4.1 without error. The extended IODEF document is an XML document that MUST be well-formed and MUST be valid according to schemata, including extension schemata, available to the validator and applicable to the XML document. Note that the receiver can look up the namespace in the IANA table to understand what specifications the embedded XML documents follow.
このドキュメントに準拠した実装は、セクション4.1で説明されている初期IANAテーブルにリストされている仕様に準拠するXMLドキュメントを含む拡張IODEFドキュメントをエラーなしで送受信できなければなりません（MUST）。拡張IODEFドキュメントはXMLドキュメントであり、整形式である必要があり、拡張スキーマを含むスキーマに従って有効である必要があり、バリデーターで使用でき、XMLドキュメントに適用できます。受信者はIANAテーブルで名前空間を検索して、埋め込みXMLドキュメントが従う仕様を理解できることに注意してください。
For the purpose of facilitating the understanding of mandatory-to-implement features, the following subsections provide an XML document conformant to this memo, and a corresponding schema.
実装に必須の機能の理解を容易にするために、以下のサブセクションでは、このメモに準拠したXMLドキュメントと、対応するスキーマを提供します。
An example IODEF document for checking an implementation's conformity with mandatory-to-implement features is provided here. The document carries Malware Metadata Exchange Format (MMDEF) metadata. Note that the metadata is generated by genMMDEF [MMDEF] with EICAR [EICAR] files. Due to the limit of 72 characters per line, some line breaks were added in this example.
ここでは、実装から実装への必須機能への適合性をチェックするためのIODEFドキュメントの例を示します。ドキュメントには、Malware Metadata Exchange Format（MMDEF）メタデータが含まれています。メタデータはGENMMDEF [MMDEF]とEICAR [EICAR]ファイルで生成されることに注意してください。 1行あたり72文字の制限があるため、この例ではいくつかの改行が追加されました。
<?xml version="1.0" encoding="UTF-8"?>
<IODEF-Document version="1.00" lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Incident purpose="reporting">
<IncidentID name="sci.example.com">189493</IncidentID>
<ReportTime>2013-06-18T23:19:24+00:00</ReportTime>
<Description>a candidate security incident</Description>
<Assessment>
<Impact completion="failed" type="admin" />
</Assessment>
<Method>
<Description>A candidate attack event</Description>
<AdditionalData dtype="xml">
<sci:AttackPattern SpecID=
"urn:ietf:params:xml:ns:mile:mmdef:1.2">
<sci:RawData dtype="xml">
<malwareMetaData xmlns="http://xml/metadataSharing.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xml/metadataSharing.xsd
file:metadataSharing.xsd" version="1.200000" id="10000">
<company>N/A</company>
<author>MMDEF Generation Script</author>
<comment>Test MMDEF v1.2 file generated using genMMDEF
</comment>
<timestamp>2013-03-23T15:12:50.726000</timestamp>
<objects>
<file id="6ce6f415d8475545be5ba114f208b0ff">
<md5>6ce6f415d8475545be5ba114f208b0ff</md5>
<sha1>da39a3ee5e6b4b0d3255bfef95601890afd80709</sha1>
<sha256>e3b0c44298fc1c149afbf4c8996fb92427ae41e464
9b934ca495991b7852b855</sha256>
<sha512>cf83e1357eefb8bdf1542850d66d8007d620e4050b
5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff83
18d2877eec2f63b931bd47417a81a538327af927
da3e</sha512>
<size>184</size>
<filename>eicar_com.zip</filename>
<MIMEType>application/zip</MIMEType>
</file>
<file id="44d88612fea8a8f36de82e1278abb02f">
<md5>44d88612fea8a8f36de82e1278abb02f</md5>
<sha1>3395856ce81f2b7382dee72602f798b642f14140</sha1>
<sha256>275a021bbfb6489e54d471899f7db9d1663fc695ec
2fe2a2c4538aabf651fd0f</sha256>
<sha512>cc805d5fab1fd71a4ab352a9c533e65fb2d5b88551
8f4e565e68847223b8e6b85cb48f3afad842726d99
239c9e36505c64b0dc9a061d9e507d833277ada3
36ab</sha512>
<size>68</size>
<crc32>1750191932</crc32>
<filename>eicar.com</filename>
<filenameWithinInstaller>eicar.com
</filenameWithinInstaller>
</file>
</objects>
<relationships>
<relationship type="createdBy" id="1">
<source>
<ref>file[@id="6ce6f415d8475545be5ba114f208b0ff"]
</ref>
</source>
<target>
<ref>file[@id="44d88612fea8a8f36de82e1278abb02f"]
</ref>
</target>
<timestamp>2013-03-23T15:12:50.744000</timestamp>
</relationship>
</relationships>
</malwareMetaData>
</sci:RawData>
</sci:AttackPattern>
</AdditionalData>
</Method>
<Contact role="creator" type="organization">
<ContactName>sci.example.com</ContactName>
<RegistryHandle registry="arin">sci.example-com
</RegistryHandle>
<Email>contact@csirt.example.com</Email>
</Contact>
<EventData>
<Flow>
<System category="source">
<Node>
<Address category="ipv4-addr">192.0.2.200</Address>
<Counter type="event">57</Counter>
</Node>
</System>
<System category="target">
<Node>
<Address category="ipv4-net">192.0.2.16/28</Address>
</Node>
<Service ip_protocol="4">
<Port>80</Port>
</Service>
</System>
</Flow>
<Expectation action="block-host" />
<Expectation action="other" />
</EventData>
</Incident>
</IODEF-Document>
An XML schema describing the elements defined in this document is given here.
このドキュメントで定義されている要素を説明するXMLスキーマを以下に示します。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:ietf:params:xml:ns:iodef-sci-1.0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"
xmlns:sci="urn:ietf:params:xml:ns:iodef-sci-1.0"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:ietf:params:xml:ns:iodef-1.0" schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/iodef-1.0.xsd"/>
<xsd:complexType name="XMLDATA">
<xsd:complexContent>
<xsd:restriction base="iodef:ExtensionType">
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="dtype" type="iodef:dtype-type"
use="required" fixed="xml"/>
<xsd:attribute name="ext-dtype" type="xsd:string"
use="prohibited"/>
<xsd:attribute name="meaning" type="xsd:string"/>
<xsd:attribute name="formatid" type="xsd:string"/>
<xsd:attribute name="restriction" type="iodef:restriction-type"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="BasicStructure">
<xsd:sequence>
<xsd:choice>
<xsd:element name="RawData" type="sci:XMLDATA"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="iodef:Reference" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="SpecID" type="xsd:string" use="required"/>
<xsd:attribute name="ext-SpecID" type="xsd:string"/>
<xsd:attribute name="ContentID" type="xsd:string"/>
</xsd:complexType>
<xsd:element name="Scoring" type="sci:BasicStructure"/>
<xsd:element name="Platform" type="sci:BasicStructure"/>
<xsd:element name="EventReport" type="sci:BasicStructure"/>
<xsd:element name="Verification" type="sci:BasicStructure"/>
<xsd:element name="Remediation" type="sci:BasicStructure"/>
<xsd:element name="AttackPattern">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Vulnerability">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="Weakness">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="sci:BasicStructure">
<sequence>
<xsd:element ref="sci:Platform" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element ref="sci:Scoring" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
This document specifies a format for encoding a particular class of security incidents appropriate for exchange across organizations. As merely a data representation, it does not directly introduce security issues. However, it is guaranteed that parties exchanging instances of this specification will have certain concerns. For this reason, the underlying message format and transport protocol used MUST ensure the appropriate degree of confidentiality, integrity, and authenticity for the specific environment. Specific security considerations are detailed in the messaging and transport documents, where the exchange of formatted information is automated; see Sections 9 and 10 of "Real-time Inter-network Defense (RID)" [RFC6545] and Section 4 of "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS" [RFC6546] for a detailed overview of security requirements and considerations.
このドキュメントでは、組織間の交換に適した特定のクラスのセキュリティインシデントをエンコードするための形式を指定します。単なるデータ表現であるため、セキュリティの問題が直接発生することはありません。ただし、この仕様のインスタンスを交換する当事者が特定の懸念を持つことは保証されています。このため、使用される基本的なメッセージ形式とトランスポートプロトコルは、特定の環境に対して適切な程度の機密性、完全性、および信頼性を保証する必要があります。特定のセキュリティに関する考慮事項は、フォーマットされた情報の交換が自動化されているメッセージングおよびトランスポートのドキュメントに詳述されています。詳細については、「リアルタイムネットワーク間防御（RID）」[RFC6545]のセクション9と10、および「HTTP / TLSを介したリアルタイムネットワーク間防御（RID）メッセージの転送」[RFC6546]のセクション4を参照してください。セキュリティ要件と考慮事項の概要。
It is RECOMMENDED that organizations that exchange data using this document develop operating procedures that consider, at a minimum, the following areas of concern.
このドキュメントを使用してデータを交換する組織は、少なくとも以下の懸念事項を考慮した運用手順を作成することをお勧めします。
The underlying messaging format, IODEF, provides data markers to indicate the sensitivity level of specific classes within the structure as well as for the entire XML document. The "restriction" attribute accomplishes this with four attribute values in IODEF [RFC5070]. These values are RECOMMENDED for use at the application level, prior to transport, to protect data as appropriate. A standard mechanism to apply XML encryption using these attribute values as triggers is defined in RID [RFC6545], Section 9.1. This mechanism may be used whether or not the RID protocol [RFC6545] and its associated transport binding [RFC6546] are used in the exchange to provide object-level security on the data to prevent possible intermediary systems or middleboxes from having access to the data being exchanged. In areas where transmission security or secrecy is questionable, the application of an XML digital signature [XMLDSIG] and/or encryption on each report will counteract both of these concerns. The data markers are RECOMMENDED for use by applications for managing access controls; however, access controls and management of those controls are out of scope for this document. Options such as the usage of a standard language (e.g., eXtensible Access Control Markup Language [XACML]) for the expression of authorization policies can be used to enable source and destination systems to better coordinate and align their respective policy expressions.
基になるメッセージング形式であるIODEFは、構造内および特定のXMLドキュメント全体の特定のクラスの機密レベルを示すデータマーカーを提供します。 「制限」属性は、IODEF [RFC5070]の4つの属性値でこれを実現します。これらの値は、必要に応じてデータを保護するために、トランスポートの前にアプリケーションレベルで使用することをお勧めします。これらの属性値をトリガーとして使用してXML暗号化を適用する標準メカニズムは、RID [RFC6545]のセクション9.1で定義されています。このメカニズムは、RIDプロトコル[RFC6545]とそれに関連するトランスポートバインディング[RFC6546]が交換で使用され、データにオブジェクトレベルのセキュリティを提供して、可能な中間システムまたはミドルボックスがデータにアクセスできないようにするかどうかに関係なく使用できます。交換した。送信のセキュリティまたは機密性が疑わしい領域では、各レポートにXMLデジタル署名[XMLDSIG]および/または暗号化を適用すると、これらの両方の問題に対処できます。データマーカーは、アプリケーションがアクセス制御を管理するために使用することをお勧めします。ただし、アクセス制御とそれらの制御の管理は、このドキュメントの範囲外です。許可ポリシーの表現のための標準言語（eXtensible Access Control Markup Language [XACML]など）の使用などのオプションを使用して、ソースシステムと宛先システムがそれぞれのポリシー式をより適切に調整および調整できるようにすることができます。
Any transport protocol used to exchange instances of IODEF documents MUST provide appropriate guarantees of confidentiality, integrity, and authenticity. The use of a standardized security protocol is encouraged. The RID protocol [RFC6545] and its associated transport binding [RFC6546] provide such security with options for mutual authentication session encryption and include application-level concerns such as policy and workflow.
IODEFドキュメントのインスタンスを交換するために使用されるトランスポートプロトコルは、機密性、整合性、および信頼性の適切な保証を提供する必要があります。標準化されたセキュリティプロトコルの使用をお勧めします。 RIDプロトコル[RFC6545]とそれに関連するトランスポートバインディング[RFC6546]は、相互認証セッション暗号化のオプションを備えたこのようなセキュリティを提供し、ポリシーやワークフローなどのアプリケーションレベルの問題を含みます。
The critical security concerns are that structured information may be falsified, accessed by unintended entities, or become corrupt during transit. We expect that each exchanging organization will determine the need, and mechanism, for transport protection.
重要なセキュリティ上の懸念は、構造化された情報が改ざんされたり、意図しないエンティティによってアクセスされたり、転送中に破損したりする可能性があることです。私たちは、各交換組織が輸送保護の必要性とメカニズムを決定することを期待しています。
For a complete review of privacy considerations when transporting incident-related information, please see RID [RFC6545], Section 9.5. Whether or not the RID protocol is used, the privacy considerations are important to consider, as incident information is often sensitive and may contain privacy-related information about individuals/ organizations or endpoints involved. Organizations will often require the establishment of legal reviews and formal policies that outline specific details of what information can be exchanged with specific entities. Typically, identifying information is anonymized where possible and appropriate. In some cases, information brokers are used to further anonymize the source of exchanged information so that other entities are unaware of the origin of a detected threat, whether or not that threat was realized.
インシデント関連情報を転送する際のプライバシーに関する考慮事項の詳細については、RID [RFC6545]、セクション9.5をご覧ください。 RIDプロトコルが使用されているかどうかにかかわらず、インシデント情報は多くの場合機密であり、関係する個人/組織またはエンドポイントに関するプライバシー関連情報が含まれている可能性があるため、プライバシーに関する考慮事項は重要です。多くの場合、組織は、特定のエンティティと交換できる情報の特定の詳細を概説する法的レビューと正式なポリシーの確立を必要とします。通常、識別情報は可能な限り適切に匿名化されます。場合によっては、情報ブローカーは交換された情報のソースをさらに匿名化するために使用され、その脅威が実現されたかどうかに関係なく、他のエンティティは検出された脅威の発生源を認識しません。
It is RECOMMENDED that policies and procedures for the exchange of cybersecurity information be established prior to participation in data exchanges. Policy and workflow procedures for the exchange of cybersecurity information often require executive-level approvals and legal reviews to appropriately establish limits on what information can be exchanged with specific organizations. RID [RFC6545], Section 9.6 outlines options and considerations for application developers to consider for policy and workflow design.
データ交換に参加する前に、サイバーセキュリティ情報の交換に関するポリシーと手順を確立することをお勧めします。サイバーセキュリティ情報を交換するためのポリシーとワークフローの手順では、多くの場合、特定の組織と交換できる情報の制限を適切に確立するために、経営幹部レベルの承認と法的レビューが必要です。 RID [RFC6545]のセクション9.6では、アプリケーション開発者がポリシーとワークフローの設計を検討する際のオプションと考慮事項について概説しています。
The cybersecurity information extension is merely a data format. Applications and transport protocols that store or exchange IODEF documents using information that can be represented through this extension will be a target for attacks. It is RECOMMENDED that systems and applications storing or exchanging this information be properly secured, have minimal services enabled, and maintain access controls and monitoring procedures.
サイバーセキュリティ情報拡張は、単なるデータ形式です。この拡張機能を通じて表現できる情報を使用してIODEFドキュメントを保存または交換するアプリケーションおよびトランスポートプロトコルは、攻撃の標的になります。この情報を保存または交換するシステムとアプリケーションは適切に保護され、最小限のサービスが有効になっていて、アクセス制御と監視手順を維持することが推奨されます。
This document uses URNs to describe XML namespaces and XML schemata [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism described in [RFC3688].
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠するXML名前空間とXMLスキーマ[XMLschemaPart1] [XMLschemaPart2]について説明します。
The following IODEF structured cybersecurity information extension namespace has been registered:
次のIODEF構造化サイバーセキュリティ情報拡張名前空間が登録されました。
URI: urn:ietf:params:xml:ns:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: None.
XML：なし。
The following IODEF structured cybersecurity information extension XML schema has been registered:
次のIODEF構造化サイバーセキュリティ情報拡張XMLスキーマが登録されています。
URI: urn:ietf:params:xml:schema:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of this document.
登録者の連絡先：このドキュメントの「著者のアドレス」セクションを参照してください。
XML: Refer to the XML schema in Section 5.2 of this document.
XML：このドキュメントのセクション5.2のXMLスキーマを参照してください。
This memo creates the following registry, which is managed by IANA:
このメモは、IANAによって管理される次のレジストリを作成します。
Name of the registry: "Structured Cybersecurity Information (SCI) Specifications"
レジストリの名前：「Structured Cybersecurity Information（SCI）Specifications」
Name of its parent registry: "Incident Object Description Exchange Format (IODEF)"
親レジストリの名前：「インシデントオブジェクト記述交換フォーマット（IODEF）」
URL of the registry: <http://www.iana.org/assignments/iodef>
Namespace details: A registry entry for a Structured Cybersecurity Information Specification (SCI specification) consists of:
名前空間の詳細：構造化サイバーセキュリティ情報仕様（SCI仕様）のレジストリエントリは、以下で構成されます。
Namespace: A URI [RFC3986] that identifies the XML namespace used by the registered SCI specification. In the case where the registrant does not request a particular URI, the IANA will assign it a Uniform Resource Name (URN) that follows RFC 3553 [RFC3553].
名前空間：登録済みのSCI仕様で使用されるXML名前空間を識別するURI [RFC3986]。登録者が特定のURIを要求しない場合、IANAはそれにRFC 3553 [RFC3553]に従うUniform Resource Name（URN）を割り当てます。
Specification Name: A string containing the spelled-out name of the SCI specification in human-readable form.
仕様名：人間が読める形式のSCI仕様のスペルアウトされた名前を含む文字列。
Reference URI: A list of one or more of the URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI.
参照URI：登録された仕様を取得できる1つ以上のURI [RFC3986]のリスト。登録された仕様は、そのURIから容易かつ公的に利用可能でなければなりません。
Applicable Classes: A list of one or more of the extension classes specified in Section 4.5 of this document. The registered SCI specification MUST only be used with the extension classes in the registry entry.
該当するクラス：このドキュメントのセクション4.5で指定されている1つ以上の拡張クラスのリスト。登録されたSCI仕様は、レジストリエントリの拡張クラスでのみ使用する必要があります。
Information that must be provided to assign a new value: The above list of information.
新しい値を割り当てるために提供する必要がある情報：上記の情報のリスト。
Fields to record in the registry: Namespace/Specification Name/ Version/Reference URI/Applicable Classes. Note that it is not necessary to include a defining reference for all assignments in this new registry.
レジストリに記録するフィールド：名前空間/仕様名/バージョン/参照URI /適用可能なクラス。この新しいレジストリにすべての割り当ての定義参照を含める必要はないことに注意してください。
Initial registry contents: Only one entry, with the following values:
レジストリの初期内容：次の値を持つ1つのエントリのみ：
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
仕様名：Malware Metadata Exchange Format
Version: 1.2 Reference URI:
バージョン：1.2参照URI：
<http://standards.ieee.org/develop/indconn/icsg/mmdef.html>,
<http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>
Applicable Classes: AttackPattern
該当するクラス：AttackPattern
Allocation policy: Specification Required (which includes 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 working group exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to retrieve the SCI 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 registered applicable classes are appropriate for the registered SCI specification.
指定された専門家は、MILE（Managed Incident Lightweight Exchange）ワーキンググループ、またはそのようなワーキンググループが存在する場合は、そのワーキンググループ（たとえば、ワーキンググループのメーリングリストへの電子メールを介して）に相談することが期待されます。 Designated Expertは、仕様の公開状況を確認し、URIが正しいことを確認するために、提供されたURIからSCI仕様を取得することが期待されています。 Designated Expertの重要な責任は、登録された適用可能なクラスが登録されたSCI仕様に適切であることを確認することです。
We would like to acknowledge David Black from EMC, who kindly provided generous support, especially on the IANA registry issues. We also would like to thank Jon Baker from MITRE, Eric Burger from Georgetown University, Paul Cichonski from NIST, Panos Kampanakis from Cisco, Ivan Kirillov from MITRE, Pearl Liang from IANA, Robert Martin from MITRE, Alexey Melnikov from Isode, Thomas Millar from US-CERT, Kathleen Moriarty from EMC, Lagadec Philippe from NATO, Sean Turner from IECA, Inc., Anthony Rutkowski from Yaana Technology, Brian Trammell from ETH Zurich, David Waltermire from NIST, James Wendorf from IEEE, and Shuhei Yamaguchi from NICT, for their sincere discussion and feedback on this document.
特にIANAレジストリの問題について、寛大なサポートを提供してくれたEMCのDavid Blackに感謝します。また、MITREのJon Baker、ジョージタウン大学のEric Barger、NISTのPaul Cichonski、CiscoのPanos Kampanakis、MITREのIvan Kirillov、IANAのPearl Liang、MITREのRobert Martin、IsodeのAlexey Melnikov、Thomas Millarにも感謝します。 US-CERT、EMCのキャスリーンモリアーティ、NATOのラガデックフィリップ、IECA、Inc.のショーンターナー、Yaana Technologyのアンソニールトコウスキー、ETHチューリッヒのブライアントラメル、NISTのデビッドウォルターミア、IEEEのジェームズウェンドルフ、NICTの山口修平、このドキュメントに関する彼らの誠実な議論とフィードバックのために。
[MMDEF] ICSG Malware Metadata Exchange Format Working Group, "Malware Metadata Exchange Format", IEEE Standards Association, November 2011, <http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>.
[MMDEF] ICSG Malware Metadata Exchange Format Working Group、「Malware Metadata Exchange Format」、IEEE Standards Association、2011年11月、<http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>。
[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月。
[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月。
[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、「The Incident Object Description Exchange Format」、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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.
[RFC6545] Moriarty、K。、「Real-time Inter-network Defense（RID）」、RFC 6545、2012年4月。
[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., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/xml/>.
[XML1.0] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告、11月2008、<http://www.w3.org/TR/xml/>。
[XMLschemaPart1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-1/>.
[XMLschemaPart1] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C勧告、2004年10月、<http://www.w3.org / TR / xmlschema-1 />。
[XMLschemaPart2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.
[XMLschemaPart2] Biron、P。およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C勧告、2004年10月、<http://www.w3.org/TR/xmlschema-2/>。
[XMLNames] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "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. Thompson、「Namespaces in XML 1.0（Third Edition）」、W3C勧告、2009年12月、<http：// www.w3.org/TR/xml-names/>。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、2003年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration and Classification (CAPEC)", <http://capec.mitre.org/>.
[CAPEC]ザMITER Corporation、「Common Attack Pattern Enumeration and Classification（CAPEC）」、<http://capec.mitre.org/>。
[CCE] National Institute of Standards and Technology, "Common Configuration Enumeration (CCE)", <http://nvd.nist.gov/cce/index.cfm>.
[CCE] National Institute of Standards and Technology、「Common Configuration Enumeration（CCE）」、<http://nvd.nist.gov/cce/index.cfm>。
[CCSS] Scarfone, K. and P. Mell, "The Common Configuration Scoring System (CCSS): Metrics for Software Security Configuration Vulnerabilities", NIST Interagency Report 7502, December 2010, <http://csrc.nist.gov/ publications/nistir/ir7502/nistir-7502_CCSS.pdf>.
[CCSS] Scarfone、K。およびP. Mell、「Common Configuration Scoring System（CCSS）：Metrics for Software Security Configuration Vulnerabilities」、NIST Interagency Report 7502、2010年12月、<http://csrc.nist.gov/の出版物/nistir/ir7502/nistir-7502_CCSS.pdf>。
[CEE] The MITRE Corporation, "Common Event Expression (CEE)", <http://cee.mitre.org/>.
[CEE]ザ・マイター・コーポレーション、「Common Event Expression（CEE）」、<http://cee.mitre.org/>。
[CPE] National Institute of Standards and Technology, "Common Platform Enumeration", June 2011, <http://scap.nist.gov/specifications/cpe/>.
[CPE]米国国立標準技術研究所、「Common Platform Enumeration」、2011年6月、<http://scap.nist.gov/specifications/cpe/>。
[CVE] The MITRE Corporation, "Common Vulnerabilities and Exposures (CVE)", <http://cve.mitre.org/>.
[CVE]ザMITER Corporation、「Common Vulnerabilities and Exposures（CVE）」、<http://cve.mitre.org/>。
[CVRF] ICASI, "The Common Vulnerability Reporting Framework (CVRF)", <http://www.icasi.org/cvrf>.
[CVRF] ICASI、「The Common Vulnerability Reporting Framework（CVRF）」、<http://www.icasi.org/cvrf>。
[CVSS] Mell, P., Scarfone, K., and S. Romanosky, "The Common Vulnerability Scoring System (CVSS) and Its Applicability to Federal Agency Systems", NIST Interagency Report 7435, August 2007, <http://csrc.nist.gov/publications/nistir/ ir7435/NISTIR-7435.pdf>.
[CVSS] Mell、P.、Scarfone、K。、およびS. Romanosky、「Common Vulnerability Scoring System（CVSS）and its Applicability to Federal Agency Systems」、NIST Interagency Report 7435、2007年8月、<http：// csrc .nist.gov / publications / nistir / ir7435 / NISTIR-7435.pdf>。
[CWE] The MITRE Corporation, "Common Weakness Enumeration (CWE)", <http://cwe.mitre.org/>.
[CWE]ザMITER Corporation、「Common Weakness Enumeration（CWE）」、<http://cwe.mitre.org/>。
[CWSS] The MITRE Corporation, "Common Weakness Scoring System (CWSS(TM))", <http://cwe.mitre.org/cwss/>.
[CWSS]ザMITER Corporation、「Common Weakness Scoring System（CWSS（TM））」、<http://cwe.mitre.org/cwss/>。
[EICAR] EICAR - European Expert Group for IT-Security, "Anti-Malware Testfile", 2003, <http://www.eicar.org/86-0-Intended-use.html>.
[EICAR] EICAR-ITセキュリティのヨーロッパ専門家グループ、「Anti-Malware Testfile」、2003年、<http://www.eicar.org/86-0-Intended-use.html>。
[MAEC] The MITRE Corporation, "Malware Attribute Enumeration and Characterization", <http://maec.mitre.org/>.
[MAEC]ザMITER Corporation、「マルウェア属性の列挙と特性評価」、<http://maec.mitre.org/>。
[OCIL] Waltermire, D., Scarfone, K., and M. Casipe, "Specification for the Open Checklist Interactive Language (OCIL) Version 2.0", NIST Interagency Report 7692, April 2011, <http://csrc.nist.gov/publications/nistir/ ir7692/nistir-7692.pdf>.
[OCIL] Waltermire、D.、Scarfone、K。、およびM. Casipe、「Open Checklist Interactive Language（OCIL）Version 2.0の仕様」、NIST Interagency Report 7692、2011年4月、<http：//csrc.nist。 gov / publications / nistir / ir7692 / nistir-7692.pdf>。
[OVAL] The MITRE Corporation, "Open Vulnerability and Assessment Language (OVAL)", <http://oval.mitre.org/>.
[OVAL]ザMITER Corporation、「Open Vulnerability and Assessment Language（OVAL）」、<http://oval.mitre.org/>。
[SCAP] Waltermire, D., Quinn, S., Scarfone, K., and A. Halbardier, "The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2", NIST Special Publication 800-126 Revision 2, September 2011, <http://csrc.nist.gov/publications/ nistpubs/800-126-rev2/SP800-126r2.pdf>.
[SCAP] Waltermire、D.、Quinn、S.、Scarfone、K。、およびA. Halbardier、「The Security Specification for the Security Content Automation Protocol（SCAP）：SCAP Version 1.2」、NIST Special Publication 800-126 Revision 2 、2011年9月、<http://csrc.nist.gov/publications/ nistpubs / 800-126-rev2 / SP800-126r2.pdf>。
[XACML] Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version 3.0", January 2013, <http://docs.oasis-open.org/xacml/3.0/ xacml-3.0-core-spec-os-en.pdf>.
[XACML] Rissanen、E。、「eXtensible Access Control Markup Language（XACML）Version 3.0」、2013年1月、<http://docs.oasis-open.org/xacml/3.0/ xacml-3.0-core-spec-os -en.pdf>。
[XCCDF] Waltermire, D., Schmidt, C., Scarfone, K., and N. Ziring, "Specification for the Extensible Configuration Checklist Description Format (XCCDF) version 1.2 (DRAFT)", NIST Interagency Report 7275, Revision 4, September 2011, <http://csrc.nist.gov/publications/nistir/ir7275-rev4/ NISTIR-7275r4.pdf>.
[XCCDF] Waltermire、D.、Schmidt、C.、Scarfone、K。、およびN. Ziring、「Extensible Configuration Checklist Description Format（XCCDF）version 1.2（DRAFT）の仕様」、NIST Interagency Report 7275、Revision 4 2011年9月、<http://csrc.nist.gov/publications/nistir/ir7275-rev4/ NISTIR-7275r4.pdf>。
[XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing (Second Edition)", June 2008, <http://www.w3.org/TR/xmldsig-core/>.
[XMLDSIG] W3C勧告、「XML署名の構文と処理（第2版）」、2008年6月、<http://www.w3.org/TR/xmldsig-core/>。
Authors' Addresses
著者のアドレス
Takeshi Takahashi National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi Koganei 184-8795 Tokyo Japan
たけし たかはし なちおなｌ いんｓちつて おｆ いんふぉｒまちおん あんｄ こっむにかちおんｓ てｃｈのぉｇｙ ４ー２ー１ ぬくいーきたまち こがねい １８４ー８７９５ ときょ じゃぱん
Phone: +80 423 27 5862
EMail: takeshi_takahashi@nict.go.jp
Kent Landfield McAfee, Inc. 5000 Headquarters Drive Plano, TX 75024 USA
Kent Landfield McAfee、Inc. 5000 Headquarters Drive Plano、TX 75024 USA
EMail: Kent_Landfield@McAfee.com
Youki Kadobayashi Nara Institute of Science and Technology 8916-5 Takayama, Ikoma 630-0192 Nara Japan
ようき かどばやし なら いんｓちつて おｆ Ｓしえんせ あんｄ てｃｈのぉｇｙ ８９１６ー５ たかやま、 いこま ６３０ー０１９２ なら じゃぱん
EMail: youki-k@is.aist-nara.ac.jp