Archive
Highlighted

Nessus exploitable vulnerabilities

Explorer

Here, am trying to find all vulnerabilities found during a nessus scan that are exploitable. The exploit_available field is shown only in nessus plugin. I would like to corelate the exploitable vulnerabilities with hosts in my network which are only shown in the nessus scan sourcetype. My search query works but once again, it takes a while to run. Any help fine tuning this is welcome.

sourcetype="nessus:scan" plugin_id="*" [search sourcetype="nessus:plugin" exploit_available="true" id="*"  | table plugin_name] | dedup plugin_id |table plugin_name, plugin_id, severity

Thanks

0 Karma
Highlighted

Re: Nessus exploitable vulnerabilities

SplunkTrust
SplunkTrust

Hi, keronedave!

Here's a couple of tips, then I put it together for you:

1) Add an index=XXX (if reasonable) to your search, it can help a lot to make Splunk not have to look everywhere for the data.
2) Try not using a subsearch and instead reforming it to stats with grouping.

Putting that together, let's try this:

index=XXX (sourcetype="nessus:scan" plugin_id="*") OR (sourcetype="nessus:plugin" exploit_available="true" id="*")  
| stats values(plugin_name) AS PluginName, values(severity) AS Severity BY plugin_id

You may need a little fiddling with that, but it should be much faster.

index=... If you need help finding your indexes where this data is, just run your original search and in the "interesting fields" flyout you'll see "index". Click that and you'll have your list. If it's more than one index, just combine them with or like this (index=A OR index=B) ...

Write back if this is succesfully fast enough, or if you need additional tweaking!

Happy Splunking!
-Rich

0 Karma
Highlighted

Re: Nessus exploitable vulnerabilities

SplunkTrust
SplunkTrust

On second thought, that might get you more than you want (because it'll get you ALL the things on the left side of the OR)

It might work better with this:

index=XXX (sourcetype="nessus:scan" plugin_id="*") OR (sourcetype="nessus:plugin" exploit_available="true" id="*")  
| stats values(plugin_name) AS PluginName, values(severity) AS Severity values(exploit_available) AS exploitable BY plugin_id
| search exploitable="true"

Either way, let us know how it goes!

0 Karma
Highlighted

Re: Nessus exploitable vulnerabilities

Explorer

Hi rich7177,
Thank you for the effort but while both your searches completes in under a minute which is an improvement on the current 78s it does not give accurate results. They both pull values from nessus:scan while ignoring the query after the OR looking for only exploitable vulnerabilities using nessus:plugins.

Search
Look for all exploitable vulnerabilities from nessus:plugin and use their ids to search nessus:scan to get their name and the hosts they affect. This is because I have noticed that not all the plugins listed by Tenable are actually vulnerabilities on my network.

0 Karma
Highlighted

Re: Nessus exploitable vulnerabilities

SplunkTrust
SplunkTrust

Sorry, I have SecurityCenter, which reports this information in a different format apparently. 🙂 Let's walk through what this is missing.

Exploitable vulnerabilities are those with exploit_available=true and a sourcetype="nessus:plugin", right?

For the other side of the equation you need the scans (sourcetype="nessus:scan") where there's been a pluginid defined ( `pluginid=*` )?

So they connect together on that pluginid - is this correct? Confirming this specifically, is it true that each pluginid from the sourcetype="nessus:plugin" sourcetype records has only ONE valid state of exploit_available? (That's how it is in my data but I don't have to fiddle with the two sourcetypes in it, so I don't know for sure with yours). The stats does a values of plugin name, severity and if it's exploitable by plugin ID.

What we should have at this point is a list, one row per plugin ID, with a single plugin name, single severity and a single "is exploitable" flag. Can you confirm that the first two lines (the base search and the stats) indeed returns this? My guess is I've got something honked up in the stats if that's not the case.

If it does, then I am not sure why the trailing | search exploitable=true makes it not just return those where it's exploitable. I can't test easily (or at least directly) with the two different sourcetypes in this case, but I've done other things like this. AND, in my single-sourcetype case (which matters nearly not at all once you've stats-grouped them together, the two following are equivalent:

index=netvuln pluginID=* 
    [search index=netvuln exploitAvailable=Yes 
    | table pluginID ] 
| dedup pluginID 
| table pluginName, pluginID, severity.description, exploitAvailable

And

index=netvuln pluginID=* 
| dedup pluginID 
| search exploitAvailable=Yes
| table pluginName, pluginID, severity.description, exploitAvailable

Though, surprisingly enough in my case (hundreds of thousands of events per day, all clumped into BIG piles separated by lots of time), the former is actually faster because it builds a small list of pluginID's where exploitable=Yes then uses that to filter the rest.

Which I guess means - maybe you are doing it as best as you can (or within a reasonably margin of tolerance).

Have you thought about building a report and accelerating it?

0 Karma