[要約] RFC 7495は、IODEFのための列挙参照形式を定義しています。 このRFCの目的は、IODEFのデータモデル内での列挙型の使用を効率化し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) A. Montville Request for Comments: 7495 CIS Category: Standards Track D. Black ISSN: 2070-1721 EMC March 2015
Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)
インシデントオブジェクト記述交換フォーマット(IODEF)の列挙参照フォーマット
Abstract
概要
The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.
インシデントオブジェクト記述交換フォーマット(IODEF)は、コンピューターのセキュリティインシデントに関する情報を共有するためのXMLデータ表現フレームワークです。 IODEFでは、Referenceクラスは、脆弱性、侵入検知システム(IDS)アラート、マルウェアサンプル、助言、または攻撃手法など、外部で指定された情報への参照を提供します。実際には、これらの参照は、列挙形式と特定の列挙値の両方を定義する外部列挙仕様に基づいていますが、IODEFリファレンスクラス(RFC 5070のIODEF v1で指定)は、これらの重要な部分の両方を含める方法を示していません情報。
This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.
このドキュメントは、外部仕様と特定の列挙識別値の両方を含むスタンドアロンのデータ形式を確立し、IANAレジストリを確立して外部列挙仕様を管理します。このドキュメントはIODEF v1を更新しませんが、この列挙参照形式はIODEF v2で使用され、このクラスの列挙参照をサポートする他の形式に適用できます。
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/rfc7495.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7495で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2015 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 1.1. Terminology ................................................3 2. Referencing External Enumerations ...............................3 2.1. Reference Name Format ......................................4 2.2. Reference Method Applicability .............................5 3. Security Considerations .........................................5 4. IANA Considerations .............................................6 5. The ReferenceName Schema ........................................8 6. References ......................................................9 6.1. Normative References .......................................9 6.2. Informative References .....................................9 Acknowledgements ..................................................10 Authors' Addresses ................................................10
There is an identified need to specify a format to include relevant enumeration values from other data representation formats in an IODEF document. It is anticipated that this requirement will exist in other standardization efforts within several IETF Working Groups, but the scope of this document pertains solely to IODEF. This format is used in IODEF v2 [IODEFv2], which will replace the original IODEF v1 [IODEF] specification; this document does not specify use of this format in IODEF v1 [IODEF].
他のデータ表現形式からの関連する列挙値をIODEFドキュメントに含める形式を指定する必要があることが確認されています。この要件は、いくつかのIETFワーキンググループ内の他の標準化活動に存在すると予想されますが、このドキュメントの範囲は、IODEFにのみ関係します。このフォーマットはIODEF v2 [IODEFv2]で使用され、元のIODEF v1 [IODEF]仕様を置き換えます。このドキュメントでは、IODEF v1 [IODEF]でのこの形式の使用を指定していません。
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]で説明されているように解釈されます。
The need is to place enumeration identifiers and their enumeration format references in IODEF's Reference class. There are several ways to accomplish this goal, but the most appropriate at this point is to require a specific structure for the ReferenceName string of the IODEF Reference class, and use an IANA registry to manage references to specific enumeration reference formats.
列挙型識別子とその列挙形式参照をIODEFの参照クラスに配置する必要があります。この目標を達成する方法はいくつかありますが、現時点で最も適切なのは、IODEF参照クラスのReferenceName文字列に特定の構造を要求し、IANAレジストリを使用して特定の列挙参照形式への参照を管理することです。
Per IODEF [IODEF], the ReferenceName is of type ML_STRING. This becomes problematic when specific references, especially enumeration formats such as Common Vulnerability Enumeration [CVE], Common Configuration Enumeration [CCE], Common Platform Enumeration [CPE], and so on, are referenced -- how is an implementer to know which type of reference this is, and thus how to parse it? One solution, presented here, is to require that ReferenceName follow a particular format.
IODEF [IODEF]ごとに、ReferenceNameはタイプML_STRINGです。これは、特定の参照、特にCommon Vulnerability Enumeration [CVE]、Common Configuration Enumeration [CCE]、Common Platform Enumeration [CPE]などの列挙形式が参照されている場合に問題になります。これを参照し、それをどのように解析するのですか?ここに示す1つの解決策は、ReferenceNameが特定の形式に従うことを要求することです。
Inclusion of such enumeration values, especially those related to security automation, is important to incident communication and investigation. Typically, an enumeration identifier is simply an identifier with a specific format as defined by an external party. Further, that enumeration identifier is itself a reference to specific information associated with the identifier. Thus, the ReferenceName is an identifier that is formatted in a specific manner and that identifies some set of associated information.
そのような列挙値、特にセキュリティ自動化に関連するものを含めることは、インシデントの通信と調査にとって重要です。通常、列挙識別子は、外部の当事者によって定義された特定の形式の識別子です。さらに、その列挙識別子自体は、識別子に関連付けられた特定の情報への参照です。したがって、ReferenceNameは特定の方法でフォーマットされ、関連する情報のセットを識別する識別子です。
For example, a vulnerability identifier following the CVE [CVE] formatting specification may be CVE-2014-0001. That identifier is formatted in a specific manner and relates to information about a specific vulnerability. Communicating the format for the identifier is the subject of this document.
たとえば、CVE [CVE]フォーマット仕様に準拠する脆弱性識別子はCVE-2014-0001です。その識別子は特定の方法でフォーマットされ、特定の脆弱性に関する情報に関連しています。識別子のフォーマットの伝達はこのドキュメントの主題です。
The ReferenceName class provides the XML representation for identifying an enumeration and specifying a value from it. A given enumeration is uniquely identified by the specIndex attribute. Each specIndex value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry (see Section 4). The child ID element represents a particular value from the corresponding enumeration identified by the specIndex attribute. The format of the ID element is described in the IANA registry entry of the enumeration.
ReferenceNameクラスは、列挙を識別し、そこから値を指定するためのXML表現を提供します。特定の列挙は、specIndex属性によって一意に識別されます。各specIndex値は、「列挙参照型識別子」IANAレジストリのエントリに対応します(セクション4を参照)。子ID要素は、specIndex属性で識別される対応する列挙からの特定の値を表します。 ID要素の形式は、列挙のIANAレジストリエントリに記述されています。
+-------------------------+ | ReferenceName | +-------------------------+ | INTEGER specIndex |<>----------[ ID ] +-------------------------+
Figure 1: The ReferenceName Class
図1:ReferenceNameクラス
The aggregate class that constitutes ReferenceName is:
ReferenceNameを構成する集約クラスは次のとおりです。
ID One. The identifier assigned to represent the particular enumeration object being referenced.
やりました。参照されている特定の列挙オブジェクトを表すために割り当てられた識別子。
The ReferenceName class has one attribute.
ReferenceNameクラスには1つの属性があります。
specIndex Required. INTEGER. Enumeration identifier. This value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry with an identical SpecIndex value.
specIndexは必須です。整数。列挙識別子。この値は、同一のSpecIndex値を持つ「列挙参照型識別子」IANAレジストリのエントリに対応します。
An example of such a reference is as follows:
このような参照の例は次のとおりです。
<iodef:Reference> <enum:ReferenceName specIndex="1"> <enum:ID>CXI-1234-XYZ</enum:ID> </enum:ReferenceName> <iodef:URL>http://cxi.example.com</iodef:URL> <iodef:Description>Foo</iodef:Description> </iodef:Reference>
Information in the IANA table (see Section 4) would include:
IANAテーブル(セクション4を参照)の情報には、次のものが含まれます。
Full Name: Concept X Identifier SpecIndex: 1 Version: any Specification URI: http://cxi.example.com/spec_url
While the scope of this document pertains to IODEF, any standard needing to reference an enumeration identified by a specially formatted string can use this method of providing structure after the standard has been published. In effect, this method provides a standardized interface for enumeration formats, thus allowing a loose coupling between a given standard and the enumeration identifiers it needs to reference now and in the future.
このドキュメントの範囲はIODEFに関係しますが、特別にフォーマットされた文字列によって識別される列挙を参照する必要がある標準は、標準が公開された後に構造を提供するこのメソッドを使用できます。実際、このメソッドは列挙型フォーマットの標準化されたインターフェイスを提供し、特定の標準と現在および将来参照する必要がある列挙型識別子との間の疎結合を可能にします。
Ensuring a proper mapping of enumeration reference ID elements to the correct SpecIndex is important. Potential consequences of not mapping correctly include inaccurate information in references and similar distribution of misinformation.
列挙参照ID要素を正しいSpecIndexに適切にマッピングすることが重要です。正しくマッピングされない場合の潜在的な結果には、参照に含まれる不正確な情報および同様の誤報の分布が含まれます。
Use of enumeration reference IDs from trusted sources is preferred to mitigate the risk of receiving and/or providing misinformation. Trust decisions with respect to enumeration reference providers are beyond the scope of this document. However, receiving an IODEF [IODEF] document containing an unknown ReferenceName (i.e., the SpecIndex does not exist in the IANA table) may indicate a misled or malicious source.
誤った情報を受け取ったり提供したりするリスクを軽減するには、信頼できるソースからの列挙参照IDを使用することをお勧めします。列挙参照プロバイダーに関する信頼の決定は、このドキュメントの範囲を超えています。ただし、不明なReferenceName(つまり、SpecIndexがIANAテーブルに存在しない)を含むIODEF [IODEF]ドキュメントを受け取った場合、誤解されたソースまたは悪意のあるソースを示している可能性があります。
This document establishes a container for publicly available enumeration values to be included in an IODEF [IODEF] document, and it is important to note the distinction between the enumeration value's format and the information conveyed by the value itself. While the enumeration value may hold information deemed to be private by relying parties, the enumeration format is likely not subject to privacy concerns.
このドキュメントは、IODEF [IODEF]ドキュメントに含まれる公に利用可能な列挙値のコンテナを確立します。列挙値の形式と値自体によって伝えられる情報の違いに注意することが重要です。列挙値は、証明書利用者によって非公開であると見なされる情報を保持する場合がありますが、列挙形式はプライバシーの問題の影響を受けない可能性があります。
However, if the Reference class includes an enumeration value in combination with other data in an IODEF [IODEF] document, the resulting combination could expose information. An example might include attack vectors or system descriptions used in a privacy-related incident. As such, the reader is referred to the IODEF [IODEF] Security Considerations section, which explicitly covers protecting IODEF [IODEF] documents in transit and at rest, ensuring
ただし、ReferenceクラスにIODEF [IODEF]ドキュメント内の他のデータと組み合わせて列挙値が含まれている場合、結果の組み合わせによって情報が公開される可能性があります。例には、プライバシー関連のインシデントで使用される攻撃ベクトルまたはシステムの説明が含まれる場合があります。そのため、読者はIODEF [IODEF]のセキュリティに関する考慮事項のセクションを参照します。このセクションでは、転送中および保存中のIODEF [IODEF]ドキュメントの保護を明示的にカバーし、
proper recipient authentication, data confidence levels, underlying transport security characteristics, and proper use of IODEF's restriction attribute.
適切な受信者認証、データ信頼レベル、基礎となるトランスポートセキュリティ特性、およびIODEFの制限属性の適切な使用。
This document specifies an enumeration reference identifier format. All fields, including abbreviation, are mandatory.
このドキュメントでは、列挙参照識別子の形式を指定します。省略形を含むすべてのフィールドは必須です。
Per this document, IANA has created and maintains the following registry:
このドキュメントに従って、IANAは次のレジストリを作成および維持しています。
Name of the Registry: "Security External Enumeration Registry"
レジストリの名前:「セキュリティ外部列挙レジストリ」
Location of Registry: http://www.iana.org/assignments/sec-ext-enum
Fields to record in the registry:
レジストリに記録するフィールド:
Full Name: The full name of the enumeration (i.e., the referenced specification) as a string from the printable ASCII character set [RFC20] with individual embedded spaces allowed. The ABNF [RFC5234] syntax for this field is:
フルネーム:列挙型のフルネーム(つまり、参照される仕様)は、個々の埋め込みスペースが許可された印刷可能なASCII文字セット[RFC20]からの文字列です。このフィールドのABNF [RFC5234]構文は次のとおりです。
FULL-NAME = 1*VCHAR *(SP 1*VCHAR)
Abbreviation: An abbreviation may be an acronym -- it consists of uppercase characters (at least two). Uppercase is used to avoid mismatches due to case differences. It is specified by this ABNF [RFC5234] syntax:
略語:略語は頭字語の場合があります-大文字(少なくとも2文字)で構成されています。大文字は、大文字と小文字の違いによる不一致を避けるために使用されます。これは、このABNF [RFC5234]構文で指定されます。
ABBREVIATION = 2*UC-ALPHA ; At least two UC-ALPHA = %x41-5A ; A-Z
Multiple registrations MAY use the same Abbreviation but MUST have different Versions.
複数の登録で同じ省略形を使用する場合がありますが、バージョンは異なる必要があります。
SpecIndex: This is an IANA-assigned positive integer that identifies the registration. The first entry added to this registry uses the value 1, and this value is incremented for each subsequent entry added to the registry.
SpecIndex:これは、登録を識別するIANA割り当ての正の整数です。このレジストリに追加された最初のエントリは値1を使用し、この値は、レジストリに追加された後続のエントリごとに増分されます。
Version: The version of the enumeration (i.e., the referenced specification) as a free-form string from the printable ASCII character set [RFC20] excepting white space, i.e., from VCHAR as defined in [RFC5234]. Some of the characters allowed in the version string are escaped when that string is used in XML documents (e.g., '<' is represented as <); the registered version string contains the unescaped ASCII character in all such cases.
バージョン:空白を除く、印刷可能なASCII文字セット[RFC20]からの自由形式の文字列としての列挙(つまり、参照された仕様)のバージョン。つまり、[RFC5234]で定義されているVCHARからの空白を除く。バージョン文字列で許可されている一部の文字は、その文字列がXMLドキュメントで使用されている場合はエスケープされます(たとえば、 '<'は&lt;として表されます)。登録されたバージョン文字列には、そのようなすべての場合にエスケープされていないASCII文字が含まれています。
Specification URI/Reference: A list of one or more URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. The URI SHOULD be a stable reference to a specific version of the specification. URIs that designate the latest version of a specification (which changes when a new version appears) SHOULD NOT be used.
仕様URI /参照:登録された仕様を取得できる1つ以上のURI [RFC3986]のリスト。登録された仕様は、そのURIから容易かつ公的に利用可能でなければなりません。 URIは、仕様の特定のバージョンへの安定した参照である必要があります(SHOULD)。仕様の最新バージョンを指定するURI(新しいバージョンが表示されると変更されます)は使用しないでください。
Initial registry contents:
レジストリの初期内容:
Full Name: Common Vulnerabilities and Exposures
氏名:一般的な脆弱性と露出
Abbreviation: CVE
略称:CVE
SpecIndex: 1
SpecIndex:1
Version: 1.0
バージョン:1.0
Specification URI/Reference: https://nvd.nist.gov/download.cfm#CVE_FEED
Allocation Policy: Specification Required [RFC5226] (which implies Expert Review [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 review the request and validate the appropriateness of the enumeration for the attribute. This review includes review of the specification associated with the request.
指定専門家は、そのようなWGが存在する場合(たとえば、ワーキンググループのメーリングリストへの電子メールを介して)、MILE(Managed Incident Lightweight Exchange)ワーキンググループまたはその後継者に相談することが期待されています。 Designated Expertは、リクエストを確認し、属性の列挙の妥当性を検証することが期待されています。このレビューには、リクエストに関連付けられた仕様のレビューが含まれます。
The Designated Expert is expected to ensure that the Full Name, Abbreviation, and Version are appropriate and that the information at the Specification URI is sufficient to unambiguously parse identifiers based on that specification. Additionally, the Designated Expert should prefer short Abbreviations over long ones.
Designated Expertは、フルネーム、略称、バージョンが適切であり、仕様URIの情報がその仕様に基づいて識別子を明確に解析するのに十分であることを保証することが期待されています。さらに、Designated Expertは、長い省略形よりも短い省略形を優先する必要があります。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688].
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠するXML名前空間とXMLスキーマについて説明します。
Registration for the IODEF enumeration reference format namespace:
IODEF列挙参照形式の名前空間の登録:
URI: urn:ietf:params:xml:ns:iodef-enum-1.0
Registrant Contact: See the "Authors' Addresses" section of this document.
登録者の連絡先:このドキュメントの「著者のアドレス」セクションを参照してください。
XML: None.
XML:なし。
Registration for the IODEF enumeration reference format XML schema:
IODEF列挙参照形式のXMLスキーマの登録:
URI: urn:ietf:params:xml:schema:iodef-enum-1.0
Registrant Contact: See the "Authors' Addresses" section of this document.
登録者の連絡先:このドキュメントの「著者のアドレス」セクションを参照してください。
XML: See Section 5, "The ReferenceName Schema", of this document.
XML:このドキュメントのセクション5「ReferenceNameスキーマ」を参照してください。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">
<!-- ========================================================== === ReferenceName === ========================================================== --> <xs:element name="ReferenceName"> <xs:complexType> <xs:sequence> <xs:element name="ID" type="xs:NCName"/> </xs:sequence> <xs:attribute name="specIndex" type="xs:integer" use="required"/> </xs:complexType> </xs:element> </xs:schema>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007, <http://www.rfc-editor.org/info/rfc5070>.
[IODEF] Danyliw、R.、Meijer、J。、およびY. Demchenko、「The Incident Object Description Exchange Format」、RFC 5070、2007年12月、<http://www.rfc-editor.org/info/rfc5070> 。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier(URI):Generic Syntax」、STD 66、RFC 3986、2005年1月、<http://www.rfc- editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF:ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/ rfc5234>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月、<http://www.rfc-editor.org/info/rfc3688>。
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20] Cerf、V。、「ネットワーク交換用のASCII形式」、STD 80、RFC 20、1969年10月、<http://www.rfc-editor.org/info/rfc20>。
[IODEFv2] Danyliw, R. and P. Stoecker, "The Incident Object Description Exchange Format v2", Work in Progress, draft-ietf-mile-rfc5070-bis-11, March 2015.
[IODEFv2] Danyliw、R。およびP. Stoecker、「The Incident Object Description Exchange Format v2」、Work in Progress、draft-ietf-mile-rfc5070-bis-11、2015年3月
[CCE] The MITRE Corporation, "Common Configuration Enumeration (CCE): Unique Identifiers for Common System Configuration Issues", website in "Archive" status, <http://cce.mitre.org>.
[CCE]ザMITER Corporation、「Common Configuration Enumeration(CCE):Unique Identifiers for Common System Configuration Issues」、ウェブサイト「アーカイブ」ステータス、<http://cce.mitre.org>。
[CPE] The MITRE Corporation, "CPE - Common Platform Enumeration", website in "Archive" status, <http://cpe.mitre.org>.
[CPE]マイターコーポレーション、「CPE-Common Platform Enumeration」、「アーカイブ」ステータスのウェブサイト、<http://cpe.mitre.org>。
[CVE] The MITRE Corporation, "CVE - Common Vulnerabilities and Exposures", <http://cve.mitre.org>.
[CVE]ザマイターコーポレーション、「CVE-Common Vulnerabilities and Exposures」、<http://cve.mitre.org>。
Acknowledgements
謝辞
The authors would like to thank Eric Burger for the recommendation to rely on XML, Roman D. Danyliw for his schema contribution and insight, and Tim Bray, Panos Kampanakis, Barry Leiba, Ted Lemon, Alexey Melnikov, Kathleen Moriarty, Takeshi Takahashi, Henry S. Thompson, and David Waltermire for their contributions and reviews.
著者は、XMLに頼るように勧めるEric Burger、スキーマへの貢献と洞察についてはRoman D. Danyliw、Tim Bray、Panos Kampanakis、Barry Leiba、Ted Lemon、Alexey Melnikov、Kathleen Moriarty、Takeshi Takahashi、Henryに感謝します。 S. Thompson、David Waltermireによる寄稿とレビュー。
Authors' Addresses
著者のアドレス
Adam W. Montville
アダムWモントビル
EMail: adam.w.montville@gmail.com
David Black EMC Corporation
デビッドブラックEMCコーポレーション
EMail: david.black@emc.com