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 3. 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.3.2 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 version 1.0. Use CPE 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 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 information consult the document "Common Platform Enumeration (CPE) - Name Format and Description" by Buttner, Wittbold, and Ziring (2006). Note that it is not necessary to define all the CPE URIs used in a benchmark; common platforms will be defined in a community concensus dictionary. Only unusual or custom platforms typically will need to be identified in a CPE cpe-list element in a benchmark. The benchmark tag is the top level element representing a complete security checklist, including descriptive text and test items. 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 CPE URIs used as platform identifiers.) 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. 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, extremely 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 inversion.) 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-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, numeric, or boolean value 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 mandatory 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. 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. Type for the set-value element in a Profile; it has one attribute and string content. The attribute is 'idref' which 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. 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. 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.) 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.