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
Explorer

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.

0 Karma
1 Solution

nkeuning
Communicator

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

View solution in original post

bwindham
Path Finder

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.

0 Karma

nkeuning
Communicator

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

rrustong
Explorer

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.

0 Karma

robdanl
Explorer

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

rrustong
Explorer

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?

0 Karma

nkeuning
Communicator

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.

0 Karma

rrustong
Explorer

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?

0 Karma

nkeuning
Communicator

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?

0 Karma

nkeuning
Communicator

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.

0 Karma

rrustong
Explorer

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?

0 Karma

nkeuning
Communicator

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.

0 Karma
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...