18 Connecting the Greenbone Security Manager to 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:

  • verinice ITSM system (see Chapter 18.2)
  • Nagios Monitoring System (see Chapter 18.3)
  • Cisco Firepower Management Center (see Chapter 18.4)

The GSM offers numerous interfaces that allow for the communication with other systems:

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 exporting of reports.
Connecting additional scanners using OSP
The Open Scanner Protocol (OSP) is a standardized interface for different vulnerability scanners. Arbitrary scanners can be integrated seamlessly 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 11.1). Additional report formats can be downloaded from the Greenbone download webpage or developed in collaboration with Greenbone Networks.
Alert via Syslog, e-mail, SNMP trap or HTTP (see Chapter 10.12)
Automatic result forwarding through connectors
These connectors are created by Greenbone Networks, verified and integrated into the GSM.
Monitoring via SNMP
The webpage https://docs.greenbone.net/API/SNMP/snmp-gos-20.08.en.html provides the current Management Information Base (MIB) file. MIB files describe the files that can be queried by SNMP about the equipment.

18.1 Using an OSP Scanner

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

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

18.2 Using Verinice

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


Fig. 18.1 Integrating the GSM with verinice

Verinice is suitable for:

  • Vulnerability remediation workflow
  • 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 operation of an ISMS. For this, Greenbone Networks offers a report format for the export of data from the GSM into verinice:

  • Verinice-ISM

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


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

18.2.1 IT Security Management

The report format Verinice ISM for verinice is preinstalled on the GSM.

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

Verinice uses the notes (see Chapter 11.7) 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 vulnerabilities have to be solved and which can be tolerated. This decision is made by tagging the vulnerabilities accordingly in the vulnerability management.

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.

After the scan is completed the report has to be exported using the report format Verinice ISM (see Chapter 11.2.2). A VNA file is created. This is a ZIP file containing the data of the scan.


For the following example SerNet verinice 1.18.1 was used.

If another version is used, the steps may differ. Contact the verinice support for help. Importing the ISM Scan Report

The report can be imported in verinice as follows:

  1. Start verinice.

  2. Select View > Show Perspective > Information Security Management in the menu bar (see Fig. 18.2).


    Fig. 18.2 Opening the perspective Information Security Management

  3. Click verinice_ism_import in the window Catalogs to import the desired catalog.

  4. Create an organization by clicking verinice_new_org (see Fig. 18.3).


    The window for defining the details of the organization can simply be closed.


    Fig. 18.3 Creating a new organization

  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 Fig. 18.4).


    Fig. 18.4 Selecting the ISM report

  7. Click OK.

    → The results of the ISM report are imported and can be unfolded in verinice (see Fig. 18.5).


    Fig. 18.5 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 from the group of imported objects to the top level.

    Right click on the organization and select Cut. Click right in the top level in the window Information Security Model and select Paste.

  2. The assets and controls must be grouped.

    Right click on Assets GSM-Scan and select Group by Tags… (see Fig. 18.6).

    Confirm the message by clicking OK.


    Fig. 18.6 Grouping the assets

  3. Right click on Controls GSM-Scan and select Group by Tags….

    Confirm the message by clicking OK.

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

    Expand the organization, right click on Persons and select Add Person….

  5. Assign the newly created person per drag and drop to the assets group.

    → The successful assignment can be displayed in the window Relations by clicking Assets GSM-Scan (see Fig. 18.7).


    Fig. 18.7 Displaying the relations for a group

  6. Right click on the organization and select Tasks > Greenbone: Start vulnerability process….

    → 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.

  7. Continue with creating a task or cancel the creation.

    The task to remediate vulnerabilities is called “Remediate Vulnerabilities”. Remediating Vulnerabilities

The created tasks can be managed with the help of the view Task (View > Show View > Tasks in the menu bar) or the web frontend of the verinice.PRO version (under: ISO 27000 tasks).

A task contains controls, scenarios and assets that are connected to a control group and are assigned to a responsible person. The responsible person remediates 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.

18.3 Using Nagios

Nagios can integrate the scan results as an additional test in its monitoring tasks. 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.


Fig. 18.8 Linking Nagios with the GSM

When linking Nagios with the GSM, Nagios will assume the controlling role.

Nagios retrieves the newest scan results from the GSM regularly and automatically. This is done via a Nagios command which uses the tool gvm-script to call the script check-gmp.gmp.py.


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.

18.3.1 Configuring the GSM User

For access Nagios requires a user to log in to the GSM. 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.

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

18.3.2 Configuring the Script

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


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/.
  1. 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="user name" --gmp-password="password" \
ssh --hostname /.../libexec/check-gmp.gmp.py --ping \
GMP OK: Ping successful
  1. Check whether there is access to the data:
nagios-host# gvm-script --gmp-username="user name" --gmp-password="password" \
ssh --hostname /.../libexec/check-gmp.gmp.py \
-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 command line switches. These can be displayed using:

nagios-host# gvm-script -c /.../etc/gvm-tools.conf ssh --hostname scripts/check-gmp.gmp.py -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.
  1. If the tests were successful the check can be integrated into Nagios monitor.

    Add the host to be monitored to the section HOST DEFINITIONS in the Nagios configuration file /.../etc/objects/localhost.cfg.

    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 Nagios command check_gmp_status.

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

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 in 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.py -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 tool gvm-script (see Chapter 15.3).

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

Fig. 18.9 Nagios displaying the monitored host status

18.3.3 Caching and Multiprocessing

The script check-gmp.gmp.py 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 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.

18.4 Using the Cisco Firepower Management Center

The Cisco Firepower Management Center (former Sourcefire Intrusion Prevention System (IPS)) is one of the leading solutions 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.

To identify and classify attacks correctly, the Firepower Management Center requires as much information as possible about the systems in the network, the applications installed on them, and the potential vulnerabilities for both. For this purpose the Firepower Management Center has its own asset database that can be augmented with information from the GSM. Additionally, the Firepower Management Center can start an automatic scan if it suspects anything.

The following connection methods are available:

Automatic data transfer from the GSM to the NIDS/IPS
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, the report will be forwarded as an alert to the NIDS/IPS with 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 Firepower Management Center have to be prepared. On the GSM a report format plug-in has to be installed. In the Firepower Management Center the option to receive the data must be enabled.


The report format Sourcefire is provided via the feed.

Report formats may not be available yet, but will be added at a later time.

In case a report format is not available, contact the Greenbone Networks Support (support@greenbone.net).

18.4.1 Configuring the Host-Input-API Clients

The Host-Input-API is an interface through which the Firepower Management Center accepts data from other applications for its asset database.

  1. Log into the Firepower Management Center.

  2. Select System > Integration in the menu bar.

  3. Select the register Host Input Client.

  4. Enter the IP address of the GSM in the input box Hostname (see Fig. 18.10).


    Fig. 18.10 Creating a host input client

  5. Enter the password in the input box Password.

  6. Click Save.


    The connection is TLS encrypted.

    → The Firepower Management 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 created and made available as a download.

  7. Click sourcefire_download to download the file (see Fig. 18.11).


    Fig. 18.11 Downloading the created PKCS#12 file

18.4.2 Configuring a Sourcefire Connector Alert

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 Fig. 18.12).


    For the information to enter in the input boxes see Chapter 10.12.

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


    Fig. 18.12 Creating an alert with Sourcefire Connector

  1. 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 Save.

18.5 Using 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.

18.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.

18.5.2 Configuring an Alemba vFire Alert

To have the GSM automatically create tickets (called “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 (see Fig. 18.13).


    For the information to enter in the input boxes see Chapter 10.12.

  4. Choose Alemba vFire in the drop-down list Method.


    Fig. 18.13 Creating an alert with Alemba vFire

  5. Click Save.

The following details of the alert can be defined:

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.
Base URL
This is the URL of the Alemba instance including the server name and the 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” 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 18.5.1).
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 10.12).
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.

18.6 Using Splunk

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

Connecting a GSM to a Splunk solution is not part of the GSM core functionality. As an add-on, Greenbone Networks provides an app for the integration with Splunk Enterprise on-premise solutions. The app is currently available at https://download.greenbone.net/tools/Greenbone-Splunk-App-1.0.1.tar.gz.


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

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


If there are problems with downloading or testing the app contact the Greenbone Networks Support.

In the following Splunk Enterprise version 8.5 is used. The installation of the app on Splunk Light is not supported. Connecting a GSM to Splunk Cloud is not supported.

18.6.1 Setting up the Greenbone-Splunk App Installing the App

The Greenbone-Splunk app can be installed as follows:

  1. Open Splunk Enterprise.
  2. Click splunk_apps in the left menu panel (see Fig. 18.14).

Fig. 18.14 Installing the Splunk app

  1. Click Install app from file.
  2. Click Browse….
  3. Select the TAR file of the Greenbone-Splunk app.
  4. Click Upload. Configuring the Greenbone-Splunk App

The port of the Greenbone-Splunk app is required for the configuration on the GSM.

Check the port of the Greenbone-Splunk app as follows:

  1. Select the Greenbone-Splunk app in the left menu panel.
  2. Select Settings > Data inputs in the menu bar.
  3. Click TCP (see Fig. 18.15).


The Greenbone-Splunk app sets up a data input on port 7680/tcp (default port) and tags the incoming data to Greenbone Scan Results and places it in the index default.


Fig. 18.15 Checking the port of the Greenbone-Splunk app

To make the data more user-friendly, the field names can be replaced as follows:

  1. Click splunk_apps in the left menu panel.

  2. In the row of Greenbone click View objects.

  3. Click Greenbone Scan Results: FIELDALIAS-reportfields.

  4. Enter the field name aliases in the respective input boxes (see Fig. 18.16).


    Fig. 18.16 Changing the field name aliases

18.6.2 Configuring a Splunk Alert

The GSM transfers the scan results in the form of an XML report via an alert directly to the Splunk main server.


The dashboard of the Greenbone-Splunk app only shows results from reports less than 7 days old.

If a report older than 7 days is sent, the dashboard will not display the results. However, the results are in the main index of the Splunk server. Creating the Splunk Alert

The alert is created as follows:

  1. Select Configuration > Alerts in the menu bar.

  2. Create a new alert by clicking new.

  3. Define the alert (see Fig. 18.17).


    For the information to enter in the input boxes see Chapter 10.12.

  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 7680 in the input box on port.


    The TCP port is 7680 by default.

    This setting can be checked in the Greenbone-Splunk app as described in Chapter

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


    Fig. 18.17 Configuring the Splunk alert

  7. Click Save. Adding the Splunk Alert to a Task

The alert can now be selected when creating a new task (see Chapter 10.2.2) or be added to an existing task (see Chapter 10.12.2). Testing the Splunk Alert

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. Click start.

  4. Select the alert in the drop-down list Alert (see Fig. 18.18).


    Fig. 18.18 Triggering the alert

  5. Click OK.

18.6.3 Using the Greenbone-Splunk App Accessing the Information in Splunk

To access the information in Splunk open the Greenbone dashboard as follows:

  1. Open Splunk Enterprise.

  2. Select the Greenbone-Splunk app in the left menu panel.

  3. Select Dashboards in the menu bar.

  4. Click Greenbone Dashboard.


    The dashboard of the Greenbone-Splunk app only shows results from reports less than 7 days old.

    If a report older than 7 days is sent, the dashboard will not display the results. However, the results are in the main index of the Splunk server.


Fig. 18.19 Greenbone dashboard within the Greenbone-Splunk app

The input field CVE-ID below the dashboard can be used to display the number of hosts affected by a certain CVE over time.


If the input box is left empty and Enter is pressed, the number of hosts affected by all CVEs is displayed. Creating a Dashboard for the Top 5 Affected Hosts and for Incoming Reports

A new dashboard can be created to show the top 5 affected hosts of all time and the incoming reports from the GSM. The dashboard will show each time a new report comes in to the Splunk server for the past year.

  1. Open Splunk Enterprise.

  2. Select the Greenbone-Splunk app in the left menu panel.

  3. Select Dashboards in the menu bar.

  4. Click Create New Dashboard.

  5. Enter a title in the input box Title, e.g., Greenbone incoming stats.

  6. Click Create Dashboard.

  7. Click Source.

  8. Copy and paste the following into the input field (replacing all):

      <label>Greenbone incoming stats</label>
              <title>Top 5 all time</title>
                      <query>sourcetype = "Greenbone Scan Results" VulnerabilityResultSeverity &gt; 0 | chart count over VulnerabilityResultHost by VulnerabilityResultThreat | fillnull High | fillnull Medium | fillnull Low | eval _count= High+Low+Medium | sort by _count desc | head 5</query>
                    <option name="charting.axisLabelsX.majorLabelStyle.overflowMode">ellipsisNone</option>
                    <option name="charting.axisLabelsX.majorLabelStyle.rotation">0</option>
                    <option name="charting.axisTitleX.visibility">visible</option>
                    <option name="charting.axisTitleY.visibility">visible</option>
                    <option name="charting.axisTitleY2.visibility">visible</option>
                    <option name="charting.axisX.scale">linear</option>
                    <option name="charting.axisY.scale">linear</option>
                    <option name="charting.axisY2.enabled">0</option>
                    <option name="charting.axisY2.scale">inherit</option>
                    <option name="charting.chart">bar</option>
                    <option name="charting.chart.bubbleMaximumSize">50</option>
                    <option name="charting.chart.bubbleMinimumSize">10</option>
                    <option name="charting.chart.bubbleSizeBy">area</option>
                    <option name="charting.chart.nullValueMode">gaps</option>
                    <option name="charting.chart.showDataLabels">none</option>
                    <option name="charting.chart.sliceCollapsingThreshold">0.01</option>
                    <option name="charting.chart.stackMode">stacked</option>
                    <option name="charting.chart.style">shiny</option>
                    <option name="charting.drilldown">all</option>
                    <option name="charting.fieldColors">{"High":0xD6563C,"Medium":0xF2B827, "Low":0x1E93C6}</option>
                    <option name="charting.layout.splitSeries">0</option>
                    <option name="charting.layout.splitSeries.allowIndependentYRanges">0</option>
                    <option name="charting.legend.labelStyle.overflowMode">ellipsisMiddle</option>
                    <option name="charting.legend.placement">right</option>
                    <option name="refresh.display">progressbar</option>
                    <title>Incoming feed to Greenbone App</title>
                      <query>| tstats count where sourcetype = "Greenbone Scan Results" by sourcetype _time | timechart span=1d count by  sourcetype</query>
                    <option name="charting.chart">line</option>
                    <option name="refresh.display">progressbar</option>
  9. Click Save.


    Fig. 18.21 Dashboard for the top 5 affected hosts and for incoming reports


[1]This control does not exist as a finalized Remediation for the Firepower Management Center but it can be implemented via GMP (see Chapter 15).