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 website or developed in collaboration with Greenbone Networks.
Alert via Syslog, e-mail, SNMP trap or HTTP (see Chapter 10.11)
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 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 provides the protocol documentation at https://docs.greenbone.net/API/OSP/osp.html.

18.2. Using Verinice

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

_images/integration_verinice-20130422_620x347.png

Fig. 18.1 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 operation of an ISMS as well as the modelling and implementation of IT-Grundschutz.

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.

Note

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

18.2.1. IT Security Management

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

With this report format plug-in 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.

Note

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.

Note

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.

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

  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.2).

    Note

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

    _images/verinice2.png

    Fig. 18.2 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.3).

    _images/verinice3.png

    Fig. 18.3 Selecting the ISM report

  7. Click OK.

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

    _images/verinice5.png

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

18.2.1.2. 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.5).

    Confirm the message by clicking OK.

    _images/verinice10.png

    Fig. 18.5 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.6).

    _images/verinice6.png

    Fig. 18.6 Displaying the relations for a group

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

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

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

18.2.1.3. Remediating Vulnerabilities

The created tasks can be managed with the help of the view Task 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.

Note

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.2.2. IT-Grundschutz

Greenbone Networks provides a special scan configuration (IT-Grundschutz scan including discovery for verinice) as well as the IT-Grundschutz report format 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 format plug-in is preinstalled on the GSM.

For optimum results in the scan it is helpful to perform an authenticated scan (see Chapter 10.3).

How to import the scan configuration and perform the IT-Grundschutz scan is described in Chapter 14.2.1.1.

After the scan is completed the report has to be exported using the report format Verinice ITG (see Chapter 11.2.2). 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.

Note

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.

18.2.2.1. Importing the ITG Scan Report

The report can be imported in verinice as follows:

  1. Start verinice.

  2. Select View > Show Perspective > IT Baseline Protection in the menu bar.

    Note

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

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

    _images/verinice7.png

    Fig. 18.7 Selecting the ITG report

  5. Click OK.

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

    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.

    _images/verinice8.png

    Fig. 18.8 Unfolding the results of the ITG report

  6. Right click on a server and select Greenbone: Automatically add module... to add the IT-Grundschutz modules.

    → Verinice chooses the appropriate components to model the system based on the tags set by the GSM (see Fig. 18.9).

    _images/verinice9.png

    Fig. 18.9 IT-Grundschutz components selected automatically

  7. Right click on a server and select Greenbone: automatic basic security check to add the results of the scans to the control catalog.

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.

_images/integration_nagios_2000x1125.png

Fig. 18.10 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.

Note

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.

Note

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 as part of the script collection of gvm-tools. This script can be called by the monitoring solution using gvm-script (see Chapter 15.3).

Note

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:

    Note

    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 192.168.10.169 /.../libexec/check-gmp.gmp --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 192.168.10.169 /.../libexec/check-gmp.gmp \
-F 192.168.10.130 --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 192.168.10.130
|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
  192.168.10.169 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.
...
  1. If the tests were successful the check can be integrated into Nagios monitor.

    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
     address                 192.168.10.130
     }
  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 192.168.10.169 $USER1$/check-gmp.gmp -F $HOSTADDRESS$
         --last-report -T $ARG1$ --status
    }

Note

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
_images/nagios-service-status.png

Fig. 18.11 Nagios site displaying the monitored host status

18.3.3. Caching and Multiprocessing

The script 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.

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

18.4.1. Installing the Report Format 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

    Important

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

  4. Click Browse... and select the previously downloaded report format plug-in (see Fig. 18.12).

  5. Click Save.

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

    _images/report_format_sourcefire_import.png

    Fig. 18.12 Importing the report format plug-in

    Note

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

  6. In the row of the report format click verify to verify it.

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

18.4.2. Configuring the Host-Input-API Clients

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

  1. Log into the Firepower Management Center.

  2. Select System > Local > Registration 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.13).

    _images/host-input-api1.png

    Fig. 18.13 Creating a host input client

  5. Enter the password in the input box Password.

    Note

    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.

  6. Click sourcefire_download to download the file (see Fig. 18.14).

    _images/host-input-api2.png

    Fig. 18.14 Downloading the created PKCS#12 file

18.4.3. 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.15).

    Tip

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

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

    _images/alert_sourcefire.png

    Fig. 18.15 Creating an alert with Sourcefire Connector

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

    Note

    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.

Footnotes

[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).

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.16).

    Tip

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

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

    _images/alert_alemba.png

    Fig. 18.16 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.
Credential
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).
Partition
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.11).
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.
Impact
The full name of an impact value.
Urgency
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.

The Splunk integration requires the installation of the Greenbone-Splunk application on the splunk server. The download and installation of the application are explained in Chapter 18.6.1.

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

18.6.1. Using the Greenbone-Splunk Application

Greenbone Networks offers a small application for the integration with Splunk. The application is currently available at https://download.greenbone.net/tools/Greenbone-Splunk-App-1.0.1.tar.gz.

Important

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.

Note

If there are problems with downloading or testing the application contact the Greenbone Networks support.

In the following Splunk Enterprise version 6.4.3 is used. The installation of the application Splunk Light is not supported.

The Greenbone-Splunk application can be installed as follows:

  1. Log in to the Splunk server.
  2. Select Apps > Manage Apps in the menu bar of Splunk (see Fig. 18.17).
_images/splunk1.png

Fig. 18.17 Installing the Splunk application

  1. Click Install app from file.

  2. Select the downloaded Greenbone-Splunk application file and upload it to the Splunk server.

  3. Click Upload.

    → The Greenbone-Splunk application is successfully installed (see Fig. 18.18).

_images/splunk3.png

Fig. 18.18 Successful installation of the Greenbone-Splunk application

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

    Check the port of the Greenbone-Splunk application. The port can be accessed in the web interface of Splunk by selecting Settings > Data inputs > TCP in the menu bar (see Fig. 18.19).

_images/splunk4.png

Fig. 18.19 Checking the port of the Greenbone-Splunk application

18.6.2. Configuring a 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 Fig. 18.20).

    Tip

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

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

    Note

    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 18.6.1).

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

    _images/alert_splunk.png

    Fig. 18.20 Configuring the Splunk alert

  7. Click Save.

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 moving the mouse over new and clicking New Task.

  3. Define the task.

    Tip

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

  4. Select the alert in the drop-down-list Alerts.

  5. Click Save.

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. Select the alert in the drop-down-list Alerts.
  4. Click Save.

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.21).

    _images/alert_report_splunk.png

    Fig. 18.21 Triggering the alert

  5. Click OK.

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

_images/splunk7.png

Fig. 18.22 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.

_images/splunk8.png

Fig. 18.23 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