Configuration testing vs Forensic testing

Shawn Wells shawn at redhat.com
Fri Oct 31 15:27:57 UTC 2014


On 10/31/14, 10:55 AM, Steve Grubb wrote:
> On Friday, October 31, 2014 10:47:37 AM Shawn Wells wrote:
>> 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.
> <snip>
>
>> I've opened tickets to track mount vs fstab, sysctl, and service vs
>> chkconfig:
> Thanks!
>
>> As/if you identify additional sections which need better separation,
>> please bring them to our attention!
> Well, in a very brief look, the selinux label check in /dev is wrong, it 
> should be:
>
> find /dev -context *:device_t:* \( -type c -o -type b \)

https://github.com/OpenSCAP/scap-security-guide/pull/324

> I think the guide should get a thorough review.

So... do one :) A solid read through by someone like yourself would be
huge in identifying gaps. Patches would be great, or even an EMailed
punch list would work well to get things done. Totally realize that a
read through of the entire document would be cumbersome -- would you be
willing to review perhaps just the audit section?

>From time to time many do read the guide top-to-bottom, and I know Jeff
Blank has been working on a read-through for awhile in prep for the NSA
RHEL6 SNAC Guide (still waiting, Jeff.....)


>>> 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).
> In retrospect, I agree. I am concerned that people not with a strong Linux 
> background don't grok the difference or perhaps learn the wrong thing.

That's a shared concern. Many only engage with a single profile....
really the STIG since it's the most matured and widely used. As other
profiles mature (e.g. USGCB) we may be able to clearly show users
multiple options and perspectives. The C2S (representing a commercial
baseline) somewhat levels out from the STIG.



More information about the scap-security-guide mailing list