Agreed that things need to be split out a bit more. We check both when
able because of various customer requirements. We filled in the gaps with
some home grown / COTS tools as part of our continuous monitoring program
to check for ³both states² again depending on requirements.
That said I do believe it also comes down to what is required by those
using / checking the tools / systems. I have had various DoD C&A teams
check only config files during the manual validation, some checked running
configurations, others checked a combination depending which STIG
checklist they had in front of them. There is very rarely any
consistency.
At other agencies like DHS where USGCB is required and their version of
³continuous monitoring² is coming via Continuous Diagnostics & Mitigation
(CDM) may force the need to accelerate splitting these apart as "both
states" will be relevant per their Configuration Management (CM)
requirement. Please keep in mind that in original CDM RFP its not
necessarily realtime. There was a 72 hour notification requirement
written into the original CDM CMaaS RFP as part of the Sample Order. That
was before Task Order 2a & 2B were released. That window may have changed
a bit.
Now that I went on a bit of a rant, it is applicable across the board
whether in DoD, IC, DHS, etc. I guess I was making the case for the
larger applicability of splitting it out.
Chris Kachigian
On 10/31/14, 10:47 AM, "Shawn Wells" <shawn(a)redhat.com> wrote:
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
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/