Re: interoperation with remediation capabilities

Hello, My name is Francisco Slavin. I am working with Spencer Shimko on the CLIP update work. He is primarily concerned with the SCAP content itself; I am working on updates to the Secstate tool [1] in order to consume this content. I wanted to chime in here regarding the way Secstate handles remediation content to help inform a the discussion of how best to approach the assessment-remediation link.

When we initially developed Secstate, the way we linked XCCDF to remediation content was largely a proof-of-concept to show how the tool can integrate the find-and-fix process of security hardening. We did use the system attribute of the<fix> element to specify that this was being done with Puppet content, thusly: <fix system="urn:xccdf:fix:script:puppet"> With that in mind, the idea was to eventually support content types other than puppet (i.e. link in legacy bash scripts, or hook in to the developing standard remediation language when that matures). We used puppet for our example content because we had a set of puppet content already developed in CLIP, so it was an easy tie-in. We used JSON in the<fix> tag for convenience, and turned that in to External Variable files for use with Puppet. By doing this we were able to run just the segments of Puppet content pertinent to a specific fix, using Puppet as a direct remediation tool instead of its designed purpose of general system management. With the current work to update Secstate (I will be posting an announcement to that list shortly as well), we would like to reconsider the way we approach the assessment-remediation link. The main goal of Secstate is to make it as easy as possible to automate the assessment and remediation of a system; with that in mind, we will support whatever approach the community settles on for this aspect of content authorship.