On 4/11/12 11:33 AM, "Jeffrey Blank" <blank(a)eclipse.ncsc.mil> wrote:
Before we could be ACK'ed (for commit), it needs some changes,
primarily
relating to granularity as noted in
https://fedorahosted.org/scap-security-guide/wiki/newxccdf .
The overall goal is to include the relevant information from the RHEL 5
prose document, but translate it into XCCDF in a way that facilitates
its re-use by different parties (and straightforward automation).
There was also some discussion in
https://fedorahosted.org/pipermail/scap-security-guide/2012-April/000185.h
tml
suggesting one CCE per Rule (as the preferred
level of granularity).
There are some benefits to this:
1)
This will position us (and Mitre) to easily
verify the correspondence/agreement between CCE description and XCCDF
description.
2)
After a set of OVAL checks is run, an
admin (or a C&A person) may only see a list of pass/fail results. When
possible, we want to keep these precise to enable well-informed
decisions. This is also relevant to the eventual addition of <fix>
tags, which may attempt to tie a remediation action to a particular
check's result.
The software also could have changed since RHEL 5, and we should not
assume that there are no errors in the RHEL 5 document to begin with. I
noticed that there is a squid user as the owner (of presumably a
sub-task) of the squid service. In your testing, does the product now
do (out of the box) what the lower_privileges Rule suggests configuring
for RHEL 5 (for the most part)? If so, we can drop that. I'm also
generally a bit more reluctant now to suggest things like altering
system startup scripts; this affects our ability to verify their
integrity.
I'll let Michael respond to most points you make above. I'm just
concerned with the last point. You need to perform integrity checks on
tons of things that will definitely be modified as part of implementing
the req guidance. The hashes must be generated after any of those
modifications take place. The startup scripts themselves do some crazy
things we patch out for our solutions. Often these modifications go above
and beyond these reqs, such as label-based mounting or the devmapper
operations which requires raw block device access. Of course reducing
those modifications to things that provide serious benefit is desirable.
But I don't think "verify their integrity" should prevent someone from
enhancing the security of the solution. If a req is best addressed by
modifying an init script so be it. After all, they're just text files ;)
Thanks,
--Spencer
Thanks,
Jeff
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/scap-security-guide