How, in general, does XCCDF_POLICY engine correlate multi-platform "shared" rule with platform specific remediation? Is this specific to oscap datastreams?
Yes. Greatly! Red Hat responds to industry generated CCE's while DISA will eventually generate CCI's mapped to their current STIG release? 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!
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
Severe "info headache"...think ice cream....but one more scoop: Who/What generates OVAL content? DISA? NIST? Contributors? Red Hat?
List of public OVAL producing orgs: https://oval.cisecurity.org/repository/registry
On Mar 2, 2016, at 9:40 AM, Mike Kuhnkey mike.kuhnkey@att.net wrote:
Severe "info headache"...think ice cream....but one more scoop: Who/What generates OVAL content? DISA? NIST? Contributors? Red Hat?
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/scap-security-guide@lists.fedorah... https://github.com/OpenSCAP/scap-security-guide/
DISA produces OVAL content to align with the STIGS. Some of the content may come from community repositories as a source. DISA maintained content can be found at http://iase.disa.mil/stigs/scap/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.
How does one reconcile (STIG) Cat-1, Cat-2, Cat-3 severity codes with, for example Profile nist-cl-il-al (available in rhel-6)? Does oscap Profile nist-cl-il-al qualify as a "collector" as discussed in the referenced nistir_8011_ipd-draft?
scap-security-guide@lists.fedorahosted.org
-
Blake Frantz -
Mackanick, Jason W CIV DISA RE (US) -
Mike Kuhnkey -
Shawn Wells