Hello,

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.

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".

Luke Kordell ________________________________________ From: scap-security-guide-bounces@lists.fedorahosted.org [scap-security-guide-bounces@lists.fedorahosted.org] on behalf of Shawn Wells [shawn@redhat.com] Sent: Thursday, October 31, 2013 11:52 AM To: scap-security-guide@lists.fedorahosted.org Subject: EXTERNAL: Re: SECSCN and all_rules profile

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

The CS2 profile has 318:

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

And the total available rules:

[shawn@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@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

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@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/stigscanresul...

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

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. _______________________________________________ scap-security-guide mailing list scap-security-guide@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-rhel6... 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@redhat.com 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-stig-...

Or this one for NIST: http://people.redhat.com/swells/scap-security-guide/RHEL6/output/table-rhel6...

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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On 11/12/13, 12:18 AM, Jeffrey Blank wrote:

Relatedly, there is a security controls catalog which is an ISO standard, so I'd be curious to know if there is any interest in linking the SSG content to it: http://en.wikipedia.org/wiki/ISO/IEC_27002

The U.S. gov certifies against requirements derived from NIST 800-53 (e.g. the STIG and CS2 baselines). Is IEC 27002 even relevant to the government?

To even view a copy of the standard one must purchase a copy: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csn...

On 11/12/13, 4:49 PM, Kordell, Luke T wrote:

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.

How'd the comparison go? Many parties would love to read your comments!

On 11/11/13, 11:02 PM, Jeffrey Blank wrote:

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-rhel6... 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.

From a policy perspective you're correct, NIST 800-53 is just a catalog of controls. For those of us fielding systems, NIST 800-53 has evolved into /requirements./

Our information systems are categorized against some CIA level. Depending on the level we're told what NIST 800-53 controls we must follow and given refine values (e.g. password lengths, audit retention, etc), generally in some master control spreadsheet. For example, on a project I'm currently working with, a snippet from our 486 rows of 800-53 requirements:

AC.7.a (U) Red Hat information systems shall enforce a limit of not more than 3 consecutive invalid login attempts by a user during a time period of not more than 15 minutes, regardless of whether the login attempt occurs via a local or network connection.[Source:NIST SP 800-53 AC-7, ICS 500-16)] AC.7.b (U) Red Hat information systems shall automatically lock an account/node for not less than 15 minutes when the maximum number of unsuccessful attempts is exceeded, regardless of whether the login attempt occurs via a local or network connection.[Source:NIST SP 800-53 AC-7, ICS 500-16]

(U) Red Hat information systems shall automatically lock the account/node until released by an administrator, after 3 consecutive invalid access attempts by a user, regardless of whether the login attempt occurs via a local or network connection.[Source:NIST SP 800-53 AC-7(1), ICS 500-16] AC.8.a (U) Red Hat information systems shall display a system use notification message or banner before granting access to the system that provides privacy and security notices consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance that states: a. (U)The user is accessing a U.S. Government information system; b. (U)System usage may be monitored, recorded, and is subject to audit; c. (U)Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and d. (U)Use of the system indicates consent to monitoring and recording. [Source:NIST SP 800-53 AC-8]

To demonstrate compliance with AC.8.a, I need to scan against and remediate for set_system_login_banner, enable_gdm_login_banner, set_system_login_banner.

For AC.7.a, I need deny_password_attempts and accounts_passwords_pam_fail_interval

For AC.7.b, deny_password_attempts_unlock_time

I'm not sure how there is really any room for interpretation that you called out above as the mappings seem cut and dry. Mapping directly against STIG identifiers works great for those who follow the STIG, however that's a small percentage of the broader community. Most need mappings directly against NIST 800-53.