[PATCH 0/4] Remediation Templates

Jeffrey Blank blank at eclipse.ncsc.mil
Sun Jun 2 17:42:10 UTC 2013


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<scap-security-guide at lists.fedorahosted.org>
> https://lists.fedorahosted.**org/mailman/listinfo/scap-**security-guide<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/20130602/4e3d3960/attachment.html>


More information about the scap-security-guide mailing list