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
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.
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.
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.
Takahashi, et al. Standards Track [Page 1]
RFC 7203 IODEF-SCI April 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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.
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.
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.
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.
The terminology used in this document follows the terminology defined in 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].
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.
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.
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.
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.
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].
4.1. IANA Table for Structured Cybersecurity Information
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.
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.
The initial IANA table has only one entry, as follows:
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.
The table is managed by IANA, following the allocation policy specified in Section 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
Takahashi, et al. Standards Track [Page 5]
RFC 7203 IODEF-SCI April 2014
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.
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".
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.
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.
+---------------------+ | New Class Name | +---------------------+ | ENUM SpecID |<>--(0..*)-[ RawData ] | STRING ext-SpecID |<>--(0..*)-[ Reference ] | STRING ContentID | +---------------------+
Figure 2: Basic Structure
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.
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."
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.
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
Takahashi, et al. Standards Track [Page 8]
RFC 7203 IODEF-SCI April 2014
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.
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.
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.
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:
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:
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:
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 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:
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:
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:
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:
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.
Takahashi, et al. Standards Track [Page 15]
RFC 7203 IODEF-SCI April 2014
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.
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.
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.
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"
Takahashi, et al. Standards Track [Page 20]
RFC 7203 IODEF-SCI April 2014
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.
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.
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.
6.2. Protection of Sensitive and Private Information
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.
Takahashi, et al. Standards Track [Page 21]
RFC 7203 IODEF-SCI April 2014
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.
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.
This document uses URNs to describe XML namespaces and XML schemata [XMLschemaPart1] [XMLschemaPart2] conforming to a registry mechanism described in [RFC3688].
The following IODEF structured cybersecurity information extension namespace has been registered:
URI: urn:ietf:params:xml:ns:iodef-sci-1.0
Registrant Contact: Refer to the Authors' Addresses section of this document.
XML: None.
The following IODEF structured cybersecurity information extension XML schema has been registered:
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.
Takahashi, et al. Standards Track [Page 22]
RFC 7203 IODEF-SCI April 2014
This memo creates the following registry, which is managed by IANA:
Name of the registry: "Structured Cybersecurity Information (SCI) Specifications"
Name of its parent registry: "Incident Object Description Exchange Format (IODEF)"
Namespace details: A registry entry for a Structured Cybersecurity Information Specification (SCI specification) consists of:
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].
Specification Name: A string containing the spelled-out name of the SCI specification in human-readable form.
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.
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.
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.
Initial registry contents: Only one entry, with the following values:
Namespace: urn:ietf:params:xml:ns:mile:mmdef:1.2
Specification Name: Malware Metadata Exchange Format
Allocation policy: Specification Required (which includes Expert Review) [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.
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Takahashi, et al. Standards Track [Page 24]
RFC 7203 IODEF-SCI April 2014
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS", RFC 6546, April 2012.
[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/>.
[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/>.
[XMLschemaPart2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <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/>.
[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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[CAPEC] The MITRE 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>.
[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>.
[CEE] The MITRE Corporation, "Common Event Expression (CEE)", <http://cee.mitre.org/>.
[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>.
[CWE] The MITRE Corporation, "Common Weakness Enumeration (CWE)", <http://cwe.mitre.org/>.
[CWSS] The MITRE Corporation, "Common Weakness Scoring System (CWSS(TM))", <http://cwe.mitre.org/cwss/>.
[MAEC] The MITRE Corporation, "Malware Attribute Enumeration and Characterization", <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>.
[OVAL] The MITRE 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>.
[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>.
[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>.