Configuration testing vs Forensic testing
Shawn Wells
shawn at redhat.com
Fri Oct 31 14:47:37 UTC 2014
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).
More information about the scap-security-guide
mailing list