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/unitte...
Have a great (hacking) weekend,
Thanks Simon! 6.4.4.5 "<xccdf:fixtext> and <xccdf:fix> Elements" was
exactly what I needed.