Create build system?

[shawndwells]

Creating a profile. such as FedRAMP or another agency (e.g. DHS 4300A) requires 5,000+ lines of XML.

Propose a shorthand build system be created. Something akin to how SCAP Security Guide decomposed XCCDF and OVAL rules into singular files that are merged together into specification-correct SCAP.

Currently to cumbersome to create profiles with existing workflow.

Does NIST envision authoritative content (e.g. profiles, like FedRAMP) to be created in this repo, or should an open source content project be created (aka fold this into the ComplianceAsCode efforts)?

[shawndwells]

For example:

SSG takes a OpenControl-inspired YAML format and transforms it into XCCDF:

https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/guide/system/selinux/selinux_state.rule

documentation_complete: true

prodtype: rhel7,fedora

title: 'Ensure SELinux State is Enforcing'

description: |-
    The SELinux state should be set to <tt><sub idref="var_selinux_state" /></tt> at
    system boot time.  In the file <tt>/etc/selinux/config</tt>, add or correct the
    following line to configure the system to boot into enforcing mode:
    <pre>SELINUX=<sub idref="var_selinux_state" /></pre>

rationale: |-
    Setting the SELinux state to enforcing ensures SELinux is able to confine
    potentially compromised processes to the security policy, which is designed to
    prevent them from causing damage to the system or further elevating their
    privileges.

severity: high

identifiers:
    cce@rhel7: 27334-2

references:
    cis: 1.6.1.2
    cui: 3.1.2,3.7.2
    disa: 2165,2696
    hipaa: 164.308(a)(1)(ii)(D),164.308(a)(3),164.308(a)(4),164.310(b),164.310(c),164.312(a),164.312(e)
    nist: AC-3,AC-3(3),AC-3(4),AC-4,AC-6,AU-9,SI-6(a)
    srg: SRG-OS-000445-GPOS-00199
    stigid@rhel7: "020210"

ocil_clause: 'SELINUX is not set to enforcing'

ocil: |-
    Check the file <tt>/etc/selinux/config</tt> and ensure the following line appears:
    <pre>SELINUX=<sub idref="var_selinux_state" /></pre>

Pairs that with an associated OVAL file:

https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/checks/oval/selinux_state.xml

<def-group>
  <definition class="compliance" id="selinux_state" version="1">
    <metadata>
      <title>SELinux Enforcing</title>
      <affected family="unix">
        <platform>multi_platform_rhel</platform>
      </affected>
      <description>The SELinux state should be enforcing the local policy.</description>
    </metadata>
    <criteria operator="AND">
      <criterion comment="enforce is disabled" test_ref="test_etc_selinux_config" />
    </criteria>
  </definition>

  <ind:textfilecontent54_test check="all" check_existence="all_exist"
  comment="/selinux/enforce is 1" id="test_etc_selinux_config" version="1">
    <ind:object object_ref="object_etc_selinux_config" />
    <ind:state state_ref="state_etc_selinux_config" />
  </ind:textfilecontent54_test>

  <ind:textfilecontent54_object id="object_etc_selinux_config" version="1">
    <ind:filepath>/etc/selinux/config</ind:filepath>
    <ind:pattern operation="pattern match">^[\s]*SELINUX[\s]*=[\s]*(.*)[\s]*$</ind:pattern>
    <ind:instance datatype="int">1</ind:instance>
  </ind:textfilecontent54_object>

  <ind:textfilecontent54_state id="state_etc_selinux_config" version="1">
    <ind:subexpression datatype="string" operation="equals" var_check="all" var_ref="var_selinux_state" />
  </ind:textfilecontent54_state>

  <external_variable comment="external variable for selinux state"
  datatype="string" id="var_selinux_state" version="1" />
</def-group>

And a build system combines the two together, including other rules, into a consolidated SCAP datastream. Using this process means nobody needed to edit the 100K+ lines of XML to create content.

Similar story with OSCAL. Need a way to integrate OSCAL, SCAP, and remediation languages like Ansible and Chef. Today that work is happening in another project already (ComplianceAsCode).

In slide ware, looks like this:

Today the "Auditor Documents" are OpenControl-based. Can easily update to OSCAL.

Should the content community (where profiles would be developed, along with formal vendor/product responses) be developed here in the OSCAL repo or somewhere else?

[david-waltermire]

@shawndwells The equivalent XML and JSON OSCAL catalog and profile formats are intended to be a publishing format for control catalogs and baselines. The SP 800-53 rev4 and FedRAMP content we are producing in OSCAL is intended to become authoritative machine representations. There is still work to do in cleaning up the data before we get there. We have been focusing on this quite a bit, but more work is still needed. NIST and FedRAMP need to work out where their authoritative OSCAL formatted documents will persist, and the OSCAL project also needs to work out how to support signing these documents for integrity and source authentication. This is work that still needs to be done.

As far as creating content, I agree that it might be cumbersome using the OSCAL XML and JSON formats. We would love to work with the community on developing content creation tools and pipelines that support easier content creation for OSCAL and SCAP. It would be great if you are willing to contribute such a generalized capability for OSCAL.

My hope for this repo is for it to be a place where generalized OSCAL schema, tooling, and other common resources can be developed. I think it is natural for other catalog and baseline efforts to create additional repos to support development of authoritative OSCAL content for subsets of the controls community and for products.

[trevor-vaughan]

The SIMP project also has this requirement (https://github.com/NationalSecurityAgency/SIMP). That said, markup languages are not Security Officer friendly so I think the focus needs to be on ease of manipulation via some web/GUI based entity instead of a mishmash of crossover languages.

Personally, the JSON format is straightforward enough for lightweight processing and addition and the XML format is good for heavyweight munging and processing.

JSON, XML, and YAML are simply not end-user friendly documentation languages. Conversely, reStructuredText, LaTeX, and Markdown are better but may be too loose for the general community (though we've gone a LONG way with RST tags and simple plugins). Ultimately though, the non-technical user needs to be able to work with this documentation and I think that's going to necessitate the generation of some sort of GUI framework that helps them along. Frankly, most of this is just "connect the dots" and "fill in the blanks" from a user point of view.

[anweiss]

Connecting similar issues ... usnistgov/OSCAL#102

[david-waltermire]

Also related to issue usnistgov/OSCAL#203.

[wendellpiez]

Noting that OSCAL content now lives in another repo as well: https://github.com/usnistgov/oscal-content.

[david-waltermire]

Since this issue was created, we have added YAML support for defining OSCAL profiles. The SP 800-53 rev5 LOW baseline in YAML is only 190 lines. The CI/CD in the oscal-content repo will auto generate XML and JSON representations. Furthermore, tooling like the Java-based oscal-cli is being developed to provide commodity tooling to support translation between XML, JSON, and YAML, and to support profile resolution.

Given all this work happening in other repos, I believe it is ok to close this issue.

[wendellpiez]

Closing because we can always reopen.

[shawndwells]

+1

This is several years old now. Time to move on :)

[aj-stein-nist]

Shawn is here? Can I ask questions about OpenControl? ;-)

[shawndwells]

Shawn is here? Can I ask questions about OpenControl? ;-)

Hah! I lurk :) OpenControl was a great first step back in the day!