I agree with Trey. The details would be more useful if they contained more information about how something failed. I would expect that in a detail.  

I'd be OK with default report ONLY showing details for the severity=high items that I failed and all other details went either into a second report I could open if I wanted, or the generic detail descriptions were on the WEB rather than part of the report. 

The report could contain information about the system, but I'm not sure if there is a lot of value of all the (static) details being in the in report by default.

Greg Elin
http://govready.org - Making FISMA compliance easier for innovators

email: gregelin@gitmachines.com
phone: 917-304-3488

On Thu, Aug 28, 2014 at 3:28 PM, Trey Henefield <trey.henefield@ultra-ats.com> wrote:

I had provided a comment a while back that I never heard back on.

"I am not sure if it has been mentioned, but I personally would find it useful to include details on the results.

For instance, considering a check that ensures all libraries meet certain permissions, it would be useful to identify all entries that are non-compliant, if failed.

The SCC scanner does this, sort of. Well it lists every item verified, which in some cases can make it difficult to identify just the failed items (needle in the haystack).

In some cases, the simplicity of the result details in OpenSCAP reports are desirable (management audience). In other cases, the verbosity in the SCC reports are useful (engineer/technician audience).

It would be ideal if OpenSCAP could offer both.

More specifically, it would be ideal if an option could be specified when generating the report to dictate the verbosity of the report details. Or perhaps even a filter within the report that allows the verbosity to be toggled.

I would consider the following three verbosity levels most useful:

LOW - No details, just the overall outcome for each check (the current OpenSCAP report scheme).

MEDIUM - Includes all (and only) failed items for each check that fails.

HIGH - Includes all items verified (both pass and fail items) for every check."

Any thoughts on including this?

Best regards,

Trey Henefield, CISSP
Senior IAVA Engineer

Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA

Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450


-----Original Message-----
From: scap-security-guide-bounces@lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Martin Preisler
Sent: Thursday, August 28, 2014 12:49 PM
To: SCAP Security Guide
Subject: New report and guide in openscap 1.1.0


as you may know I have been working on a complete rewrite of HTML report and guide for the upcoming openscap 1.1.0 release. It's a feature that will touch almost every user of openscap. I would like to gather feedback from the scap-security-guide community so that we can make sure there aren't any blocker issues in the release. It is natural that there will be small issues that we will iron out in minor releases. Basically we would just like to make sure the new report and guide aren't missing anything crucial that would prevent adoption.

See https://mpreisle.fedorapeople.org/openscap/1.1.0_xslt/ for sample HTML report and guide from SSG for RHEL6.

Looking forward to feedback.

Martin Preisler
SCAP Security Guide mailing list

The information contained in this communication from
trey.henefield@ultra-ats.com sent at 2014-08-28 15:28:40 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

SCAP Security Guide mailing list