Mike, Yeah, it'd be wonderful to have all the data and then do filtering on it for the reports. The new reporting format with Nessus3 has promise. But I think Tenable is focusing on other aspects of Nessus now over reporting. It's come up before on the list many times. There's nothing like a perfect solution now. I think ultimately each shop is going to have to do a lot of their own customization.
--------
Jeff Mercer - CISO - Security Vulnerability Assessments
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 07, 2007 10:54 AM
To: Mercer, Jeff C - Raleigh, NC
Cc: Nessus List; [EMAIL PROTECTED]
Subject: RE: Reports: Problem.... solution....
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" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/07/2007 06:58 AM
To
<[EMAIL PROTECTED]>, "Nessus List" <[email protected]>
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
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
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus
<<ATT135356.gif>>
_______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
