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.
Thank you - Francisco Slavin
[1] Secstate tool -https://fedorahosted.org/secstate/
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jeffrey Blank Sent: Friday, March 16, 2012 12:28 PM To: scap-security-guide@lists.fedorahosted.org Subject: interoperation with remediation capabilities
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
Yes. It remains possible for us to add non-SCAP stuff (as shorthand/macros we invent, and then transform out of the "final" SCAP-only content), but this is really not preferable.
I would like our outputs to be either: 1) in SCAP formats (with intended usage of the elements), if machine-consumable 2) in human-readable formats
To me, this means that the <fix> tags should only contain simple bash commands. Hopefully linkage to things like Puppet modules can be achieved in a manner that is
To that end, it is my intention to (at M.1 perhaps) declare Rule IDs frozen, so that any external tools which process results can have confidence that the world won't be shifting underneath them. I've renamed the subject line to match this thread.
I also haven't read the CRE draft (Dec 2011) published by NIST/Mitre yet. It may not relate to our short-term efforts, but we may want to keep it in mind.
___________________________ Jeffrey Blank 410-854-8675 Global Mitigations NSA Information Assurance _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide