[Open-scap] Remediation Scripts

Shawn Wells shawn at redhat.com
Sat Apr 6 01:58:58 UTC 2013


On 4/5/13 6:08 AM, Simon Lukasik wrote:
> 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,


Thanks Simon! 6.4.4.5 "<xccdf:fixtext> and <xccdf:fix> Elements" was 
exactly what I needed.




More information about the Open-scap-list mailing list