stig_overlay.sh of rhel6 appears to be same for rhel7. When completed what will rhel7 stig_overlay look like when rhel6 references are replaced? Should I be talking with DISA FSO or have I missed something in the Wiki or blogs?
DISA RHEL-7 Draft STIG references to "SRG-OS-000001-GPOS-00001" are new to me...Is this a new form of unified references? Somehow cross-referenced to "CCI"? I need some guidance here, or is it still being sorted out?
I really don't know how to phrase this question intelligently....can someone help me out?
On 2/29/16 7:02 PM, Mike Kuhnkey wrote:
stig_overlay.sh of rhel6 appears to be same for rhel7. When completed what will rhel7 stig_overlay look like when rhel6 references are replaced? Should I be talking with DISA FSO or have I missed something in the Wiki or blogs?
It's not well documented =/
DISA creates their own identification scheme outside of industry CCEs. These are the RHEL-06-* identifiers you mention. They come from the RHEL/6/input/auxiliary/stig_overlay.xml file.
For example: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/aux...
<overlay owner="disastig" ruleid="partition_for_var_log_audit"ownerid="RHEL-06-000004" disa="137" severity="low"> <VMSinfo VKey="38467" SVKey="50267" VRelease="1" /> <title>The system must use a separate file system for the system audit data path.</title> </overlay>
This will take the partition_for_var_log_audit rule and embed RHEL-06-000004 into its metadata.
As DISA gets closer to releasing the RHEL7 STIG, we'll update these mappings for RHEL7 content (as by that time, DISA will have finalized their RHEL-07-* numbering schemes).
DISA RHEL-7 Draft STIG references to "SRG-OS-000001-GPOS-00001" are new to me...Is this a new form of unified references? Somehow cross-referenced to "CCI"? I need some guidance here, or is it still being sorted out?
I really don't know how to phrase this question intelligently....can someone help me out?
You're not crazy. The SRG system is broken and going away. Until SRG dies, the system goes something like this:
Step 1: DISA attempts to interpret NIST 800-53 and selects controls they feel are relevant for an operating system. From this, they create high level requirements in the form of "General Purpose Operating System Security Requirements Guide," or GPOS SRG. This is where the SRG-OS-######-GPOS-##### numbers come from. The GPOS SRG is generic, applicable to RHEL, Windows, OSX, etc. An example could be "Audit Privileged User Actions." Outside of DISA, these numbers are entirely meaningless.
Step 2: Once DISA has the high-level requirements, they create product-specific configuration guidance. This is where RHEL-07-###### numbers come from. "Audit Privileged User Actions" might mean adding 10+ audit rules for Linux, so we'd have RHEL-07-000000 through RHEL-07-000010 mapped back to a single SRG-OS-GPS identifier. When RHEL deployments attest to STIG compliance, they must show conformance to RHEL-07-###### controls.
Step 3: Once the RHEL-07-###### controls and naming schema is finalized, we map them into the stig_overlay file. This will bind the DISA identifiers into OpenSCAP XCCDF content. End result being DISA identifiers show up in OpenSCAP HTML and CLI reports, looking something like this:
Title Set Password Strength Minimum Special Characters Rule accounts_password_pam_ocredit Ident CCE-26409-3 Ident DISA FSO RHEL-06-000058 Result pass
Does this help?
scap-security-guide@lists.fedorahosted.org
-
Mike Kuhnkey -
Shawn Wells