Jeff, Those answers make sense. I guess my final comments (at least inline) are below.
-Rob > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of Jeffrey Blank > Sent: Friday, February 15, 2013 4:11 PM > To: [email protected] > Subject: Re: Draft RHEL6 STIG Released! > > > > > > On 02/15/2013 11:21 AM, Robert Sanders wrote: > > Morning all, I've been looking over the draft stig and had some > > observations (some of which may be complete naïve) > > Not naive, merely unaware of some unusual constraints :) > > > - noticed that *many* of the STIG line items have the content > > duplicated almost exactly (different CCI number perhaps). > IPv4/IPv6 > > firewall items for example. Is there a requirement somewhere that > > each CCI number must match a discrete STIG? > > I believe this is a result of the new STIG process, which > involves ensuring (or otherwise documenting) that each item > from an SRG document (in this case the OS SRG), each of which > is keyed on a CCI, is addressed by a compliance Rule. > > I do not know if there will be improvement to the STIG > stylesheet or content generation mechanisms directly from FSO > (and of course that is the only official place to get a STIG). > > That said, it should not be hard to generate alternative > presentations that are semantically equivalent (viz. have no > duplicates) with a little XSLT. In fact, we should have some > tables in the output folder that have this or similar... > Not a huge problem, just gruntwork on making sure each applicable STIG get a checkbox to be checked.... > > - regarding the SSH settings - many of the settings for > > /etc/ssh/sshd_config are duplicated, but I see no corresponding > > settings for /etc/ssh/ssh_config (Protocol, ciphers, etc). > > These are client settings. I would argue that they are out > of scope for two reasons: > 1) It is perfectly reasonable for DoD users to connect to > non-DoD servers (and they should assume a lower level of > confidentiality/integrity when doing so). DoD SSH servers > will attain compliance through the Rules for sshd_config. > 2) Users can override client settings at any time anyway (-F option). > > Make sense also. I initially raised this question because the omission of the client settings was glaring compared to the RHEL5 STIG. > > - really noob one - if IPv6 is disable, can ip6tables > actually start? > > If not, then by disabling ipv6 you are always going to get > dinged by > > not having ip6tables active. > > Disabling iptables in the manner we have done (with the > option), should still permit ip6tables to start. What does > your testing say? > I haven't actually tried. Raised the question partially because of some frustration with the earlier RHEL5 STIG where the IPv6 kernel modules were disabled, but the manual *check* was referencing files in /proc. If IPv6 was disabled then those files were not being populated, yet the lack of those files was being equated to the files being present with the wrong settings. _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
