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?
... View more
