Thanks for the information George.
On the windows side: I almost always run NessusGUI.exe, not the Nessus
Client.exe. I didn't realize there were such differences in the report
option.
The Nessus Client.exe look sharper, in my opinion, however, I will
continue to use the NessusGUI generated reports, due to their flexibility.
I'm also not sure where, if I wanted to tweak them, Like I did with the
NessusGUI xsl templates, I could do so. Maybe there's more options than I
realize with the .nessus format.
I *really* like the ability to list reports by the level of severity, and
exclude information stuff only. It's much easier/quicker to parse and
hand out for remediation.
I also like having the host name right by the IP address. It makes for
quicker referencing for a lot of folks on our team. Those are the 2
primary reasons I'll stick with the XSL files I created -- but it seems
like a reasonable report option to add in on your side at some point.
I don't know what other folks do, but here's a quick overview of our
process. In their current state, I'm typically the only one who even sees
the reports...
1) Run the scan for say, 20 hosts
2) Using NessusGUI.exe and some custom XSL, create reports that show mid
to upper level issues only, that must be remediated for PCI
3) From report, create 2nd doc which contains the crucial info: for
instance:
a) if there are old versions of ApplicationXYZ, which is now 3
patches behind, nessus reports 3: I cut the older 2, and just list
remediation as getting it to latest patch level
b) include where possible paths to executables of concern
(sometimes cobbled from different plugin output)
c) create final doc listing the Nessus Synopsis (and a line of
description where the synopsis is particularly vague), + solution and
plugin output (where useful)
From there, we assign ownership for resolution and I track it all in a
spreadsheet.
Right now, I've adjusted my process to fit the tool, however, it'd be much
more efficient to have the tool fit the process. Of course, that's my
perspective. If my process/needs are unique and oddballish enough to be
fairly uncommon, then it makes sense to keep the tool as it is, too.
"George A. Theall" <theall@tenablesecurity.com>
Sent by: nessus-bounces@list.nessus.org
09/26/2007 07:25 PM
To
nessus@list.nessus.org
cc
Subject
Re: When does a plugin include a path?
On 09/26/07 19:56, Mike.Vasquez@cityofmesa.org wrote:
I'm reviewing reports, and have noted that (in particular with Flash and
Adobe reader plugins) there is inconsistency on when a file/version/path
is included in the plugin output. For remediation -- I *love* that
info. Clears up lots of questions.
Case in point: 2 plugins: adobe_reader_709.nasl, and
adobe_pdf_plugin_80.nasl -- the former: no file location output, the
latter includes it.
Is there a technical reason? Or just something that wasn't gotten
around to? On a "to do" list?
We've been making plugins more verbose for the past several months:
version info from banner checks, version / path info for local Windows
checks, contents of files and output of commands when exploiting
vulnerabilities, etc. As you note, it greatly helps in terms of
remediation.
In cases where the info is available via another plugin, though, we've
tended to not include it to avoid redundancy and minimize code
complexity. For example, adobe_reader_installed.nasl reports the
installation path and version info of Adobe Reader on Windows systems
whereas there isn't another plugin that does this for Adobe's PDF plugin.
That said, I'd welcome feedback from you or others about the current
report format.
George
--
theall@tenablesecurity.com
_______________________________________________
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
