On 04/05/2013 06:00 AM, Shawn Wells wrote: > On 3/27/13 11:36 AM, Nunez, Luis K wrote: >> This is good a conversation worth informing others on. I am cross >> posting to the Open-SCAP-list and Remediation-dev mailing lists. >> >> I’ve noticed pockets of remediation discussions in the various >> email-lists and would like to align them to a forum where can work as >> a collective. >> I don’t want to stifle this effort or conversation but would like to >> move the discussion to the remediation-dev list. The remediation-dev >> list, is an open list for all to participate, was setup to inform and >> to foster capabilities to enable automated enterprise remediation. >> The list members constitute industry vendors and government >> constituents. It contains experience and knowledge from previous >> attempts at remediation capabilities. >> >> Some observations on the current discussion. The OpenSCAP remediation >> capability addresses part of the problem. The current discourse >> (OpenSCAP XCCDF remediation) is beginning to touch on various >> Remediation Architectural issues (Workflow, tasking, reporting, OVRL, >> etc…). As you know the subject of Remediation is broad with many >> perspectives and implications. Before we spiral out control, I’ve >> seen it happen many times before with this subject, lets break them >> down into manageable sets. >> >> For lack of better reference material on Remediation Architecture, I >> would like to propose the NIST IR 7670 as a frame of reference for >> topic of discussions. The NIST IR 7670 is by no means a standard, >> but it is something to reference form a work flow and use cases. >> Certainly the NIST IR 7670 is subject to revision to suit the needs of >> the community as it evolves and it invites any and all for critics to >> make it better. >> >> And so using the “Derived Requirements” from the IR 7670 I believe we >> can have meaningful discourse and solutions. The current discussions >> on “Remediation Scripting” seems to originate and is related to DR 5 >> – Remediation Policy specification. It would be great to leverage the >> existing capabilities in OpenSCAP as a way to prototype and exercise >> elements in the XCCDF specification for remedial needs. We could also >> use this effort to propose revisions in specifications and guidance as >> needed. The prototype working code and content will be the mechanism >> by which a rough consensus from the community is achieved. >> >> Going forward I would like to invite thoughts and ideas to further >> innovate remediation capabilities. > > > In regards to DR 5, a key challenge I see is passing XCCDF refine-value > pairings into remediation scripts. > > For example, in the SSG content we set a umask of 022 to meet FSO > standards: > <refine-value idref="var_umask_for_daemons" selector="022" \> > > How can I get the value of var_umask_for_daemons into remediation > content? To my (limited) knowledge of current standards such a method > doesn't exist, is it planned via NIST or the OpenSCAP guys? >
It is already possible with OpenSCAP. For more info please see NISTIR-7275r4 and search for the <sub> element. Here is an example of <sub> usage in the OpenSCAP unit tests: http://git.fedorahosted.org/cgit/openscap.git/tree/tests/API/XCCDF/unittests/test_remediation_subs_value_refine_value.xccdf.xml Have a great (hacking) weekend, -- Simon Lukasik Security Technologies _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
