17. Integration with Other Systems

The Greenbone Security Manager (GSM) can be connected to other systems.

Some systems have already been integrated into the GSM by Greenbone Networks including the verinice ITSM system, the Sourcefire IPS Defense Center and the Nagios Monitoring System.

17.1. Integration with Third-Party Vendors

The GSM has numerous interfaces that allow for the communication with third-party vendors.

Hereby the GSM offers the following interfaces:

Greenbone Management Protocol (GMP)
The Greenbone Management Protocol allows to remote control the GSM completely. The protocol supports the creating of users, creating and starting of scan tasks and downloading reports.
Connecting additional scanners via OSP
The Open Scanner Protocol (OSP) is a standardized interface for different vulnerability scanners. Arbitrary scanners can be seamlessly integrated into the GSM vulnerability management. Controlling the scanners and handling the results works in the same way for all scanners.
Report Format
The GSM can present the scan results in any format. To do so the GSM already comes with a multitude of pre-installed report formats (see Chapter Managing Report Formats). Additional report formats can be downloaded from the Greenbone download website or developed in collaboration with Greenbone Networks.
Alert via Syslog, E-Mail, SNMP-Trap or HTTP (see Chapter Using Alerts)
Automatic result forwarding through connectors
These connectors are created by Greenbone Networks, verified and integrated into the GSM.
Monitoring via SNMP
The website https://docs.greenbone.net/API/SNMP/snmp-gos-4.3.en.html provides the current MIB file (Management Information Base). MIB files describe the files that can be queried by SNMP about the equipment.

17.1.1. OSP Scanner

The Open Scanner Protocol (OSP) resembles the Greenbone Management Protocol (GMP, see chapter Greenbone Management Protocol). It is XML based, stateless and does not require a permanent connection for communication. The design allows for embedding of additional scanners seamlessly into GSM.

The open format allows developing custom OSP scanners. Greenbone provides the protocol documentation at https://docs.greenbone.net/API/OSP/osp.html.

17.2. Verinice

Verinice is a free Open Source Information Security Management System (ISMS) developed by SerNet.


Integrating the GSM with verinice

Verinice is suitable for:

  • Vulnerability remediation workflow
  • Implementing the IT-Grundschutz catalogs of the German Federal Office for Information Security (BSI)
  • Performing risk analysis based on ISO 27005
  • Operating an ISMS based on ISO 27001
  • Performing an IS assessment per VDA specifications
  • Proof of compliance with standards such as ISO 27002, IDW PS 330

The GSM can support the modelling and implementation of IT-Grundschutz as well as the operation of an ISMS.

For this, Greenbone Networks offers two report plug-ins for the export of data from the GSM into verinice:

  • Verinice-ISM: containing all scan results
  • Verinice-ITG: containing the scan results of a BSI IT-Grundschutz scan

It is possible to transfer data completely automated from the GSM to verinicePRO, the server extension of verinice.

Following the manual, the import of reports from the GSM in the free verinice version is covered.


For support with the use of the connector contact SerNet or Greenbone Networks.

17.2.1. IT Security Management

The report plug-in for verinice is pre-configured and is available as “Verinice-ISM”.

With this report plug-in Greenbone Networks supports the vulnerability remediation workflow in verinice.

Verinice uses the notes (see Chapter Using Notes) of the scan results to create objects for processing. If there are no notes in a task only the assets will be imported as well as the complete vulnerability report. Exclusively such vulnerabilities that have a note will be imported by verinice as vulnerabilities. This allows controlling the import in fine detail.


Within the entire security process it has to be decided which vulnerability must be resolved and which are tolerable. This decision is made in the vulnerability management, by tagging the vulnerabilities accordingly.

The remediation workflow targets at solving any of the managed issues. Within the remediation workflow it is not allowed to decide about tolerating an issue.

Afterwards the report has to be saved as Verinice ISM-Report. A VNA file will be created. This is a ZIP file containing the data of the GSM scan. Importing of the ISM Scan

The report can be imported in Verinice as follows:

  1. Start Verinice.

  2. Open the ISM perspective.

  3. Import the catalog Implementation Assistance for ISO27001.

  4. Create an organization.

    → Afterwards the screen should look like displayed in figure ISM perspective in Verinice.


    ISM perspective in Verinice

  5. In the window Information Security Model click verinice_ism_import.

  6. Click Select file... and select the ISM report. The remaining parameters can be kept with their default settings (see figure Selecting the ISM report).


    Selecting the ISM report

  7. Click OK.

    → The results of the ISM report are imported and can be unfolded in Verinice (see figure Unfolding the results of the ISM report).


    Unfolding the results of the ISM report

The process to track vulnerabilities for the imported organization can be separated into two sub processes:

  • Creation of tasks
  • Remediation of vulnerabilities Creating Tasks

Before creating tasks the data for the organization must be prepared as follows:

  1. After the first import of an organization it must be moved to the top level from the group of imported objects.

    Cut the organization and paste it into the top level (see figure Moving the imported organization to the top level).


Moving the imported organization to the top level

  1. The assets and controls must be grouped.

    Right click on Assets GSM-Scans and select Group with Tags....

    Right click on Controls GSM-Scans and select Group with Tags....

  2. All assets groups must be assigned a responsible person.

    Create a person and assign them by drag and drop to the assets group.

    → The successful assignment is displayed in the window Relations (see figure Displaying the relations for a group).


    Displaying the relations for a group

  3. Right click on the organization and select Greenbone: Start Vulnerability Tracking.

    → It is verified whether all assets and controls are grouped and whether all asset groups are assigned to a person. A message displays the result of the verification.

  4. Continue with creating a task or cancel the creation. Remediating Vulnerabilities

The created tasks can be managed with the help of the task view or the web frontend of the verinice.Pro version (under: ISO 27000 tasks). The task to remediate vulnerabilities is called “Remediate Vulnerabilities”.

A task contains controls, scenarios and assets that are connected to a control group and are assigned to a responsible person.

As the responsible person remediate the vulnerabilities for all assets.


If the deadline for the task “Remediate Vulnerabilities” expires, a reminder e-mail is sent to the responsible person.

After the task is completed all connections between assets and scenarios that were assigned to a task are deleted.

The following states of a control are possible:

  • Implemented: no asset is assigned to the scenario anymore
  • Partly: other connections to assets still exist

17.2.2. IT-Grundschutz

Greenbone Networks provides a special configuration (IT-Grundschutz scan including discovery for Verinice) as well as an IT-Grundschutz report plug-in (Verinice ITG) which allows for the export of a report suited for Verinice.

For optimum results the scan configuration needs to be imported. The report plug-in is now shipped with the GSM. A manual import is not required anymore.

For optimum results in the scan it is helpful to perform an authenticated scan (see Chapter Running an Authenticated Scan Using Local Security Checks).

As soon as the scan is completed, export it in the verinice ITG format. A VNA file is created. This is a ZIP archive in which the results of the scans are stored. This file can be loaded by verinice directly.

Following for clarity purposes a scan is being used with only one host. Importing the ITG Scan

The report can be imported in Verinice as follows:

  1. Start Verinice.

  2. Open the BSI IT Baseline perspective (see figure Starting Verinice).


    If no IT bond has been created yet the middle view is empty.


    Starting Verinice

  3. In the window BSI Model click verinice_ism_import.

  4. Click Select file... and select the ITG report. The remaining parameters can be kept with their default settings (see figure Selecting the ITG report).


    Selecting the ITG report

  5. Click OK.

    → The results of the ITG report are imported and can be unfolded in Verinice (see figure Unfolding the results of the ITG report).


    Unfolding the results of the ITG report

The imported objects are named by the target in the GSM or their IP address. Every imported object has a sub-object GSM result with the activity results of the scan.

Now the IT-Grundschutz modules can be added by right clicking on a server and selecting Greenbone: Automatically assign components.

Verinice chooses the appropriate components to model the system based on the tags set by the GSM.


IT-Grundschutz components selected automatically

Now the results of the scans can be added into the control catalog by right clicking on a server and selecting Greenbone: Automatic Base Security Check.

17.3. Nagios

Nagios can integrate the scan results in its monitoring tasks as an additional test. In this case the scanned systems are automatically matched with the monitored systems. With this the scan results are eventually available for the alert rules and other processes of Nagios.


Linking Nagios with the GSM

When linking Nagios with the GSM, Nagios will assume the controlling role. Nagios regularly and automatically retrieves the newest scan results from the GSM. This is done via a Nagios command which uses the gvm-script tool to call the check-gmp.gmp script.

Follow the instructions to connect the GSM to Nagios.


Other products compatible with Nagios such as Open Monitoring Distribution, Icinga, Centreon etc. should generally work but may require small adjustments to the described steps.

17.3.1. Configuring the GSM User

For access the plug-in requires a user used to log in to the appliance. For this user a scan target (or multiple scan targets) has to be set up with all hosts of which the security status should be monitored. The sample configuration used here assumes that there is only one relevant target but technically it is possible to link complex setups with multiple targets and multiple GSMs.

The GSM user account provided for queries by the GMP script must be owner of the relevant scan targets or at least have unrestricted reading access to them. The tasks should be run as scheduled scans regularly.

In addition, network access via GMP to the GSM must be possible. Therefore, the GMP access must be activated in the GOS administration menu (see Chapter Activating GMP).

17.3.2. Configuring the Script

Greenbone Networks provides the check-gmp.gmp script as part of the script collection of gvm-tools. This script can be called by the monitoring solution using gvm-script (see Chapter GVM-Tools).


The following assumes Nagios is installed in /usr/local/nagios/, afterwards referred to as /.../.

Adjust the file location if necessary.

  1. Copy the plug-in to /.../libexec/.

  2. Check if the script can reach the GSM through the network, GMP was activated and the user was created properly.


    In the following command replace the IP address with the IP address of the GSM and provide the user name and the created password.

nagios-host# gvm-script --gmp-username=webadmin --gmp-password=kennwort \
ssh --hostname /.../libexec/check-gmp.gmp --ping \
GMP OK: Ping successful
  1. Check whether there is access to the data.
nagios-host# gvm-script --gmp-username=webadmin --gmp-password=kennwort \
ssh --hostname /.../libexec/check-gmp.gmp \
-F --last-report -T "Scan Suspect Host" --status
GMP CRITICAL: 284 vulnerabilities found - High: 118 Medium: 153 Low: 13
Report did contain 1 errors for IP
|High=118 Medium=153 Low=13

The script supports several commandline switches. These can be displayed using:

nagios-host# gvm-script -c /.../etc/gvm-tools.conf ssh --hostname scripts/check-gmp.gmp -H
usage: check-gmp [-H] [-V] [--cache [CACHE]] [--clean] [-F HOSTADDRESS] [-T TASK]

Check-GMP Nagios Command Plugin 2.0.0 (C) 2017-2019 Greenbone Networks GmbH

optional arguments:
-H                    Show this help message and exit.
-V, --version         Show program's version number and exit
--cache [CACHE]       Path to cache file. Default: /tmp/check_gmp/reports.db.
--clean               Activate to clean the database.

 → If the tests were successful the check can be integrated into Nagios monitor.
  1. Add the host to be monitored in the Nagios /.../etc/objects/localhost.cfg configuration file, in the section HOST DEFINITIONS.

    In this example the host is a Metasploitable Linux.

define host{
     use                     linux-server
     host_name               metasploitable
     alias                   metasploitable
  1. In the same configuration file, in the section SERVICE DEFINITIONS, define a new service which calls the check_gmp_status nagios command.

    As the example shows, an argument is passed to the command, the task name where to fetch the report from.

define service{
     use                    local-service    ; Name of service template to use
     host_name              metasploitable
     service_description    GMP task last report status
     check_command          check_gmp_status!metasploitable
  1. Create the check_gmp_status command into the file /.../etc/objects/commands.cfg.
define command{
    command_name    check_gmp_status
    command_line    gvm-script -c /.../etc/gvm-tools.conf ssh
       --hostname $USER1$/check-gmp.gmp -F $HOSTADDRESS$
         --last-report -T $ARG1$ --status


In the command line it can be seen that no user name and password options but a configuration file are passed to the gvm-script tool (see Chapter GVM-Tools).

  1. Restart the Nagios service to apply the new configuration.
nagios-host# systemctl restart nagios

Nagios site displaying the monitored host status

17.3.3. Caching and Multiprocessing

The check-gmp.gmp supports caching. All new reports will be cached in a SQLite database. The first call with an unknown host will take longer because the report needs to be retrieved from the GSM. Subsequent calls to the plug-in will only retrieve the current report from the GSM if the end time of the scan differs. Otherwise, the information from the database is used. This will greatly reduce the load both on the monitoring server and the GSM.

The cache file is written to /tmp/check_gmp/reports.db by default. A different location of the database can be specified using the command line switch --cache.

To further reduce the load both on the monitoring server and the GSM the plug-in can restrict the maximum number of simultaneously running plug-in instances. Additionally started instances are stopped and wait for their continuation. The default value of MAX_RUNNING_INSTANCES is 10. The default can be modified using the command line switch -I.

17.4. Firepower Management Center

The Cisco Firepower Management Center (former Sourcefire Intrusion Prevention System) (IPS) is one of the leading solution for intrusion detection and defense in computer networks. As a Network Intrusion Detection System (NIDS) it is tasked with the discovery, alerting and the defense against attacks on the network.

For Firepower to correctly identify and classify attacks it requires as close as possible information about the systems in the network, the installed applications as well as their possible vulnerabilities. For this purpose Firepower has its own asset database that can be augmented with information from the GSM. Additionally, the Sourcefire system can start an automatic scan if it suspects anything.

The following connection methods are available:

Automatic data transfer from the GSM to the NIDS/IDS
If the GSM and NIDS/IDS are configured respectively the data transfer from the GSM to the NIDS/IPS can be utilized easily, like any other alert functionality of the GSM. After completion of the scan it will be forwarded as an alert to the NIDS/IPS in respect to the desired criteria. If the scan task is run automatically on a weekly basis, a fully automated alerting and optimization system is obtained.
Active control of the GSM by the NIDS/IPS
In the operation of the NIDS/IPS suspected incidents on systems with high risk can occur. In such a case the NIDS/IPS can instruct the GSM to check the system [1].

To use the connection methods the GSM as well as the Sourcefire Defense Center have to be prepared. On the GSM a report plug-in has to be installed and on the Sourcefire Defense Center receiving the data must be enabled.

17.4.1. Installing the Report Plug-in

The report plug-in can be installed as follows:

  1. Download the following report format plug-in: https://download.greenbone.net/rfps/sourcefire-1.1.0.xml


    External links to the Greenbone download website are case-sensitive.

    Note that upper cases, lower cases and special characters have to be entered exactly as they are written here.

  2. Select Configuration > Report Formats in the menu bar.

  3. Click new.

  4. Click Browse... and select the previously downloaded report format plug-in.

  5. Click Create.

    → The imported report format is displayed on the page Report Formats.


    Importing the report format plug-in


    The report format plug-in has to be verified and activated before it can be used.

  6. Verify the signature of the report format by clicking verify.

    → The result of the verification is displayed in the column Trust (Last Verified).

  7. In the row of the report format click edit.

  8. For Active select the radiobutton Yes.

  9. Click Save.

17.4.2. Configuring the Host-Input-API clients


Setting up the GSM in the defense center

Log into the Sourcefire Defense Center and create a Host-Input-Client. The Host-Input-API is an interface through which the Defense Center accepts data from other applications for its asset database. This option can be found in the web interface under System->Local->Registration. There change into the Host Input Client register. Here create the GSM appliance. It is important to enter the IP address of the appliance that the appliance will use to connect to the Defense Center. The connection is TLS encrypted. The Defense Center creates a private key and certificate automatically. In the certificate the IP address entered above will be used as Common Name and verified when the client is establishing a connection. If the client uses a different IP address, the connection fails.

The created PKCS#12 file is optionally secured by a password.

Afterwards the certificate and the key are being created and made available as a download. Download this file.


Downloading the created PKCS#12 file

17.4.3. Configuring Alerts on the GSM

Now the respective alert must be set up on the GSM.

  1. Select Configuration > Alerts in the menu bar.

  2. Create a new alert by clicking new.

  3. Define the alert (see figure Using the PKCS#12 file for authentication).

  4. Choose Sourcefire Connector in the drop-down-list Method.


    Using the PKCS#12 file for authentication

  5. Supply the PKCS#12 file by clicking Browse....


    If a password was entered when the client was created, the PKCS#12 file has to be decrypted before loading it into the GSM.

    To do so, the following command in Linux can be used:

$ openssl pkcs12 -in encrypted.pkcs12 -nodes -out decrypted.pcks12
Enter Import Password : password
MAC verified OK
  1. Click Create.


[1]This control does not exist as a finalized Remediation for the Sourcefire system but it can be implemented via GMP (see chapter Greenbone Management Protocol).

17.5. Alemba vFire

vFire is an Enterprise Service Management application, developed by Alemba.

The GSM can be configured to create tickets in an instance of vFire based on events like finished scans.

17.5.1. Prerequisites for Alemba vFire

For the integration to work properly, the following prerequisites must be met on the vFire system:

  • The vFire installation must support the RESTful Alemba API, which has been added in vFire version 9.7. The legacy API of older versions is not supported by the Greenbone connector.
  • An Alemba API client with the correct session type (analyst/user) and password login must be enabled.
  • The user account that should be used requires permissions to use the Alemba API.

17.5.2. Configuring the Alemba vFire Alert

To have the GSM automatically create tickets (calls) in vFire, an alert must be set up as follows:

  1. Select Configuration > Alerts in the menu bar.
  2. Create a new alert by clicking new.
  3. Define the alert.
  4. Choose Alemba vFire in the drop-down-list Method.
  5. Click Create.

The options for the alert are:

Report Formats:
The report formats used for the attachments. Multiple report formats can be selected or the selection can be left empty if no attachments are wanted.
vFire Base URL:
This is the URL of the Alemba instance including the server name and virtual directory. For example, if the user interface is accessed via https://alemba.example.com/vfire/core.aspx, the base URL would be https://alemba.example.com/vfire.
The user name and the password used for logging into Alemba vFire.
Session Type:
The type of session to use. It can be either “analyst” or “user”. As an “analyst” it is possible to perform some actions not available to a “user”. The user account requires special permissions for these actions and the number of concurrent logins may be limited.
Alemba Client ID:
This is the Alemba API client ID (see Chapter Prerequisites for Alemba vFire).
The partition to create the ticket in. See the Alemba vFire help for more information about partitioning.
Call Description:
This is the template for the description text used for the newly created calls. The same placeholders as in the message input box of the e-mail alert method can be used (see Chapter Using Alerts).
Call Template:
The name of a call template to use for the calls created by the alert. A call template can be configured in vFire to fill in all the fields that cannot be specified directly in the alert.
Call Type:
The name of a call type to use for the calls created by the alert.
The full name of an impact value.
The full name of an urgency value.

17.6. Splunk

The GSM can be configured to forward the scan results to a Splunk enterprise installation for further analysis and correlation.

The Splunk integration requires the installation of the Greenbone Splunk app on the splunk server. The download and installation of the app are explained in Chapter Splunk Application.

Once the app is installed on the Splunk server, the GSM can be instructed to send the results to the Splunk server.

17.6.1. Configuring the Splunk Alert

The GSM is configured as follows:

  1. Select Configuration > Alerts in the menu bar.

  2. Create a new alert by clicking new.

  3. Define the alert (see figure Configuring the Splunk alert).

  4. Choose Send to host in the drop-down-list Method.

  5. Enter the IP address of the Splunk server in the input box Send to host and the port of the Greenbone Splunk app in the input box on port


    The TCP port is 7680 by default.

    These setting can be checked using the Splunk web interface by selecting Settings > Data Inputs > TCP (see Chapter Splunk Application).

  6. Choose XML in the drop-down-list Report.


    Configuring the Splunk alert

  7. Click Create.

This alert can now be added to the appropriate task as follows:

  1. Select Scans > Tasks in the menu bar.
  2. Create a new task by clicking new and selecting New Task.
  3. Define the task.
  4. Enter the name of the alert in the input box Alerts.
  5. Click Create.

The alert can be added to already existing tasks as well. The alert does not modify the scan behavior.

  1. Select Scans > Tasks in the menu bar.
  2. In the row of the task click edit.
  3. Enter the name of the alert in the input box Alerts.
  4. Click Create.

For testing purposes existing reports may be processed by the alert.

  1. Select Scans > Reports in the menu bar.

  2. Click on the date of a report.

  3. Move the mouse over Report: Results.

    → A drop-down-list is opened.

  4. Click Report: Summary and Download.

  5. In the row of the desired version, select Splunk Connector in the column Run Alert (see figure Processing an existing report using the alert).

  6. In the row of the desired version click start.


    Processing an existing report using the alert

17.6.2. Accessing the Information in Splunk

To access the information in Splunk switch to the Greenbone dashboard. The Greenbone dashboard within the Splunk web interface displays the vulnerabilities found within the last 7 days.


Greenbone dashboard within the Splunk web interface

Since the information forwarded by the GSM is indexed by Splunk the search view can be used to search for any data.


Splunk server supporting complex searches

Some supported indexes are:

  • host
  • source, sourcetype
  • date_hour, date_minute, date_month, date_year, date_mdate, date_wday, date_zone
  • VulnerabilityResultNvtCVE
  • VulnerabilityResultNvtCVSS
  • VulnerabilityResultQod
  • VulnerabilityResultSeverity
  • VulnerabilityResultThreat