On 10/31/14, 10:31 AM, Steve Grubb wrote:
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:
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
"persistent vs runtime in OVAL+OCIL for mount checks"
"persistent vs runtime in OVAL+OCIL for sysctl checks"
"persistent vs runtime in OVAL+OCIL for service/chkconfig"
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
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).