New report and guide in openscap 1.1.0

Martin Preisler mpreisle at redhat.com
Mon Sep 1 09:45:37 UTC 2014


----- Original Message -----
> From: "Greg Elin" <gregelin at gitmachines.com>
> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> Sent: Friday, August 29, 2014 11:18:53 PM
> Subject: Re: New report and guide in openscap 1.1.0
> 
> Martin,
> 
> Thank you for the work on cleaner, modern, interactive report.
> 
> The three feature improvements that are most valuable are:
>    1. Including the priority of a control in the summary listing b/c it
> saves a lot of time looking things up. I needed this.
>    2. The interactive filtering b/c it also saves a lot of time b/c it
> allows me to use the report in planning and to have a conversation. I
> needed this.
>    3. Modern look and pop-up details. Also saves me time b/c it keeps my
> place while I look deeper (less cumbersome). I will use this.

Thanks.

> 
> Least needed features:
>    1. I'm less sure if I currently need the collapsing groups feature. I've
> been playing with it. On the plus side, the grouping has utility and it's
> particularly nice to collapse things to less than a handful of summary
> groups. It is also a big nerd knob whose presence is felt in everything I
> do in the detail section. The filters provide me with optional controls;
> the collapsing sections I have to actively manage. Even fully expanded, I
> am cognitively managing the groups presence as I scan down and look at
> items. I have to coordinate the filters and the grouping
> collapse/expansion. It's a powerful feature, and I might like it at times,
> but I also might find it cumbersome and bothersome in the future, too. I'd
> almost rather try the report a while with just the filters and other
> improvements first. (Or maybe make it optional...)

I am against making things optional. We want one report with a simple
quality assurance matrix. We want one set of features and we want to keep
them working.

This is the first time I have heard somebody not liking the collapse/expand
feature and it was one of the features people asked for so I am keeping it
for now.

>   2. I keep wondering if the detail section should even be part of the
> report, or should be online by default. Does it make sense to include by
> default static information? I suppose running the report on a system on
> segregated network would be one reason -- but is that the most common
> scenario?  Why have the detail information in the same report vs a
> second-related report?

No, details will not be uploaded anywhere on the web. They are generated
locally, you can keep them local. Uploading them anywhere or even querying
things from the web leaks information about your infrastructure.

> Features I still want:
>   1. I still want an even higher level executive summary that begins to tie
> the details of the scan to actual system and organizational risk. I want a
> report that creates shared awareness between Dev, Ops, Sec, and Mission.

Mock-up please.

>   2. Diff'ing: Comparing result with previous report. If I am using the
> repot to lock down a system, I want to easily see what's changed since the
> previous scan.

People ask for this all the time. We plan to do it but it requires changes in
more areas than just the report. Stay tuned.

>   3. Inclusion of comments and waivers. If I am consciously ignoring a test
> that is in the profile, it would be helpful to see and share that in the
> report (and see the result therefore as 'passed*' or 'pass waiver".

Same as above. This is not as simple as it seems.

>   4. Time estimates and prioritization. How long will it take me to fix
> different items? Which ones have automated fixes?

If you can tell us where we can get these times, I am all for it. If you
really want this the first step is to propose a change to XCCDF and get
the metadata in there. Second step is to convince content authors that
they want to use the new metadata. In a few years we may have time estimates.

In the end I think this can't possibly be automated. We can pull a number
out of a hat and call it the time estimation but that wouldn't be honest.

-- 
Martin Preisler


More information about the scap-security-guide mailing list