[PATCH 0/4] Remediation Templates

Nunez, Luis K lnunez at mitre.org
Tue Jun 4 17:43:26 UTC 2013


 

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.  

 

-ln

 

From: scap-security-guide-bounces at lists.fedorahosted.org
[mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of
Jeffrey Blank
Sent: Sunday, June 02, 2013 1:42 PM
To: scap-security-guide at lists.fedorahosted.org
Subject: Re: [PATCH 0/4] Remediation Templates

 

It is not so simple.  

 

This is a strategy problem.  If there is only one contributor who is capable
of fixing OVAL problems, then there should be serious viability concerns
about the project.  The addition of remediation content, which would
logically depend on this checking content, would only compound the problem.
I am seeking evidence of community motivation and capability to address the
OVAL problems before we move on to any remediation efforts.  

 

There was significant irony in observations about how checking content (from
Aqueduct, for example) is better than the checking content actually used by
system auditors (who may be leveraging OVAL content issued by DISA), yet
there seems to be so much interest in producing remediation content.  DISA
is waiting on our OVAL content to be fully baked so that they can issue it.
How much testing of the OVAL content as described at
https://fedorahosted.org/scap-security-guide/wiki/usageguide has been
carried out?  Does it work?  Is it suitable to base remediation content on?

 

Another interesting note is that in fact tooling support from OpenSCAP for
remediation scripts was further ahead than I thought:

https://www.redhat.com/archives/open-scap-list/2013-June/msg00001.html

(I again tip my hat to Simon and Peter and the other OpenSCAP devs.)

 

This means that, from a tooling perspective, the ability to automatically
generate parameterized remediation scripts is already there (and my next
post should put us yet closer to being able to work remediation).  But
still: if the checks aren't any good, then nobody should trust the
remediation scripts generated.

 

 

 

 

On Sat, Jun 1, 2013 at 6:58 PM, Shawn Wells <shawn at redhat.com> wrote:

On 6/1/13 6:52 PM, Jeffrey Blank wrote:

Yes, but please hold off on remediation content until the OVAL validates per
the schematron, and there is a means of handling parameters/variables in fix
content.  If you don't eat your meat, you can't have any pudding.  But we
should be able to have both.

 

The value of working sequentially doesn't make sense for such such a
parallel development effort, with members of different skill levels
contributing.

For example: I've no idea how to fix the remaining OVAL issues, so you're
telling me and all other would-be contributors to completely stop helping
for awhile? What value does that add?


_______________________________________________
scap-security-guide mailing list
scap-security-guide at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20130604/f8920e89/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/f8920e89/attachment-0001.p7s>


More information about the scap-security-guide mailing list