On 10/31/14, 10:31 AM, Steve Grubb wrote: > Hello, > > I think there is a problem in the SSG content. I think that the current > content is intended to check the system configuration. This would be done by > examining the files on disk to warn about changes or thing that are > misconfigured. There is also another category of testing that is forensics > which checks the ephemeral / current values being enforced. Both are > necessary > and useful, but they should not be mixed. > > Some examples to illustrate the point: > > Forensic Configuration > ----------------------------------------------------------------- > auditctl -l vs cat /etc/audit/audit.rules > mount vs cat /etc/fstab > sysctl -a vs cat/etc/sysctl.conf > service ip6tables status vs chkconfig ip6tables --list > > All these need to be changed in the prose to better express what the SCAP > tool > is actually checking. IOW, you can get different results by hand than the > tool > itself would report.
Emphatically agree there needs to be better separation. Thanks for starting the discussion. The auditctl usage in OCIL vs the regex on audit.rules in OVAL is a perfect example of this (which was patched earlier this week btw). I've opened tickets to track mount vs fstab, sysctl, and service vs chkconfig: "persistent vs runtime in OVAL+OCIL for mount checks" https://github.com/OpenSCAP/scap-security-guide/issues/320 "persistent vs runtime in OVAL+OCIL for sysctl checks" https://github.com/OpenSCAP/scap-security-guide/issues/321 "persistent vs runtime in OVAL+OCIL for service/chkconfig" https://github.com/OpenSCAP/scap-security-guide/issues/322 As/if you identify additional sections which need better separation, please bring them to our attention! > This really needs to be addressed before anyone else uses SSG as the basis of > their own recommendations. Again, forensic checking is useful and I would say > content should be specifically designed with that in mind. But it is not what > should be in a baseline. That's a bit strong of language. SSG represents a catalog of controls, from which agencies make selections for formal baselines that we turn into profiles. Often (e.g. with the STIG) the agency wishes to include capabilities for static/persistent configuration (e.g. sysctl.conf) *and* ephemeral system state (sysctl -a). -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
