Note: This article applies only to the Rapid7 InsightVM Cloud connector. For information about the Rapid7 Nexpose On-Premises connector (a file-based connector), refer to the Rapid7 Nexpose On-Premises Connector information.
For more information about migrating to the Rapid7 InsightVM Cloud connector, including Frequently Asked Questions, refer to the Migrating to the Rapid7 InsightVM from a Nexpose Connector in Cisco Vulnerability Management information.
This connector is Rapid7’s cloud-based solution that pulls data from on-premises Nexpose consoles that scan IT environments for vulnerabilities, and then it identifies active services, open ports, and applications.
Use the Cisco Vulnerability Management with Rapid7 InsightVM Cloud connector to do the following:
- Find vulnerability information to reduce risk in your IT environment.
- Support the products and vendors you have already invested in.
- Improve visibility with more comprehensive, powerful, flexible, and effective threat detection.
For more information about Cisco Vulnerability Management and the connectors, see the following links:
- Getting Started with the Cisco Vulnerability Management Platform
- Cisco Vulnerability Management User Training Videos
For help with adding or using this connector, contact Cisco Technical Support.
Cisco Vulnerability Management Administrator and API Key Prerequisites
Before you setup and run this connector, ensure you have Cisco Vulnerability Management administrator credentials, and an API Key with the required permission level.
To Add and Run the InsightVM Cloud Connector
Important: Only Cisco Vulnerability Management administrators can add connectors. In addition, you must have an InsightVM API Key. To use the full functionality and the required access levels when using the InsightVM connector, only users enabled with the "Platform Administrator" role in Rapid7 can generate the keys that Cisco Vulnerability Management uses.
1. In the Cisco Vulnerability Management UI, click Connectors.
2. Click Add Connector.
3. In the Vulnerability Management section, click Rapid7 InsightVM Cloud.
4. On the Connectors InsightVM page, enter the following information:
- Name: Enter a name for the connector or leave it as InsightVM.
- Schedule: Choose the frequency, such as Daily. Note: By default, Cisco Vulnerability Management imports updates daily at 12 AM.
- Region: Choose the Rapid7 Insight data storage region that applies to you.
- API Key: Paste your InsightVM API key.
- Asset Inactivity Limit (days): Enter a time in days for the connector level asset inactivity limit.
5. Click Save And Verify.
Migrating from Rapid7 Nexpose
Note: For more information, about Migration from Rapid7 Nexpose to InsightVM, see the Migrating to the Rapid7 InsightVM from a Nexpose Connector in Cisco Vulnerability Management information.
Many customers will be migrating from the Cisco Vulnerability Management Nexpose connector to the InsightVM connector. Customers should be aware that these are two different Rapid7 products and customers should approach migration expecting the data imported into Cisco Vulnerability Management to be different. Here are a few known differences:
- Different external IDs
- No open ports on assets
- Fewer vulnerabilities overall
- More broadly applicable fixes (and therefore fewer)
- fix_published is not an ingested field
To confirm that the data in Cisco Vulnerability Management is accurate, see the InsightVM Cloud Integrations API and compare the data.
Note: Ensure you contact Cisco if you see any cases where you feel the data imported into Cisco Vulnerability Management is less accurate than the raw data in InsightVM.
Data Mapping
Source Name | Explanation | Response Path |
Asset | Single asset from /vm/v4/integration/assets
|
data[0] |
Vuln | Single vuln from /vm/v4/integration/vulnerabilities
|
data[0] |
InsightVM Source and Example | Cisco Vulnerability Management Field and Example | Notes |
Asset:new[0].vulnerability_id If a comparison time is supplied, the vulnerabilities that are new in the latest version at the current time. Example: aix-4_1-u427500 |
vulnerabilities.identifier Example: 00044f612345baf759462dbe6db733b6a9c59ab4 |
Asset has 3 vulnerability collections in the properties new, remediated, and same. Example: Asset = { "new": [{"vulnerability_id":"aix-4_1-u427500",...}], "same": [{"vulnerability_id":"aix-4_1-u427501",...}], "remediated": [{"vulnerability_id":"aix-4_1-u427502",...}] } |
Asset:same[0].vulnerability_id If a comparison time is supplied and includeSame is true, the vulnerabilities that are the same between the current time and the comparison time. Example: aix-4_1-u427501 |
vulnerabilities.identifier 00044f612345baf759462dbe6db733b6a9c59ab4 |
|
Asset:remediated[0].vulnerability_id If a comparison time is supplied, the vulnerabilities that were remediated in the latest version at the current time. Example: aix-4_1-u427502 |
vulnerabilities.identifier Example: 00044f612345baf759462dbe6db733b6a9c59ab4 |
|
Asset:new[0].first_found Asset:remediated[0].first_found Asset:same[0].first_found Example: 2011-11-08T19:52:19Z |
vulnerabilities.found_on Example: 2020-12-30T11:07:15.000Z |
|
Track vulnerability moving from new/same into remediated. Vulnerability IDs from InsightVM are always unique, even if the vulnerability is re-opened. Therefore, if a vulnerability that was in new/same is now in remediated, that vulnerability will always be remediated forever. If this vulnerability becomes active again on the asset, a new vulnerability will be created on InsightVM’s side. |
vulnerabilities.last_fixed_on Example: 2021-09-11T06:04:15.000Z |
|
Asset:new[0].last_found Asset:remediated[0].last_found Asset:same[0].last_found Example: 2019-08-15T19:13:18.771Z |
vulnerabilities:last_found_on Example: 2020-12-30T14:17:26.000Z |
|
If the vulnerability is in new or same, it is open. If the vulnerability is in remediated, it is closed. |
vulnerabilities.is_open Example: true |
Use the vulnerability status field to track the collection of the vulnerability. |
Asset:new[0].risk_score Asset:remediated[0].risk_score Asset:same[0].risk_score Example: 63881.921875 |
vulnerabilities.scanner_score Example: 9.3 |
|
Asset:new[0].cves Asset:remediated[0].cves Asset:same[0].cves Example: vuln.cves CVE-2015-2466 |
vulnerabilities.cve_raw_data Example: CVE-2015-2466 |
All CVEs assigned to this vulnerability. |
Asset:new[0].cves Asset:remediated[0].cves Asset:same[0].cves Example: CVE-2015-2466 |
vulnerabilities.name Example: CVE-2015-2466 |
|
Asset:new[0].cves Asset:remediated[0].cves Asset:same[0].cves Example: CVE-2015-2466 |
vulnerabilities.definition_identifier Example: InsightVM CVE-2015-2466 |
|
Asset:new[0].solution_fix Asset:remediated[0].solution_fix Asset:same[0].solution_fix |
vulnerabilities.solution Example: null |
{ "solution_fix": "<p><ol><li>Use 'suma' to download the latest security updates: `suma -x -a RqType=Security`</li><li>Use smit/smitty to apply the latest security updates</li></ol></p>", "solution_id": "aix-fileset-upgrade-aix-5_3-devices.pci.1410ec02.rte", "solution_summary": "Install the latest version of devices.pci.1410ec02.rte", "solution_type": "workaround" } |
Vuln.description Example: |
vulnerabilities.description Example: A spoofing vulnerability exists when… |
data[0].description |
vulnerabilities.pci_related Example: false |
{ "pci_cvss_score": 10.0, "pci_fail": true, "pci_severity_score": 5, "pci_special_notes": "", "pci_status": "fail" } |
|
Asset:{new/same/remediated}[0].proof |
vulnerabilities.details Example: null |
|
Vuln.port Example: 443 |
vulnerabilities.port Example: null |
|
Asset:host_name Example: machinename.example.com |
locators.hostname Example: mymachine1 |
The hostname can either be a local hostname or an FQDN. Therefore, the logic distinguishes between the hostname and FQDN. if is_fqdn(Asset:host_name) toLowerCase(EXTRACT HOSTNAME FROM FQDN) else: toLowerCase(Asset:host_name) |
locators.container Example: null |
||
locators.image Example: null |
||
locators.ec2 Example: null |
||
Asset:host_name Example: machinename.example.com |
locators.netbios Example: MACHINENAME |
According to the API docs the hostname can either be a local hostname or an fqdn. Therefore logic needs to be applied to distinguish between hostname,netbios and FQDN. if is_fqdn(Asset:host_name) && (Asset.os_family) == 'Windows” : toUpperCase(EXTRACT HOSTNAME FROM Asset:host_name) else if is_fqdn(Asset:host_name) && (Asset.os_family) != 'Windows”: NULL else if !is_fqdn(Asset:host_name) && ((Asset.os_family) == 'Windows”): toUpperCase(Asset:host_name) else: NULL |
locators.url Example: null |
||
locators.file Example: null |
||
Asset:host_name Example machinename.example.com: |
locators.fqdn Example: machinename.example.com |
According to the API docs the hostname can either be a local hostname or an FQDN. Therefore, logic needs to be applied to distinguish between hostname and FQDN. if is_fqdn(Asset:host_name) toLowerCase(Asset:hostname) else: NULL |
locators.database Example: null |
||
locators.application Example: null |
||
Asset.ip Example: 10.10.10.10 |
locators.ip_address Example: 172.17.230.209 |
|
Asset.id Example: 700e2525-5383-4748-af02-9dea73ab306d-default-asset-10 |
locators.external_id Example: 9eaf3a8b5962e0e6b1af9ec756664a9b823df2d1 |
|
Asset.mac Example: 00:00:00:09:00:00 or 000000090000 |
locators.mac_address Example: null |
if mac_address_locator is not a formatted MAC address: mac_address_locator: Add a colon “:" after each pair of characters (except for the first pair) |
Asset.os_vendor Example: Microsoft |
os_vendor
|
|
Asset.os_name Example: Windows; Linux |
os_family Example: "Windows10", "Windows11" |
|
Asset.os_version Example: 2.6.18 |
os_version Example: 10.0.18363.1256 |
|
Asset.last_assessed_for_vulnerabilities Example: 2020-03-20T19:19:42.611Z |
last_seen_time Example: 2021-09-16T05:18:06Z |
|
ports Example: [] |
Ports are only on vulnerabilities, so to put it on the asset, we’d have to always get all the vulnerabilities (no incremental runs) or always includeSame, which will greatly increase our data volume and processing time. | |
network_interfaces Example: [] |
||
Asset.tags Example: [{"name":"lab", "type":"SITE"}] |
tags Example: [ "test tag 1", "test tag 2" ] |
Frequently Asked Questions
When I’m viewing fixes, why do a different number of Scanner IDs display compared to the number that displayed when I was using a different connector?
Cisco Vulnerability Management normalizes the vulnerability data by the CVE, CWE or WASC identifier. This is how it can ingest data from many different sources and represent the data across multiple tools. Individual scanning tools may normalize in other ways, and this can lead to a difference in counts between the tools.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)
© 1992-2024 Cisco Systems, Inc. All rights reserved.
Comments
Please sign in to leave a comment.