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: [] On Behalf Of Shawn Wells
Sent: Tuesday, June 04, 2013 2:22 PM
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 @

And then the spec @

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?