On Tuesday, June 04, 2013 09:11:41 PM Nunez, Luis K wrote:
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.
But CRE is an emerging standard. Which means that there is no software support
for it in anything that I know of. It could change 5 more times in the next
year. I don't know if its a good idea to use an unfinished standard.
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.
One issue is that the tools on RHEL5/6 would be certifying to SCAP 1.2. Once
that is done, they likely will not be updated for fear of losing the
certification. Doing CRE work (assuming its ratified) would better fit with RHEL7
work where the tools could changed because SCAP 1.3 is not defined.
-Steve