topic Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system? in All Apps and Add-ons

In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

rrustong — Tue, 09 Oct 2018 19:09:29 GMT

Unless I'm missing something, it appears that the add-on only collects scan results if the vulnerability has not been previously discovered on a system. An event is created in Splunk when a vulnerability is first discovered on a system, but no event is created on subsequent scans that continue to detect that vulnerability.

In order to determine if a vulnerability exists on a system, I believe I have to run an all-time search looking for the existence of the vulnerability and then excluding it if I find a later result where hasBeenMitigated is set to true. Is this correct? Or is there an easier way to determine if a vulnerability still exists on a system?

One use-case for this is to be able to compare vulnerabilities to details from our AV software. For example: If we learn about a new vulnerability that exists in the wild and our AV software has released an update to cover the exploit, we need to be able to search for systems that are vulnerable to the exploit according to Tenable and have not yet received the update to the AV software.

Is there a good way to accomplish this without needing to do an all-time search for the earliest instance of a vulnerability being discovered on a system?

In the Splunk-built version of the add-on, it appears to import all scan results regardless of whether it has been previously discovered or not. However, it does not include any adaptive responses, so I'd rather use the version built by Tenable.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

nkeuning — Tue, 29 Sep 2020 21:35:03 GMT

Hi rrustong,

You are correct, we store only one event for each open vulnerability. This event is created/stored based on the firstSeen/first_seen date field. Your logic is correct, the only thing i might suggest is some de-duping and leveraging the state field. Here is an example i would use for SecurityCenter data:
get_tenable_index\ sourcetype="tenable:sc:vuln" | dedup ip, repository.id, pluginID, port, protocol | search state=open OR state=reopened

basically this gets the correct index, limits data to SC vulnerabilities, dedupes data so we only get the most recent vuln events for every host and then limits the results to only open or reopened vulns so we dont show fixed vulns.

Sincerely,

Nick

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

rrustong — Wed, 10 Oct 2018 18:56:47 GMT

Thanks for the info. Unfortunately this means that vulnerability status is dependent on our retention settings of the index. I'm not a security guy so I don't know the likelihood of this happening, but if a vulnerability were to be first discovered on a system 4 months ago and we have a 3 month data retention, we would no longer show that system as being affected by that vulnerability.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

nkeuning — Wed, 10 Oct 2018 19:01:21 GMT

That is correct, we need the retention policy to be very long on our index. This will stay a requirement moving forward as it is the only way to bring the size of our data in splunk down to a manageable level and report the state of vulnerabilities. This will improve some in our next major release as we improve usability of our data.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

rrustong — Wed, 10 Oct 2018 19:27:48 GMT

Can you give me any hints on how it will be improved? I'm trying to determine if I should stick with this version or go with the Splunk-built version. I'm sure you can't give dates, but any idea how far out the new version is? weeks? months? a year?

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

nkeuning — Wed, 10 Oct 2018 19:47:38 GMT

The theme of the next release is simpler searching of the data structures and improved tracking of state information and assets. No timeline yet as we are still in planning phases.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

rrustong — Wed, 10 Oct 2018 23:41:33 GMT

Another question for you, what causes the state to change? In looking at my events, I only have open as a value for state. Our Nessus install is relatively new, so I'm not sure if we would have anything with any other state. Prior to your answer, I was looking at the hasBeenMitigated field where I do have both true and false values. What's the difference between these fields?

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

nkeuning — Thu, 11 Oct 2018 00:17:07 GMT

The state changes when 1) an open vulnerability is fixed (mitigated) OR 2) a previously fixed vulnerability is found again on the same machine. The possible states are open, reopened and fixed.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

rrustong — Thu, 11 Oct 2018 15:53:40 GMT

Thanks for confirming what I suspected. However, the reason I asked is because that doesn't seem to line up with my results. When looking at my tenable:sc:vuln events, 100% of them show state=open, with a small percentage of them where hasBeenMitigated=true. What would cause them to be true for hasBeenMitigated but remain in an open state?

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

nkeuning — Thu, 11 Oct 2018 17:09:32 GMT

I'm checking with the dev team. It looks like there may be a logic issue. If we pull data from the cumulative view we get what are otherwise active vulns. These fall into open or reopened. open should be when hasBeenMitigated == false/0 and reopened should be when hasBeenMitigated == true/1. Thanks for double clicking into this. Can you please open a support case with Tenable so we can track this appropriately?

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

bwindham — Mon, 25 Mar 2019 16:31:47 GMT

I am pulling Tenable.io data into Splunk at this time. I am noticing the "New" and "Resurfaced" tags on the vulnerabilities. I am also noticing that those are the only ones that are input into Splunk. I did see a prior Splunk Answers question at https://answers.splunk.com/answers/691887/in-the-tenable-add-on-for-splunk-what-is-the-best.html.

So, it appears that this is the way it works. That you must look at data for "All Time" and dedup based on ip, plugin id, etc.
What happens if you delete the History in Tenable? Will it start fresh and all vulnerabilities will be seen as new? Or, does it still have some historical relevance that it is looking at? I wish to have all vulnerabilities at the time of the scan sent over to Splunk.

Re: In the Tenable Add-On for Splunk, what is the best way to determine if a vulnerability still exists on a host system?

robdanl — Wed, 15 Apr 2020 20:09:24 GMT

I would make an addition to the example as it is deduping but you may end up removing a version that isn't the latest state.

`get_tenable_index` sourcetype="tenable:sc:vuln" | dedup ip, repository.id, pluginID, port, protocol sortby - lastSeen | search state=open OR state=reopened