SECSCN and all_rules profile

Shawn Wells shawn at redhat.com
Thu Oct 31 17:52:39 UTC 2013


On 10/31/13, 12:51 PM, Kordell, Luke T wrote:
> 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?

You're correct - something is off here.

The STIG profile has 251 rules:
> [shawn at SSG-RHEL6 input]$ pwd
> /var/www/html/scap-security-guide/RHEL6/input
> [shawn at SSG-RHEL6 input]$ grep -rin "<select id" profiles/common.xml 
> profiles/stig-rhel6-server.xml | wc -l
> 251

The CS2 profile has 318:
> [shawn at SSG-RHEL6 input]$ grep -rin "<select id" profiles/CS2.xml | wc -l
> 318

And the total available rules:
> [shawn at SSG-RHEL6 input]$ grep -ri "<rule id" services/ system/ wc -l
> 385

If you wanted to create an XCCDF profile with everything, a quick hack 
job would be:
> [shawn at 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 at 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 at SSG-RHEL6 input]$ echo "</Profile>" >> profiles/scan_everything.xml

If you don't want to take the default refine values (such as for 
password lengths, you'll have 49 tunables to incorporate into the profile:
> [shawn at SSG-RHEL6 input]$ grep -rin "<Value id" * | wc -l
> 49
Note that in the XCCDF these are expressed as value IDs, whereas XCCDF 
profiles need the <refine value= tags. A quick sed one-liner should take 
care of this for you, if there's a need.

Once the profile is created, add the relevant lines to input/guide.xslt 
and then (re)run "make content"


> 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?

SECSCN utilizes shell scripting to perform the configuration checks, 
which makes it easier to show the command(s) used to perform a 
particular test. Since we're using OVAL.... well.... things would get 
incredibly ugly (and arguably confusing to the average user) if we 
dumped the OVAL code into the result output.

Failure reasons -- such as giving the piece of a config file or system 
element that caused the failure -- is up for debate. Here's an example 
of how a few checks looked on RHEL5. Unless someone is feeling 
ambitious, I wouldn't expect this anytime soon.
http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/10/stigscanresults-beforeaqueduct.html#ruleresult-idp28747760

For Certification Test Plan type docs, this table might help:
http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-stig-rhel6.html

While this one is for the STIG, per-profile tables are reasonable to create.

> 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?
Francisco Slavin of Tresys wrote RHEL6/transforms/xccdf-addfixes.xslt to 
merge things together. In short, for every XCCDF rule, the script checks 
to see if there is a bash script within the RHEL6/input/fixes/bash 
directory of the same name. If so, the script combines things together 
automagically during the Make process.


More information about the scap-security-guide mailing list