Hello, I thought it would be useful to generate an "all_rules" profile to help us in the requirements-gathering phase of a profile development. To create this profile I grepped the .xml files contained in the system and services directories for "Rule id=" and used the output to create an all_rules profile. The all_rules profile and CS2 profile list 388 rules while the STIG lists 389. I expected the all_rules profile to have more rules than either since it should contain at least all the rules called by both CS2 and the STIG. Are there rules in other directories, or am I missing something else?

[shawn@SSG-RHEL6 input]$ pwd /var/www/html/scap-security-guide/RHEL6/input [shawn@SSG-RHEL6 input]$ grep -rin "<select id" profiles/common.xml profiles/stig-rhel6-server.xml | wc -l 251

[shawn@SSG-RHEL6 input]$ grep -rin "<select id" profiles/CS2.xml | wc -l 318

[shawn@SSG-RHEL6 input]$ grep -ri "<rule id" services/ system/ wc -l 385

[shawn@SSG-RHEL6 input]$ grep -ri "<rule id" services/ system/ | awk -F: '{print $2}' | \ sed 's/Rule id/select idref/g' > profiles/scan_everything.xml [shawn@SSG-RHEL6 input]$ echo -e "<Profile id=\"scan_everything\">\n \ <description>I'm going to scan everything, because I'm kinda crazy :)</description>\n \ $(cat profiles/scan_everything.xml)" > profiles/scan_everything.xml [shawn@SSG-RHEL6 input]$ echo "</Profile>" >> profiles/scan_everything.xml

[shawn@SSG-RHEL6 input]$ grep -rin "<Value id" * | wc -l 49

I have been comparing SECSCN output to the STIG and CS2 profiles and thus-far it has raised a couple questions. First SECSCN lists the bash commands it uses to gather its results and lists the exact reasons for a failed test. Are there plans to include this capability in the future or would this be handled by a scanning automation tool like oscap?

What component of SCAP and/or OVAL is linked to bash? Is it possible to get access to this underlying source-code for modification purposes?

Thank you! I am using the all_rules profile to compare currently developed SCAP rules to the checks carried-out by SECSCN. For some of the auditing checks that SECSCN runs this may be difficult, but I hope to prove that SCAP is just as comprehensive.

The consensus content was developed using an open-source project called SCAP Security Guide. The project’s website is https://fedorahosted.org/scap-security-guide/. Except for differences in formatting to accommodate the DISA STIG publishing process, the content of the RHEL6 STIG should mirror the SCAP Security Guide content with only minor divergence as updates from multiple sources work through the consensus process.

I guess this has turned into an OVAL oriented question concerning how it defines system objects. I think at this point a fail/pass value and a well-described rule should be more than enough for a system administrator to find and address whatever caused a "fail".

It is also important to note that NIST 800-53 is not a requirements document. It is a catalog of security controls (designed to provide a common vocabulary), from which parties can choose the controls they wish to implement, often in order to create policy. CNSSI-1253 is one such example; DISA SRGs (which are being synchronized with Common Criteria Protection Profiles) are another example as these represent a DoD selection from the NIST catalog. The NIST controls mapped in http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh... are subject to great deal of interpretation. Future patches may bring these much more in line with DISA's approach (used for the STIG), which is based on their CCI list (which is itself a deconstructed version of 800-53, and was created in order to provide the information from 800-53 in a granular and machine-parseable form). This approach seems like a more reasonable way to use 800-53. Vague association with an 800-53 control, or several 800-53 controls, as featured in the other table, is not a policy-driven approach; it is more like a policy-decorated approach, assuming there is any such policy requiring the implementation of the controls listed there. Of course, in the absence of any authoritative guidance on how to effectively use 800-53, it's very much choose your own adventure. I suggest choosing one with a degree of clarity, and in which the benefits outweigh the costs. On Mon, Nov 4, 2013 at 8:34 PM, Shawn Wells <shawn(a)redhat.com&gt; wrote: > On 11/4/13, 7:38 PM, Kordell, Luke T wrote: > > Thank you! I am using the all_rules profile to compare currently developed > SCAP rules to the checks carried-out by SECSCN. For some of the auditing > checks that SECSCN runs this may be difficult, but I hope to prove that SCAP > is just as comprehensive. > > This conversation creeps up every now and then. SECSCN is a tool. OpenSCAP > is a tool. SCAP Security Guide, I suppose, can be argued is a tool. Tools > must comprehensively address policy. > > To ensure SSG addresses policy, collaboration occurred directly with policy > owners such as DISA FSO (for the STIG) and NSA (for the SNAC guides). DISA > calls out this collaboration within section 1.1 of the STIG Overview: > > The consensus content was developed using an open-source project called SCAP > Security Guide. > The project’s website is https://fedorahosted.org/scap-security-guide/. > Except for differences in > formatting to accommodate the DISA STIG publishing process, the content of > the RHEL6 STIG > should mirror the SCAP Security Guide content with only minor divergence as > updates from > multiple sources work through the consensus process. > > > To aid in this, refer to the policy tables, such as this one for the STIG: > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-st... > > Or this one for NIST: > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh... > > Thoughts on what additional information SSG could provide to show policy > correlations would be most welcome. > > > > I guess this has turned into an OVAL oriented question concerning how it > defines system objects. I think at this point a fail/pass value and a > well-described rule should be more than enough for a system administrator to > find and address whatever caused a "fail". > > > > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >

It is also important to note that NIST 800-53 is not a requirements document. It is a catalog of security controls (designed to provide a common vocabulary), from which parties can choose the controls they wish to implement, often in order to create policy. CNSSI-1253 is one such example; DISA SRGs (which are being synchronized with Common Criteria Protection Profiles) are another example as these represent a DoD selection from the NIST catalog. The NIST controls mapped in http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh... are subject to great deal of interpretation. Future patches may bring these much more in line with DISA's approach (used for the STIG), which is based on their CCI list (which is itself a deconstructed version of 800-53, and was created in order to provide the information from 800-53 in a granular and machine-parseable form). This approach seems like a more reasonable way to use 800-53. Vague association with an 800-53 control, or several 800-53 controls, as featured in the other table, is not a policy-driven approach; it is more like a policy-decorated approach, assuming there is any such policy requiring the implementation of the controls listed there. Of course, in the absence of any authoritative guidance on how to effectively use 800-53, it's very much choose your own adventure. I suggest choosing one with a degree of clarity, and in which the benefits outweigh the costs. On Mon, Nov 4, 2013 at 8:34 PM, Shawn Wells <shawn(a)redhat.com&gt; wrote: > On 11/4/13, 7:38 PM, Kordell, Luke T wrote: > > Thank you! I am using the all_rules profile to compare currently developed > SCAP rules to the checks carried-out by SECSCN. For some of the auditing > checks that SECSCN runs this may be difficult, but I hope to prove that SCAP > is just as comprehensive. > > This conversation creeps up every now and then. SECSCN is a tool. OpenSCAP > is a tool. SCAP Security Guide, I suppose, can be argued is a tool. Tools > must comprehensively address policy. > > To ensure SSG addresses policy, collaboration occurred directly with policy > owners such as DISA FSO (for the STIG) and NSA (for the SNAC guides). DISA > calls out this collaboration within section 1.1 of the STIG Overview: > > The consensus content was developed using an open-source project called SCAP > Security Guide. > The project’s website is https://fedorahosted.org/scap-security-guide/. > Except for differences in > formatting to accommodate the DISA STIG publishing process, the content of > the RHEL6 STIG > should mirror the SCAP Security Guide content with only minor divergence as > updates from > multiple sources work through the consensus process. > > > To aid in this, refer to the policy tables, such as this one for the STIG: > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-st... > > Or this one for NIST: > http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rh... > > Thoughts on what additional information SSG could provide to show policy > correlations would be most welcome. > > > > I guess this has turned into an OVAL oriented question concerning how it > defines system objects. I think at this point a fail/pass value and a > well-described rule should be more than enough for a system administrator to > find and address whatever caused a "fail". > > > > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >

Thank you for all the useful feedback! I am actually comparing the SCAP rules against SECSCNcontrols that have already been selected. My team may choose to utilize additional SCAP scans as we see fit, but my minimum requirements are somewhat straight-forward. I realize that many of the controls are open to interpretation but I think in some of these cases a series of SCAP rules can be called to check all aspects. For instance one of our user account configuration control requirements can be covered by calling two SCAP rules. I know this may not work in all cases, but to me it's worth putting in the time to connect all the dots. In some situations SCAP seems more precise than SECSCN which can make the two difficult to compare.