Organizations which use Red Hat Enterprise Linux 5 and must adhere to the U.S. Defense Information Systems Agency's (DISA) UNIX Security Technical Implementation Guide (STIG) have been stuck with documentation and assessment tools which only support up to Red Hat Enterprise Linux 4.
This frustrates many system administrators because they must deal with false positives produced by the System Readiness Review (SRR) scripts and a checklist with incorrect procedures.
The only hint of future support is seen on the DISA Field Security Office (FSO) website under their frequently asked questions (FAQ). The question, “When will there be a RedHat 5 STIG and SRR scripts?” was answered as follows:
“FSO is currently working with the vendor and the DoD Consensus team to develop the security requirements for RedHat5. FSO has no plans to develop UNIX scripts which support RedHat5 since they are moving towards utilizing the Security Content Automation Protocols and HBSS (Host Based Security System) Policy Auditor for future assessments. There is no estimated completion date at this time for the HBSS Policy Auditor RedHat5 benchmark. FSO expects to have the STIG completed by late FY10 or early FY11.”
In January 2011, Red Hat Enterprise Linux 6 was released adding to the frustration. In a January 27, 2011 email, Steve Grubb (Red Hat) writes to the gov-sec mailing list that Red Hat Enterprise Linux 6 includes an OpenSCAP scanner.
Before I go into too much detail about OpenSCAP, I should give a little background. The STIGs are published by DISA FSO. There are three pieces:
- UNIX STIG V5R1 (April 2006) — This is the main document and it gives plenty of explanations, rationale, and general information.
- UNIX Security Checklist (published quarterly) — details the requirements by line item to include what to look for in configuration files as well as commands to be executed.
- System Readiness Review (SRR) Scripts (published quarterly) — scan the operating system for compliancy. To download, you must have DoD PKI access.
The checklists and associated SRR scripts are the components most people have heartburn about. In May 2010, the DISA FSO gave a presentation titled “STIGs, SCAP, and Data Metrics.” In this presentation, they identified some “Maintenance Challenges”:
- High demand from the user community for new and updated security guidance
- Rapid pace of new technology
- Limited resources to develop guidance and tools to evaluate compliance
- Development and maintenance of varying tools/techniques for supporting compliance checks:
- Gold Disk (Windows)
- Security Readiness Review Scripts (Unix, some DB)
The SRR scripts have always been written in Bourne shell script for portability reasons. However, the difficulty in maintaining the collection of scripts, limited reporting capabilities, and lack of interoperability with other tools has pushed DISA in a new direction.
The Information Security Automation Program (ISAP) is a U.S. government multi-agency initiative to enable automation and standardization of technical security operations. ISAP’s technical specifications are contained in the related Security Content Automation Protocol (SCAP).
ISAP’s security automation content is either contained within, or referenced by, the National Vulnerability Database (NVD) maintained by NIST. Current SCAP protocols include CVE, CCE, CPE, CVSS, OVAL, and XCCDF.
In the aforementioned presentation, DISA went on to say that they were “Developing Security Requirements Guides (SRGs) that address overarching requirements...” in order to “promote structure.”
On February 2, 2011, DISA FSO posted “OS SRG (UNIX), Version 1.1” which was completed in November 2010. The downloaded archive contained several files but no Microsoft Word formatted Checklist document (I can live with that). Instead, you get two XML documents:
- Operating System Security Requirements Guide (UNIX Version)
- Operating System Policy Security Requirements Guide (UNIX Version)
The documents are in what is referred to as XCCDF. According to the provided “STIG Transformation to XCCDF FAQ” document.
"The move to an eXtensible Configuration Checklist Description Format (XCCDF) formatted STIG provides the ability for the consumption of the STIGs by the various automated assessment tools, such as Host Based Security System (HBSS)."
According to the FAQ, “The STIG is still used the same way; it is just that the data is in a different format.” They do provide an XSL to transform the XCCDF/XML documents to XHTML so you can read them in your web browser.
As an engineer, I love the idea of promoting structure so this makes sense to me. Now that I found my checklists, how can I perform a scan like I did with the SRR scripts?
According to the email announcement from DISA FSO, the “automated assessments can then be accomplished using SCAP compliant tools through the use of DISA generated benchmarks based on the STIG requirements. This will replace the UNIX SRR scripts.”
A benchmark is the version of the STIG that contains the Open Vulnerability and Assessment Language (OVAL) code. This code allows an OVAL-compliant security tool to perform an automated assessment of the system. This is similar to the quarterly released checklist and associated SRR scripts which are used today.
Like the SRR scripts, the benchmark does not contain all the checks necessary to meet the STIG requirements. For example, GEN00080 requires that “all server system equipment must be located in a controlled area.” There is no way an automated benchmark could check for this so you would have to “manually” verify this yourself.
Based on the information above, I need a benchmark (OVAL content) in order to assess a system. The FAQ document lists the following:
- STIG-OVAL.xml – This file contains the detailed OVAL check code. This will only be provided if OVAL exists for the technology.
- STIG-CPE-OVAL.xml - This is OVAL code that will provide information to the tool on how to check to see if the product being evaluated exists on the system.
- STIG-CPE-DICTIONARY.xml – This is the file that contains the CPE information about the product.
However, I could not find any of those files. The only XML files found were the checklist documents. According to the DISA FSO email announcement, this content won't be available until late 2011.
Out of curiosity, I went to the NVD website and searched through all of the operating system checklists. Specifically, I needed a checklist with the associated OVAL content in order to assess the system.
I found 164 checklists, most of them are for Microsoft products to support the U.S. Government Configuration Baseline (USGCB), formerly known as the Federal Desktop Core Configuration (FDCC). The only UNIX/Linux related content I found were:
- zOS ACF2 STIG Checklist (Version 6, Release 4) (XCCDF only)
- zOS TSS STIG Checklist (Version 6, Release 4) (XCCDF only)
- zOS RACF STIG Checklist (Version 6, Release 4) (XCCDF only)
- DoD Consensus Security Configuration Checklist for Red Hat Enterprise Linux 5 (XCCDF and OVAL Content, yeah!)
However, there is no OVAL content to support the UNIX STIG. The Red Hat content listed above had both the checklist and the OVAL content but it was only for Red Hat Enterprise Linux 5 and not for the UNIX STIG.
The SCAP website emphasizes the importance of community involvement. It appears that DISA's strategy is to focus on developing the Security Requirement Guides (SRGs) and associated checklists (XCCDF) while the “community” develops the OVAL content. This alleviates them from having to write and maintain the SRR scripts.
Presently, the primary vendor contributing to content is Red Hat. As a matter of fact, they are sponsoring the OpenSCAP project, hence the delivery of the OpenSCAP scanner in Fedora 14 and Red Hat Enterprise Linux 6.
So the bottom line is Red Hat Enterprise Linux 5 and 6 are still not supported by the DISA UNIX STIG. It is expected that vendors (and the SCAP community) will deliver the appropriate SCAP content to assess systems in late 2011. Until then, system administrators can continue to use the SRR scripts and deal with false positives on the newer Red Hat distributions.
In my next blog post, I will discuss Security Blanket's use of SCAP enumeration and mapping specifications as well as our possible role as a “producer.”
Cross-posted from Security Blanket Technical Blog