On 04/11/2012 11:52 AM, Spencer R. Shimko wrote:
On 4/11/12 11:33 AM, "Jeffrey Blank"blank@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:
This will position us (and Mitre) to easily verify the correspondence/agreement between CCE description and XCCDF description.
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 ;)
I think the question is more one of how much does this really enhance the security. In some cases such as where permissions were changed from the default, they provided little to no real value and merely hampered things like rpm -V. If the security provided is significant I think we can all agree its worth the pain.
Thanks,
Kevin
Thanks, --Spencer
Thanks, Jeff _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide