Improved Support for Remediation in XCCDF

[djhaynes]

Challenge: Some vendors have leveraged the fix and fixtext constructs in XCCDF for remediation. However, these constructs are not well-defined in the XCCDF specification and could be improved to facilitate more widespread use.

Proposal: Update the XCCDF specification to improve documentation for the fix and fixtext constructs leveraging lessons learned from organizations that are using these constructs in their content and tools

[wmunyan]

Agreed. Could it be possible to define some "fix systems" that content authors could use to define the information contained in the fix element? For example, there is a common URI used to define that a check system is OVAL. Can a starting list be developed for something similar in fix elements (i.e. for Ansible, Chef, Puppet, PowerShell, bash, etc)?

[redhatrises]

Technically the XCCDF 1.2 spec already has some of these in place (Table 17 of the spec), should we expand the list to not be so explicit instead so that we are not having to always revisit and modify the list?

[wmunyan]

@redhatrises thanks for the reference in the spec! I'll refer to the spec of the system attribute on the check element which states:

The URI for a checking system. The URI SHALL be compliant with the appropriate checking system
specification (e.g., OVAL, OCIL). If the checking system uses XML namespaces, then the @system 
attribute for the system SHOULD be its namespace.

I think the existing URI specification is good, and can be left there. Should a snippet like the above be added to that table to allow for other "fix systems"?

Also, probably good to add powershell to the list of urn:xccdf:fix:script:_language_ options.

[DavidRies]

Should we also include the ability to reference external fixes, e.g.?:

• external scripts packaged in SCAP bundle or datastream
• fix ids for external tools
• patches that can be download/run from vendors

[DavidRies]

And, should be tailorable so organizations can assign their own approved fixes?

[redhatrises]

Should we also include the ability to reference external fixes, e.g.?:

* external scripts packaged in SCAP bundle or datastream

Why are "external" scripts being packaged in a SCAP bundle or datastream? Seems like they should be integrated into the bundle or datastream.

* fix ids for external tools

Hmmmmm..... isn't this what a rule id is for?

* patches that can be download/run from vendors

Feel like the capability already exists... unless you are thinking about adding a href like is done for an external OVAL feed?

And, should be tailorable so organizations can assign their own approved fixes?

Why not? But then comes the question of how this would look in a tailored file.

[DavidRies]

Here are some clarifications:

• External scripts: we might be agreeing--I'm not sure what distinction you're making between "packaged" and "integrated" in this context. I just meant that we should support including fix scripts that are not included within the . They could be included as independent files within an SCAP Bundle (SCE is often used this way) or in their own components within a Datastream and then referenced accordingly.

• Fix Ids: I am referring to IDs for fixes in external remediation tools. It seems a remediation for a rule should be able to reference a specific id in an external tool. For example, I might want the remediation for rule@id="FOO" to be a specific GPO or Chef Recipe and I should be able to refer to that using an id and/or URI of some sort.

[redhatrises]

Here are some clarifications:

* External scripts: we might be agreeing--I'm not sure what distinction you're making between "packaged" and "integrated" in this context. I just meant that we should support including fix scripts that are not included within the . They could be included as independent files within an SCAP Bundle (SCE is often used this way) or in their own components within a Datastream and then referenced accordingly.

* Fix Ids: I am referring to IDs for fixes in external remediation tools. It seems a remediation for a rule should be able to reference a specific id in an external tool. For example, I might want the remediation for rule@id="FOO" to be a specific GPO or Chef Recipe and I should be able to refer to that using an id and/or URI of some sort.

@DavidRies can you provide a code example of these? URI already exists, and technically, you can already call external scripts and such from the fix system. Code examples would be helpful to get an accurate picture.

[DavidRies]

I'm not sure how to provide a code sample for this. And... it sounds like you're saying these can already be accomplished with the current spec. I might not be appreciating what we already have.

I can try to explain differently.

External Scripts

Currently, Rules can reference checks that aren't included inline within the rule using the <xccdf:check-content-ref>' element, e.g.:. This allows checks to be re-used by multiple Rules. And, it allows the checks to exist outside of the'. It seems to me that this would be useful for remediations as well.... unless this capability already exists?

Fix Ids

I don't have a good example. I haven't had to do this myself. Vendors and organizations that use XCCDF for assessment have told me that they create their own mappings between Rule Ids and specific remediations that they have implemented in other technologies (e.g. Powershell, Ansible, Puppet, Chef, Tanium, etc.). The current <xccdf:fix> tag has an @system that can be used to specify the engine, language, etc. that should be used to process the tag contents, but it's not clear to me how this could be used to reference a specific external remediation. For example, if I wanted to specify that a Rule could be remediated using a specific Chef run list (e.g. 'recipe[COOKBOOK::RECIPE]'), how would I do that using the current spec?

[djhaynes]

We need to put together some examples of what we are trying to accomplish (problem statement, use cases, code example, etc.). This is a combination of updating existing documentation (e.g., add new languages, etc.), but, also make it so we don't always have to update the specification to keep it up-to-date.

ACTION: Bernd will provide some examples and use cases for this.

[redhatrises]

I'm not sure how to provide a code sample for this. And... it sounds like you're saying these can already be accomplished with the current spec. I might not be appreciating what we already have.

I can try to explain differently.

External Scripts

Currently, Rules can reference checks that aren't included inline within the rule using the <xccdf:check-content-ref>' element, e.g.: ``. This allows checks to be re-used by multiple Rules. And, it allows the checks to exist outside of the'. It seems to me that this would be useful for remediations as well.... unless this capability already exists?

<fix xmlns:xhtml="http://www.w3.org/1999/xhtml" id="sshd_use_approved_ciphers" system="urn:xccdf:fix:urls">
file:///myfile
</fix>

Or does the above not work?

Fix Ids

I don't have a good example. I haven't had to do this myself. Vendors and organizations that use XCCDF for assessment have told me that they create their own mappings between Rule Ids and specific remediations that they have implemented in other technologies (e.g. Powershell, Ansible, Puppet, Chef, Tanium, etc.). The current <xccdf:fix> tag has an @System that can be used to specify the engine, language, etc. that should be used to process the tag contents, but it's not clear to me how this could be used to reference a specific external remediation. For example, if I wanted to specify that a Rule could be remediated using a specific Chef run list (e.g. 'recipe[COOKBOOK::RECIPE]'), how would I do that using the current spec?

<fix xmlns:xhtml="http://www.w3.org/1999/xhtml" id="my_rule" system="urn:xccdf:fix:script:chef">
recipe[COOKBOOK::RECIPE]')
</fix>

The engine would handle the everything around the run_list e.g. knife node run_list add NODE_NAME would be handled by the engine. Alternatively,

<fix xmlns:xhtml="http://www.w3.org/1999/xhtml" id="my_rule" system="urn:xccdf:fix:script:chef_run_list">
{
  "example": {
    "attr": "val"
  },
  "run_list": [
    "recipe[example::default]",
    "recipe[example::sub]"
  ]
}
</fix>

could be your run list, and everything else surrounding the run_list is handled by the engine.

[wmunyan]

I think the fix element needs to be enhanced to a form analogous to the check element. Already existing in the fix element is the system attribute, and like the check element's attribute of the same name, it should be documented and function to identify the "language" of the fix content.

I have never used the child elements inside the fix element (sub and instance), so I cannot opine on their use in content other than CIS (where we dont use them).

I propose the addition of a choice between a fix-content or fix-content-ref elements (again analogous to their check counterparts).

The fix-content element holds the actual code of a fix, in the language or system specified by the fix element’s system attribute. (This is adapted documentation based on the check-content description in the XCCDF 1.2 schema) The body of this element may be any XML, but cannot contain any XCCDF elements. XCCDF tools do not process its content directly but instead pass the content directly to engines capable of executing the fix. I would also add that, potentially, this element can contain simply the remediation content, such as a chef recipe snippet or ansible playbook snippet. The example below utilizes a CDATA element, but if that's not needed/desired then the form can be changed:

<fix system="urn:xccdf:fix:ansible">
    <fix-content>
        <![CDATA[
            - name: "Ensure 'Windows Firewall: Domain: Firewall state' is set to 'On (recommended)'"
              win_regedit:
                    path: HKLM:\Software\Policies\Microsoft\WindowsFirewall\DomainProfile
                    name: "EnableFirewall"
                    data: "1"
                    type: dword
        ]]>
    </fix-content>
</fix>

The fix-content-ref would contain similar href and name attributes to identify the appropriate fix content in an external file/repository.

<fix system="urn:xccdf:fix:ansible">
    <fix-content-ref 
        href="My_Custom_Benchmark_v1.0.0-Ansible.yml" 
        name="Ensure 'Windows Firewall: Domain: Firewall state' is set to 'On (recommended)'"/>
</fix>

[redhatrises]

I would vote to make it simpler and less complicated. I don't think that we need to add the <fix-content> element as I am not sure that it makes sense or is needed, and for sure not the CDATA element as adding either would be a backwards incompatible change that would break stability for us and many linux distros/users downstream. What we have done which has worked well is something similar to the following:

<fix system="urn:xccdf:fix:ansible">
- name: "Ensure 'Windows Firewall: Domain: Firewall state' is set to 'On (recommended)'"
  win_regedit:
                    path: HKLM:\Software\Policies\Microsoft\WindowsFirewall\DomainProfile
                    name: "EnableFirewall"
                    data: '<sub idref="var_enable_windows_firewall"/>'
                    type: dword
</fix>

I do like the idea of adding the fix-content-ref element in. Alternatively, could also do the following:

<fix system="urn:xccdf:fix:ansible"  href="do_somthing.yml" name="My addition custom somthing" />

[djhaynes]

@wmunyan and @redhatrises, is this something that we would want to discuss at the workshop?

[redhatrises]

Don't see why we couldn't or shouldn't.

[wmunyan]

Notes from Workshop:

• Similar to issue on referencing/downloading compressed files, need ways to verify integrity/signature of any external content.
• Favor given to adding fix-content-ref, as then the @media-type attribute can be included as well.
• Mention made of a NIST-controlled "IANA" table for us to add fix system values for tooling and values for scripting languages
• Modifications to slide decks that tools SHOULD not execute the combined remediation, but should just generate the remediation content.

[bgro]

Something I meant to bring up during the workshop but then forgot: for better support of automated fixes (but it would probably also come in handy for non-OVAL-based check systems such as SCE) would be some standard mechnism for handling content that is shared between several fixes/checks. Redhat currently uses immutable values to do so, but that seems like a hack. Rather than that, a mechanism for storing shared content on collection/group level should be added to XCCDF, I think.

[wmunyan]

The most recent call suggested the addition of a fix-export element in order to allow XCCDF Values to pass to any external content referenced by fix-content-ref's

[canb227]

Following conversation on 4/16:

Expand list of scripting languages to modernize document. Don't change requirements. Can implement this either by simply expanding the existing list or by pointing to a new NIST dynamic name repository.