Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Nessus-Users
[Top] [All Lists]

Re: Reports: Problem.... solution....

Subject: Re: Reports: Problem.... solution....
Date: Tue, 06 Nov 2007 19:30:16 -0500
Hi Mike,

It's not a pipe dream, but it would be an optimization for your
environment. At Tenable, we always get feature requests for Nessus that
would work great for one environment, but perhaps not another one.

For example, many of our larger organizations that use Nessus have
strict software upgrade policies. It's never about upgrading to the
latest release for them, it is about fixing a vulnerability or ensuring
compatibility with their production applications.

We could also easily write every plugin to say "upgrade to the latest
version of product x.y.z" but this can be ambiguous as you then leave it
up to the adminstrator to determine what the latest release is. And in
the case of Firefox, we could also have said to just accept any and all
updates from the Mozilla organization.

The thing is, you end up putting Nessus in charge of what to patch and
making decisions about what software runs in your organization. You
don't get a chance to tell someone that Firefox isn't the corporate
standard and they need to switch to Safari or IE.

I've blogged about this sort of issue before here:
http://blog.tenablesecurity.com/2006/10/knowing_when_to.html

The type of report you are asking for does exist in vulnerability
management tools like our Security Center and other enterprise security
management products, but not typically in the vulnerability scanners
themselves.

Ron Gula
Tenable Network Security


Mike.Vasquez@cityofmesa.org wrote:
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

<Prev in Thread] Current Thread [Next in Thread>