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.
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
