[PATCH 0/4] Remediation Templates

Steve Grubb sgrubb at redhat.com
Tue Jun 4 21:36:15 UTC 2013


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
 


More information about the scap-security-guide mailing list