Qualys VMDR Response Integration via API

Purpose

This guide explains how to connect Qualys VMDR to Logsign as a Response integration, so an analyst can pull host vulnerability detection data for a specific IP address directly into a Logsign Incident. This is a query integration, not a log collection poller: it does not pull Qualys logs into Logsign on a schedule. It only runs when an analyst (or a correlation rule) calls its method from Settings > Integrations > Responses.

Do not confuse this with Logsign's separate Qualys VMDR data collection poller, which ingests appliance and scan data on its own schedule and is documented in a different article. The two integrations share the same underlying Qualys account and platform concepts (base URL, API user, roles), but they are configured and used independently, and this guide only covers the Response/Action side.

Prerequisites

You need an account with Administration privileges in Qualys to create the dedicated API user described in Step 1. You also need to know which Qualys platform (region/shard) your subscription runs on, since Qualys does not use a single global API address; see Step 1 for how to identify it.

Authentication is HTTP Basic (username and password) against the Qualys VM API. There is no OAuth flow and no separate API key or token for this integration; whatever username and password you configure are the same credentials the API user would use to authenticate against Qualys directly.

Step 1: Identify your Qualys platform and create a least-privilege API user

Identify your platform first. Qualys operates several separate platform instances (sometimes called shards), each with its own hostname for both the web console and the API. Your subscription lives on exactly one of them, and pointing the integration at the wrong one will fail authentication even with correct credentials, because the account simply does not exist on that platform. The most reliable way to confirm yours is to log in to your Qualys console and check Help > About, which shows your current platform under Security Operations Center (SOC). Qualys also publishes a platform identification lookup at qualys.com if you only know your login URL.

The table below lists the current published API server URLs by platform, sourced from Qualys's own platform identification page. Confirm against Help > About in your own console before relying on it, since Qualys occasionally adds new platforms.

Important: the qualysapi.* hostname is the one to use for this integration's Host field. The qualysguard.* hostname is where you log in to the web console in a browser; it is a different service and will not accept the API calls this integration makes. Logsign's separately published Qualys VMDR data collection (poller) article currently lists qualysguard.* addresses as "Common Examples" for its API host field, which is inconsistent with Qualys's own documentation on this point; that discrepancy is tracked separately and is not corrected here, but for this Response integration use the qualysapi.* address for your platform.

Create the API user with least privilege. Do not point this integration at a personal administrator login.

1. Log in to Qualys with Admin privileges and go to Administration > Role Management.
2. Either reuse the built-in Unit Manager role (with API Access enabled), or create a new custom role scoped to only what this integration needs.
3. On the role, enable API Access. Qualys's Reader role commonly returns 401/unauthorized on API calls even when it can browse the console UI fine, so Reader alone is not sufficient here; this matches what Logsign's own published Qualys VMDR poller documentation already notes for the same account.
4. Grant read access to host vulnerability detection data (the VM module's Host Assets / Scan Results read permission) and to the KnowledgeBase module, since this integration's single method calls both. If you narrow the role to a specific Business Unit or set of asset groups, only IPs within that scope will return results; queries for IPs outside the account's scope will come back empty rather than with a permission error (see Notes and Limits).
5. Go to Administration > Create User, create a dedicated service account (for example svc-logsign-qualys), assign it the role from the previous steps, and enable both API Access and GUI Access on the user itself. Complete the email verification/activation flow so the account is active.

Qualys's own role and permission screen names can shift slightly between console versions and are managed per subscription; the specific "Host Assets read" / "KnowledgeBase read" permission checkbox names above were not confirmed against a live Role Management screen for this guide. Treat them as a starting point and adjust to match what your console actually shows.

Step 2: Configure the integration in Logsign

In Logsign, go to Settings > Integrations > Responses, search for Qualys VMDR, click Configure, then +Device.

Based on source-code review, the integration's underlying configuration also defines an optional outbound proxy URL field, but it is not listed in the integration's manifest (the schema the Logsign UI form is generated from), so it is likely not configurable from the UI at this time. This was not confirmed against a live device-creation screen for this guide.

Save the device. Logsign performs a connectivity check when the device is saved (or when using a Test action, if your build exposes one in the UI): it calls the Qualys VM API with a dummy IP address and checks that the response contains a valid <HOST_LIST_OUTPUT> XML root element. This confirms the Host, Username and Password combination can reach Qualys's VM API and authenticate successfully, but it does not confirm KnowledgeBase access; it is possible to pass this check and still get a 401 or an empty result from the method below if the account lacks KnowledgeBase permission. This detail was derived from source-code review and not confirmed against a live UI screenshot.

Available Methods

This integration exposes a single method from within an Incident's Responses panel.

get_host_detections

Looks up an IP address in Qualys VMDR and returns the vulnerabilities Qualys has detected on that host. This is typically used to pivot from an IP that appears in a Logsign alarm or Incident straight into Qualys's vulnerability data for that host, without leaving Logsign.

Behind the scenes, a single call to this method makes two separate sequential Qualys API requests: first a host detection list call against the VM API's host detection endpoint to collect the QIDs (Qualys's internal vulnerability identifiers) currently detected on that IP, then a KnowledgeBase lookup to fetch the full details for those QIDs. Both requests count separately against your subscription's concurrency and rate limits (see Notes and Limits).

The result returned to the Incident timeline is a list of records with the following fields, taken directly from the integration's response schema and matching what the Logsign incident timeline card displays for this method:

If Qualys has no detections on record for the IP you query, the method returns no result rather than an error; the Incident timeline card shows an empty table in this case. This can mean the host genuinely has no open vulnerabilities, but it can equally mean the IP has never been scanned, has not been re-scanned recently, or falls outside the API user's Business Unit/asset group scope, none of which are distinguishable from the response alone.

Notes and Limits

• This is a query integration, not a log collector. It does not ingest Qualys scan results into Logsign's event store on its own; each call returns data only for the specific IP an analyst (or a correlation rule) queries at that moment.
• Authentication is HTTP Basic against Qualys's own VM API login, with no support for any Qualys multi-factor/token step. If your organization enforces MFA at the account level for all Qualys logins, confirm with Qualys support whether that applies to Basic Auth API calls for the service account, since a blanket MFA policy could make this integration unusable regardless of correct credentials. This was not verified against a live Qualys account for this guide.

• Qualys enforces both a concurrency limit and a rate limit per subscription, per API, and returns HTTP 409 Conflict (not 429) when either is exceeded. Qualys's own published limits, as of the last update to their reference document, are summarized below. Confirm your subscription's actual service level with Qualys, since these can be customized per subscription:

  Service Level	Concurrency Limit (per API)	Rate Limit (per API)
  Express/Consultant	1 concurrent call	50 calls per day
  Standard	2 concurrent calls	300 calls per hour
  Enterprise	5 concurrent calls	750 calls per hour
  Premium	10 concurrent calls	2000 calls per hour

  Because each get_host_detections call makes two Qualys API requests (one to the host detection endpoint, one to the KnowledgeBase endpoint), a burst of lookups from Logsign consumes the quota roughly twice as fast as the call count from an analyst's perspective would suggest. On a Standard subscription, more than 2 near-simultaneous lookups from different analysts (or a correlation rule firing repeatedly) can trigger a concurrency-limit 409.

• Qualys exposes current quota usage in every API response's HTTP headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-ToWait-Sec, X-ConcurrencyLimit-Limit, X-ConcurrencyLimit-Running). This integration does not currently surface those headers to the Logsign UI; if you need to monitor quota consumption, check the Activity Log in the Qualys console instead (Users > Activity Log, search Details for "API"), which records blocked calls as "API blocked (concurrency): ..." or "API blocked (rate): ...".
• Insecure Skip Verify defaults to true (TLS certificate validation skipped). See Step 2 for guidance on when it is safe to disable.
• Only IPs already known to Qualys as an asset, and within the API user's Business Unit/asset group scope, return data. There is no way for this integration to trigger a new Qualys scan or add a new asset; it is read-only against existing detection data.

Troubleshooting