7.2. Defining Compliance Policy

The security or compliance policy is rarely written from scratch. ISO 27000 standard series, derivative works, and other sources provide security policy templates and practice recommendations that should be helpful to start with. However, organizations building theirs information security program need to amend the policy templates to align with their needs. The policy template should be chosen on the basis of its relevancy to the company environment and then the template has to be adjusted because either the template contains build-in assumptions which cannot be applied to the organization, or the template explicitly requires that certain decisions have to be made.
Red Hat Enterprise Linux auditing capabilities are based on the Security Content Automation Protocol (SCAP) standard. SCAP is a synthesis of interoperable specifications that standardize the format and nomenclature by which software flaw and security configuration information is communicated, both to machines and humans. SCAP is a multi-purpose framework of specifications that supports automated configuration, vulnerability and patch checking, technical control compliance activities, and security measurement.
In other words, SCAP is a vendor-neutral way of expressing security policy, and as such it is widely used in modern enterprises. SCAP specifications create an ecosystem where the format of security content is well known and standardized while the implementation of the scanner or policy editor is not mandated. Such a status enables organizations to build their security policy (SCAP content) once, no matter how many security vendors do they employ.
The latest version of SCAP includes several underlying standards. These components are organized into groups according to their function within SCAP as follows:

SCAP Components

  • Languages — This group consists of SCAP languages that define standard vocabularies and conventions for expressing compliance policy.
    • The eXtensible Configuration Checklist Description Format (XCCDF) — A language designed to express, organize, and manage security guidance.
    • Open Vulnerability and Assessment Language (OVAL) — A language developed to perform logical assertion about the state of the scanned system.
    • Open Checklist Interactive Language (OCIL) — A language designed to provide a standard way to query users and interpret user responses to the given questions.
    • Asset Identification (AI) — A language developed to provide a data model, methods, and guidance for identifying security assets.
    • Asset Reporting Format (ARF) — A language designed to express the transport format of information about collected security assets and the relationship between assets and security reports.
  • Enumerations — This group includes SCAP standards that define naming format and an official list or dictionary of items from certain security-related areas of interest.
    • Common Configuration Enumeration (CCE) — An enumeration of security-relevant configuration elements for applications and operating systems.
    • Common Platform Enumeration (CPE) — A structured naming scheme used to identify information technology (IT) systems, platforms, and software packages.
    • Common Vulnerabilities and Exposures (CVE) — A reference method to a collection of publicly known software vulnerabilities and exposures.
  • Metrics — This group comprises of frameworks to identify and evaluate security risks.
    • Common Configuration Scoring System (CCSS) — A metric system to evaluate security-relevant configuration elements and assign them scores in order to help users to prioritize appropriate response steps.
    • Common Vulnerability Scoring System (CVSS) — A metric system to evaluate software vulnerabilities and assign them scores in order to help users prioritize their security risks.
  • Integrity — An SCAP specification to maintain integrity of SCAP content and scan results.
    • Trust Model for Security Automation Data (TMSAD) — A set of recommendations explaining usage of existing specification to represent signatures, hashes, key information, and identity information in context of an XML file within a security automation domain.
Each of the SCAP components has its own XML-based document format and its XML name space. A compliance policy expressed in SCAP can either take a form of a single OVAL definition XML file, data stream file, single zip archive, or a set of separate XML files containing an XCCDF file that represents a policy checklist.

7.2.1. The XCCDF File Format

The XCCDF language is designed to support information interchange, document generation, organizational and situational tailoring, automated compliance testing, and compliance scoring. The language is mostly descriptive and does not contain any commands to perform security scans. However, an XCCDF document can refer to other SCAP components, and as such it can be used to craft a compliance policy that is portable among all the target platforms with the exception of the related assessment documents (OVAL, OCIL).
The common way to represent a compliance policy is a set of XML files where one of the files is an XCCDF checklist. This XCCDF file usually points to the assessment resources, multiple OVAL, OCIL and the Script Check Engine (SCE) files. Furthermore, the file set can contain a CPE dictionary file and an OVAL file defining objects for this dictionary.
Being an XML-based language, the XCCDF defines and uses a vast selection of XML elements and attributes. The following list briefly introduces the main XCCDF elements; for more details about XCCDF, consult the NIST Interagency Report 7275 Revision 4.

Main XML Elements of the XCCDF Document

  • <xccdf:Benchmark> — This is a root element that encloses the whole XCCDF document. It may also contain checklist metadata, such as a title, description, list of authors, date of the latest modification, and status of the checklist acceptance.
  • <xccdf:Rule> — This is a key element that represents a checklist requirement and holds its description. It may contain child elements that define actions verifying or enforcing compliance with the given rule or modify the rule itself.
  • <xccdf:Value> — This key element is used for expressing properties of other XCCDF elements within the benchmark.
  • <xccdf:Group> — This element is used to organize an XCCDF document to structures with the same context or requirement domains by gathering the <xccdf:Rule>, <xccdf:Value>, and <xccdf:Group> elements.
  • <xccdf:Profile> — This element serves for a named tailoring of the XCCDF benchmark. It allows the benchmark to hold several different tailorings. <xccdf:Profile> utilizes several selector elements, such as <xccdf:select> or <xccdf:refine-rule>, to determine which elements are going to be modified and processed while it is in effect.
  • <xccdf:Tailoring> — This element allows defining the benchmark profiles outside the benchmark, which is sometimes desirable for manual tailoring of the compliance policy.
  • <xccdf:TestResult> — This element serves for keeping the scan results for the given benchmark on the target system. Each <xccdf:TestResult> should refer to the profile that was used to define the compliance policy for the particular scan and it should also contain important information about the target system that is relevant for the scan.
  • <xccdf:rule-result> — This is a child element of <xccdf:TestResult> that is used to hold the result of applying a specific rule from the benchmark to the target system.
  • <xccdf:fix> — This is a child element of <xccdf:Rule> that serves for remediation of the target system that is not compliant with the given rule. It can contain a command or script that is run on the target system in order to bring the system into compliance the rule.
  • <xccdf:check> — This is a child element of <xccdf:Rule> that refers to an external source which defines how to evaluate the given rule.
  • <xccdf:select> — This is a selector element that is used for including or excluding the chosen rules or groups of rules from the policy.
  • <xccdf:set-value> — This is a selector element that is used for overwriting the current value of the specified <xccdf:Value> element without modifying any of its other properties.
  • <xccdf:refine-value> — This is a selector element that is used for specifying constraints of the particular <xccdf:Value> element during policy tailoring.
  • <xccdf:refine-rule> — This selector element allows overwriting properties of the selected rules.

Example 7.1. An Example of an XCCDF Document

        
<?xml version="1.0" encoding="UTF-8"?>
<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2"
    id="xccdf_com.example.www_benchmark_test">
  <status>incomplete</status>
  <version>0.1</version>
  <Profile id="xccdf_com.example.www_profile_1">
    <title>Profile title is compulsory</title>
    <select idref="xccdf_com.example.www_group_1" 
        selected="true"/>
    <select idref="xccdf_com.example.www_rule_1" 
        selected="true"/>
    <refine-value idref="xccdf_com.example.www_value_1"
        selector="telnet service"/>
  </Profile>
  <Group id="xccdf_com.example.www_group_1">
    <Value id="xccdf_com.example.www_value_1">
      <value selector="telnet_service">telnet-server</value>
      <value selector="dhcp_servide">dhcpd</value>
      <value selector="ftp_service">tftpd</value>
    </Value>
    <Rule id="xccdf_com.example.www_rule_1">
      <title>The telnet-server Package Shall Not Be Installed </title>
      <rationale>
        Removing the telnet-server package decreases the risk
        of the telnet service’s accidental (or intentional) activation
      </rationale>
      <fix platform="cpe:/o:redhat:enterprise_linux:6" 
          reboot="false" 
          disruption="low" 
          system="urn:xccdf:fix:script:sh">
        yum -y remove 
        <sub idref="xccdf_com.example.www_value_1"/>
      </fix>
      <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
        <check-export value-id="xccdf_com.example.www_value_1" 
            export-name="oval:com.example.www:var:1"/>
        <check-content-ref href="examplary.oval.xml" 
            name="oval:com.example.www:def:1"/>
      </check>
      <check system="http://open-scap.org/page/SCE">
        <check-import import-name="stdout"/>
        <check-content-ref href="telnet_server.sh"/>
      </check>
    </Rule>
  </Group>
</Benchmark>

7.2.2. The OVAL File Format

The Open Vulnerability Assessment Language (OVAL) is the essential and oldest component of SCAP. The main goal of the OVAL standard is to enable interoperability among security products. That is achieved by standardization of the following three domains:
  1. Representation of the target system configuration.
  2. Analysis of the target system for the presence of a particular machine state.
  3. Reporting the results of the comparison between the specified machine state and the observed machine state.
Unlike other tools or custom scripts, the OVAL language describes a required state of resources in a declarative manner. The OVAL language code is never executed directly, but by means of an OVAL interpreter tool called scanner. The declarative nature of OVAL ensures that the state of the assessed system is not accidentally modified, which is important because security scanners are often run with the highest possible privileges.
OVAL specification is open for public comments and contribution and various IT companies collaborate with the MITRE Corporation, federally funded not-for-profit organization. The OVAL specification is continuously evolving and different editions are distinguished by a version number. The current version 5.11.1 was released in April 2015.
Like all other SCAP components, OVAL is based on XML. The OVAL standard defines several document formats. Each of them includes different kind of information and serves a different purpose.

The OVAL Document Formats

  • The OVAL Definitions format is the most common OVAL file format that is used directly for system scans. The OVAL Definitions document describes the required state of the target system.
  • The OVAL Variables format defines variables used to amend the OVAL Definitions document. The OVAL Variables document is typically used in conjunction with the OVAL Definitions document to tailor the security content for the target system at runtime.
  • The OVAL System Characteristics format holds information about the assessed system. The OVAL System Characteristics document is typically used to compare the actual state of the system against the expected state defined by an OVAL Definitions document.
  • The OVAL Results is the most comprehensive OVAL format that is used to report results of the system evaluation. The OVAL Results document typically contains copy of the evaluated OVAL definitions, bound OVAL variables, OVAL system characteristics, and results of tests that are computed based on comparison of the system characteristics and the definitions.
  • The OVAL Directives format is used to tailor verbosity of an OVAL Result document by either including or excluding certain details.
  • The OVAL Common Model format contains definitions of constructs and enumerations used in several other OVAL schemes. It is used to reuse OVAL definitions in order to avoid duplications across multiple documents.
The OVAL Definitions document consists of a set of configuration requirements where each requirement is defined in the following five basic sections: definitions, tests, objects, states, and variables. The elements within the definitions section describe which of the tests shall be fulfilled to satisfy the given definition. The test elements link objects and states together. During the system evaluation, a test is considered passed when a resource of the assessed system that is denoted by the given object element corresponds with the given state element. The variables section defines external variables which may be used to adjust elements from the states section. Besides these sections, the OVAL Definitions document typically contains also the generator and signature sections. The generator section holds information about the document origin and various additional information related to its content.
Each element from the OVAL document basic sections is unambiguously identified by an identifier in the following form: 
oval:namespace:type:ID
where namespace is a name space defining the identifier, type is either def for definitions elements, tst for tests elements, obj for objects element, ste for states elements, and var for variables elements, and ID is an integer value of the identifier.

Example 7.2. An Example of an OVAL Definitions Document

          
<?xml version="1.0" encoding="utf-8"?>
<oval_definitions
    xmlns:lin-def="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux"
    xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
    xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <generator>
    <oval:product_name>vim</oval:product_name>
    <oval:schema_version>5.10.1</oval:schema_version>
    <oval:timestamp>2012-11-22T15:00:00+01:00</oval:timestamp>
  </generator>
  <definitions>
    <definition class="inventory" 
        id="oval:org.open-scap.cpe.rhel:def:7" 
        version="1">
      <metadata>
        <title>Red Hat Enterprise Linux 7</title>
        <affected family="unix">
          <platform>Red Hat Enterprise Linux 7</platform>
        </affected>
        <reference ref_id="cpe:/o:redhat:enterprise_linux:7" 
            source="CPE"/>
        <description>
          The operating system installed on the system is Red Hat Enterprise Linux 7
        </description>
      </metadata>
      <criteria>
        <criterion comment="Red Hat Enterprise Linux 7 is installed" 
            test_ref="oval:org.open-scap.cpe.rhel:tst:7"/>
      </criteria>
    </definition>
  </definitions>
  <tests>
    <lin-def:rpminfo_test check_existence="at_least_one_exists" 
        id="oval:org.open-scap.cpe.rhel:tst:7" 
        version="1" 
        check="at least one" 
        comment="redhat-release is version 7">
      <lin-def:object object_ref="oval:org.open-scap.cpe.redhat-release:obj:1"/>
      <lin-def:state state_ref="oval:org.open-scap.cpe.rhel:ste:7"/>
    </lin-def:rpminfo_test>
  </tests>
  <objects>
    <lin-def:rpmverifyfile_object id="oval:org.open-scap.cpe.redhat-release:obj:1" 
        version="1">
      <!-- This object represents rpm package which owns /etc/redhat-release file -->
      <lin-def:behaviors nolinkto='true' 
          nomd5='true' 
          nosize='true' 
          nouser='true' 
          nogroup='true' 
          nomtime='true' 
          nomode='true' 
          nordev='true' 
          noconfigfiles='true' 
          noghostfiles='true' />
      <lin-def:name operation="pattern match"/>
      <lin-def:epoch operation="pattern match"/>
      <lin-def:version operation="pattern match"/>
      <lin-def:release operation="pattern match"/>
      <lin-def:arch operation="pattern match"/>
      <lin-def:filepath>/etc/redhat-release</lin-def:filepath>
    </lin-def:rpmverifyfile_object>
  </objects>
  <states>
    <lin-def:rpminfo_state id="oval:org.open-scap.cpe.rhel:ste:7" 
        version="1">
      <lin-def:name operation="pattern match">^redhat-release</lin-def:name>
      <lin-def:version operation="pattern match">^7[^\d]</lin-def:version>
    </lin-def:rpminfo_state>
  </states>
</oval_definitions>

7.2.3. The Data Stream Format

SCAP data stream is a file format used since SCAP version 1.2 and it represents a bundle of XCCDF, OVAL, and other component files which can be used to define a compliance policy expressed by an XCCDF checklist. It also contains an index and catalog that allow splitting the given data stream into files according to the SCAP components.
The data stream uses XML format that consists of a header formed by a table of contents and a list of the <ds:component> elements. Each of these elements encompasses an SCAP component such as XCCDF, OVAL, CPE, and other. The data stream file may contain multiple components of the same type, and thus covering all security policies needed by your organization.

Example 7.3. An Example of a Data Stream Header

        
<ds:data-stream-collection xmlns:ds="http://scap.nist.gov/schema/scap/source/1.2" 
    xmlns:xlink="http://www.w3.org/1999/xlink" 
    xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog" 
    id="scap_org.open-scap_collection_from_xccdf_ssg-rhel7-xccdf-1.2.xml"
    schematron-version="1.0">
  <ds:data-stream id="scap_org.open-scap_datastream_from_xccdf_ssg-rhel7-xccdf-1.2.xml" 
      scap-version="1.2" use-case="OTHER">
  <ds:dictionaries>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel7-cpe-dictionary.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-cpe-dictionary.xml">
      <cat:catalog>
        <cat:uri name="ssg-rhel7-cpe-oval.xml" 
            uri="#scap_org.open-scap_cref_output--ssg-rhel7-cpe-oval.xml"/>
      </cat:catalog>
    </ds:component-ref>
  </ds:dictionaries>
  <ds:checklists>
    <ds:component-ref id="scap_org.open-scap_cref_ssg-rhel7-xccdf-1.2.xml" 
        xlink:href="#scap_org.open-scap_comp_ssg-rhel7-xccdf-1.2.xml">
      <cat:catalog>
        <cat:uri name="ssg-rhel7-oval.xml" 
            uri="#scap_org.open-scap_cref_ssg-rhel7-oval.xml"/>
      </cat:catalog>
    </ds:component-ref>
  </ds:checklists>
  <ds:checks>
    <ds:component-ref id="scap_org.open-scap_cref_ssg-rhel7-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_ssg-rhel7-oval.xml"/>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel7-cpe-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-cpe-oval.xml"/>
    <ds:component-ref id="scap_org.open-scap_cref_output--ssg-rhel7-oval.xml" 
        xlink:href="#scap_org.open-scap_comp_output--ssg-rhel7-oval.xml"/>
  </ds:checks>
</ds:data-stream>
<ds:component id="scap_org.open-scap_comp_ssg-rhel7-oval.xml"
    timestamp="2014-03-14T16:21:59">
  <oval_definitions xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5" 
      xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5" 
      xmlns:ind="http://oval.mitre.org/XMLSchema/oval-definitions-5#independent" 
      xmlns:unix="http://oval.mitre.org/XMLSchema/oval-definitions-5#unix" 
      xmlns:linux="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://oval.mitre.org/XMLSchema/oval-common-5 
      oval-common-schema.xsd 
          http://oval.mitre.org/XMLSchema/oval-definitions-5 
      oval-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#independent 
      independent-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#unix 
      unix-definitions-schema.xsd
          http://oval.mitre.org/XMLSchema/oval-definitions-5#linux 
      linux-definitions-schema.xsd">