Jeff, Those answers make sense. I guess my final comments (at least inline) are below.
-Rob
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Jeffrey Blank Sent: Friday, February 15, 2013 4:11 PM To: scap-security-guide@lists.fedorahosted.org 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:
- 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide