Splunk Enterprise Security

Tenable not importing vuln or asset information

Wallace44
Explorer

We have installed Tenable Add-on For Splunk, and configured it to connect to cloud.tenable.com with an API key.

Our Splunk Enterprise is V 7.3.3 and Tenable Add-on is 3.1.0.

The connection establishes correctly, however doesn't appear to be downloading all the required information from Tenable.
We get only tenable:io:plugin information ingested into our Splunk Index.

I expect to also see tenable:io:vuln and tenable:io:assets, however it seems that the process for these two other pieces of information just doesn't occur. The only 'customisation' we've done is that we don't use the default index, we use a dedicated tenable index. We have updated the get_tenable_index macro to look for this new index.

Increasing the logs to DEBUG and running another fetch, shows the system is connecting and reports it's exporting the vuln list, however still no information ingested into Splunk. Log output from the last run::

2020-02-05 16:15:14,312 DEBUG pid=3980 tid=MainThread file=cli_common.py:cacheConfFile:345 | Preloading from 'C:\Program Files\Splunk\var\run\splunk\merged\server.conf'.
2020-02-05 16:15:14,315 DEBUG pid=3980 tid=MainThread file=cli_common.py:cacheConfFile:345 | Preloading from 'C:\Program Files\Splunk\var\run\splunk\merged\web.conf'.
2020-02-05 16:15:14,573 DEBUG pid=3980 tid=MainThread file=__init__.py:simpleRequest:480 | simpleRequest > GET https://127.0.0.1:8089/services/kvstore/status?output_mode=json [] sessionSource=direct timeout=30
2020-02-05 16:15:14,625 DEBUG pid=3980 tid=MainThread file=__init__.py:simpleRequest:511 | simpleRequest < server responded status=200 responseTime=0.0500s
2020-02-05 16:15:14,631 INFO pid=3980 tid=MainThread file=base_modinput.py:log_info:295 | Tenable.io data collection started for input: Tenable_Cloud_IO_Input
2020-02-05 16:15:14,631 INFO pid=3980 tid=MainThread file=base_modinput.py:log_info:295 | Tenable.io vulns:last_found data collection started
2020-02-05 16:15:14,631 DEBUG pid=3980 tid=MainThread file=base_modinput.py:log_debug:288 | Check point name is Tenable_Cloud_IO_Input_vulns_last_found
2020-02-05 16:15:14,631 INFO pid=3980 tid=MainThread file=splunk_rest_client.py:_request_handler:100 | Use HTTP connection pooling
2020-02-05 16:15:14,631 DEBUG pid=3980 tid=MainThread file=binding.py:get:678 | GET request to https://127.0.0.1:8089/servicesNS/nobody/TA-tenable/storage/collections/config/TA_tenable_checkpointer (body: {})
2020-02-05 16:15:14,632 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_new_conn:959 | Starting new HTTPS connection (1): 127.0.0.1:8089
2020-02-05 16:15:14,638 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://127.0.0.1:8089 "GET /servicesNS/nobody/TA-tenable/storage/collections/config/TA_tenable_checkpointer HTTP/1.1" 200 5326
2020-02-05 16:15:14,640 DEBUG pid=3980 tid=MainThread file=binding.py:new_f:73 | Operation took 0:00:00.008000
2020-02-05 16:15:14,640 DEBUG pid=3980 tid=MainThread file=binding.py:get:678 | GET request to https://127.0.0.1:8089/servicesNS/nobody/TA-tenable/storage/collections/config/ (body: {'offset': 0, 'count': -1, 'search': 'TA_tenable_checkpointer'})
2020-02-05 16:15:14,642 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://127.0.0.1:8089 "GET /servicesNS/nobody/TA-tenable/storage/collections/config/?offset=0&count=-1&search=TA_tenable_checkpointer HTTP/1.1" 200 4514
2020-02-05 16:15:14,642 DEBUG pid=3980 tid=MainThread file=binding.py:new_f:73 | Operation took 0:00:00.003000
2020-02-05 16:15:14,644 DEBUG pid=3980 tid=MainThread file=binding.py:get:678 | GET request to https://127.0.0.1:8089/servicesNS/nobody/TA-tenable/storage/collections/data/TA_tenable_checkpointer/Tenable_Cloud_IO_Input_vulns_last_found (body: {})
2020-02-05 16:15:14,648 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://127.0.0.1:8089 "GET /servicesNS/nobody/TA-tenable/storage/collections/data/TA_tenable_checkpointer/Tenable_Cloud_IO_Input_vulns_last_found HTTP/1.1" 404 140
2020-02-05 16:15:14,648 DEBUG pid=3980 tid=MainThread file=base_modinput.py:log_debug:288 | Check point state returned is None
2020-02-05 16:15:14,648 DEBUG pid=3980 tid=MainThread file=base.py:_request:446 | {"params": {}, "method": "POST", "url": "https://cloud.tenable.com/vulns/export", "body": {"filters": {"severity": ["medium", "high", "critical"], "state": ["open", "reopened"]}, "num_assets": "500"}}
2020-02-05 16:15:14,648 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_new_conn:959 | Starting new HTTPS connection (1): cloud.tenable.com:443
2020-02-05 16:15:15,078 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://cloud.tenable.com:443 "POST /vulns/export HTTP/1.1" 200 None
2020-02-05 16:15:15,078 DEBUG pid=3980 tid=MainThread file=base.py:_request:476 | Request-UUID fbf3312ac715e21af4e3daf2c34d5aa6 for https://cloud.tenable.com/vulns/export
2020-02-05 16:15:15,079 DEBUG pid=3980 tid=MainThread file=exports.py:vulns:253 | Initiated vuln export ccbfe170-558e-44cd-bac2-c5d3319b3ebd
2020-02-05 16:15:15,079 DEBUG pid=3980 tid=MainThread file=base.py:_request:446 | {"params": {}, "method": "GET", "url": "https://cloud.tenable.com/vulns/export/ccbfe170-558e-44cd-bac2-c5d3319b3ebd/status", "body": {}}
2020-02-05 16:15:15,292 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://cloud.tenable.com:443 "GET /vulns/export/ccbfe170-558e-44cd-bac2-c5d3319b3ebd/status HTTP/1.1" 200 None
2020-02-05 16:15:15,293 DEBUG pid=3980 tid=MainThread file=base.py:_request:476 | Request-UUID 8b65774a8afef55e32a0ff615776445c for https://cloud.tenable.com/vulns/export/ccbfe170-558e-44cd-bac2-c5d3319b3ebd/status
2020-02-05 16:15:15,295 INFO pid=3980 tid=MainThread file=base_modinput.py:log_info:295 | Tenable.io vulns:last_found data collection completed
2020-02-05 16:15:15,295 INFO pid=3980 tid=MainThread file=base_modinput.py:log_info:295 | Tenable.io vulns:last_fixed data collection started
2020-02-05 16:15:15,295 DEBUG pid=3980 tid=MainThread file=base_modinput.py:log_debug:288 | Check point name is Tenable_Cloud_IO_Input_vulns_last_fixed
2020-02-05 16:15:15,295 DEBUG pid=3980 tid=MainThread file=binding.py:get:678 | GET request to https://127.0.0.1:8089/servicesNS/nobody/TA-tenable/storage/collections/data/TA_tenable_checkpointer/Tenable_Cloud_IO_Input_vulns_last_fixed (body: {})
2020-02-05 16:15:15,298 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://127.0.0.1:8089 "GET /servicesNS/nobody/TA-tenable/storage/collections/data/TA_tenable_checkpointer/Tenable_Cloud_IO_Input_vulns_last_fixed HTTP/1.1" 404 140
2020-02-05 16:15:15,298 DEBUG pid=3980 tid=MainThread file=base_modinput.py:log_debug:288 | Check point state returned is None
2020-02-05 16:15:15,298 DEBUG pid=3980 tid=MainThread file=base.py:_request:446 | {"params": {}, "method": "POST", "url": "https://cloud.tenable.com/vulns/export", "body": {"filters": {"severity": ["medium", "high", "critical"], "state": ["fixed"]}, "num_assets": "500"}}
2020-02-05 16:15:15,486 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://cloud.tenable.com:443 "POST /vulns/export HTTP/1.1" 200 None
2020-02-05 16:15:15,486 DEBUG pid=3980 tid=MainThread file=base.py:_request:476 | Request-UUID a4a54d52658adbc0c74d9c0540862412 for https://cloud.tenable.com/vulns/export
2020-02-05 16:15:15,486 DEBUG pid=3980 tid=MainThread file=exports.py:vulns:253 | Initiated vuln export 35621064-7604-4fa4-839c-4b823a203c95
2020-02-05 16:15:15,486 DEBUG pid=3980 tid=MainThread file=base.py:_request:446 | {"params": {}, "method": "GET", "url": "https://cloud.tenable.com/vulns/export/35621064-7604-4fa4-839c-4b823a203c95/status", "body": {}}
2020-02-05 16:15:15,691 DEBUG pid=3980 tid=MainThread file=connectionpool.py:_make_request:437 | https://cloud.tenable.com:443 "GET /vulns/export/35621064-7604-4fa4-839c-4b823a203c95/status HTTP/1.1" 200 None
2020-02-05 16:15:15,693 DEBUG pid=3980 tid=MainThread file=base.py:_request:476 | Request-UUID 419dbcc8daa5ec7bf4376eed37849703 for https://cloud.tenable.com/vulns/export/35621064-7604-4fa4-839c-4b823a203c95/status
2020-02-05 16:15:15,694 INFO pid=3980 tid=MainThread file=base_modinput.py:log_info:295 | Tenable.io vulns:last_fixed data collection completed

I've included only the vulns section as they all seem to report that same results (the plugin section is huge, and does actually import data correctly).

Any ideas?

0 Karma
1 Solution

Wallace44
Explorer

I managed to resolve this today. It turned out to be a permissions issue - though I'm not really sure why.

The API key for the account I was using was linked to an account with permission level 64 (From Tenable API doco) which is an Administrative account. Somehow that wasn't enough, and this same issue affected a number of other Administrator accounts as well.

In the end, I picked another account - I believe the one that originally set the account up and created an API key for that account. As soon as I switched, the logs showed the API downloading the vuln and asset chunks no problem.

Still not sure why the other accounts didn't have access, but after spending 2 days on this one task, I'm not going to investigate further and am just happy it's now working (I suspect it's to do with Access Groups created in Tenable).

View solution in original post

wkamil
Engager

I had the same issue and did some testing after reading @Wallace44's answer For some reason going to Access Groups and enabling "All Users" under the "All Assets" group allowed me to start pulling in Vuln and Asset events.

It doesn't make any sense though because the user was already added to that access group and should have been able to pull it.. I'm thinking this is a Tenable IO bug.

0 Karma

Wallace44
Explorer

I managed to resolve this today. It turned out to be a permissions issue - though I'm not really sure why.

The API key for the account I was using was linked to an account with permission level 64 (From Tenable API doco) which is an Administrative account. Somehow that wasn't enough, and this same issue affected a number of other Administrator accounts as well.

In the end, I picked another account - I believe the one that originally set the account up and created an API key for that account. As soon as I switched, the logs showed the API downloading the vuln and asset chunks no problem.

Still not sure why the other accounts didn't have access, but after spending 2 days on this one task, I'm not going to investigate further and am just happy it's now working (I suspect it's to do with Access Groups created in Tenable).

Get Updates on the Splunk Community!

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 ...

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...