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