On 3/1/16 8:48 AM, Mike Kuhnkey wrote:

Yes. Greatly! Red Hat responds to industry generated CCE's while DISA will eventually generate CCI's mapped to their current STIG release?

NIST gives vendors an assignment of CCEs to pair with configuration guidance. OpenSCAP/SSG serves as Red Hat's configuration community, so within SSG we assign CCEs to specific XCCDF rules.

In the past DISA has used CCIs, however those should be abstracted away from end-users. With RHEL7 STIG content, you'll likely need to attest to either the RHEL-07-##### control (from DISA), or more SCA's will want users will attest against the CCE (which maps back to NIST 800-53).

Both SRG & CCI references appear to be falling from grace as far as providing stability for shared rule references (multi-platform from a Red Hat perspective),and ...we can only guess for DISA. I have an unrelated question to XCCDF_POLICY engine which I'll put in another thread. Thank you for clarification!

In recent times the SRGs are meant to reflect DISA's control selections and refinements from NIST 800-53. DISA CCI's then come along and provide the "ability to trace security requirements from their origin to their low-level implementation" [0]... aka specific implementation guidance for a product. Sprinkled in are the RHEL-07-##### identifiers. And then we have CCEs that are assigned by NIST/vendors. What controls do you need to actually document compliance against during system accreditation? It's confusing as hell.

Within SSG, we map each XCCDF rule to a CCE. That CCE is then mapped to regulatory identifiers.

To make all this real, we can look at the RHEL6 "audit_rules_time_watch_localtime" rule: https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/6/input/xcc...

It contains this snippet of code: <ident cce="27172-6" stig="RHEL-06-000173" /> <oval id="audit_rules_time_watch_localtime" /> <ref nist="AC-3(10),AU-1(b),AU-2(a),AU-2(c),AU-2(d),AU-12(a),AU-12(c),IR-5" /> <ref disa="1487,169" />

so from that, we can see: - XCCDF rule "audit_rules_time_watch_localtime" is mapped to Red Hat CCE-27172-6 - CCE-27172-6 is further mapped against * NIST 800-53 AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5 * DISA CCI's 1487 and 169

When OpenSCAP verifies compliance with CCE-27172-6, we're able to generate reports that show conformance with the above DISA CCIs and document configuration against the NIST controls.

That mapping is how we generate the sample RTMs, such as the RHEL6 NIST table: http://people.redhat.com/swells/scap-security-guide/RHEL/6/output/table-rhel...

[0] http://iase.disa.mil/stigs/cci/Pages/index.aspx

Mike,

Actually just the opposite is occurring with SRG's and CCI's. NIST IR 8011 which is out in draft specifically discusses the same context of using "control items" for granularity. CCI's are decomposed 800-53 controls which are normally more targeted to being measurable. The same CCI may be met in various operating systems by different methods. They were not intended to be standard "rule" language. The document I was referencing can be reviewed at http://csrc.nist.gov/publications/drafts/nistir-8011/nistir_8011_ipd-draft_v...

DISA actually starts from the CCI's for requirements instead of doing a reverse mapping. This provides us a better picture in relation to risk or unmet requirements which are levied down from the federal government through NIST in the 800-53 controls and then into the DoD through the CNSS 1253 baselines. DoD systems must be authorized and accredited based off of those baselines in accordance with how they categorize their information systems in a similar process defined in the NIST 800-60.