CRE is for identifying remediation related actions. Using CRE-IDs makes for
easy references when conveying or describing remediations.
Fixing systems could also leverage this information as the basis to building
remediation content in a preferred language or tool.
Value I see is in providing a common base upon which fix systems such as
Anaconda, Puppet and others could provide consistent remediation. While bash
meets the needs of providing automated scripted remediation for a localhost,
from an enterprise management standpoint we need the flexibility in
identifying remediation actions in identifiable way.
Users fear the term remediation used with STIGs, it is going to be a hard sell
to implement automated remediation in any manner. CRE is not the silver
bullet but it begins the process of accountability on what actions performed
on a system. Side topic: has there been any thought on remediation roll back
changes?
I am looking for ways in which to advance the state of automated remediation,
which the SSG project is at the cutting edge. Scripting is a start, but we
need to look at flexible ways to operate in diverse environments.
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn
Wells
Sent: Tuesday, June 04, 2013 2:22 PM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: [PATCH 0/4] Remediation Templates
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?