1. Introduction
The Extensible Configuration Checklist Description Format (XCCDF [1]) Waltermire represents structured collections of security
configuration rules for target systems. XCCDF is part of the Security Content Automation
Protocol (SCAP — pronounced ess-cap) Quinn
Radack: an ecosystem of interoperable Extensible Markup Language (XML) W3C-XML vocabularies, reference data, and software tools. SCAP serves as a
digital thread
Hedberg for cybersecurity Lubell2015. System
administrators rely on SCAP to secure their servers, workstations, and networks. XCCDF
saves
checklist developers the pain of having to learn multiple proprietary formats and
lowers
deployment barriers for automated configuration checking. XCCDF-expressed checklists
can be
used with any SCAP-conforming software product.
XCCDF is a powerful and versatile language, but it is not checklist author-friendly. Although XCCDF enables automation of security configuration scans and generation of human-readable documentation, it is of limited use in helping authors reuse existing content when developing a new checklist. XCCDF is designed in a modular manner to facilitate reuse of sub-elements across different checklists. However, as checklist target types proliferate, efficient management of such content becomes increasingly challenging. Also, XCCDF's syntax is verbose and cluttered with namespaces, making checklist authoring labor-intensive and error-prone.
These shortcomings were of less concern in the recent past when most computing occurred
on
commodity hardware running one of a small number of popular operating systems. But
today the
mobile computing revolution and the Internet of Things
are spawning a greater
variety of devices, operating systems, and applications that need protection from
cyber-threats. Creating XCCDF content for this multitude of platforms is becoming
untenable.
Checklist authors need better tools to cope with this new diversity — and with the
ever-increasing need to prevent security incidents.
This paper explores how the Darwin Information Typing Architecture (DITA) OASIS-DITA can improve life for XCCDF checklist authors. Section 2 provides an overview of XCCDF and introduces a sample checklist to be
used as a case study. Section 3 describes the ad hoc approach the SCAP
Security Guide (SSG) OpenSCAP-SSG project uses to address XCCDF and SCAP
authoring and reuse challenges. Section 4 illustrates how DITA
topic
and map
element type specializations can be used to
improve the XCCDF authoring experience. Section 5 discusses how DITA can meet
reuse challenges in a more robust and maintainable manner than the SSG approach described.
Section 6 summarizes the case study results and offers some
concluding remarks.
2. XCCDF Overview and Example
The XCCDF specification Waltermire defines XCCDF's data model and
processing semantics. The current version of XCCDF is 1.2. The specification references
a
schema XCCDF as XCCDF's normative XML representation. This schema's
<Benchmark>
element is the root element of a checklist, or benchmark
document
using XCCDF terminology. A <Benchmark>
element contains a
collection of <Rule>
, <Value>
, and <Group>
elements. A <Rule>
specifies a single item to check, such as a firewall's
default setting. A <Rule>
also specifies how the checking should be done, such
as with an implementation-specific scripting language or with the Open Vulnerability
Assessment Language (OVAL) OVAL, an SCAP standard for representing system
configuration information, assessing machine state, and reporting assessment results.
A
<Value>
represents a named parameter that can be used within rules and
tailored for a particular configuration scenario. A <Group>
collects
<Rule>
, <Value>
, and other <Group>
elements
into an aggregation that is meaningful to a checklist user, for example, a collection
of
firewall configuration settings.
A <Benchmark>
element also contains one or more <Profile>
elements.
A
<Profile>
is a named collection of references to <Group>
,
<Rule>
, and <Value>
elements.
Profiles allow different combinations of groups
and rules to be enabled so that they are included in a series of tests, or disabled
so that
they are not. Profiles can also tailor the value of the named parameters in
<Value>
elements. Profiles allow a single benchmark to support different
test scenarios by enabling different combinations of tests and parameter values. XCCDF's
<Profile>
element increases a benchmark document's versatility, but also
increases the document's complexity by adding many cross references.
This paper uses as an ongoing example a simple XCCDF checklist consisting of four
ungrouped rules for version 7 of Red Hat Enterprise Linux (RHEL7) [2], none of which use any <Value>
parameters. The example was
extracted from a more complex XCCDF checklist developed by the Center for Internet
Security
CIS. Two of the rules pertain to SELinux StPierre, a
Linux kernel module for Mandatory Access Control (MAC).
MAC
is the security principle of limiting the ability of a user or running application
to access
system resources Hu. The other
two rules apply to firewall configuration. The checklist defines two profiles:
-
Firewall with MAC
referencing all four rules, -
Firewall
referencing only the two firewall-related rules.
Figure 1 shows the high-level XCCDF representation of this
checklist. Ellipsis symbols indicate lower-level details omitted for brevity. In this
checklist, all rules have a @selected
attribute set to false
.
Thus, no rules in the benchmark document are processed by default. Instead, each profile
must
explicitly select the rules it wishes to include in its test scenario (as shown later
in Figure 3).
Figure 2 shows the checklist loaded as input into SCAP Workbench OpenSCAP-Workbench, a security configuration scanner user interface. The user
has selected the Firewall with MAC
profile. The Rules
pane
displays the title and description of each rule in the profile. If the user were to
click on
the Scan
button, the software would scan a remote machine to determine
compliance with the four profile rules and report the results back to the user.
Figure 3 shows the XCCDF representation of the
Firewall with MAC
profile. The <select>
elements reference
the rules comprising the profile. Each <select>
element has an
@idref
attribute identifying a rule and a @selected
attribute set
to true
to explicitly include the referenced rule for use in the profile's test
scenario.
The XCCDF markup shown in Figure 1 and Figure 3 exhibits the following characteristics:
-
Identifiers are long. XCCDF requires that identifiers be both unique and descriptive, and that they contain a reverse-Domain Name System (DNS) style string associated with the content author. The profile identifier and four rule identifiers all meet these requirements.
-
Rule identifiers are repetitive. They all start with
"xccdf_gov.nist_rule_"
.
These characteristics promote interoperability and completeness, but at the expense of author-friendliness and maintainability.
Now consider Figure 4, the XCCDF representation of the first
of the four rules referenced by the Firewall with MAC
profile. This rule checks
whether SELinux is enabled. The <description>
and <rationale>
elements document the rule and its justification. The <complex-check>
element
represents a Boolean expression of <check>
elements, which in turn reference
the code for determining whether the system being scanned complies with the rule.
In this
example, checking is done using OVAL. Each <check-content-ref>
element's
@href
attribute references an external file containing OVAL definitions, and
the @name
attribute identifies the particular OVAL definition used to perform the
check. Like XCCDF, OVAL requires identifiers to be descriptive and use reverse-DNS
syntax.
The XML in Figure 4 exhibits the same XCCDF characteristics as the profile XML shown in Figure 3. Additionally:
-
There are multiple Uniform Resource Identifiers (URIs): the XCCDF default namespace
http://checklists.nist.gov/xccdf/1.2
and the OVAL URIhttp://oval.mitre.org/XMLSchema/oval-definitions-5
. -
The markup representing the checking of the rule is verbose and complex.
The rule's <complex-check>
markup complexity is partly because the check
requires a Boolean expression referencing three OVAL definitions, but the
<check-content-ref>
syntax and repetitive @system
attributes
further exacerbate matters.
This
added verbosity is perhaps necessary to allow for possibilities such as check systems
other
than OVAL, and embedded code for performing a
check. However, given that SCAP-conforming tools
are required to support OVAL as a checking language in XCCDF, and most XCCDF benchmarks
use
OVAL, this extra verbosity is generally not needed in
practice.
The discussion so far has focused on XCCDF characteristics that impede authoring such
as
verbosity and redundancy. An additional concern is that XCCDF and other SCAP languages
do not
facilitate reuse of content applicable to multiple platforms Lubell2017. To
see why, consider as an example the third rule shown in Figure 2,
Ensure iptables is installed.
Iptables, an application for configuring the
Linux kernel firewall, is available in all Linux distributions. Therefore, this rule
is
potentially applicable to all Linux systems.
A reasonable way to check for compliance with this rule would be for the rule's OVAL definition to invoke RHEL's package manager, rpm, to verify that iptables is installed. But unlike iptables, not all Linux distributions come with rpm. Fedora, an open source Linux distribution closely related to RHEL, has rpm. On the other hand, Debian and Ubuntu (a Debian derivative) both use dpkg for package management. Figure 5 shows the relationships between the Debian, Ubuntu, RHEL, and Fedora Linux distributions in terms of their shared kernel and package manager components.
This example illustrates the problem of platform fragmentation. Platform fragmentation
occurs when the same operating system, software application, or hardware component
is bundled
by multiple entities — with each bundler
providing different
customizations Vecchiato. Although XCCDF and other SCAP languages allow for
associations between rules or collections of rules and platforms, the SCAP ecosystem
currently
does not provide the kind of guidance shown in Figure 5 to
checklist authors. Therefore, checklist authors need other methods and tools outside
the scope
of SCAP to help them leverage taxonomic and other relationships to maximize reuse
when
creating new checklists. The next section discusses how this is done in the SSG
project.
3. The SCAP Security Guide Approach
The SSG OpenSCAP-SSG is an open source project whose output is a growing
collection of SCAP-expressed content (security guides) for Linux distributions and
software
applications. This SSG-generated SCAP content is widely used in government and industry.
Current and recent users
include
cloud computing providers, national defense agencies, and the financial services and
airline
industries [3]. The SSG source code
consists of:
-
Scripts and Extensible Style Language Transformations (XSLT) W3C-XSLT for generating SCAP content,
-
XML files that serve as input to the scripts and XSLT.
shareddirectory tree. Platform-specific module files applicable only to an individual security guide reside in platform-specific directory trees. The XML input files are further modularized into logically-related checklist components such as profiles, groups, and OVAL definitions. Building SCAP security guides from the source requires running scripts that perform XML transformations, macro substitutions, and merging of the XML input modules into bigger SCAP-conforming files.
SSG contributors create rules, profiles, and other XML input modules using a shorthand XML vocabulary. The shorthand is less verbose and namespace-heavy than the XCCDF markup shown in Section 2. The SSG build process converts the shorthand to XCCDF and OVAL. This build process is complicated and requires SSG contributors to understand not only SCAP, but also the one-off way the SSG source files are organized and structured Preisler.
Figure 6 shows a high-level view of the SSG source code directory
structure. The shared
directory subtree shown in the left-hand column contains
content, XSLT, and scripts applicable to more than one Linux distribution. Platform-specific
subtrees contain content, transforms, and scripts applicable only to a single distribution
or
application. The right-hand column shows the subtree for RHEL7. Each distribution-specific
directory tree has a Makefile with targets needed for building SCAP content for that
distribution. A master Makefile in the source code root directory has targets for
building all
the SCAP content.
Figure 6
Shared Content and Transforms | RHEL7-specific Content and Transforms |
shared ├── images ├── misc ├── modules ├── oval ├── references ├── remediations ├── templates ├── transforms ├── utils └── xccdf |
RHEL └──7 ├── input │ ├── auxiliary │ ├── oval │ └── profiles ├── kickstart ├── templates ├── transforms └── utils |
All rules and profiles in the source code are defined using the SSG shorthand XML.
Rules
that are common across multiple Linux distributions, such as the rule for determining
whether
SELinux is enabled, reside in shared/xccdf
. Rules specific to a particular Linux
distribution are in the distribution's input
directory subtree. Since all rules
for RHEL7 come from shared/xccdf
, the RHEL7 input
directory has no
xccdf
subdirectory.
Profiles are distribution-specific and reside in the distribution's
input/profiles
directory.
XSLT stylesheets in a platform-specific transforms
directory generate
SCAP-conforming XML, such as the RHEL7 benchmark shown in Figure 1.
These stylesheets use <xsl:include>
elements to incorporate stylesheets from
../../../shared/transforms
. The stylesheets first combine the individual
shorthand XML files (both shared and distribution-specific) into a single shorthand
benchmark
file. They then transform the combined shorthand benchmark into an XCCDF-conforming
benchmark
document.
The SSG XSLT stylesheets support reuse not only of structural checklist components
such as
rules, but also of inline fragments. The stylesheets automatically insert frequently-occurring
fragments when feasible to do so. For example, the value of the @system
attribute
in all XCCDF rules using OVAL is the same URI:
http://oval.mitre.org/XMLSchema/oval-definitions-5
. Therefore, the shorthand
XML syntax omits @system
and its value, saving authors the trouble of having to
repeatedly specify it.
For reusable fragments where the author determines placement, the SSG shorthand employs
-macro
elements. For example, a RHEL7 checklist author might want to use the
full name of the product to which the checklist applies — Red Hat Enterprise
Linux 7
— in multiple places within elements where mixed content is allowed.
To save authors the trouble of having to specify a full product name for every occurrence,
the
RHEL-specific XSLT in RHEL/7/transforms
contains the following variable
declaration:
<xsl:variable name="product_long_name">Red Hat Enterprise Linux 7</xsl:variable>The stylesheet in
shared/transforms
for converting the combined shorthand XML
components into an XCCDF benchmark contains the following template
rule:<xsl:template match="product-name-macro"> <xsl:value-of select="$product_long_name"/> </xsl:template>The template rule and variable declaration enable an SSG author to specify a product name inline as
<product-name-macro/>
. Doing so not only minimizes the opportunity for
undetected typos, but also maximizes the reusability of the <rule>
or other
structural element containing the product name.
Figure 7 summarizes the overall SSG transformation process discussed in the preceding paragraphs. The stylesheets first combine individual shorthand XML files and then, using constants defined as variable declarations and macros defined as template rules, produce an XCCDF-conforming benchmark document.
4. Specialized DITA Element Types for XCCDF
The DITA standard OASIS-DITA is an XML-based architecture for creating,
managing, reusing, and delivering technical content. A variety of authoring applications
and
processors — commercial as well as free and open source — conform to DITA OASIS-DITA-xml.org. DITA has two basic building blocks: the topic
and map
element types. A topic
is a reusable chunk of
information. A map
is an aggregation of topics or other maps. DITA supports
reuse not only of topics and maps, but also of inline XML elements and fragments.
DITA information types are specializable. Specialization is an information modeling
technique that helps avoid inconsistency and facilitate interoperability Krima. A specialized information type is a refinement of an existing base type and therefore
must
be at least as constrained.
Specialization
imposes some discipline on designers of new DITA information types, with the upside
that
implementations can easily leverage other DITA-conforming implementations Kimber. DITA includes built-in specialized element types based on the
topic
base type, such as concept
, task
,
reference
, and glossary group
. DITA also allows for definition
of new specialized element types based on topic
, map
, or other
specialized types.
In this section, I define new DITA specialized element types to support the authoring of XCCDF rules and profiles. I also provide examples of other XCCDF elements for which DITA specializations could be defined. These types have the same advantages as the XCCDF shorthand vocabulary, but with the added benefits of validation and more author-friendliness when using DITA-aware XML editing software. The specialization approach follows guidance from the DITA standard OASIS-DITA and from Eliot Kimber's DITA Configuration and Specialization Tutorials Kimber.
Rule Element Type
To develop a specialized DITA information type for XCCDF rule authoring, let us begin
by
revisiting the Ensure SELinux is not disabled in bootloader configuration
rule shown in Figure 4. A DITA rule
element type
should mitigate the three XCCDF authoring barriers highlighted in Section 2:
-
Repetitive and overly long identifiers,
-
Namespace proliferation,
-
Overly verbose check expressions.
I choose to define the new rule
element type as a specialization of the
DITA concept
topic type. A concept
has the loosest content
model of DITA's built-in topic-based types, making it easy to specialize.
<concept>
, the concept
topic type's root element, contains
a <title>
followed by <conbody>
, the main body element.
<conbody>
may contain DITA <section>
elements, which
subdivide content within a topic and are not allowed to be nested. DITA
<sectiondiv>
elements subdivide content within a <section>
and may be nested inside one another. <section>
and
<sectiondiv>
may contain mixed content including <xref>
, a
DITA linking element. <xref>
has an @href
attribute, which may
reference another topic, map, or non-DITA resource.
The next step is to create a rule
document type shell based on the
concept
document type shell. A DITA document type shell defines which
elements and attributes are allowed in a DITA document, and is usually specified using
Document Type Definition (DTD) syntax. The DITA standard provides a modular architecture
for
document type shells to facilitate creation of new shells. A recommended practice
is to make
a copy of an existing shell (the concept
shell in our case) and modify the
modules as needed for the new document type.
Figure 8 shows the Ensure SELinux is not disabled in
bootloader configuration
rule represented in a manner similar in spirit to the SSG
shorthand syntax, which mitigates the XCCDF rule authoring barriers. The new
rule
document type shell will specify a grammar for authoring rules such as
the rule in Figure 8.
Looking at Figure 8 in the context of the DITA
concept
element type, one observes the following:
-
The
<oval>
element can be specialized from DITA's<xref>
element, without additional constraints. -
<OR>
and<AND>
can be specialized from DITA's<sectiondiv>
element, constrained to allow one or more<oval>
elements or Boolean expressions as content. -
<check>
can be specialized from DITA's<section>
element, constrained to allow either a single<oval>
element or Boolean expression of<oval>
elements as content. -
<description>
and<rationale>
can be specializations of<section>
without additional constraints. -
<rulebody>
can be specialized from<conbody>
, but constrained to allow only a<description>
,<rationale>
, and<check>
as content. -
<rule>
can be specialized from<concept>
, but constrained to allow only a<title>
and<rulebody>
as content. -
The DITA
<title>
element can be used as is.
After creating a rule
document type shell reflecting these observations,
I add DITA @class
attributes with default values to each specialized element:
<rule>
, <rulebody>
, <description>
,
<rationale>
, <rationale>
, <check>
,
<AND>
, <OR>
, and <oval>
. Default values
are used to hide the DITA specialization machinery from authors, who have no need
to see it
when editing content. The @class
attribute specifies the element's
specialization hierarchy — a mapping from the element name to its more generalized
DITA concept and topic element equivalents. For example, the <rule>
element's @class
attribute has the value "- topic/topic concept/concept
rule/rule "
, which specialization-aware DITA processors interpret to mean
The
<rule>
element in theruleelement type specializes<concept>
from theconceptelement type, which in turn specializes<topic>
from thetopicelement type.
Table I
Element | Specialization Hierarchy (@class value)
|
Document Type Shell Constraints |
<rule> |
"- topic/topic concept/concept rule/rule " |
(title, rulebody) |
<rulebody> |
"- topic/body concept/conbody rule/rulebody " |
(description, rationale, check) |
<description> |
"- topic/section concept/section rule/description " |
none |
<rationale> |
"- topic/section concept/section rule/rationale " |
none |
<check> |
"- topic/section concept/section rule/check " |
(OR | AND | oval) |
<OR> |
"- topic/sectiondiv concept/sectiondiv rule/OR " |
(OR | AND | oval)+ |
<AND> |
"- topic/sectiondiv concept/sectiondiv rule/AND " |
(OR | AND | oval)+ |
<oval> |
"- topic/xref concept/xref rule/oval " |
none |
Table I shows the specialization hierarchy and document type
shell constraint for each new element in the rule
element type. The
specialization hierarchy effectively specifies the default specialization-aware DITA
processing behavior. DITA specialization hierarchies maximize reuse of existing markup
and
transformation code Priestley. The document type shell constraints specify
requirements for valid XML.
Suppose an XCCDF rule author were to use a DITA specialization-aware XML application
such as Oxygen XML Editor. Figure 9 shows the Ensure
SELinux is not disabled in bootloader configuration
rule as presented in Oxygen's
user interface. The screen capture occurred when the user was about to insert a new
element
following the <oval>
element whose @href
value is
oval/1059.dita
. A simple Cascading Style Sheet (CSS) W3C-CSS augments Oxygen's CSS styling for the concept
element type by adding
Rule:
, Description:
, Rationale:
, and
Check:
labels, as well as the parentheses and OR
and
AND
in the check expression. This is all the CSS code
does. Other presentation aspects such as the fonts used and the clickable @href
links are derived using the specialization hierarchies shown in Table I.
Analogous to the CSS augmentation of the default DITA presentation, the rule document
type shell constraints shown in Table I augment the default DITA
visual editing and validation capabilities. The drop-down list of elements shown in
Figure 9 limits the user's choices to inserting an
<AND>
, <OR>
, or <oval>
element, or adding
a new <AND>
after the current <AND>
element. Any DITA
concept
topic document type shell constraints not overridden by the
rule
document type shell remain. For example, the user can add any content
inside the <description>
or <rationale>
elements permitted
by the concept
document type shell's content model for
<section>
.
Profile Element Type
I choose to define the new profile
element type as a simple
specialization of the DITA map
element type. <map>
, the
map
type's root element, may contain a <title>
, followed by
a <topicmeta>
element, followed by a sequence of <topicref>
elements. <topicmeta>
, in this context, specifies metadata applicable to all
topics in the map, and may contain a brief description of the map in a
<shortdesc>
element. The <topicref>
element uses
@href
to reference a map resource.
I first create a profile
document type shell based on the
map
document type shell. Figure 10 shows the
Firewall with MAC
profile represented in a manner similar in spirit to the
SSG shorthand syntax, and that mitigates the XCCDF authoring barriers discussed in
Section 2.
Table II
Element | Specialization Hierarchy (@class value)
|
Document Type Shell Constraints |
<profile> |
"- map/map profile/profile " |
(title, profilemeta, rule+) |
<profilemeta> |
"- map/topicmeta profile/profilemeta " |
none |
<rule> |
"- map/topicref profile/rule " |
none |
Looking at Figure 10 in the context of the DITA
map
document type, one observes the following:
-
<rule>
can be specialized from DITA's<topicref>
element, without additional constraints. -
<profilemeta>
can be specialized from DITA's<topicmeta>
element, without additional constraints. -
<profile>
can be specialized from DITA's<map>
element, but constrained to allow only a<title>
,<profilemeta>
, and one or more<rule>
elements as content. -
The DITA
<title>
and<shortdesc>
elements can be used as is.
Table II shows the specialization hierarchy and document
type shell constraint for each new element in the profile
type. Figure 11 shows the Oxygen presentation with clickable
@href
links. Minimal CSS styling adds the Profile:
label. All
other presentation characteristics are inherited from the map
element type's
CSS styling.
Other Element Types
The previous subsections demonstrated how shorthand XML vocabularies for XCCDF rules
and
profiles can be implemented as specializations of the DITA concept
and
map
element types respectively. Specialization can also be used to create
DITA element types for XCCDF groups and values as well. A group
type could be
specialized from the DITA map
element type, and value
can be
specialized from the base topic
type or one of the DITA built-in types
specialized from topic
.
An XCCDF benchmark document as a whole could be represented using a
benchmark
element type specializing map
. Doing so would
explicitly represent the high-level checklist structure, which the SSG build system
represents implicitly in Makefiles and in the XSLT implementing the Transform
shorthand to XCCDF
box in the Figure 7 flowchart.
DITA maps have additional benefits besides making the transformation process more
explicit
and self-documenting for XCCDF authors. As the next section will discuss, maps enable
reuse
of XCCDF content and can reduce the coding needed to implement the shorthand-to-XCCDF
transformation.
5. Reuse and Implementation Considerations
This section revisits the SSG approach covered in Section 3 from a reuse perspective. The first subsection describes how maps and other DITA features can improve upon SSG solutions for reusing XCCDF content. The second subsection discusses how the use of DITA can simplify implementation of the conversion from shorthand XML to XCCDF.
Block and Inline Content Reuse
DITA maps can improve upon the SSG
reuse
mechanism. Relying on directory subtrees imposes a rigid hierarchy on reuse relationships,
and is insufficient to account for all the varieties of platform fragmentation. There
are a
lot ways to categorize platforms. The package manager-based classification shown in
Figure 5 is just one of many. Lineage is another way to
characterize a platform. For example, Ubuntu Linux is derived from Debian, while RHEL
is a
commercial sibling of the open source Fedora. Linux distributions can also be classified
according to graphical desktop environment. For example, some Linux distributions
come
bundled with GNOME , while others come with Enlightenment. And GNOME and Enlightenment
each
have variants. Linux distributions optimized for specialized hardware, increasingly
common
as the shared/xccdf
Internet of Things
continues to grow, add yet another wrinkle to
platform fragmentation. Raspbian Raspbian, a Debian derivative tailored
for Raspberry Pi hardware, is an example of a hardware-optimized Linux distribution.
Multiple
DITA maps can be used to slice and dice a repository of DITA resources for creating
XCCDF
benchmarks covering a wide variety of Linux-based
platforms. Each map can represent a different
platform class. And maps can overlap with one another, or a map can reference another
map.
Maps can capture parent-child relationships as well as sibling relationships. Also,
DITA
supports conditional profiling OASIS-DITA, which allows the same content
to be associated with multiple organization schemes as defined using DITA's filtering
attributes. The classification possibilities are endless. Unlike the SSG shared
directory subtree, a DITA map-based approach is flexible enough to keep pace with
growing
platform fragmentation.
The discussion of DITA so far has focused on topics and maps, with an emphasis on
reusability of topic-based information such as XCCDF rules. In addition to facilitating
reuse of structural block content, DITA provides mechanisms for reusing inline content.
These mechanisms can be applied to frequently repeated fragments in an XCCDF benchmark
document such as the product name (Red Hat Enterprise Linux 7
in our
scenario). One such DITA capability is content key references, a method for indirectly
addressing inline content locations Oxygen.
A content key and key reference can implement the same functionality as the
product-name-macro
SSG's XSLT template rule. One way to do this is to use
DITA's <keydef>
element to define a product_name
key in a
benchmark's root map as shown in the DITA benchmark document (specializing on the
base
map
element type) in Figure 12. The
product_name
key can then be referenced from anywhere within the root map
using the @keyref
attribute of the DITA <ph>
(phrase)
element.
The product_name
key can also be referenced from within any resource the
root map references. For example, the referenced topic introduction.dita
could
contain the following paragraph:
<p>This document provides prescriptive guidance for establishing a secure configuration for <ph keyref="product_name"/> systems.</p>
Code Reuse
A major benefit of DITA is that it can reduce the amount of coding needed to transform
a
collection of resources to a desired output format. The savings result from the DITA
standard's requirements for output-producing processors. A conforming DITA processor
must be
able to merge topics in a map as well as resolve content references, eliminating the
need
for custom transformation code to perform these functions. A specialization-aware
DITA
processor can do all the above for specialized DITA documents through inheritance
of
processing behavior from base types via the @class
attribute. The DITA Open
Toolkit DITA-OT, an output-producing and specialization-aware DITA
processor used in Oxygen and other XML software applications, illustrates the potential
benefits of DITA for transformation of shorthand XML to XCCDF.
The DITA Open Toolkit is not part of the DITA standard — they are separately
managed. However, both originated from the same research and development effort at
IBM Priestley
S-R. The Toolkit does not support XCCDF out of the box, but has an
extensible plug-in mechanism for implementing custom output formats or adding additional
functionality to existing output formats. The plug-in architecture allows for developers
to
reuse built-in transformation code, as well as code from other plug-ins, by integrating
new
XSLT via extension points.
The DITA Open Toolkit's built-in transformation
code includes a preprocessing module that implements map operations and content references.
The preprocessing is used in all transformations by default.
A Toolkit XCCDF plug-in would require XSLT template rules matching against
@class
attribute values to convert elements from the specialized types from
Section 4 into XCCDF equivalents. For example, the template
rule below transforms the rule
element type's <rule>
element
into an <xccdf:Rule>
element. The value of $rule-prefix
could
be passed as a parameter to the plug-in. For the RHEL7 example from Section 2, the parameter value would be xccdf_gov.nist_rule_
.
fn:rule-id
is a stylesheet-defined function that constructs a reverse-DNS
syntax XCCDF identifier from $rule-prefix
and the <rule>
element's @id
attribute value.
<xsl:template match="*[contains(@class, ' rule/rule ')]"> <xccdf:Rule id="{fn:rule-id($rule-prefix,@id)}" …> <xsl:apply-templates/> </xccdf:Rule> </xsl:template>
The template rule below transforms the rule
element type's
<oval>
element into an <xccdf:check>
element with a nested
<xccdf:check-content-ref>
. fn:oval-def
constructs the OVAL
definition's reverse-DNS name from the $oval-def-prefix
parameter value
(oval:gov.nist.redhat_redhat_enterprise_linux_7:def:
for the RHEL7 example)
and the <oval>
element's @href
attribute value.
$oval-uri
provides the value of <xccdf:check>
's
@href
attribute
(http://oval.mitre.org/XMLSchema/oval-definitions-5
).
<xccdf:check-content-ref>
's @href
attribute is assigned the
value of $oval-location
(CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.1.0-oval.xml
).
<xsl:template match="*[contains(@class, ' rule/oval ')]"> <xccdf:check system="{$oval-uri}"> <xccdf:check-content-ref href="{$oval-location}" name="{fn:oval-def($oval-def-prefix,@href)}"/> </xccdf:check> </xsl:template>
6. Conclusion
The case study described in this paper investigated the feasibility of DITA for creating XCCDF security configuration checklists, and whether DITA could improve upon the SCAP Security Guide project's ad hoc approach to authoring and reuse. Proof-of-concept implementations of DITA element types for rules and profiles showed that DITA specialization is both feasible and offers tangible benefits beyond the SSG shorthand XML, such as validation and an improved authoring experience. Additional analysis and examples showed how DITA topic maps can improve reuse of structural XCCDF elements, and how DITA features such as key referencing can facilitate reuse of inline fragments.
This case study has a significant limitation. Analysis was limited to a single XCCDF
checklist with only four rules, two profiles, and no <Group>
or
<Value>
XCCDF
elements.
The rule and profile DITA element types do not provide the full range of XCCDF's flexibility
[6]. For example, rule
and profile
do not consider XCCDF
checklist capabilities such as automated remediation of misconfigurations. Similarly,
the case
study also assumed checklist authors would use OVAL for rule checking and would adopt
a
specific convention for using the @selected
attribute. While these simplifying
assumptions align with a large amount of the XCCDF content published thus far, some
authors
might find these assumptions limiting. Until more sophisticated checklists from a
cross
section of Linux platforms are studied, it would be premature to conclude definitively
that
DITA will revolutionize the development of XCCDF and other SCAP content. The SSG authoring
approach may have its shortcomings, but it has been successful in producing an impressive
collection of widely-deployed SCAP content. Further implementation and testing are
needed to
determine whether the promising results presented in this paper can scale up to a
collection
of larger and more diverse
checklists.
An open question is to what extent adoption of DITA as an alternative to the SSG's
ad hoc
authoring approach would simplify the SSG transformation shown in Figure 7. At the very least, assembly relationships, platform
commonalities, and reusable structures and fragments would be more maintainable explicitly
represented in DITA than implicitly represented in XSLT and Makefiles. Additionally,
DITA's
default processing of maps and key references should simplify implementation of the
Combine shorthand XML components
and Transform shorthand to
XCCDF
steps. Implementing an XCCDF plug-in would be a good way to learn how much the
DITA Open Toolkit further simplifies implementation.
Author's Note
I am grateful to Eliot Kimber for his DITA Configuration and Specialization Tutorials, which were immensely helpful when writing this paper and creating the implementation examples. I also wish to thank Charles Schmidt, co-author of the XCCDF specification, for his thoughtful and helpful review of an earlier draft.
Appendix. List of Acronyms
CSS |
Cascading Style Sheet |
DITA |
Darwin Information Typing Architecture |
DTD |
Document Type Definition |
MAC |
Mandatory Access Control |
NIST |
National Institute of Standards and Technology |
OVAL |
Open Vulnerability Assessment Language |
RHEL |
Red Hat Enterprise Linux |
SELinux |
Security-Enhanced Linux |
SCAP |
Security Content Automation Protocol |
SSG |
SCAP Security Guide |
URI |
Uniform Resource Identifier |
XCCDF |
Extensible Configuration Checklist Description Format |
XSLT |
Extensible Stylesheet Language Transformation |
References
[CIS] Center for Internet Security. CIS Red Hat
Enterprise Linux 7 Benchmark v2.1.0
(2016). https://benchmarks.cisecurity.org [Prose documentation, XCCDF, and OVAL available to CIS
members]
[DITA-OT] DITA Open Toolkit. http://www.dita-ot.org
[Hedberg] T. Hedberg, J. Lubell, L. Fischer, L. Maggiano, and A. Barnard
Feeney. Testing the Digital Thread in Support of Model-Based Manufacturing and
Inspection.
Journal of Computing and Information Science in Engineering.
16 (2) (2016). doi:https://doi.org/10.1115/1.4032697
[Hu] V.C. Hu, D.R. Kuhn, T. Xie, and J. Hwang. Model Checking for
Verification of Mandatory Access Control Models and Properties.
International Journal of Software Engineering and Knowledge
Engineering. 21 (1). pp. 103–27 (2011). doi:https://doi.org/10.1142/S021819401100513X.
[Kimber] E. Kimber. DITA for Practitioners Volume 1: Architecture and Technology. XMLPress (2012). [Configuration and Specialization tutorials online at http://www.xiruss.org/tutorials/dita-specialization]
[Krima] S. Krima and J. Lubell. Flat Versus Hierarchical Information
Models in PLM Standardization Frameworks.
In Product Lifecycle
Management for Digital Transformation of Industries: 13th IFIP WG 5.1 International
Conference, PLM 2016, Columbia, SC, USA, July 11-13, 2016, Revised Selected
Papers. R. Harik, L. Rivest, A. Bernard, B. Eynard, and A. Bouras, Eds. Cham:
Springer International Publishing. pp. 121–133 (2016). doi:https://doi.org/10.1007/978-3-319-54660-5_12
[Lubell2015] J. Lubell. Extending the Cybersecurity Digital Thread
with XForms.
In Proceedings of Balisage: The Markup Conference
2015. Balisage Series on Markup Technologies, vol. 15 (2015). doi:https://doi.org/10.4242/BalisageVol15.Lubell01
[Lubell2017] J. Lubell and T. Zimmerman. The Challenge of Automating
Security Configuration Checklists in Manufacturing Environments.
In Critical Infrastructure Protection XI. M. Rice and S. Shenoi, Eds.
Springer Berlin Heidelberg (2017). [To appear]
[OASIS-DITA] Organization for the Advancement of Structured Information
Standards. Darwin Information Typing Architecture (DITA) Version 1.3 Part 2: Technical
Content Edition.
OASIS Standard (2016). http://docs.oasis-open.org/dita/dita/v1.3/dita-v1.3-part2-tech-content.html
[OASIS-DITA-xml.org] Organization for the Advancement of Structured
Information Standards. DITA XML.org.
http://dita.xml.org
[OpenSCAP-SSG] OpenSCAP Portal. SCAP Security Guide.
http://www.open-scap.org/security-policies/scap-security-guide
[OpenSCAP-Workbench] OpenSCAP Portal. SCAP Workbench.
https://www.open-scap.org/tools/scap-workbench
[OVAL] OVAL Documentation. http://ovalproject.github.io
[Oxygen] Oxygen XML Editor Blog. DITA Reuse Strategies (Short
Tutorial describing all DITA Reuse possibilities).
http://blog.oxygenxml.com/2015/11/dita-reuse-strategies-short-tutorial.html
[Priestley] M. Priestley and D. A. Schell. Specialization in DITA:
Technology, Process, & Policy.
In Proceedings of the 20th
Annual International Conference on Computer Documentation. pp. 164–176 (2002).
doi:https://doi.org/10.1145/584955.584980
[Preisler] M. Preisler. Contributing to SCAP Security Guide —
Part 1.
https://martin.preisler.me/2016/10/contributing-to-scap-security-guide-part-1
[Raspbian] Raspbian. https://www.raspbian.org
[StPierre] P. St. Pierre. Securing Linux with Mandatory Access
Controls.
Linux.com (2005). https://www.linux.com/news/securing-linux-mandatory-access-controls
[Quinn] S. Quinn, K. Scarfone, and D. Waltermire. Guide to Adopting
and Using the Security Content Automation Protocol (SCAP) Version 1.2 (Draft).
NIST
Special Publication 800-117. Revision 1 (2012). http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-117-Rev.%201
[Radack] S. Radack and R. Kuhn. Managing Security: The Security
Content Automation Protocol.
IT Professional. vol. 13(1). pp. 9–11 (2011). doi:https://doi.org/10.1109/MITP.2011.11
[S-R] K. Schengili-Roberts. Don Day and Michael Priestley on the
Beginnings of DITA: Part 1.
http://www.ditawriter.com/don-day-and-michael-priestley-on-the-beginnings-of-dita-part-1
[Vecchiato] D. Vecchiato, M. Vieira, and E. Martins. The Perils of
Android Security Configuration.
Computer. vol. 49(6). pp. 15-21 (2016). doi:https://doi.org/10.1109/MC.2016.184
[Waltermire] D. Waltermire, C. Schmidt, K. Scarfone, and N. Ziring.
Specification for the Extensible Configuration Checklist Description Format (XCCDF)
Version 1.2.
NIST Interagency Report 7275 Revision 4 (2012). https://scap.nist.gov/specifications/xccdf
[W3C-CSS] World Wide Web Consortium. Cascading Style Sheets Level 2
Revision 1 (CSS 2.1).
W3C Recommendation (2011). https://www.w3.org/TR/CSS2
[W3C-XML] World Wide Web Consortium. Extensible Markup Language (XML)
1.0 (Fifth Edition).
W3C Recommendation (2008). https://www.w3.org/TR/xml
[W3C-XSLT] World Wide Web Consortium. XSL Transformations (XSLT)
Version 2.0.
W3C Recommendation (2007). https://www.w3.org/TR/xslt20
[XCCDF] XCCDF — The Extensible Configuration Checklist Description Format. https://scap.nist.gov/specifications/xccdf
[2] 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.
[4] This rule
element type assumes that an XCCDF rule is disabled by
default. Thus, an XCCDF <Rule>
element generated from a DITA
rule
should have @selected="false"
. Although more
restrictive than the XCCDF specification, this assumption allows for a more
simplified rule
syntax.
[5] This shorthand syntax assumes that rules in the benchmark are disabled by
default. Identifying a rule in a profile thus implies that it should be changed to
a
selected status (with
@selected="true"
).
[6] This lack of flexibility is a limitation of the case study and not of DITA. The rule and profile element types described in this paper only scratch the surface of what is possible with DITA's specialization mechanism.