SCAP standard family comprises of multiple component standard. The components are designed to work together the common goal. For each component the standard defines a document format with syntax and semantics of the internal data structures. All the component standards are based on Extensible Markup Language (XML) and each component standard defines its own XML namespace. Different versions of the same component standard (language) may also be distinguished by different XML namespace.
Some features implemented OpenSCAP are not covered by SCAP standards specification although they are interoperable with SCAP — e.g. Script Check Engine. For these we try to release the specification to allow interoperability with other vendors.
The XCCDF acronym stands for Extensible Configuration Checklist Description Format. As the name suggests, the language is used to describe the security checklists. The language is designed to support information interchange, document generation, organizational and situational tailoring, automated compliance testing, and compliance scoring.
The language contains no commands to perform the scan and it is mostly descriptive. Other component documents (OVAL, OCIL) may be referred from the XCCDF, so one could come to the conclusion that the XCCDF binds all other component standards together. If the XCCDF document is written carefully, it is possible to achieve document which is portable among all the target platforms, and only the assessment documents (OVAL, OCIL) would differ.
Like all the SCAP languages, the XCCDF is based on XML and defines its XML elements and attributes. The XCCDF documents tend to be several hundred lines long. The language specification describes all the elements in detail, and it can be consulted in the NIST Interagency Report 7275 Revision 4.
OpenSCAP supports XCCDF in versions 1.1 and 1.2. For more information about XCCDF, please visit the XCCDF website
An example of an XCCDF check requiring disable remote login over the SSH protocol:See the code
The OVAL acronym stands for Open Vulnerability and Assessment Language. OVAL is declarative language for making logical assertions about the state of system. It is main component of the SCAP standard. It is used to describe security vulnerabilities or desired configuration of systems. OVAL definitions define a secure state of some objects in a computer, for example configuration files, file permissions, processes. OVAL definitions are evaluated using an interpreter called scanner.
The language consists of three parts that correspond to the three steps of the assessment process:
Main concept of the OVAL document are definitions, tests, objects and states. Each definition specifies tests which need to be satisfied. A test links together an object and a state. Test will pass when a resource denoted by given object satisfies requirements in a corresponding state. The variables section defines external variables which may be used to adjust states elements.
An example of OVAL objects describing an single entry in a configuration file:See the code
Like all the SCAP languages, the OVAL is based on XML. The language is defined be XML schemas. These schemas are divided to the Core specification, which is common to all platforms, and many platform-specific extensions, which contains elements applicable only on a specific platform (eg. Linux or Windows specific things). Each component has its own XML namespace.
OVAL is developed by community of contributors from many industry, academic, and government organizations. The development is directed by the OVAL Board. More information about OVAL can be found at the official OVAL website. OpenSCAP supports OVAL version 5.11 and older versions too.
OVAL documents can be found at Center for Internet Security OVAL repository.
DataStream is a format that packs other SCAP components into a single file. This is useful when distributing SCAP content for example over WWW, beacuse a single file is easier to handle.
The Asset Reporting Format (ARF) consolidates multiple result files (OVAL results and XCCDF results). It is also often called Result DataStream.
The Common Platform Enumeration (CPE) serves to identify IT platforms and systems using unequivocally defined names. CPE also includes a method for checking names against a system, and a description format for binding text and tests to a name.
CPE is used in OVAL and XCCDF documents to identify target platform of checks or definitions. Example of such CPE identifier is cpe:/o:fedoraproject:fedora:22 (for Fedora).
Common Vulnerabilities and Exposures (CVE) is a reference dictionary for publicly known security vulnerabilities and exposures. CVE provides standardized names (identifiers) of vulnerabilities. The CVE allows interoperability between different security tools.
CVE can be used for patch management, vulnerability detection and intrusion detection.
List of CVEs can be found in the National Vulnerability Database
Common Weakness Enumeration (CWE) is a community-developed list of software weaknesses. CWE leads its effort to describe in detail known security weaknesses and flaws. It also provides information about prevention, implementation and mitigation of a weakness. The project is supported by the MITRE Corporation. For more information, please visit CWE website.
The Script Check Engine: SCAP extension to allow script execution from SCAP policy. It allows you to make your scripts interoperable with your security policy. For more information, please visit SCE page.
SCAP standard offers tailoring for XCCDF 1.2. OpenSCAP introduces an extension to XCCDF 1.1 specification that allows tools and users to create tailoring files even for XCCDF 1.1.
You can use XCCDF 1.1 tailoring file in the same way as XCCDF 1.2 tailoring, you should only use namespace