All Apps and Add-ons

Nessus exploitable vulnerabilities

keronedave
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

Richfez
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

Richfez
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

keronedave
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

Richfez
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 plugin_id defined ( plugin_id=* )?

So they connect together on that plugin_id - is this correct? Confirming this specifically, is it true that each plugin_id 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
Get Updates on the Splunk Community!

Take Your Breath Away with Splunk Risk-Based Alerting (RBA)

WATCH NOW!The Splunk Guide to Risk-Based Alerting is here to empower your SOC like never before. Join Haylee ...

SignalFlow: What? Why? How?

What is SignalFlow? Splunk Observability Cloud’s analytics engine, SignalFlow, opens up a world of in-depth ...

Federated Search for Amazon S3 | Key Use Cases to Streamline Compliance Workflows

Modern business operations are supported by data compliance. As regulations evolve, organizations must ...