Can Cisco Vulnerability Management import vulnerabilities discovered via manual assessments?

The Cisco Vulnerability Management platform offers you the functionality to import vulnerability data from any external system such as manual assessments, pen-test test results and tools without an out of the box connector available.

The process, in a nutshell, involves converting the outputs from those mentioned sources into JSON format that can then be ingested by the Data Importer.

The conversion of the data into JSON format is typically the responsibility of the customer. However, we do offer a set of scripts that will facilitate the conversion of CSV data (which is a very common export format for most tools) into prepared JSON that the Data Importer will interpret.

These scripts are available on our Public Samples GitHub Repository located here:

https://github.com/KennaPublicSamples/All_Samples/tree/master/KDI%20Importer - Connect to preview

The script calls on your vulnerability source CSV file and an additional metadata.csv file. This metadata file will act as the translator to map headings and fields from the source to the required headers in the JSON format. As mentioned, JSON is required for successful ingestion into the platform. The output JSON file can then be uploaded directly into the Data Importer and will run in a similar fashion to other connectors.

This script uses the fully documented and supported REST API. They are not part of the Cisco Vulnerability Management Engineering program and do not participate in a formal SDLC program.

The script is written in Ruby. You can run ruby from a desktop but for scheduled runs against your Cisco Vulnerability Management instance, a server space is recommended.

• Server should be sized based on the expected data file processing size but usually those sizes are not extreme and do not require a heavy duty server.
• The server machine should be able to make calls via https to the API (sometimes 443 access is allowed by default and sometimes firewall access from servers must be explicitly granted).
• Many customers store the files they are going to process directly on the server, so disk space for these files should be considered.
• If you plan on writing scripts that access other internal APIs or file directories, the machine would need access to those items.
• For automation purposes, the server should be either part of the centralized scheduler process or have a scheduler on it that can be accessed by the appropriate teams (windows server has a scheduler).
• Finally, the machine will need access to install ruby.
  • https://www.ruby-lang.org
  • https://rubygems.org
  • https://rubyinstaller.org (for windows)

All the code samples in this GitHub repository are offered “as is” and include no warranty of any kind. Use them at your own risk. In no event will Cisco Vulnerability Management be liable to end user or any other party for damages of any kind arising from the use of these samples.

If you are a customer with an assigned Customer Success Team, then your Customer Success Engineer will be able to provide further guidance and assistance on the configuration and operation of the scripts.