Formal computer security guidance helps enterprises of all sizes to implement effective security actions. These security actions are typically specified via benchmarks.
A computer security BENCHMARK is a document that specifies settings and option selections that minimize the security risks associated with a computer hardware or software system. Written in Extensible Configuration Checklist Description Format (XCCDF) language, it can be read, translated, and presented by checking tools. However, it does not contain the information needed to evaluate compliance. An AUTOMATED BENCHMARK document is required to perform the compliance check. Automated benchmarks specify the same settings and option selections as standard benchmarks, but in addition to being written in XCCDF they use one or more standardized checking languages to contain the information needed to evaluate compliance. MITRE advocates the use of automated benchmarks because of the compliance checks.
Benefits of Automated Benchmarks
- Repeatable — Guidance is accompanied by machine-readable tests for compliance
- Faster — Compliance assessment is no longer a difficult manual process
- Correlation — Results are augmented with standard identifiers for issues
Benchmarks can be written for installation and configuration issues, deployment options, account and password policies, settings for security features, product key features, etc.
Each benchmark contains a "Rule," which is the unit of a benchmark containing the recommendation, rationale, and how to of the specified action. In the case of an automated benchmark, a Rule consists of the recommendation, rationale, how-to, and the compliance check.
The subcomponents of the Rule are defined as follows:
- Recommendation — explains what security-relevant action to take
- Rationale — explains why the action should be taken
- How-To — details how to carry out the action
- Compliance Check — a Boolean check used to determine compliance with a desired state. Ideally, the compliance check is expressed in a standardized format such as OVAL to ensure the guidance is easily consumed by a broad audience.
Example of a Rule:
|Recommendation:||Change the default encryption key during the installation of the Tivoli Identity Manager|
|Rationale:||The encryption key is used to encrypt TIM passwords and other sensitive data. The default encryption key is [sunshine]. If the default encryption key is not changed a malicious user could potentially use the default key to gain access to TIM passwords and sensitive data. Changing the default encryption key will help protect Tivoli passwords and sensitive data.|
Rules are categorized as they are developed and help analysts to understand the level of effort required to add compliance checks to a benchmark, provide a rough estimate of how much of a guide can be covered with compliance checks, and helps indicate which checking system to use. Rules fall into three categories:
- Check Category — applied to a Rule that indicates a tool can run a test and determine a true or false result indicating that the system is in compliance or not
- Question Category — applied to a Rule that indicates a question must be asked of a user to determine compliance
- Report Category — applied to a Rule that indicates a report is needed for further analysis to determine compliance
Once the Rule is created, the guidance must be mapped to existing configuration controls. Common control standards include NIST Special Publication 800-53: Recommended Security Controls for Federal Information Systems and Common Configuration Enumeration (CCE™). Control stands are used because they refer to widely-recognized regulatory frameworks, cite precise configuration controls, facilitate clear communication, and provide pointers to further information.
|TITLE:||PREVIOUS LOGON NOTIFICATION|
|CONTROL:||The information system notifies the user, upon successful logon, of the date and time of the last logon, and the number of unsuccessful logon attempts since the last successful logon.|
|DESCRIPTION:||The "Disable CTRL+ALT+Delete Requirement for Logon" policy should be set correctly.|
|PARAMETER:||Enabled / Disabled|
Compliance Test (Automated Benchmarks only)
Compliance tests are Boolean checks used to determine compliance with the desired state defined by the Rule. There are currently two standards for compliance tests that ensure the guidance can be easily consumed by a broad audience, Open Checklist Interactive Language (OCIL) for gathering structured information from end users in order to accurately perform the compliance testing, and Open Vulnerability and Assessment Language (OVAL®) for system configuration checking and reporting the results.
Example of an OVAL compliance test: oval:org.mitre.oval:def:5275.
There are five phases in the benchmark development process.
- Phase 1 — Writing Good Guidance
- Phase 2 — Augmenting Guidance
- Phase 3 — Automating Assessment
- Phase 4 — Benchmark Structuring and Tailoring
- Phase 5 — Managing Compliance (An ongoing process)
Page Last Updated: April 15, 2011