Rapid7 InsightVM Response Integration via API

Purpose

This guide explains how to connect Rapid7 InsightVM to Logsign as a Response integration, so an analyst can query asset, vulnerability, site and scan data from InsightVM, and trigger or control scans, directly from a Logsign Incident. This is a query/action integration, not a log collection poller: it does not pull InsightVM logs into Logsign on a schedule. It only runs when an analyst (or, for the read-only methods, a correlation rule) calls one of its methods from Settings > Integrations > Responses.

InsightVM is Rapid7's on-premises vulnerability management console (the product is sometimes confused with an EDR/endpoint detection tool because of how it is labeled in some older Logsign builds; it is not an EDR, it is a vulnerability scanner and asset risk platform). The integration talks to your own Security Console over its REST API, so there is no Rapid7 cloud tenant or region to select: the host is whatever address your organization uses to reach its Security Console.

Based on the current integration manifest in the Logsign codebase, this integration is registered with disable_action_rule: true, which means it is filtered out of the automated Action Rules (correlation-triggered playbook) list in the Logsign UI. In practice this integration is available as a manual, analyst-triggered Response from inside an Incident, not as something a correlation rule fires on its own. If your build behaves differently, treat this as the current source-level behavior rather than a guarantee, since it was not confirmed against a live UI screenshot for this guide.

Prerequisites

You need network reachability from your Logsign instance to the InsightVM Security Console on its HTTPS management port (3780 by default for on-premises Security Consoles). You also need a Security Console user account dedicated to this integration; Step 1 below covers how to scope that account down from a full administrator. The exact minimum Logsign version that ships this integration was not found in release notes for this guide; the underlying code has been present in the Logsign repository since 2022, so any reasonably current Logsign 6.x build should include it, but confirm with Logsign support if you are on an older build and do not see Rapid7 InsightVM listed under Settings > Integrations > Responses.

One authentication detail to plan around: the integration authenticates with HTTP Basic Authorization (username and password) only. It does not send an InsightVM two-factor authentication token on any request. If two-factor authentication is enforced for the account you create in Step 1, every call this integration makes will fail with a 401, even with a correct username and password. Use an account that is exempt from 2FA enforcement, or disable 2FA specifically for the service account if your organization's policy allows it.

Step 1: Create a least-privilege API user on the InsightVM Security Console

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.

1. Sign in to the Security Console as a Global Administrator, open Administration > Users, and create a new user (a dedicated service account, for example svc-logsign-insightvm).
2. When choosing a role, avoid the built-in Global Administrator preset unless you specifically need the site-creation and site-deletion methods described below. Instead, create a custom role.
3. For the read and query methods (listing sites, assets, asset groups, scans, scan engines, scan templates, and vulnerabilities), grant the custom role View Site Asset Data and View Group Asset Data, then explicitly assign that user access to the specific sites and/or asset groups you want Logsign to be able to query. A custom role with no site or asset group access attached will authenticate successfully but return empty results.
4. For start_site_scan and change_scan_status, also grant the site-level permission Start Unscheduled Scans (and, if you want scheduled scans to remain adjustable through this account, Schedule Automatic Scans) on the sites this account can access.
5. For create_new_site and delete_site_by_id: according to Rapid7's published documentation, site creation and deletion (the "Manage Sites" capability) is restricted to the Global Administrator role and cannot be granted through a custom role. If you need Logsign to be able to create or delete sites through this integration, the service account has to be a Global Administrator; there is no scoped middle ground on the Rapid7 side for this specific capability. If you only need the read/query and scan-control methods, skip this and keep the account scoped as a custom role.
6. Save the user, then use the same username and password when configuring the integration in Logsign in Step 2. InsightVM's API v3 does not use a separate API key; it authenticates with the console login credentials over Basic Auth.

The exact wording and location of these permission checkboxes can shift slightly between InsightVM releases, and this guide's permission names were taken from Rapid7's published user-management documentation rather than a live custom-role screen, so treat the permission names above as a strong starting point and confirm them against your own console version if anything is missing.

Step 2: Configure the integration in Logsign

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

Save the device. There is no dedicated "Test Connection" method exposed in the method list; the integration does have an internal connectivity check that calls GET /sites against your configured host and path, but it runs as part of Logsign's own device-save flow rather than as something you invoke separately.

Available Methods

Every method below is invoked from within an Incident's Responses panel by selecting the configured Rapid7 InsightVM device and the method name. Parameters marked "functionally required" are not enforced by the underlying schema (so the form will let you submit them blank), but the call will fail or return an unhelpful result without them.

get_sites

Lists sites configured in InsightVM, with asset counts, risk score and vulnerability summary per site.

create_new_site

Creates a new InsightVM site. Requires the Global Administrator-level account described in Step 1.

delete_site_by_id

Deletes a site by ID. Requires the Global Administrator-level account described in Step 1. This is destructive and not reversible from InsightVM's side; the historical scan and asset data tied to the site is removed with it.

get_assets

Lists assets known to InsightVM, with host names, IP/MAC addresses, OS fingerprint and vulnerability counts.

get_asset_detail_by_asset_id

Returns the full asset record for a single asset: services, software inventory, users, groups, OS fingerprint and vulnerability totals. This is typically the first call an analyst makes when pivoting from an IP or hostname in an alarm to InsightVM's view of that host.

asset_search

Searches assets by a single filter condition (field, operator, value or value range) combined with a match mode.

Note: InsightVM's own API documents asset search as a POST request. Based on a source-code review, this integration issues the request as an HTTP GET with a body instead. Most HTTP clients and proxies tolerate this, but if your environment has anything in the path that strips bodies from GET requests, this method may return unexpected results. This was not confirmed against a live console for this guide.

get_asset_groups

Lists asset groups with asset counts, risk score and vulnerability summary per group. No parameters.

create_asset_group

Creates a static or dynamic (search-based) asset group.

Note: the same GET-instead-of-POST behavior noted for asset_search applies to create_asset_group; based on source-code review this method also sends its request as an HTTP GET rather than the POST that InsightVM's API documents for group creation. Not confirmed against a live console for this guide.

delete_asset_group

get_scans

Lists scans, active or historical, with status, timing and vulnerability counts.

get_scan_by_id

change_scan_status

Pauses, stops or resumes a running scan.

start_site_scan

Starts a new scan against a site, optionally limited to a specific list of hosts within it. This is typically used to trigger an on-demand rescan of a host that just triggered an alarm.

get_scan_engines

Lists configured scan engines with address, port and status. No parameters.

get_scan_templates

Lists available scan templates with their discovery, performance and check configuration. No parameters.

get_asset_vulnerabilities

Lists the vulnerabilities found on a specific asset, with per-vulnerability status and instance count.

get_vulnerability_detail_by_asset

Returns detail for a single vulnerability on a single asset, including per-port/protocol proof and status.

Based on a source-code review, the current implementation reads both the asset and vulnerability identifiers from the same internal field, so the two values shown as separate fields in the Logsign form may not both be honored by the underlying request; in practice this can return the wrong vulnerability, or the same vulnerability regardless of which ID you enter. This was not confirmed against a live console for this guide. If you rely on this method, verify the returned result matches the vulnerability you expected before acting on it, and consider reporting this to Logsign support if you confirm the mismatch.

Notes and Limits

• This is a query/action integration, not a log collector. It does not ingest InsightVM scan results or vulnerability data into Logsign's event store on its own; each method call returns data only for the specific request an analyst (or a correlation rule, for read-only methods) makes at that moment.
• Authentication is HTTP Basic (username and password) against the Security Console's own login. There is no separate API key concept for this integration, and no support for supplying an InsightVM two-factor authentication token, so the service account must not have 2FA enforced.
• Site and scan creation/deletion require Global Administrator on the InsightVM side; the read/query methods and scan start/pause/stop/resume can run with a scoped custom role that only has visibility into specific sites or asset groups. See Step 1 for the split.
• Based on a source-code review, asset_search and create_asset_group issue their requests as HTTP GET rather than the POST that InsightVM's API documents for these operations, and both methods' multi-value filter (the "values" array) is not read correctly by the current code. None of this was confirmed against a live console for this guide; if you plan to depend on multi-value asset search filters or on group creation from Logsign, test against your own console first.
• get_vulnerability_detail_by_asset appears, from source-code review, to conflate its Asset ID and Vulnerability ID parameters. Treat results from this specific method with extra caution until verified against your own console.
• InsightVM's on-premises Security Console API does not document a rate limit (no 429 response is defined in Rapid7's published API v3 specification), unlike Rapid7's cloud APIs which do enforce one. That said, a busy console under heavy scan load may respond slowly to API calls regardless.
• The TLS verification setting (Insecure Skip Verify) defaults to true, which skips certificate validation. This is a sensible default for a self-signed on-premises console but is worth revisiting if your console has a certificate from a CA your organization already trusts.

Troubleshooting