Purpose
This guide explains how to connect Tenable to Logsign as a Response integration, so an analyst can look up policies, scans, scan results, vulnerabilities, reports and assets, and launch or delete scans, directly from a Logsign Incident. This is a query/action integration, not a log collection poller: it does not pull Tenable data into Logsign on a schedule. It only runs when an analyst calls one of its methods from Settings > Integrations > Responses.
Based on the API paths used by the integration (/policy, /scan, /scanResult, /analysis, /report, /asset) and the x-apikey: accesskey=...; secretkey=... authentication header it sends, this integration targets Tenable Security Center (formerly SecurityCenter, also referred to as Tenable.sc), Tenable's on-premises vulnerability management console. It does not target Tenable.io / Tenable Vulnerability Management, Tenable's cloud product, which uses a completely different API (different endpoint paths, different resource model, and cloud rate limiting). If your organization only uses Tenable's cloud service and does not run a Security Center appliance, this integration will not work against it.
Because Tenable Security Center is a customer-hosted appliance, there is no shared cloud region or Tenable-hosted endpoint to pick. The Host you configure in Step 2 is always your own organization's Security Center server address. Logsign also ships a separate, unrelated Tenable Security Center Integration via API poller document that covers scheduled vulnerability log collection into Logsign USO; this guide covers the manual/analyst-triggered Response integration only, not that poller.
Prerequisites
You need network reachability from your Logsign instance to the Security Center appliance's HTTPS management interface. You also need a Security Center user account dedicated to this integration; Step 1 covers how to scope that account rather than reusing a personal administrator login.
An administrator must enable API key authentication on the Security Center appliance before any user can authenticate with an API key. This is a one-time, appliance-wide setting under System > Configuration > Security > Authentication Settings > Allow API Keys. If this toggle is off, every request this integration sends will be rejected, regardless of whether the access key and secret key themselves are valid.
The exact minimum Logsign version that ships this integration was not confirmed for this guide. Recent Logsign release notes (versions 6.4.88 and 6.4.90) mention "Tenable response integration has been updated," so treat any reasonably current Logsign 6.4.x build as a safe baseline, and confirm with Logsign support if Tenable does not appear under Settings > Integrations > Responses on an older build.
Step 1: Generate Tenable Security Center API keys
Do not point this integration at a personal administrator login. Create a dedicated service account instead, scoped to only what the methods you intend to use actually require.
- Sign in to Security Center with an administrator account, go to System > Configuration, open the Security tile, and confirm Allow API Keys is turned on under Authentication Settings (see Prerequisites). Skip this if it is already enabled.
- Go to Users > Users and create a new user (for example
svc-logsign-response) rather than reusing a personal account. - Assign this user a role and repository/organization access scoped to what Logsign needs to see and do, not full Security Manager. Tenable Security Center attributes every API request to the user account behind the key, and the key can only perform actions that account itself is permitted to perform, nothing more. For the read-only methods (list_policies, list_scans, list_scan_results, get_scan_result, get_vulnerabilities, list_reports, get_report, list_assets, get_asset) the account needs read/view access to the repositories and scan results you want visible from Logsign. For start_scan and delete_scan the account additionally needs permission to manage the specific scans it should control, and for delete_report it needs permission to manage the reports it should be able to remove. Tenable Security Center's exact custom-role checkbox names were not verified live for this guide; confirm the closest matching permissions in your own console's Users > Roles screen before relying on them.
- Select the checkbox for the new user, then from the actions above the table choose API Keys > Generate API Key, and confirm by clicking Generate.
- The Your API Key window shows the Access Key and Secret Key once. Copy both immediately and store them somewhere safe. Security Center does not display the secret key again after you close this window; if it is lost, you must generate a new key pair, which invalidates the old one.
Step 2: Configure the integration in Logsign
In Logsign, go to Settings > Integrations > Responses, search for Tenable, click Configure, then +Device.
| Field | Required | Value / Notes |
|---|---|---|
| Device Name | Yes | A label for this configuration, used when selecting the device from an Incident's Responses panel. |
| Host | Yes | The full base URL of your Security Center appliance, including the scheme, for example https://sc.yourcompany.local. This is a strict requirement, not a style preference: based on source-code review, the integration parses this field with Go's standard URL parser and, if the https:// scheme is missing, the parser treats the entire value as a relative path rather than a hostname, which produces a broken, host-less request URL and every call fails. Correct: https://sc.yourcompany.local. Wrong: sc.yourcompany.local. Do not add a path (no /rest, no trailing slash) after the host; the integration builds each endpoint's path internally and any path you add here is discarded, not appended. There is no fixed list of regional or cloud hosts for this integration, since it always points at your own on-premises appliance. |
| Access Key | Yes | The Access Key generated in Step 1. |
| Secret Key | Yes | The Secret Key generated in Step 1. Stored encrypted by Logsign. |
Logsign sends the access key and secret key together in a single x-apikey request header on every call (x-apikey: accesskey=...; secretkey=...), matching Tenable's documented API key header format. There is no separate token exchange step and no token to refresh.
Available Methods
Every method below is invoked from within an Incident's Responses panel by selecting the configured Tenable device and the method name.
list_policies
Lists scan policies configured on the appliance. No parameters.
list_scans
| Parameter | Type | Required | Notes |
|---|---|---|---|
| fields | string | No | Comma-separated list of scan fields to return, forwarded as a query-string parameter. |
start_scan
Launches a scan. Based on source-code review, this method always sends a diagnosticTarget and diagnosticPassword in the launch request and rejects the call if either is blank. Tenable's own Launch Scan API documents both fields as optional, used only to run a special diagnostic scan against a single target with the given credential; a normal scan launch is supposed to be possible with an empty body. As currently implemented, this Logsign method cannot launch a plain scan without a diagnostic target and password, so you will need to supply a valid target host and credential every time you use it, even for what would otherwise be a routine rescan. This was not confirmed against a live appliance for this guide.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Scan ID, as returned by list_scans. |
| diagnosticTarget | string | Yes (see note above) | Target host or IP for the diagnostic scan. |
| diagnosticPassword | string | Yes (see note above) | Credential associated with the diagnostic target. |
delete_scan
Deletes a scan by ID. This is destructive; Tenable does not undo this from its side.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Scan ID. |
list_scan_results
Lists scan results within a time window. Tenable's published Scan Result API documents this as a GET request with startTime/endTime passed as query-string parameters (filtered against createdTime, defaulting to the last 30 days if omitted). Based on source-code review, this integration instead sends an HTTP POST with startTime and endTime in a JSON body. This was not confirmed against a live appliance for this guide; if the call behaves unexpectedly, try a wide, clearly valid epoch range first to rule out a filter mismatch.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| startTime | string (epoch seconds) | Yes | |
| endTime | string (epoch seconds) | Yes |
get_scan_result
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Scan result ID, as returned by list_scan_results. |
get_vulnerabilities
Queries the Analysis API for vulnerability records tied to a saved query ID. Tenable's Analysis API documents startOffset and endOffset together as the pagination window for results. Based on source-code review, this method only exposes startOffset as a settable parameter; endOffset is always sent empty. Depending on how Security Center treats a missing endOffset, this may silently limit how many records a single call returns. This was not confirmed against a live appliance for this guide; if you see fewer vulnerability records than expected, try increasing startOffset across repeated calls rather than relying on a single call to return everything.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | ID of the saved query to run. |
| sortDir | string | No | |
| sortField | string | No | |
| sourceType | string | No | For example cumulative or individual, per Tenable's Analysis API. |
| startOffset | string | No | Result window start. See note above; endOffset is not exposed by this method. |
| scanID | string | No | Required by Tenable's API when sourceType is individual. |
| view | string | No |
list_reports
Lists reports within a time window. The same GET-versus-POST caveat noted for list_scan_results applies here: Tenable documents this as a GET with query-string filters, this integration sends a POST with a JSON body. Not confirmed against a live appliance for this guide.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| startTime | string (epoch seconds) | Yes | |
| endTime | string (epoch seconds) | Yes |
get_report
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Report ID. |
delete_report
Deletes a report by ID. Destructive, not reversible from Tenable's side.
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Report ID. |
list_assets
Lists asset lists (asset groups) configured on the appliance. No parameters.
get_asset
| Parameter | Type | Required | Notes |
|---|---|---|---|
| id | string | Yes | Asset list ID, as returned by list_assets. |
Notes and Limits
- This is a query/action integration, not a log collector. It does not ingest Security Center scan or vulnerability data into Logsign's event store on its own; each method call returns data only for the specific request an analyst makes at that moment. If you want continuous vulnerability data collection into Logsign, that is covered by the separate Tenable Security Center Integration via API poller document, not by this Response integration.
- This integration targets Tenable Security Center (on-premises), not Tenable.io / Tenable Vulnerability Management (cloud). The two products have different REST APIs and this integration will not work against a Tenable.io tenant.
- Based on source-code review, 10 of the 12 methods (every method except list_policies and list_scans) build their request path without the
/rest/prefix that Tenable's own documentation specifies as part of the base URI structure for Security Center's REST API (http://host:port/rest/resource-name). Only list_policies and list_scans include/rest/in their request path. This was not confirmed against a live appliance for this guide; if a specific method consistently returns 404 while list_policies or list_scans work fine with the same Host and credentials, this mismatch is the most likely explanation, and it is worth reporting to Logsign support with the exact method name. - Authentication is a static Access Key and Secret Key pair sent in the
x-apikeyheader on every call. There is no OAuth flow and no token expiry to manage, but a leaked key pair grants standing access until it is regenerated on the Security Center side. - Because most Security Center appliances use a self-signed certificate, treat the appliance as something that should only be reachable from your internal network and from Logsign, not exposed to the public internet.
- Tenable Security Center's public REST API documentation does not define a 429 / rate-limit response for the appliance's own API, unlike Tenable's cloud APIs (Tenable.io / Tenable Vulnerability Management), which do enforce documented rate limits. This is expected: Security Center is a single customer-owned appliance, not a shared multi-tenant service. A 429 seen against a Security Center integration most likely comes from a reverse proxy or load balancer placed in front of the appliance rather than from Security Center itself, or from the appliance being overloaded during an active scan.
Troubleshooting
| Symptom / Code | Likely Cause | What to Check |
|---|---|---|
| 401 Unauthorized | Access Key or Secret Key is wrong, expired, or was regenerated on the Security Center side after this device was configured in Logsign, or API key authentication is not enabled on the appliance at all. | Confirm Allow API Keys is on under System > Configuration > Security. Re-generate the key pair in Security Center and update the device configuration in Logsign with the new values. |
| 403 Forbidden | The key authenticated successfully but the underlying user account lacks permission for the specific action, for example calling delete_scan or start_scan with an account that only has read access. | Check the service account's role and repository/scan access in Security Center. The key inherits the account's exact permissions, nothing more; see Step 1. |
| 404 Not Found | Either the ID does not exist, or (based on source-code review, not confirmed live) the request is missing the /rest/ prefix that Tenable's documented API structure expects for most of this integration's methods. See Notes and Limits. | Verify the ID with a corresponding list method first (list_scans, list_reports, list_assets). If the ID is confirmed correct and the same failure is consistent across every call to a specific method, report the method name to Logsign support. |
| 429 Too Many Requests | Not documented as a native Security Center API response. More likely a proxy/load balancer in front of the appliance, or the appliance itself under heavy scan load. | Retry after a short delay. If it recurs consistently, check for a reverse proxy in the network path and the appliance's own CPU/load during active scans. |
| Connection refused / timeout | Wrong Host value, or a firewall between Logsign and the Security Center appliance is blocking the HTTPS management port. | Confirm the Host field includes the https:// scheme (see Step 2's format warning) and that Logsign can reach the appliance's management interface. |
| TLS / certificate error | The appliance is using a self-signed or internally issued certificate that Logsign's HTTP client does not trust. | Import the appliance's CA certificate into Logsign's trust store, or confirm with Logsign support how this integration's TLS verification behavior is configured, since no separate "skip verify" field is exposed for this device. |
| "No id provided" / "No startTime provided" / "No diagnosticTarget provided" (or similar) error, call rejected before it reaches Tenable | A required field was left blank in the Logsign method form. The integration validates several parameters itself before sending the request. See the Available Methods section above, especially start_scan's diagnosticTarget/diagnosticPassword requirement. | Fill in every parameter marked Required for that method, even ones Tenable's own API would treat as optional. |
| Empty or unexpectedly short results from list_scan_results, list_reports or get_vulnerabilities | Possible mismatch between the request format this integration sends and what Tenable's documented API expects for these specific endpoints (GET vs. POST for list_scan_results/list_reports, missing endOffset for get_vulnerabilities). See Notes and Limits and the per-method notes above. | Try a clearly wide time range or offset first to rule out a filter/pagination issue before assuming the underlying data does not exist. |