[PATCH 0/4] Remediation Templates

Nunez, Luis K lnunez at mitre.org
Tue Jun 4 21:11:41 UTC 2013


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 at lists.fedorahosted.org 
[mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Shawn 
Wells
Sent: Tuesday, June 04, 2013 2:22 PM
To: scap-security-guide at 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130604/00e8ece6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7057 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130604/00e8ece6/attachment-0001.p7s>


More information about the scap-security-guide mailing list