I do realize that option as well, but I personally like having the full
data, and being able to manage the output on the reporting end, as opposed
to tweaking the policy every time a new plugin comes out that supersedes a
prior one. If the data/correlation is built into the plugin/report
itself, it gives many more options to massaging the output than if you
just turn plugins off.
Just a personal preference. :-)
Thanks,
Mike
"Mercer, Jeff C - Raleigh, NC" <Jeff.C.Mercer@usps.gov>
Sent by: nessus-bounces@list.nessus.org
11/07/2007 06:58 AM
To
<Mike.Vasquez@cityofmesa.org>, "Nessus List" <nessus@list.nessus.org>
cc
Subject
RE: Reports: Problem.... solution....
Mike,
You're making it too hard. Just disable the plugins that check for older
versions of Firefox and leave only the one which checks for the most
recent relase.
That's how we do it in our environment. We use NessusWX for our client
but it doesn't matter what client you use as they all support making
custom plugin sets.
Works the same way for other 3rd party software checks for Quicktime,
Thunderbird, Adobe, etc...
--------
Jeff Mercer - CISO - Security Vulnerability Assessments
From: nessus-bounces@list.nessus.org
[mailto:nessus-bounces@list.nessus.org] On Behalf Of
Mike.Vasquez@cityofmesa.org
Sent: Tuesday, November 06, 2007 5:58 PM
To: Nessus List
Subject: Reports: Problem.... solution....
I've pondered this for a while, and it's an issue that bugs me, and this
is probably just a pipe-dream of a solution, but here goes:
Problem: I scan and generate reports all the time, and my key focus is
generating the cleanest, simplest reports to hand over to the folks that
administer the servers. So, let's say we have a box with Firefox 2.0.0.2,
and an older version of Java. My report ends up looking something like:
Issue 1: Upgrade to Firefox 2.0.0.3
Issue 2: Upgrade to Firefox 2.0.0.4
Issue 3: Upgrade to Firefox 2.0.0.5
Issue 4: Upgrade to Firefox 2.0.0.6
Issue 5: Upgrade to Firefox 2.0.0.7
Issue 6: Upgrade to Java 1.14_12
Issue 7: Upgrade to Java 1.15_8
You get the idea.
From one standpoint, I can see the value of knowing *just how* out of date
everything is, but on the otherhand, it does skew things a bit from a
remediation perspective. "Oh No, I've got 7 things to fix" is really "Oh.
I've got 2 things to update". All the remediator wants to know is
*what's the bottom line. What will *really* remediate this?
So, how can I view the *most current* issue for Firefox, and generate a
report, as long as the issue is of say, at least *Medium* level severity?
Solution: Add 2 pieces of information, a <Family> and <Version>.
We all know that certain software products are much more susceptible to
these types of issues. "Bubba's eShopping Compendium PHP Package" is a
non-issue. Firefox. Java. Quicktime. Flash. Acrobat. All of these
are much more susceptible to frequent updates, minor revision/security
fixes, and thus, longer reports.
Here's how I envision it: Firefox is family <13245> (random assigned
number I picked outta my head). Version increments by "x" whenever a new
issue/patch/update comes out -- newer version, higher number, so the above
looks like:
Issue 1: Upgrade to Firefox 2.0.0.3 <Family>13245</Family>
<Version>26</Version>
Issue 2: Upgrade to Firefox 2.0.0.4 <Family>13245</Family>
<Version>28</Version>
Issue 3: Upgrade to Firefox 2.0.0.5 <Family>13245</Family>
<Version>29</Version>
Issue 4: Upgrade to Firefox 2.0.0.6 <Family>13245</Family>
<Version>33</Version>
Issue 5: Upgrade to Firefox 2.0.0.7 <Family>13245</Family>
<Version>36</Version>
Risk (hole/warning) is already captured. So with this info, I could
easily pull the most recent version, at the severity level, that I wanted.
Talk about nice clean reports that the end Admins will appreciate.
Ya, I know it's a lot of work, but I've got to think I'm not the *only*
one who would like to see something like this. Consider that while many
products don't need the info (See Bubba), just hitting the big ones will
make a big difference.
Even if 1.5 of Firefox and 2.0 of Firefox are dubbed "different families"
-- it's still going to produce a much cleaner report than the current
model.
So ya, it's a big change, and would require updating a lot of nasl's as
well, I imagine, but would be worth it.
Thanks for considering,
Mike
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
