[PATCH 0/4] Remediation Templates
Shawn Wells
shawn at redhat.com
Tue Jun 4 18:21:33 UTC 2013
On 6/4/13 1:43 PM, Nunez, Luis K wrote:
>
> Another way to look at the remediation strategy is to have an
> independent source for building fix content. The source would provide
> basic information needed to change a system to a secure state. This
> information would reside alongside the check information in the XCCDF
> policy. Having a common source will help in achieving consistency in
> remedial actions performed by differing scripting languages or fix
> systems .
>
> This method could also be used as a way to check parity in the
> checking and fixing content for correctness.
>
> This is probably a good time to review Common Remediation Enumeration
> and see if fits into the project objective. CRE was created to
> identify and provide a reference point for actions necessary to
> correct a security issue. Based on the CRE-ID one could build
> remediation scripts and systems in a referenced way. The CRE-ID could
> also be used for traceability in troubleshooting and change control
> management.
>
Reviewed the examples @
http://scap.nist.gov/specifications/cre/1.0/cre_examples.xml
And then the spec @
http://scap.nist.gov/specifications/cre/1.0/cre_1.0-draft.xsd
Seems like this would be a major schema change, requiring updates to
every rule, but I don't particularly see the value. Maybe it's just me
being dense =/
Seems like an interesting approach to have XCCDF express "requirements,"
OVAL to check system state, <fix> tags for automated compliance, then
CRE for manual remediation. From what I gather, the CRE really is a
different way to express SSG's usage of OCIL tags. Can you help explain
what value would be gained by changing content to CRE?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130604/2e4cdb97/attachment.html>
More information about the scap-security-guide
mailing list