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
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.
这是一份互联网标准跟踪文件。
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/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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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是已经在使用的支持这种交换的工具之一。
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]。在这种情况下，网络安全信息包含广泛的结构化数据表示类型，可用于评估或报告资产或资产组的安全态势。此类结构化描述有助于更好地理解事件，同时实现更精简的自动化安全操作。因此，在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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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以嵌入结构化信息，这些类可以作为AdditionalData和RecordItem类的元素内容一致地嵌入到IODEF文档中[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表只有一个条目，如下所示：
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
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.
该表由IANA按照第7节规定的分配政策进行管理。
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
扩展类的SpecID属性（第4.5节）必须允许规范名称空间字段的值，但是不要求实现支持IANA表的所有规范，并且可以选择支持哪些规范。但是，至少需要支持初始IANA表中列出的规范，如第5节所述。如果一个实现接收到它不支持的数据，它可以通过查找IANA表或通知
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.
发送方无法解析数据。请注意，查找可以手动或自动完成，但不建议从IANA网站自动下载数据，因为它不是为多台设备大规模检索数据而设计的。
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数据模型中定义的所有数据类型。添加了一种数据类型：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、漏洞、评分、弱点、事件报告、验证和补救。图1描述了IODEF事件类[RFC5070]和新定义的类之间的关系。按照RFC 5070[RFC5070]的要求，它以统一建模语言（UML）语法表示。UML表示仅用于说明目的；元素在XML中指定，如第5.2节所定义。
+---------------+
| 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]
+---------------+
+---------------+
| 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 |
+---------------------+
+---------------------+
| 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:
三个属性的定义如下所示：
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：必需。枚举。规范的标识符，用于指定结构化信息的格式。该值应从IANA表（第4.1节）中列出的名称空间[XMLNames]或“private”中选择。值“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元素的值为“private”时，才能使用此属性
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:
同样，两个要素的定义如下所示：
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
原始数据：零或更多。XMLDATA。结构化信息的XML文档。这是一个完整的文档，根据规范及其由SpecID/ext SpecID标识的版本进行格式化。使用此元素时，写入者/发送者必须确保SpecID/ext SpecID指定的命名空间
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.
XML的模式是一致的；如果不是，则应首选SpecID标识的名称空间，并且应记录不一致性，以便人工更正问题。
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：参考[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是可选元素，但其中一个元素必须用于传递结构化信息。注意，为了避免混淆接收器，只能使用其中一个。
This document defines eight extension classes, as described in the subsections that follow.
本文档定义了八个扩展类，如下小节所述。
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是数据类型为“xml”的Incident.Method.AdditionalData元素的扩展类。它描述了事件或事件的攻击模式。建议方法类[RFC5070]在可用时包含扩展元素。AttackPattern类的结构如下所示：
+---------------------+
| AttackPattern |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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、漏洞、弱点和系统[RFC5070]类在可用时包含扩展元素。平台元素的结构如下所示：
+---------------------+
| Platform |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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:
漏洞是数据类型为“xml”的Incident.Method.AdditionalData元素的扩展类。扩展描述了在事件中暴露或被利用的漏洞。建议方法类包含扩展元素（只要可用）。漏洞元素的结构如下所示：
+---------------------+
| Vulnerability |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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.
评分是一个扩展类，用于描述安全性方面的严重性评分。建议漏洞和弱点类在可用时包含扩展元素。
A Scoring class is structured as follows:
评分等级的结构如下所示：
+---------------------+
| Scoring |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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:
缺点是数据类型为“xml”的Incident.Method.AdditionalData元素的扩展类。扩展描述了在事件中暴露或被利用的弱点类型。建议方法类包含扩展元素（只要可用）。弱点要素的结构如下所示：
+---------------------+
| Weakness |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |<>--(0..*)-[ Platform ]
| |<>--(0..*)-[ Scoring ]
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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是数据类型为“xml”的Incident.EventData.Record.RecordData.RecordItem元素的扩展类。该扩展嵌入结构化事件报告。建议RecordItem类在可用时包含扩展元素。EventReport元素的结构如下所示：
+---------------------+
| EventReport |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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:
验证是数据类型为“xml”的Incident.AdditionalData元素的扩展类。扩展元素描述了有关验证安全性的信息，例如用于处理事件的检查表。建议事件类包含扩展元素（只要可用）。验证类的结构如下所示：
+---------------------+
| Verification |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| STRING ContentID |
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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:
修正是数据类型为“xml”的Incident.AdditionalData元素的扩展类。扩展元素描述事件修复信息，包括说明。建议事件类包含扩展元素（只要可用）。修正类的结构如下所示：
+---------------------+
| Remediation |
+---------------------+
| ENUM SpecID |<>--(0..*)-[ RawData ]
| STRING ext-SpecID |<>--(0..*)-[ Reference ]
| String ContentID |
+---------------------+
+---------------------+
| 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：必需。枚举。见第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.
原始数据：零或更多。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.
符合本文件的实现必须能够发送和接收扩展IODEF文件，其中包含符合第4.1节所述初始IANA表中所列规范的XML文件，且无误。扩展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文档，用于检查实现是否符合强制实现功能。该文档包含恶意软件元数据交换格式（MMDEF）元数据。注意，元数据是由GENMDEF[MMDEF]和EICAR[EICAR]文件生成的。由于每行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>
<?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>
<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>
<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"?>
<?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: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: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: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: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"/>
<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>
</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>
</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"
底层消息传递格式IODEF提供了数据标记，以指示结构中特定类以及整个XML文档的敏感度级别。“限制”
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[RFC5070]中的四个属性值完成此操作。建议在传输之前在应用程序级别使用这些值，以酌情保护数据。RID[RFC6545]第9.1节定义了使用这些属性值作为触发器应用XML加密的标准机制。无论在交换中是否使用RID协议[RFC6545]及其关联的传输绑定[RFC6546]来提供数据的对象级安全性，以防止可能的中间系统或中间盒访问正在交换的数据，都可以使用该机制。在传输安全性或保密性有问题的领域，对每份报告应用XML数字签名[XMLDSIG]和/或加密将抵消这两个问题。建议应用程序使用数据标记来管理访问控制；但是，访问控制和这些控制的管理不在本文件的范围内。诸如使用标准语言（例如，可扩展访问控制标记语言[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[RCF645 ]，第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
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
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"
注册处名称：“结构化网络安全信息（SCI）规范”
Name of its parent registry: "Incident Object Description Exchange Format (IODEF)"
其父注册表的名称：“事件对象描述交换格式（IODEF）”
URL of the registry: <http://www.iana.org/assignments/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].
名称空间：一个URI[RFC3986]，用于标识已注册SCI规范使用的XML名称空间。在注册人未请求特定URI的情况下，IANA将在RFC 3553[RFC3553]之后为其分配统一资源名（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：一个或多个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节规定的一个或多个扩展类别列表。注册的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:
初始注册表内容：只有一个条目，具有以下值：
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
规范名称：恶意软件元数据交换格式
Version: 1.2
版本：1.2
Reference URI:
参考URI：
<http://standards.ieee.org/develop/indconn/icsg/mmdef.html>,
<http://grouper.ieee.org/groups/malware/malwg/Schema1.2/>
<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（托管事件轻量交换）工作组或其继任者（如果存在任何此类工作组）（例如，通过电子邮件发送至工作组的邮件列表）。指定专家将从提供的URI检索SCI规范，以检查规范的公共可用性并验证URI的正确性。指定专家的一项重要职责是确保注册的适用类别适用于注册的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.
我们要感谢EMC的David Black，他提供了慷慨的支持，特别是在IANA注册问题上。我们还要感谢米特尔的Jon Baker、乔治敦大学的Eric Burger、NIST的Paul Cichonski、Cisco的Panos Kampanakis、米特尔的Ivan Kirillov、IANA的Pearl Liang、米特尔的Robert Martin、Isode的Alexey Melnikov、US-CERT的Thomas Millar、EMC的Kathleen Moriarty、北约的Lagadec Philippe、，IECA，Inc.的Sean Turner、Yaana Technology的Anthony Rutkowski、苏黎世ETH的Brian Trammell、NIST的David Waltermier、IEEE的James Wendorf和NICT的Shuhei Yamaguchi感谢他们对本文件的真诚讨论和反馈。
[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恶意软件元数据交换格式工作组，“恶意软件元数据交换格式”，IEEE标准协会，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，“统一资源标识符（URI）：通用语法”，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，“事件对象描述交换格式”，RFC 50702007年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月。
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.
[RFC6545]Moriarty，K.，“实时网络间防御（RID）”，RFC 65452012年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，“可扩展标记语言（XML）1.0（第五版）”，W3C建议，2008年11月<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模式第1部分：结构第二版”，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模式第2部分：数据类型第二版”，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，“XML 1.0中的名称空间（第三版）”，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，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，2003年6月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[CAPEC] The MITRE Corporation, "Common Attack Pattern Enumeration and Classification (CAPEC)", <http://capec.mitre.org/>.
[CAPEC]MITRE公司，“常见攻击模式枚举和分类（CAPEC）”<http://capec.mitre.org/>.
[CCE] National Institute of Standards and Technology, "Common Configuration Enumeration (CCE)", <http://nvd.nist.gov/cce/index.cfm>.
[CCE]国家标准与技术研究所，“通用配置枚举（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，“通用配置评分系统（CCSS）：软件安全配置漏洞的度量”，NIST机构间报告7502，2010年12月<http://csrc.nist.gov/ 出版物/nistir/ir7502/nistir-7502\u CCSS.pdf>。
[CEE] The MITRE Corporation, "Common Event Expression (CEE)", <http://cee.mitre.org/>.
[CEE]米特尔公司，“共同事件表达（CEE）”<http://cee.mitre.org/>.
[CPE] National Institute of Standards and Technology, "Common Platform Enumeration", June 2011, <http://scap.nist.gov/specifications/cpe/>.
[CPE]国家标准与技术研究所，“公共平台枚举”，2011年6月<http://scap.nist.gov/specifications/cpe/>.
[CVE] The MITRE Corporation, "Common Vulnerabilities and Exposures (CVE)", <http://cve.mitre.org/>.
[CVE]米特尔公司，“常见漏洞和风险（CVE）”<http://cve.mitre.org/>.
[CVRF] ICASI, "The Common Vulnerability Reporting Framework (CVRF)", <http://www.icasi.org/cvrf>.
[CVRF]ICASI，“通用漏洞报告框架（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，“共同脆弱性评分系统（CVSS）及其对联邦机构系统的适用性”，NIST机构间报告74352007年8月<http://csrc.nist.gov/publications/nistir/ ir7435/NISTIR-7435.pdf>。
[CWE] The MITRE Corporation, "Common Weakness Enumeration (CWE)", <http://cwe.mitre.org/>.
[CWE]米特公司，“共同弱点枚举（CWE）”<http://cwe.mitre.org/>.
[CWSS] The MITRE Corporation, "Common Weakness Scoring System (CWSS(TM))", <http://cwe.mitre.org/cwss/>.
[CWSS]米特尔公司，“共同弱点评分系统（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安全专家组，“反恶意软件测试文件”，2003年<http://www.eicar.org/86-0-Intended-use.html>.
[MAEC] The MITRE Corporation, "Malware Attribute Enumeration and Characterization", <http://maec.mitre.org/>.
[MAEC]MITRE公司，“恶意软件属性枚举和特征描述”<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，“开放式清单交互语言（OCIL）2.0版规范”，NIST机构间报告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/>.
[椭圆形]米特尔公司，“开放脆弱性和评估语言（椭圆形）”<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，“安全内容自动化协议（SCAP）的技术规范：SCAP版本1.2”，NIST特别出版物800-126第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.“可扩展访问控制标记语言（XACML）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，“可扩展配置清单描述格式规范（XCCDF）第1.2版（草案）”，NIST机构间报告7275，第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签名语法和处理（第二版）”，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
Takeshi Takahashi国立信息和通信技术研究所4-2-1 Nukui Kitamachi Koganei 184-8795日本东京
Phone: +80 423 27 5862
EMail: takeshi_takahashi@nict.go.jp
Phone: +80 423 27 5862
EMail: takeshi_takahashi@nict.go.jp
Kent Landfield McAfee, Inc. 5000 Headquarters Drive Plano, TX 75024 USA
美国德克萨斯州普兰诺市肯特兰德菲尔德麦卡菲公司总部大道5000号，邮编75024
EMail: Kent_Landfield@McAfee.com
EMail: Kent_Landfield@McAfee.com
Youki Kadobayashi Nara Institute of Science and Technology 8916-5 Takayama, Ikoma 630-0192 Nara Japan
Youki Kadobayashi Nara科学技术研究所日本奈良市高山8916-5号，邮编630-0192
EMail: youki-k@is.aist-nara.ac.jp
EMail: youki-k@is.aist-nara.ac.jp