Draft RHEL6 STIG Released… now what?!

On 12-FEB-2013 DISA released the first public draft of the Red Hat Enterprise Linux 6 (RHEL6) STIG. Let’s play with it. Understand it. Become friends.

[18-JUNE-2013 editors note: the RHEL6 STIG is now finalized and available on DISA FSO’s website. Some editorial is available here]

The Draft RHEL6 STIG is an incredible milestone. For the first time the content development of a STIG has been open sourced. Through an initiative lead by the National Security Agency’s Information Assurance Directorate (NSA IAD), with partnership from DISA Field Security Operations (DISA FSO), an open source community named the SCAP Security Guide project (SSG) was formed. This community developed the “upstream” SCAP content from which the RHEL6 STIG is derived. The movement towards transparent collaboration — between government agencies, industry partners, and content consumers — further reflects acceptance by the NSA and DISA FSO of the benefits of open source development models.

On 12-FEB-2013 DISA FSO released the first public Draft RHEL6 STIG. This initial draft only includes XCCDF content which can be transformed into an HTML guide. The adoring public has until 26-FEB-2013 to inform DISA of any concerns regarding the content — are passwords to complex? Should SELinux be disabled? Are the audit rules comprehensive enough? — feedback in such areas is welcome and needed to ensure a functional RHEL6 STIG.

On 27-FEB-2013, the day after the public comment period ends, the SSG community will be busy addressing all reported issues. Based off current schedules, a “Final Draft” will be released on 19-MAR-2013. We’ll then go through a final round of public feedback, to have the final (“production ready”) STIG published near the end of April.

Shameless plug for the SSG: If you’d like to see this happen sooner, please feel free to contribute to the SCAP Security Guide! We need developers to address known issues, and  extra assistance will help get things done faster. Your SCAP-foo skills need not be strong, support in creating documentation is vital to usability, as is user testing of our incremental builds.

Below are instructions on transforming the content into a usable form (HTML guides), and how/where to provide feedback to DISA FSO:

  1. SCAP is a content protocol of which you’ll need an interpreter; this is very analogous to how a web browser is needed to view HTML content. Within RHEL6 we ship an interpreter named OpenSCAP, which can be installed via yum:
    $ sudo sh -c "yum -y install openscap-utils"


  2. Next, download and unpack the DISA RHEL6 Draft STIG:
    $ wget -O /tmp/u_draft_redhat%206_v1r03_stig.zip \


  3. Let’s extract DISA’s zip file:
    $ sudo sh -c "mkdir -p /usr/share/xml/scap/DISA"
    $ unzip -d /tmp/ \
    Archive: /tmp/u_draft_redhat%206_v1r03_stig.zip
    inflating: /tmp/U_RedHat6_V1R03_Readme.txt
    inflating: /tmp/U_RedHat6_V1R03_manual_STIG.zip
    inflating: /tmp/U_RedHat6_V1R03_Overview.pdf

    Yes, DISA put a zip file within a zip file. The *_manual_STIG.zip contains the actual SCAP content, of which should be extracted to /usr/share/xml/scap/DISA/:

    $ sudo sh -c "unzip -d /usr/share/xml/scap/DISA/ \
    Archive: /tmp/U_RedHat6_V1R03_manual_STIG.zip
    inflating: /usr/share/xml/scap/DISA/U_RedHat6_v1r03_manual-xccdf.xml
    inflating: /usr/share/xml/scap/DISA/stig_unclass.xsl
    inflating: /usr/share/xml/scap/DISA/DoD-DISA-logos-as-JPEG.jpg


  4. XCCDF is an XML specification which defines what compliance rule(s) your system will be scanned against. The XML is fairly straight forward, however lets convert it into HTML for easier viewing:
    $ oscap xccdf generate guide --profile allrules \
    /usr/share/xml/scap/DISA/U_RedHat6_v1r03_manual-xccdf.xml \ 
    WARNING: Processing an unresolved XCCDF document. This may have unexpected results.

    The command above will convert the XML content to an HTML file. You may ignore the message of “WARNING: Processing an unresolved XCCDF document….” This message relates to the method which DISA publishes their content, and does not effect usage. The Table of Contents will list out the various rules contained within the STIG. Click on the first item — OS-SRG-000016 — and let’s review it. You’ll quickly notice that DISA has decorated the content with several XML tags (such as FalseNegatives, SeverityOverrideGuidance, etc) which have little apparent meaning. These XML tags are generated through DISA’s internal tooling and may be ignored. Once you get past the formatting you’ll notice a review of the requirement (via the VulnDiscussion tag), and implementation details under “Remediation instructions.”

  5. U.S. Military systems are classified by a “Mission Assurance Category” (MAC) and “Confidentiality Level.” Matrixed together these definitions define what levels of Availability, Integrity, and Confidentiality your system must meet. You can review formal MAC and Confidentiality levels here. In Step 4 we created an HTML checklist reflecting all rules contained within the STIG. If you’re interested in breaking them out per MAC and Confidentiality Level, you can run the following command:
    $ for scapProfile in MAC-1_Classified MAC-1_Public MAC-1_Sensitive \
    MAC-2_Classified MAC-2_Public MAC-2_Sensitive \
    MAC-3_Classified MAC-3_Public MAC-3_Sensitive; do \
    oscap xccdf generate guide --profile $scapProfile \
    /usr/share/xml/scap/DISA/U_RedHat6_v1r03_manual-xccdf.xml \
    >/tmp/DISA_DRAFT_RHEL6_STIG-$scapProfile.html \

    Note: You can against ignore the messages about “WARNING: Processing an unresolved XCCDF document.” Here are the HTML files which would be generated:

At this point you’re probably asking what the heck you’re supposed to be doing with this guide. Peer review of the content to identify any known issues is needed (“this setting will break my system!”), as is review of the implementation details (“n00b! Your audit rule regex is wrong!”). If you find something please EMail disa.letterkenny.FSO.mbx.stig-customer-support-mailbox@mail.mil, but be sure to call out which rule number you’re referring to. They’re identifiable as “RHEL-06-000xxx” in the content.