Hello, 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 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.
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. Thanks, -Steve -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
