This schema defines the eXtensible Configuration Checklist
Description Format (XCCDF), a data format for defining
security benchmarks and checklists, and for recording
the results of applying such benchmarks.
For more information, consult the specification
document, "Specification for the Extensible Configuration
Checklist Description Format", version 1.1 revision 4.
This schema was developed by Neal Ziring, with ideas and
assistance from David Waltermire. The following helpful
individuals also contributed ideas to the definition
of this schema: David Proulx, Andrew Buttner, Ryan Wilson,
Matthew Kerr, Stephen Quinn. Ian Crawford found numerous
discrepancies between this schema and the spec document.
Peter Mell and his colleagues also made many suggestions.
1.1.4.3
XCCDF Language
Neal Ziring
1.1.4.3
2007-10-10
Import the XML namespace because this schema uses
the xml:lang and xml:base attributes.
Import the simple Dublin Core namespace because this
schema uses it for benchmark metadata and for references.
Import the CIS platform schema, which we use for
describing target IT platforms in the Benchmark. The
CIS platform schema was designed by David Waltermire.
Use of the CIS platform schema in XCCDF benchmarks is
deprecated. The CIS platform schema is included only for
backward compatibility with XCCDF 1.0. Use CPE 2.0 instead.
Import the XCCDF-P platform schema, which we use
for describing target IT platforms in the Benchmark.
The CIS platform schema was designed by Neal Ziring
using ideas and concepts developed by DISA, CIS, and
others. Use of XCCDF-P platform specification in
XCCDF benchmarks is deprecated. XCCDF-P is included
in this schema only for backward compatibility with
version 1.1 and 1.1.2. Use CPE 2.0 instead.
Import the Common Platform Enumeration XML schema,
which can be used for naming and describing target
IT platforms in the Benchmark. Every CPE name is
a URI that begins with "cpe:". For more details see
"Common Platform Enumeration (CPE) - Specification",
by Buttner, Wittbold, and Ziring (2007). Use of CPE 1.0
definitions in XCCDF benchmarks is deprecated. CPE 1.0
is included in this schema only for backward compatibility
with XCCDF 1.1.2 and 1.1.3. CPE 2.0 Names should be used
for simple (unitary) platforms, and CPE 2.0 Language
definitions used for complex platforms.
Import the Common Platform Enumeration language schema,
which can be used for defining compound CPE tests for
complex IT platforms in the Benchmark. For more info
see "Common Platform Enumeration (CPE) - Specification",
Version 2.0" by Buttner and Ziring (Sept 2007).
The benchmark tag is the top level element representing a
complete security checklist, including descriptive text,
metadata, test items, and test results. A Benchmark may
be signed with a XML-Signature.
Legal notices must have unique id values.
Items must have unique id values, and also they
must not collide
Model system attributes must be unique.
Value item ids are special keys, need this for
the valueIdKeyRef and valueExtIdKeyRef keyrefs below.
Group item ids are special keys, need this for
the groupIdKeyRef keyref below.
Rule items have a unique key, we need
this for the ruleIdKeyRef keyref below.
(Rule key refs are used by rule-results.)
Group and Rule item ids are special keys, we
need this for the requiresIdKeyRef keyref below.
Plaintext objects and Value objects each have
and id, and they must be unique and not overlap.
Profile objects have a unique id, it is used
for extension, too.
An extends attribute on Value object
must reference an existing Value.
An extends attribute on Group object
must reference an existing Group.
An extends attribute on Rule object
must reference an existing Rule.
An extends attribute on Profile object
must reference an existing Profile.
Check-export elements must reference existing values.
Sub elements must reference existing Value or
plain-text ids.
The rule-result element idref must refer to an
existing Rule.
The requires a profile element in a TestResult
element to refer to an existing Profile
Data type for legal notice element that has text
content and a unique id attribute.
Data type for a reusable text block, with an
unique id attribute.
Data type for a reference citation, an href URL attribute
(optional), with content of text or simple Dublin Core
elements. Elements of this type can also have an override
attribute to help manage inheritance.
XML-Signature over the Benchmark; note that this will
always be an 'enveloped' signature, so the single
element child of this element should be dsig:Signature.
Metadata for the Benchmark, should be Dublin Core
or some other well-specified and accepted metadata
format. If Dublin Core, then it will be a sequence
of simple Dublin Core elements. The NIST checklist
metadata should also be supported, although the
specification document is still in draft in NIST
special pub 800-70.
The acceptance status of an Item with an optional date attribute
that signifies the date of the status change.
A suggested scoring model for a Benchmark, also
encapsulating any parameters needed by the model.
Every model is designated with a URI, which
appears here as the system attribute.
Parameter names must be unique.
Type for a scoring model parameter: a name and a
string value.
The possible status codes for an Benchmark or Item to be
inherited from the parent element if it is not defined.
Type for a version number, with a timestamp attribute
for when the version was made.
Type for a string with an xml:lang attribute.
Elements of this type can also have an override
attribute to help manage inheritance.
Type for a string with XHTML elements and xml:lang attribute.
Elements of this type can also have an override
attribute to help manage inheritance.
Type for a string with embedded Value substitutions and
XHTML elements, and an xml:lang attribute. Elements of
this type can also have an override attribute to help
manage inheritance. [Note: this definition is rather
loose, it allows anything whatsoever to occur insides
XHTML tags inside here. Further, constraints of the XHTML
schema do not get checked! It might be possible to solve
this using XML Schema redefinition features.]
Type for a string with embedded Value substitutions and
XHTML elements, an xml:lang attribute, and a profile-note tag.
Type for a string with embedded Value substitutions
and XHTML elements, and an xml:lang attribute.
Elements of this type can also have an override
attribute to help manage inheritance.
Data type for elements that have no content,
just a mandatory id reference.
Data type for elements that have no content,
just a space-separated list of id references.
Data type for elements that have no content,
just a mandatory id reference, but also have
an override attribute for controlling inheritance.
Data type for elements that have no content,
just a mandatory URI as an id. (This is mainly for the
platform element, which uses CPE URIs and CPE Language
identifers used as platform identifiers.) When referring
to a local CPE Language identifier, the URL should use
local reference syntax: "#cpeid1".
Data type for elements that have no content,
just a mandatory URI reference, but also have
an override attribute for controlling inheritance.
Type element type imposes constraints shared by all
Groups, Rules and Values. The itemType is abstract, so
the element Item can never appear in a valid XCCDF document.
This abstract item type represents the basic data shared by all
Groups, Rules and Values
This abstract item type represents the basic data shared by all
Groups and Rules. It extends the itemType given above.
Data type for the Group element that represents a grouping of
Groups, Rules and Values.
The Rule element contains the description for
a single item of guidance or constraint. Rules
form the basis for testing a target platform for
compliance with a benchmark, for scoring, and
for conveying descriptive prose, identifiers,
references, and remediation information.
Data type for the Rule element that represents a
specific benchmark test.
Type for a long-term globally meaningful identifier,
consisting of a string (ID) and a URI of the naming
scheme within which the name is meaningful.
Data type for the warning element under the Rule
object, a rich text string with substitutions
allowed, plus an attribute for the kind of warning.
Allowed warning category keywords for the warning
element. The allowed categories are:
general=broad or general-purpose warning (default
for compatibility for XCCDF 1.0)
functionality=warning about possible impacts to
functionality or operational features
performance=warning about changes to target
system performance or throughput
hardware=warning about hardware restrictions or
possible impacts to hardware
legal=warning about legal implications
regulatory=warning about regulatory obligations
or compliance implications
management=warning about impacts to the mgmt
or administration of the target system
audit=warning about impacts to audit or logging
dependency=warning about dependencies between
this Rule and other parts of the target
system, or version dependencies.
Data type for the fixText element that represents
a rich text string, with substitutions allowed, and
a series of attributes that qualify the fix.
Type for a string with embedded Value and instance
substitutions and an optional platform id ref attribute, but
no embedded XHTML markup.
The platform attribute should refer to a platform-definition
element in the platform-definitions child of the Benchmark.
Allowed strategy keyword values for a Rule fix or
fixtext. The allowed values are:
unknown= strategy not defined (default for forward
compatibility for XCCDF 1.0)
configure=adjust target config or settings
patch=apply a patch, hotfix, or update
policy=remediation by changing policies/procedures
disable=turn off or deinstall something
enable=turn on or install something
restrict=adjust permissions or ACLs
update=install upgrade or update the system
combination=combo of two or more of the above
Allowed rating values values for a Rule fix
or fixtext: disruption, complexity, and maybe overhead.
The possible values are:
unknown= rating unknown or impossible to estimate
(default for forward compatibility for XCCDF 1.0)
low = little or no potential for disruption,
very modest complexity
medium= some chance of minor disruption,
substantial complexity
high = likely to cause serious disruption, very complex
Type for an instance element in a fix element. The
instance element inside a fix element designates a
spot where the name of the instance should be
substituted into the fix template to generate the
final fix data. The instance element in this usage
has one optional attribute: context.
The type for an element that can contains a boolean
expression based on checks. This element can have only
complex-check and check elements as children. It has two
attributes: operator and negate. The operator attribute
can have values "OR" or "AND", and the negate attribute is
boolean. See the specification document for truth tables
for the operators and negations. Note: complex-check is
defined in this way for conceptual equivalence with OVAL.
The type for the allowed operator names for the
complex-check operator attribute. For now, we just
allow boolean AND and OR as operators. (The
complex-check has a separate mechanism for negation.)
Data type for the check element, a checking system
specification URI, and XML content. The content of the
check element is: zero or more check-export elements,
zero or more check-content-ref elements, and finally
an optional check-content element. An content-less
check element isn't legal, but XSD cannot express that!
Data type for the check-import element, which specifies a
value that the benchmark author wishes to retrieve from the
the checking system. The import-name attribute gives the
name or id of the value in the checking system. When the
check-import element appears in the context of a rule-result,
then the element's content is the desired value. When the
check-import element appears in the context of a Rule, then
it should be empty and any content must be ignored.
Data type for the check-export element, which specifies
a mapping between an XCCDF internal Value id and a
value name to be used by the checking system or processor.
Data type for the check-content-ref element, which
points to the code for a detached check in another file.
This element has no body, just a couple of attributes:
href and name. The name is optional, if it does not appear
then this reference is to the entire other document.
Data type for the check-content element, which holds
the actual code of an enveloped check in some other
(non-XCCDF) language. This element can hold almost
anything; XCCDF tools do not process its content directly.
Data type for a Rule's weight, a non-negative real number.
Data type for the Value element, which represents a
tailorable string, boolean, or number in the Benchmark.
The choice element specifies a list of legal or suggested
choices for a Value object. It holds one or more choice
elements, a mustMatch attribute, and a selector attribute.
This type is for an element that has string content
and a selector attribute. It is used for some of
the child elements of Value.
This type is for an element that has numeric content
and a selector attribute. It is used for two of
the child elements of Value.
Data type for elements that have no content, just a URI.
Allowed data types for Values, just string, numeric,
and true/false.
Allowed operators for Values. Note that most of
these are valid only for numeric data, but the
schema doesn't enforce that.
Allowed interface hint values. When an interfaceHint
appears on the Value, it provides a suggestion to a
tailoring or benchmarking tool about how to present the
UI for adjusting a Value.
Data type for the Profile element, which holds a
specific tailoring of the Benchmark. The main part
of a Profile is the selectors: select, set-value,
refine-rule, and refine-value. A Profile may also be
signed with an XML-Signature.
Type for the select element in a Profile; all it has are two
attributes, no content. The two attributes are idref which
refers to a Group or Rule, and selected which is boolean.
As content, the select element can contain zero or more
remark elements, which allows the benchmark author to
add explanatory material or other additional prose.
Type for the set-value element in a Profile; it
has one required attribute and string content. The
attribute is 'idref', it refers to a Value.
Type for the refine-value element in a Profile; all it has
are three attributes, no content. The three attributes are
'idref' which refers to a Value, 'selector' which designates
certain element children of the Value, and 'operator' which
can override the operator attribute of the Value.
As content, the refine-value element can contain zero or more
remark elements, which allows the benchmark author to
add explanatory material or other additional prose.
Type for the refine-rule element in a Profile; all it has
are four attributes, no content. The main attribute is
'idref' which refers to a Rule, and three attributes that
allow the Profile author to adjust aspects of how a Rule is
processed during a benchmark run: weight, severity, role.
As content, the refine-rule element can contain zero or more
remark elements, which allows the benchmark author to
add explanatory material or other additional prose.
Data type for the TestResult element, which holds the
results of one application of the Benchmark. The optional
test-system attribute gives the name of the benchmarking tool.
Type for a score value in a TestResult, the content is a
real number and the element can have two optional attributes.
This element holds a list of facts about the target system
or platform. Each fact is an element of type factType.
Each fact must have a name, but duplicate names are allowed.
(For example, if you had a fact about MAC addresses, and the
target system had three NICs, then you'd need three
instance of the "urn:xccdf:fact:ethernet:MAC" fact.)
Type for an identity element in a TestResult.
The content is a string, the name of the identity.
The authenticated attribute indicates whether the
test system authenticated using that identity in order
to apply the benchmark. The privileged attribute indicates
whether the identity has access rights beyond those of
normal system users (e.g. "root" on Unix")
Element type for a fact about a target system: a
name-value pair with a type. The content of the element
is the value, the type attribute gives the type. This
is an area where XML schema is weak: we can't make the
schema validator check that the content matches the type.
This element holds all the information about the
application of one rule to a target. It may only
appear as part of a TestResult object.
Type for an instance element in a rule-result.
The content is a string, but the element may
also have two attribute: context and parentContext.
This type records the details of the target system
instance for multiply instantiated rules.
Type for an override block in a rule-result.
It contains five mandatory parts: time, authority,
old-result, new-result, and remark.
Type for a message generated by the checking
engine or XCCDF tool during benchmark testing.
Content is string plus required severity attribute.
Allowed values for message severity.
Allowed result indicators for a test, several possibilities:
pass= the test passed, target complies w/ benchmark
fail= the test failed, target does not comply
error= an error occurred and test could not complete,
or the test does not apply to this plaform
unknown= could not tell what happened, results
with this status are not to be scored
notapplicable=Rule did not apply to test target
fixed=rule failed, but was later fixed (score as pass)
notchecked=Rule did not cause any evaluation by
the checking engine (role of "unchecked")
notselected=Rule was not selected in the Benchmark,
and therefore was not checked (selected="0")
informational=Rule was evaluated by the checking
engine, but isn't to be scored (role of "unscored")
Allowed severity values for a Rule.
there are several possible values:
unknown= severity not defined (default, for forward
compatibility from XCCDF 1.0)
info = rule is informational only, failing the
rule does not imply failure to conform to
the security guidance of the benchmark.
(usually would also have a weight of 0)
low = not a serious problem
medium= fairly serious problem
high = a grave or critical problem
Allowed checking and scoring roles for a Rule.
There are several possible values:
full = if the rule is selected, then check it and let the
result contribute to the score and appear in reports
(default, for compatibility for XCCDF 1.0).
unscored = check the rule, and include the results in
any report, but do not include the result in
score computations (in the default scoring model
the same effect can be achieved with weight=0)
unchecked = don't check the rule, just force the result
status to 'unknown'. Include the rule's
information in any reports.