Ce contenu n'est pas disponible dans la langue sélectionnée.
8.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.
8.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 8.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>
