On Monday, November 03, 2014 09:15:52 PM Kachigian, Christopher R wrote:
Agreed that things need to be split out a bit more. We check both
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.
Thanks for your insight. But since I stirred the pot, I probably should
elaborate a bit more. Baselines really are about the configuration for next
boot. What I noticed was that the recommended *manual* checks were different
from what I know the SCAP scanner is looking at. Ideally, manual checks should
produce the exact same results as the automated tools. Chances are they
produce the same results, but in a particular case the format of a tool's
output changed causing people grief that is unfortunate.
That said, I think there is room for the creation of content specifically
looking for the fleeting / ephemeral values - just in case. The main issue is
that OVAL doesn't always support this. There is no OVAL equivalent to auditctl
-l, services iptables status, or sysctl -a.
I've mentioned before to the OVAL editorial board that if I could do it over
again, I'd want to be more careful about combining in-memory checks and on-
disk checks. An example of this might be the partition check which is an
amalgamation of both. I would prefer a pure on-disk and in-memory
separation...but its too late.
The only way that forensic scanning can be done is to avoid OVAL in the XCCDF
and just use a shell script/app or even better use the SCE interface.
Anyways, hope this clears up my thoughts. Its more a case of manual !=
automated tests in a few cases. By and large they do match.