A DITA Open Toolkit Plug-in for Packaging Security Content
Official contribution of the National Institute of Standards and Technology; not subject to copyright in the United States.
Table of Contents
Official contribution of the National Institute of Standards and Technology; not subject to copyright in the United States.
Table of Contents
The Security Content Automation Protocol (SCAP — pronounced
standard  contains a family of Extensible Markup Language
(XML)  vocabularies for representing security content. System
administrators use configuration checking and vulnerability scanning software tools
produce and consume SCAP data to secure servers, workstations, networks, and other
deployed hardware and applications. United States government agencies and their service
providers are required to use SCAP-conforming software products  and content  for security policy
compliance checking and continuous monitoring of information technology assets. The
private sector also relies on SCAP products and content for ensuring its information
systems are protected. For example, banks and credit card companies use SCAP-conforming
security configuration checklists  to verify compliance with
the Payment Card Industry Data Security Standard .
Additionally, some private sector organizations use SCAP's XML vocabularies to develop
security content for internal use, or to provide to their customers .
Central to the SCAP standard is the source data stream collection data model, an XML schema  defined in NIST Special Publication (SP) 800-126 (Technical Specification for the Security Content Automation Protocol) . This schema specifies how to package, into a self-contained entity, the collective input required for an SCAP-conforming software product to assure a system is not overly vulnerable to cyberattack. The schema enables lossless exchange of security content between SCAP-conforming software products, allowing SCAP users to avoid vendor lock-in and to share source data stream collections within their organization or with partners.
But the same SCAP source data stream collection schema that promotes interoperability and shareability among SCAP-conforming software products also makes source data stream collection authoring hard. The reason why is that no schema can single-handedly meet the needs of SCAP scanner tool developers and SCAP content authors. Section 3 of this paper discusses use of the Darwin Information Typing Architecture (DITA) standard  to define a new source data stream collection XML document type for content authors. This new document type, which specializes DITA's map type, does not replace the SP 800-126 schema. Instead, the new DITA document type serves as an alternative that makes it easier for authors to express a source data stream collection. Section 4 describes SCAP Composer, a software application that implements the new, author-friendly document type and transforms valid instances of it into valid instances of the SP 800-126 schema. SCAP composer uses the DITA Open Toolkit , an open source DITA processor. The National Institute of Standards and Technology expects to make SCAP Composer available as open source software in late 2019.
Before delving into the authoring schema and application, it is important to
understand why they are needed. Section 2 of
this paper provides an overview of the NIST SP 800-126 schema's underlying data model
— highlighting its advantages and drawbacks. But first it is instructive to see
an example of SCAP in action. Figure 1 illustrates what an
SCAP-conforming software product can do with a source data stream collection. The
software depicted enables a user to open an SCAP source data stream collection file,
view security checklists, and perform configuration and vulnerability scans. The
checklists reside in the source data stream collection's checklist component, whose
content conforms to the Extensible Configuration Checklist Description Format (XCCDF)
specification . XCCDF an XML vocabulary SCAP uses to
represent security configuration rules. Clicking the
Scan button causes
the target system — either the local computer or a remote system — to be checked against
the checklist to determine whether the checklist's rules are satisfied. Using this
software to scan a remote target requires that an SCAP scanning client be installed
remote system, and that the network allows secure upload of the SCAP source data stream
collection file to that system.
This software also provides a user interface for selecting a subset of rules from a checklist component, assigning parameters to the subset, and saving the result as a tailoring document. The tailoring document references the original checklist component without modifying the XML resource it contains, and thus promotes reuse of SCAP content.
The preceding discussion of Figure 1 suggests the following important requirements that the SP 800-126 schema must address:
Self-containment: A source data stream collection must bundle all information needed to perform a scan on the target, without relying on references to external files or resources. Self-containment facilitates scans of remote targets by ensuring a complete transmission of information between the host system initiating the scan and target. Also, a self-contained source data stream collection may be digitally signed in its entirety to ensure integrity and trustworthiness.
Reversibility: A source data stream collection must bundle its components such that the XML resources the components contain are unmodified from their original states, and any XML resource can be extracted and re-bundled into a new collection without modification to the XML. Reversibility makes it easier to reuse SCAP content such as the checklist shown in Figure 1.
Figure 2 provides a high-level example of an SCAP source data stream collection containing two data streams and five components. Each component encapsulates an XML resource conforming to an SCAP vocabulary schema (such as the schema for checklists). Each data stream represents a specific SCAP use case, for example, checking the configuration of a server running Ubuntu Linux version 16.04. Data streams reference components, as shown by the arrows. More than one data stream can reference the same component.
Figure 2 does not capture two subtleties of SCAP source data
stream collections. The first has to do with the part-whole relationship between a
component and the XML resource it encapsulates. An XML resource typically exists outside
the scope of a source data stream collection. For example, a checklist contained in
component may have been copied from its original residing in a security checklist
repository. Therefore, one can think of a component as a snapshot of an XML resource
a specific point in time. Figure 3 illustrates this idea with
two distinct components, each in a distinct source data stream collection, encapsulating
the same XML resource. To capture this
snapshot notion, the SP 800-126
schema represents a component as a wrapper element, with a time stamp attribute,
surrounding a copy of the XML resource.
The second subtlety pertains to component references — shown as directional arrows in Figure 2 and Figure 3. At first glance, it seems that an XLink simple link  can easily represent a component reference. But there is a less-than-obvious complication. A data stream collection might have two components, with one component's XML resource referencing the other component's XML resource. In fact, it is common in SCAP for a source data stream to have both a component containing a checklist resource and a component containing a check resource described in the Open Vulnerability Assessment Language (OVAL). OVAL  is an XML vocabulary for representing system configuration information, tests and states. An XCCDF checklist rule typically references check definitions in an OVAL resource that are used to determine if the current state of a system satisfies the rule criteria. XCCDF checklist rules and OVAL definitions together usually make up most of the XML data in a source data stream collection.
Figure 4 shows a source data stream collection containing
checklist and check components. The directional arrow labeled
indicates a reference from within a checklist rule to a check definition (each
represented by a small square inside the XML resource). The problem is that the act
encapsulating the checklist and check resources into components in a source data stream
collection breaks the internal references from checklist rules to check definitions.
an example, consider the following reference to a check definition from within a
<check-content-ref href="oval.xml" name="oval:nist.validation.family:def:1"/>The referenced check definition's identifier is
oval:nist.validation.family:def:1, and the definition is in a check resource whose Uniform Resource Locator (URI), relative to the checklist resource URI, is
oval.xml. This relative URI reference is useless for an SCAP-conforming software product consuming the source data stream shown in Figure 4. What the SCAP-conforming software product needs to know is where to find the check component contained inside the source data stream collection, not the check resource outside the source data stream collection's scope. However, SCAP's reversibility requirement dictates that modifying the encapsulated XML resource inside a component is not allowed.
The SP 800-126 schema solves this problem by requiring that a data stream referencing a component with internal references to a location inside another component include a mapping. The mapping enables the source data stream collection consumer to translate internal references within the encapsulated XML resource to the corresponding component location within the source data stream collection. Figure 4 shows the mapping as dotted lines indicating a pair of URI references. The first URI reference is the relative URI reference inside the checklist rule. The second is the reference to the check component in the source data stream collection.
The SP 800-126 schema expresses the mapping using XML Catalogs standard  syntax. Figure 5 shows a possible
XML representation of the reference to the checklist component shown in Figure 4. The
component-ref element has an XLink
simple link pointing to the component, whose identifier is
scap_gov.nist_comp_content-xccdf. An embedded XML Catalogs
uri element tells the source data stream collection consumer to
translate internal references to
oval.xml from within the checklist
resource to references to the URI of the data stream component reference that points
the check component,
<component-ref id="scap_gov.nist_cref_content-xccdf" xlink:href="#scap_gov.nist_comp_content-xccdf"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"> <uri name="oval.xml" uri="#scap_gov.nist_cref_content-oval"/> </catalog> </component-ref>
The long, verbose identifiers in Figure 5 are the result of
a SP 800-126 requirement that data stream collections, data streams, components and
component references have globally-unique identifiers (GUIDs). To this end, the schema
requires the identifier format conventions shown in Table I. An
identifier must be underscore-delimited, beginning with
scap, followed by
a reverse domain name system (DNS) style substring associated with the creator, followed
by a substring indicating the object type being identified (
comp), and ending
with an XML NCName . For example, a data stream containing the
component reference shown in Figure 5 could have
scap_gov.nist_datastream_example as its identifier. By requiring GUIDs,
SP 800-126 reduces the likelihood of conflicting identifiers within a source data
collection or identifiers that conflict with those in another organization's source
|Object||Identifier Format Convention|
|Data Stream Collection||scap_reverseDNS_collection_name|
To recap, the SP 800-126 self-containment and reversibility requirements — although important for component integration and interoperability — result in added schema complexity and added pain for source data stream collection authors. The GUID format minimizes the possibility of ambiguous or dangling references, but it results in verbose, repetitive, and author-unfriendly identifiers. The SP 800-126 schema's underlying data model, hampered by XML's inability to intuitively express part-whole relationships between a component and its encapsulated XML resource, represents component references as first class objects using XML Catalogs to handle translation of resource-to-resource references from within the source data stream collection. This added complexity makes authoring a chore and impedes human readability of source data stream collections. Appendix A shows the source data stream collection XML that was read into the SCAP scanner software application shown in Figure 1. Figure 6 shows a less verbose, easier-to-read, and more author-friendly equivalent representation of this source data stream collection using the new DITA type discussed in Section 3.
This section describes a new DITA element type for source data stream collections. The source data stream collection element type design arose from a conceptual implementation-agnostic information model developed to gain a deeper understanding of source data stream collections and how they achieve self-containment and reversibility. Reference  discusses the conceptual model and how it paved the way for an earlier DITA application. This paper provides a more implementation-focused perspective, with expanded discussions of DITA specialization in this section and DITA-OT implementation in Section 4.
DITA, developed by the Organization for the Advancement of Structured Information Standards (OASIS), is a standardized XML-based architecture for authoring, managing, reusing and transforming technical content . DITA does not specify a schema or set of schemas per se. Instead, the DITA architecture provides:
A set of architectural building blocks for forming XML vocabularies called element types. These building blocks provide a variety of useful features for enabling content management and reuse.
Two basic element types created from the building blocks: the topic and the map. A topic is chunk of information. A map is structured collection of references to topics, other maps, and non-DITA resources such as, for example, XML documents created using non-DITA vocabularies.
Rules for creating new element types that inherit their processing semantics from existing DITA element types. A new element type is a specialization of the element type from which it inherits. The architecture provides rules for creation of specialized element and attribute domains, which are then collectively used to define specialized element types. DITA vocabulary developers may also specify constraints on a vocabulary's elements and attributes. Element and attribute domain specializations can be reused to create additional new element types, and thus promote modular and interoperable DITA development. Any new element type must be a specialization of an existing DITA vocabulary. Specialization makes DITA unique among other XML technologies in that implementations of specialized element types automatically inherit the functionality of DITA-conforming implementations of the element type specialized .
Rules for creating an XML schema for authoring documents conforming to a DITA element type. This schema is called a document type shell. The document type shell is used only for authoring. DITA processing is determined by the DITA document's architectural attributes, not the document type shell used to author it.
The burden of following the rules for creating specializations and document type shells is a downside of DITA. But this burden falls mostly on developers of specializations. Content authors are not exposed to this burden. A DITA document's architectural attributes are defined by the document type shell using default values, hiding them — and their complexity — from content authors. More importantly, software application developers implementing a DITA specialization gain the benefit of inherited functionality, resulting in reduced implementation cost .
The source data stream collection element type is a specialization of DITA's map element type. The map element type was chosen for specialization because SCAP source data stream collections and data streams are map-like in nature. Like a DITA map, a source data stream collection is essentially a structured collection of components and references to components. Each source data stream collection element inherits from one of the following elements from the DITA map element type:
map: A DITA map's top-level element.
topicref: References a topic or external (non-DITA) resource.
Can also aggregate groups of nested
keydef: Creates an alias for a file path or short piece of
@props, a DITA attribute from which new metadata attributes can be specialized.
Table II lists all the XML elements and attributes in the
source data stream collection element type's document type shell. The leftmost column
contains the element names. The second column from the left specifies the DITA map
which the source data stream collection element inherits. The third column from the
shows the element's content model.
? indicate zero or more occurrences, one or more occurrences, and
optional, respectively. The rightmost column specifies each element's attributes.
|Element||Inherits From||Content Model||Attributes|
scapDataStreamCollection, the source data stream collection's root
element, has three attributes.
@reverseDNS provides the
reverseDNS portion for all GUIDs in the collection.
scapName provides the name portion of the
schematronVersion specifies which version of the SCAP
Requirements Schematron  schema to use for validating that a
transformation (discussed in Section 4) of the DITA map conforms to
SP 800-126 requirements.
scapComponent represents a component.
@scope are attributes defined in the DITA
standard. In DITA,
@keys provides a list of key names, but the source data
stream collection element type further constrains it to represent a single key name.
This succinct name may be used elsewhere in the DITA map in place of the XML resource
URI (represented by
@href) that the component encapsulates. This attribute
enables source data stream collection authors to specify the URI in just one place
use the key name elsewhere in the DITA map. The optional
@href points to a local resource (the default) or an
external resource on the Internet.
scapDataStream represents a source data stream.
provides the name portion of the data stream's GUID.
@useCase correspond to required
attributes in the SP 800-126 schema specifying the version of the SCAP standard to
the data stream content should conform, and the data stream's use case.
scapChecks aggregate groups of dictionary component references,
checklist component references, and check component references, respectively.
scapOcilRef are all component references.
@keyref, a DITA
attribute, enables the author to specify the component being referenced using the
name corresponding to the
saving authors the trouble of having to type the same URI multiple times, and minimizing
the number of DITA map revisions needed if the URI changes.
references a dictionary component that assigns identifiers to platforms (hardware,
operating system, or software application) using SCAP's Common Platform Enumeration
(CPE) nomenclature. These identifiers are typically used in checklist and check
components for checking the presence of a device, operating system, or software product
on the target system.
scapOcilRef reference a benchmark
component, tailoring component, check component containing an OVAL check resource,
check component containing an Open Checklist Interactive Language (OCIL) check resource,
respectively. OCIL is used for checking state via a human-oriented collection of
information when OVAL-based methods are not feasible.
scapUri together represent the mapping
(shown in Figure 4) translating internal references within an
encapsulated XML resource to the corresponding component location within the source
@keyref is used to specify the component whose
encapsulated XML resource is being referenced from within the component referenced
the parent element of
scapExternalLinks. The optional
@localUri is for overriding the URI obtained when DITA processing
resolves the key reference specified in
@keyref. This is needed when the
referencing and referenced XML resources are in different local directories, or when
is external and the other is local.
Figure 6 lists a DITA map representing the data stream
collection shown in Appendix A. This data stream collection contains
one data stream and four components referenced by the data stream. The dictionary
component and the check component referenced by the dictionary component encapsulate
dictionary and check resources in the same directory as the DITA map. The benchmark
component encapsulates a checklist resource in a subdirectory. Another check component
encapsulates a check resource located externally (and has the value
@scope). Because the dictionary and
checklist resources both reference check resources, the dictionary component reference
and benchmark component references contain
<scapDataStreamCollection reverseDNS="gov.nist" scapName="example" schematronVersion="1.3"> <scapComponent href="checklist-content/xccdf.xml" keys="content-xccdf"/> <scapComponent scope="external" keys="content-oval" href= "https://raw.githubusercontent.com/usnistgov/sctools/master/dita/examples/ nist-example/checklist-content/oval.xml"/> <scapComponent href="cpe-oval.xml" keys="content-cpe-oval"/> <scapComponent href="cpe-dictionary.xml" keys="content-cpe-dictionary"/> <scapDataStream scapName="example" scapVersion="1.3" useCase="CONFIGURATION"> <scapDictionaries> <scapCpeListRef keyref="content-cpe-dictionary"> <scapExternalLinks> <scapUri localUri="cpe-oval.xml" keyref="content-cpe-oval"/> </scapExternalLinks> </scapCpeListRef> </scapDictionaries> <scapChecklists> <scapBenchmarkRef keyref="content-xccdf"> <scapExternalLinks> <scapUri localUri="oval.xml" keyref="content-oval"/> </scapExternalLinks> </scapBenchmarkRef> </scapChecklists> <scapChecks> <scapOvalRef keyref="content-oval"/> <scapOvalRef keyref="content-cpe-oval"/> </scapChecks> </scapDataStream> </scapDataStreamCollection>
The DITA Open Toolkit (DITA-OT)  meets the DITA standard's
requirements for a specialization-aware, output-producing DITA processor. As such,
DITA-OT merges topics referenced in a map and resolves key references, eliminating
need for custom transformation code to perform the functions. Because it is
specialization-aware, DITA-OT inherits the processing behavior for elements in the
source data stream collection element type from their supertypes. Thus,
keydef's processing behavior,
map's processing behavior,
and the elements based on
processing behavior. As a result, DITA-OT built-in functionality greatly reduced the
coding effort required to implement SCAP Composer.
DITA-OT has a modular architecture with an extensible plug-in mechanism. SCAP Composer consists of two DITA-OT plug-ins:
A document type plug-in implementing the source data stream collection element type discussed in Section 3. The source data stream collection document type shell is defined using RELAX NG compact syntax  with annotations to support default attributes .
A transformation plug-in, requiring the document type plug-in, that
converts a source data stream collection DITA map into an SCAP source data
stream collection XML document. The transformation plug-in uses the NIST
SCAP Content Validation Tool , also known as
SCAPVal, to check conformance of individual XML resources and the
converted source data stream to SP 800-126 requirements.
nxmlmode for authoring and validating XML documents against a RELAX NG schema, and a standalone DITA-OT installation. Both deployment options were tested with numerous source data stream collection DITA maps, including the source data stream collection DITA map in Figure 6.
SCAP Composer's source code consists principally of the following:
RELAX NG compact syntax definitions for the specialized element and attribute domains, constraints, document type shell, and public and system identifiers needed for the source data stream collection specialized map type. The document type plug-in contains these definitions.
Extensible Style Language transformation (XSLT) 
code that extracts data from the source data stream collection DITA map and
generates SCAP output. This code is part of the transformation plug-in. The
code leverages DITA-OT built-in transformation logic and therefore only
needs to perform tasks beyond basic DITA processing, such as transforming
scapURI element and extracting values of attributes needed
An Ant script for managing the various transformation steps. Ant  is a tool for declaring a sequence of build actions in XML. DITA-OT provides an Ant script declaring a default sequence of extensible transformation steps. Every plug-in has its own Ant script, which may use, extend, or skip steps in the default Ant script.
The flowchart in Figure 7 illustrates the workflow defined by the
transformation plug-in's Ant script. This workflow begins when DITA-OT is invoked
sds (short for
collection) as the output format argument. The plug-in accepts two
additional optional arguments:
sds.scapval: The path to the SCAPval Java Archive (JAR)
@key attribute value of
one of the input DITA map's
Processing begins with a preprocessing stage common to all transformation plug-ins.
The preprocessing includes the merging and key reference resolution operations mentioned
sds.componentkey is specified, SCAPval validates the XML
resource pointed to by the key's
scapComponent element, and a validation
report is produced as output (assuming
sds.scapval is also specified; if
not, processing stops with an error message). If
sds.componentkey is not
specified, the plug-in generates a single file in SP 800-126 schema format from the
map and XML resources. If
sds.scapval is specified, the plug-in then
validates the generated file and produces a validation report.
Suppose the source data stream collection DITA map file name is
nist-example-hybrid.ditamap, and DITA-OT is invoked as
dita -i nist-example-hybrid.ditamap -f sds --sds.scapval=scapval-1.3.2.jarSCAP Composer will produce two outputs: the transformation result shown in Appendix A and a SCAPval-generated validation report of the transformation result. Figure 8 shows the beginning summary section of the validation report. The rest of the report provides detailed results for each validation requirement tested. Reference  provides more information regarding SCAP validation requirements, their associated test procedures, and which test procedures include validation using SCAPval.
SCAP Composer takes an incremental approach to aiding SCAP content authors. This is both a limitation and a strength. The limitation is that SCAP Composer only helps with creating source data stream collections. It does not offer any help with creating the XML resources encapsulated in a source data stream collection. Checklist and check resources are large, highly complex, and hard to create using conventional XML editing software applications. Reference  explores the feasibly of developing DITA element types for representing checklist rules and profiles (collections of rules), but more implementation and testing is needed to scale the proof-of-concept demonstration to real-world rule sets.
SCAP Composer's incrementalism is a strength in that its limited scope makes it easy both to deploy and integrate with other SCAP content development aids. SCAP Composer has no software dependencies other than DITA-OT, which runs in all common operating systems. SCAP Composer is not tethered to a larger SCAP software product or content repository infrastructure. This flexibility enables SCAP Composer to contribute to a larger authoring and content management solution by providing the piece responsible for creating source data stream collections, leaving it up to other mechanisms to produce and manage the XML resources to be encapsulated.
DITA-OT's extensible and customizable transformation workflow offers many possibilities for combining DITA processing with other capabilities. SCAP Composer exploits this to combine transformation from DITA to SP 800-126 XML with SCAPval validation and report generation. DITA-OT flexibility even allows a workflow with no DITA processing at all, as demonstrated by DITA-OT plug-in from Jason Fox  that automatically displays a random cat picture or XKCD comic strip as a splash screen while waiting for another plug-in's transformation to complete.
Although Fox's plug-in sounds frivolous, the same underlying idea can be practical
the context of SCAP Composer. For example, a future version of SCAP Composer could
supplemented with a
decompose plug-in whose input includes an SP 800-126
schema-conforming source data stream collection, and whose output is the set of XML
resources encapsulated by the components contained in the collection. Such a plug-in
would perform no DITA processing yet would add useful and complementary functionality.
Software products that produce and manage SCAP are part of the broader research and development goal of modeling cybersecurity compliance requirements in a manner enabling them to be structured, organized, executed and reused efficiently . SCAP Composer is a small contribution to this goal. Other efforts, such as the Compliance as Code open source project , are more ambitious. Compliance as Code contains a collection of compliance rules written in a YAML  format, OVAL XML fragments, as well as code fragments for automated remediation of compliance issues. A collection of build scripts generates SCAP source data stream collections and remediation scripts from the fragments. Another effort, ConfigValidator , is a system that checks a variety of targets — including running containers and cloud-based environments — for compliance with configuration rules written in a YAML-based declarative language.
The Compliance as Code and ConfigValidator projects have broader scopes and implement far more capabilities than SCAP Composer. However, both rely on one-off collections of scripts for processing compliance rules written in non-XML formats. Lack of standardization is a barrier to reusing the Compliance as Code and ConfigValidator technology in other projects. Also, both projects reject the use of XML for authoring compliance rules, claiming XML is hard for humans to edit. But, as SCAP Composer shows, XML is not the problem. The real problem is that, as discussed in Section 2, no single schema can meet all implementation requirements.
This paper describes SCAP Composer, a novel software application for creating and validating SCAP source data stream collections. What makes SCAP Composer unique is its use of DITA specialization and the DITA Open Toolkit to simplify the reuse of SCAP content while adhering to self-containment and reversibility requirements. Integration with SCAPval adds the ability for users to conveniently check source data stream collections and their components for conformance to SP 800-126. Other efforts to facilitate authoring and reuse of SCAP content rely on ad hoc authoring formats and extract/transform/load workflows, making them difficult to maintain or deploy in new projects. SCAP Composer is based on DITA, a robust architecture specifically for authoring and organization of topic-oriented information. Because it is standards-based and has a small footprint and scope, SCAP Composer is easy to integrate into a variety of SCAP authoring and deployment scenarios.
The author thanks his colleagues at the National Institute of Standards and Technology and the anonymous Balisage reviewers for helpful comments and feedback on earlier versions of this paper.
This appendix lists the SCAP-conforming XML read into the scanner software shown in Figure 1. To save space, the XML resource markup is not shown.
<sds:data-stream-collection xmlns:sds="http://scap.nist.gov/schema/scap/source/1.2" xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="scap_gov.nist_collection_example" schematron-version="1.3"> <sds:data-stream id="scap_gov.nist_datastream_example" scap-version="1.3" timestamp="2019-04-05T20:57:48.814-04:00" use-case="CONFIGURATION"> <sds:dictionaries> <sds:component-ref id="scap_gov.nist_cref_content-cpe-dictionary" xlink:href="#scap_gov.nist_comp_content-cpe-dictionary"> <cat:catalog> <cat:uri name="cpe-oval.xml" uri="#scap_gov.nist_cref_content-cpe-oval"/> </cat:catalog> </sds:component-ref> </sds:dictionaries> <sds:checklists> <sds:component-ref id="scap_gov.nist_cref_content-xccdf" xlink:href="#scap_gov.nist_comp_content-xccdf"> <cat:catalog> <cat:uri name="oval.xml" uri="#scap_gov.nist_cref_content-oval"/> </cat:catalog> </sds:component-ref> </sds:checklists> <sds:checks> <sds:component-ref id="scap_gov.nist_cref_content-oval" xlink:href="#scap_gov.nist_comp_content-oval"/> <sds:component-ref id="scap_gov.nist_cref_content-cpe-oval" xlink:href="#scap_gov.nist_comp_content-cpe-oval"/> </sds:checks> </sds:data-stream> <sds:component id="scap_gov.nist_comp_content-xccdf" timestamp="2019-04-05T20:57:48.814-04:00"> <Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" ...> ...</Benchmark> </sds:component> <sds:component id="scap_gov.nist_comp_content-oval" timestamp="2019-04-05T20:57:48.814-04:00"> <oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" ...> ...</oval_definitions> </sds:component> <sds:component id="scap_gov.nist_comp_content-cpe-oval" timestamp="2019-04-05T20:57:48.814-04:00"> <oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" ...> ...</oval_definitions> </sds:component> <sds:component id="scap_gov.nist_comp_content-cpe-dictionary" timestamp="2019-04-05T20:57:48.814-04:00"> <cpe-list xmlns="http://cpe.mitre.org/dictionary/2.0" ...> ...</cpe-list> </sds:component> </sds:data-stream-collection>
 Quinn S, Scarfone K, Waltermire D (2012) Guide to Adopting and Using the Security Content Automation Protocol (SCAP) Version 1.2 (Draft), NIST Special Publication 800-117.
 SCAP Validated Products and Modules - Security Content Automation Protocol Validation Program. Available at https://csrc.nist.gov/Projects/scap-validation-program/Validated-Products-and-Modules
 Guide to the Secure Configuration of Red Hat Enterprise Linux 7. OpenSCAP Security Guide. Available at https://static.open-scap.org/ssg-guides/ssg-rhel7-guide-pci-dss.html
 Payment Card Industry (PCI) Data Security Standard (2018), Version 3.2.1.
 OVAL Repository: Top Contributors. Available at https://oval.cisecurity.org/repository/top-contributors
 Waltermire D, Quinn S, Booth H, Scarfone K, Prisaca D (2018) The technical specification for the security content automation protocol (SCAP) version 1.3 (National Institute of Standards and Technology, Gaithersburg, MD), NIST SP 800-126r3. doi:https://doi.org/10.6028/NIST.SP.800-126r3
 DITA Version 1.3 Specification (2018) (Organization for the Advancement of Structured Information Standards), OASIS Standard. Available at http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-part0-overview.html
 Waltermire D, Schmidt C, Scarfone K, Ziring N (2011) Specification for the Extensible Configuration Checklist Description Format (XCCDF) Version 1.2, NIST Interagency Report 7275 Revision 4. Available at http://csrc.nist.gov/publications/PubsNISTIRs.html
 XML Catalogs (2005), OASIS Standard V1.1. Available at https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html
 Lubell J (2018) A New SCAP Information and Data Model for Content Authors. Critical Infrastructure Protection XII, eds Staggs J, Shenoi S (Springer International Publishing), pp 127–146. doi:https://doi.org/10.1007/978-3-030-04537-1_8. Available at https://www.nist.gov/publications/new-scap-information-model-and-data-model-content-authors
 Kimber E (2012) DITA for Practitioners Volume 1: Architecture and Technology (XMLPress).
 Information technology — Document Schema Definition Language (DSDL) — Part 3: Rule-based validation — Schematron (2016) (International Organization for Standardization), ISO/IEC 19757-3. Available at http://schematron.com
 Information technology — Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG (2008) (International Organization for Standardization), ISO/IEC 19757-2. Available at https://relaxng.org
 Cook M, Quinn S, Waltermire D, Prisaca D (2018) Security content automation protocol (SCAP) version 1.3 validation program test requirements (National Institute of Standards and Technology, Gaithersburg, MD), NIST IR 7511r5. doi:https://doi.org/10.6028/NIST.IR.7511r5
 Lubell J (2017) Using DITA to Create Security Configuration Checklists: A Case Study. Proceedings of Balisage: The Markup Conference, Balisage Series on Markup Technologies. (Washington, DC). doi:https://doi.org/10.4242/BalisageVol19.Lubell01
 Steffens A, Lichter H, Moscher M (2018) Towards Data-driven Continuous Compliance Testing. 3rd Workshop on Continuous Software Engineering (Ulm, Germany), pp 78–84.
 Ben-Kiki O, Evans C (2009) YAML Ain’t Markup Language (YAML™) Version 1.2, 3rd Edition.
 Baset S, Suneja S, Bila N, Tuncer O, Isci C (2017) Usable declarative configuration specification and validation for applications, systems, and cloud. Proceedings of the 18th ACM/IFIP/USENIX Middleware Conference on Industrial Track - Middleware ’17 (ACM Press, Las Vegas, Nevada), pp 29–35. doi:https://doi.org/10.1145/3154448.3154453
 Certain commercial and third-party products and services are identified in this paper to foster understanding. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.
 Although SCAP allows for source data stream collections to contain multiple data streams, it is common for a collection to contain only a single data stream.
 To help reduce the sea of acronyms in this paper, unless explicitly stated
otherwise, the terms
checklist resource imply XCCDF as the
checklist language. Similarly,
check resource imply OVAL as the check
 SCAPval is a command-line application that validates SCAP source and result data streams against SP 800-126 XML schemas, and encapsulated XML resources against their XML schemas. SCAPval uses Schematron  to perform additional validations. SCAPval's output is a detailed validation report (Figure 8 shows an example of a validation report's summary section). Laboratories accredited to test SCAP products are required to use SCAPval reports as part of their testing process. Developers of SCAP software products such as the scanner shown in Figure 1, SCAP content developers, and organizations deploying SCAP products may use SCAPval for quality assurance, or to gain insight into SCAP validation requirements or product capabilities.