I would always highlight with a bright green that all rules pass and not use any coloring for a failing system. Getting everything green is an achievement. Anything else is just typical rather than failing.
So. For 100% passing (pseudo code): <green> Target device "my-server" is passing 223 of 223 rules defined in profile "usgcb-rhel6-server"! </green> And for less than 100% passing (pseudo code): <light gray background> Target device "my-server" is passing 166 of 223 rules defined in profile "usgcb-rhel6-server"! Results show "my-server" failing <green>0 high severity rules</green>, 16 medium severity rules, and 31 low severity rules of the profile. Also, there were 10 rules indicating a known checking engine "error" or an "unknown" problem. </light gray background> Other thoughts: - It would be nice if the text block was easy to copy and paste to share with someone. Which also makes me wonder if unique report ID can be generated somehow to link back to this report. Greg On Tue, Sep 2, 2014 at 1:54 PM, Shawn Wells <sh...@redhat.com> wrote: > On 9/2/14, 11:43 AM, Martin Preisler wrote: > > ----- Original Message ----- > > > From: "Steve Grubb" <sgr...@redhat.com> <sgr...@redhat.com>> To: > scap-security-guide@lists.fedorahosted.org> Cc: "Martin Preisler" > <mprei...@redhat.com> <mprei...@redhat.com>> Sent: Tuesday, September 2, 2014 > 5:33:05 PM> Subject: Re: Best ways to say this system is not compliant> > On > Tuesday, September 02, 2014 08:48:17 AM Martin Preisler wrote: > > > > > Several participants in the thread "Re: New report and guide in > openscap> > > 1.1.0"> > > raised concerned over a language "The system is not > compliant!" in the> > > report. > > > > > > I decided to avoid using the word compliant at all in this case.> > > XCCDF spec defines what it means on the report but people may think> > the > word has a different meaning and may be shocked.> > > > So instead I decided > to explicitly say how many rules failed or were> > inconclusive.> > > > For > example:> > "The target system did not satisfy conditions of 131 rules! > Furthermore,> > the results of 2 rules were inconclusive. Please review rule > results> > and consider applying remediation." > > > > Inconclusive is a word that I would not use. It prejudices the results > by> indicating that something may or may not be wrong and it can't really > tell. > > That is exactly the case. It's not prejudice, it's fact. > > > > That's not the message I want from any tool. Imagine running badblocks, > aide,> or find and the message output is that it's inconclusive. :-)> > I'd > simply say something to the effect that the scan has findings that need> to> > be reviewed. Short & simple. > > The report says "inconclusive" for rules 'error' or 'unknown' as cdf:result. > > Excerpt from XCCDF 1.2 spec: > > error - The checking engine could not complete the evaluation, therefore the > status of the target's compliance with the rule is not certain. This could > happen, for example, if a testing tool was run with insufficient privileges > and could not gather all of the necessary information. > > unknown - The testing tool encountered some problem and the result is unknown. > For example, a result of 'unknown' might be given if the testing tool was > unable to interpret the output of the checking engine (the output has no > meaning to the testing tool). > > I am not a native speaker but I am pretty sure inconclusive is the right > word for this. If not, please provide an alternative. > > > Would it be possible to add a tooltip/hover so that when people mouse over > the "Rule Overview" check boxes they would see these definitions? > > Many find the differences between notchecked, notselected, and > notapplicable confusing... and really, to someone who hasn't read the xccdf > spec, that's entirely understandable. > > > > -- > SCAP Security Guide mailing list > scap-security-guide@lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ >
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
