18 Den Greenbone Security Manager mit anderen Systemen verbinden

Der Greenbone Security Manager (GSM) kann mit anderen System verbunden werden.

Einige Systeme sind bereits in den GSM integriert:

  • Verinice ITSM-System (siehe Kapitel 18.2)
  • Nagios-Monitoring-System (siehe Kapitel 18.3)
  • Cisco Firepower Management Center (siehe Kapitel 18.4)

Der GSM bietet zahlreiche Schnittstellen für die Kommunikation mit anderen Systemen:

Greenbone Management Protocol (GMP)
Das Greenbone Management Protocol ermöglicht die vollständige Fernsteuerung des GSMs. Das Protokoll unterstützt das Erstellen von Benutzern, das Erstellen und Starten von Scanaufgaben und das Exportieren von Berichten.
Zusätzliche Scanner mithilfe von OSP verbinden
Das Open Scanner Protocol (OSP) ist eine standardisierte Schnittstelle für unterschiedliche Schwachstellenscanner. Beliebige Scanner können problemlos in das GSM-Schwachstellenmanagement integriert werden. Das Steuern der Scanner und die Bearbeitung der Ergebnisse geschieht für alle Scanner auf gleiche Weise.
Berichtformat
Der GSM kann die Scanergebnisse in jedem Format wiedergeben. Dafür ist auf dem GSM bereits eine Vielzahl an Berichtformaten vorinstalliert (siehe Kapitel 11.1). Zusätzliche Berichtformate können von der Greenbone-Downloadseite heruntergeladen oder in Zusammenarbeit mit Greenbone Networks entwickelt werden.
Benachrichtigung über Syslog, E-Mail, SNMP-Trap oder HTTP (siehe Kapitel 10.12)
Automatische Weiterleitung der Ergbnisse über Konnektoren
Diese Konnektoren werden durch Greenbone Networks erstellt, verifiziert und in den GSM integriert.
Überwachung mithilfe von SNMP
Die Webseite https://docs.greenbone.net/API/SNMP/snmp-gos-20.08-21.04.de.html stellt das aktuelle Management-Information-Base-Datei (MIB-Datei) bereit. MIB-Dateien beschreiben die Dateien, die SNMP über das Gerät abfragen kann.

18.1 Einen OSP-Scanner nutzen

Das Open Scanner Protocol (OSP) ähnelt dem Greenbone Management Protocol (GMP, siehe Kapitel 15). Es ist XML-basiert, zustandslos und benötigt keine dauerhafte Kommunikationsverbindung. Das Design erlaubt das problemlose Einbetten zusätzlicher Scanner in den GSM.

Das offene Format ermöglicht das Entwickeln benutzerdefinierter OSP-Scanner. Greenbone Networks stellt die Dokumentation des Protokolls unter https://docs.greenbone.net/API/OSP/osp-21.04.html.

18.2 Verinice nutzen

Verinice ist ein freies Open-Source-ISMS (Information Security Management System), das von SerNet entwickelt wurde.

_images/verinice_integration.png

Abb. 18.1 Den GSM mit verinice verbinden

Verinice eignet sich für:

  • Workflow zur Schwachstellenbeseitigung
  • Durchführen von Risikoanalysen basierend auf ISO 27005
  • Betreiben eines ISMS basierend auf ISO 27001
  • Durchführen einer IS-Bewertung per VDA-Spezifikationen
  • Nachweisen der Konformität mit Standards wie ISO 27002, IDW PS 330

Der GSM kann das Betreiben einen ISMS unterstützen. Dafür bietet Greenbone Networks ein Berichtformat zum Exportieren von Daten aus dem GSM in verinice:

  • Verinice-ISM

Es ist möglich, die Daten vollkommen automatisch vom GSM auf verinice.PRO, der Servererweiterung von verinice, zu übertragen.

Bemerkung

Zur Unterstützung bei der Nutzung des Konnektors kann SerNet oder Greenbone Networks kontaktiert werden.

18.2.1 IT-Sicherheitsmanagement

Das Berichtformat Verinice ISM für verinice ist auf dem GSM vorinstalliert.

Mit diesem Berichtformat unterstützt Greenbone Networks den Workflow zur Schwachstellenbeseitigung in verinice.

Verinice nutzt die Notizen (siehe Kapitel 11.7) der Scanergebnisse, um Objekte für die Verarbeitung zu erstellen. Falls keine Notizen für eine Aufgabe vorhanden sind, werden nur die Assets sowie der gesamte Schwachstellenbericht importiert. Ausschließlich die Schwachstellen, die Notizen aufweisen, werden von verinice als Schwachstellen importiert. Dies ermöglicht es, den Import bis ins Detail zu steuern.

Bemerkung

Während des Sicherheitsprozesses muss entschieden werden, welche Schwachstellen gelöst werden müssen und welche toleriert werden können. Diese Entscheidung wird durch das Taggen der entsprechenden Schwachstellen im Schwachstellenmanagement getroffen.

Das Ziel des Beseitigungsworkflows ist die Lösung der festgelegten Probleme. Während des Workflows ist eine Entscheidung, ob ein Problem toleriert werden soll, nicht mehr zulässig.

Nachdem ein Scan abgeschlossen ist, muss der Bericht mithilfe des Berichtformats Verinice ISM exportiert werden (siehe Kapitel 11.2.2). Eine VNA-Datei wird erstellt. Dies ist eine ZIP-Datei, die die Daten des Scans enthält.

Bemerkung

Im folgenden Beispiel wurde SerNet verinice 1.18.1 genutzt.

Falls eine andere Version genutzt wird, unterscheiden sich die Schritte möglicherweise. Der Support von verinice kann zur Unterstützung kontaktiert werden.

18.2.1.1 Den ISM-Scanbericht importieren

Der Bericht kann wie folgt in verinice importiert werden:

  1. Verinice starten.

  2. Ansicht > Zeige Perspektive… > Information Security Management in der Menüleiste wählen (siehe Abb. 18.2).

    _images/verinice1-de.png

    Abb. 18.2 Die Perspektive Information Security Management öffnen

  3. Im Fenster Kataloge auf verinice_ism_import klicken, um den gewünschten Katalog zu importieren.

  4. Auf verinice_new_org klicken, um eine Organisation zu erstellen (siehe Abb. 18.3).

    Bemerkung

    Das Fenster zum Festlegen der Details der Organisation kann einfach geschlossen werden.

    _images/verinice2-de.png

    Abb. 18.3 Erstellen einer neuen Organisation

  5. Im Fenster ISM auf verinice_ism_import klicken.

  6. Auf Datei auswählen… klicken und den ISM-Bericht wählen. Die übrigen Parameter können mit ihren Standardeinstellungen übernommen werden (siehe Abb. 18.4).

    _images/verinice3-de.png

    Abb. 18.4 Wählen des ISM-Berichts

  7. Auf OK klicken.

    → Die Ergebnisse des ISM-Berichts werden importiert und können in verinice ausgeklappt werden (siehe Abb. 18.5).

    _images/verinice5-de.png

    Abb. 18.5 Ausklappen der Ergebnisse des ISM-Berichts

Der Prozess zur Verfolgung von Schwachstellen für die importierte Organisation gliedert sich in zwei Unterprozesse:

  • Erstellen von Aufgaben
  • Beseitigen von Schwachstellen

18.2.1.2 Aufgaben erstellen

Vor dem Erstellen der Aufgaben müssen die Daten für die Organisation wie folgt vorbereitet werden:

  1. Nach dem ersten Importieren einer Organisation muss diese von der Gruppe importierter Objekte auf die oberste Ebene verschoben werden.

    Auf die Organisation rechtsklicken und Ausschneiden wählen. In die oberste Ebene im Fenster ISM rechtsklicken und Einfügen wählen.

  2. Die Assets und Controls müssen gruppiert werden.

    Auf Assets GSM-Scan rechtsklicken und Gruppiere mit Tags… wählen (siehe Abb. 18.6).

    Nachricht durch Klicken auf OK bestätigen.

    _images/verinice10-de.png

    Abb. 18.6 Gruppieren der Assets

  3. Auf Controls GSM-Scan rechtsklicken und Gruppiere mit Tags… wählen.

    Nachricht durch Klicken auf OK bestätigen.

  4. Alle Assetgruppen müssen einer verantwortlichen Person zugeordnet werden.

    Organisation ausklappen, auf Persons rechtsklicken und Neue Person wählen.

  5. Neu erstellte Person per Drag-and-Drop der Assetgruppe zuweisen.

    → Die erfolgreiche Zuweisung kann im Fenster Verknüpfungen durch Klicken auf Assets GSM-Scan angezeigt werden (siehe Abb. 18.7).

    _images/verinice6-de.png

    Abb. 18.7 Anzeigen der Beziehungen einer Gruppe

  6. Auf die Organisation rechtsklicken und Aufgaben > Greenbone: Starte Schwachstellenverfolgung… wählen.

    → Es wird verifiziert, ob alle Assets und Controls gruppiert sind und ob alle Assetgruppen einer Person zugewiesen sind. Eine Nachricht zeigt das Ergebnis der Verifizierung an.

  7. Mit dem Erstellen der Aufgabe fortfahren oder das Erstellen abbrechen.

    Die Aufgabe zum Beseitigen von Schwachstellen heißt „Remediate Vulnerabilities“.

18.2.1.3 Schwachstellen beseitigen

Die erstellten Aufgaben können mithilfe der Ansicht Aufgaben (Ansicht > Zeige View… > Aufgaben in der Menüleiste) oder des Web-Frontends der verinice.PRO-Version (unter: ISO 27000 tasks) verwaltet werden.

Eine Aufgabe enthält Controls, Scenarios und Assets, welche mit einer Kontrollgruppe verbunden und einer verantwortlichen Person zugeordnet sind. Die verantwortliche Person beseitigt die Schwachstelle für alle Assets.

Bemerkung

Falls die Deadline für die Aufgabe „Remediate Vulnerabilities“ abläuft, wird eine E-Mail mit einer Erinnerung an die verantwortliche Person gesendet.

Nachdem die Aufgabe abgeschlossen ist, werden alle Verbindungen zwischen den Assets und Scenarios, die der Aufgabe zugeordnet waren, gelöscht.

Die folgenden Zustände eines Controls sind möglich:

  • Implemented: Dem Scenario ist kein Asset mehr zugeordnet.
  • Partly: Andere Verbindungen zu den Assets sind noch vorhanden.

18.3 Nagios nutzen

Nagios kann die Scanergebnisse als zusätzlichen Test in seine Überwachungsaufgaben integrieren. Die gescannten Systeme werden automatisch den überwachten Systemen zugeordnet. Damit sind die Scanergebnisse schlussendlich für Benachrichtigungsregeln und andere Prozesse von Nagios verfügbar.

_images/nagios_integration.png

Abb. 18.8 Verbinden von Nagios mit dem GSM

Beim Verbinden von Nagios mit dem GSM übernimmt Nagios die steuernde Rolle.

Nagios erhält die neusten Scanergebnisse regelmäßig und automatisch vom GSM. Dies geschieht mithilfe eines Nagios-Befehls, der das Tool gvm-script nutzt, um das Skript check-gmp.gmp.py aufzurufen.

Bemerkung

Andere Produkte, die mit Nagios kompatibel sind, wie Open Monitoring Distribution, Icinga, Centreon etc. sollten in der Regel funktionieren, könnten allerdings kleinere Anpassungen der beschriebenen Schritte benötigen.

18.3.1 Den GSM-Benutzer konfigurieren

Für den Zugang benötigt Nagios einen Benutzer zum Einloggen in den GSM. Für diesen Benutzer muss ein Scanziel (oder mehrere Scanziele) mit allen Hosts, für die der Sicherheitsstatus überwacht werden soll, erstellt werden.

Bemerkung

Die hier genutzte Beispielkonfiguration nimmt an, dass es nur ein relevantes Ziel gibt, aber streng genommen ist es möglich, komplexe Setups mit mehreren Zielen und mehreren GSMs einzubinden.

Der GSM-Benutzeraccount, der für Abfragen vom GMP-Skript bereitgestellt wird, muss der Besitzer der relevanten Scanziele sein oder zumindest uneingeschränkten Lesezugriff auf diese haben.

Die Aufgaben sollten regelmäßig als geplante Scans laufen.

Zusätzlich muss der Netzwerkzugriff auf den GSM über GMP möglich sein. Dafür muss der GMP-Zugriff im GOS-Administrationsmenü aktiviert werden (siehe Kapitel 15.2).

18.3.2 Das Skript konfigurieren

Greenbone Networks stellt das Skript check-gmp.gmp.py als Teil der Skriptsammlung der gvm-tools bereit (siehe Kapitel 15.3). Dieses Skript kann von der Überwachungslösung mithilfe von gvm-script aufgerufen werden.

Bemerkung

Im Folgenden wird angenommen, dass Nagios unter /usr/local/nagios/, nachfolgend als /.../ bezeichnet, installiert ist.

Der Speicherort kann bei Bedarf angepasst werden.

  1. Plug-in nach /.../libexec/ kopieren.

  2. Prüfen, ob das Skript den GSM über das Netzwerk erreichen kann, GMP aktiviert wurde und der Benutzer korrekt erstellt wurde:

    Bemerkung

    Im folgenden Befehl müssen die IP-Adresse durch die IP-Adresse des GSMs ersetzt und der Benutzername und das erstellte Passwort angegeben werden.

nagios-host# gvm-script --gmp-username="user name" --gmp-password="password" \
ssh --hostname 192.168.10.169 /.../libexec/check-gmp.gmp.py --ping \
GMP OK: Ping successful
  1. Prüfen, ob auf die Daten zugegriffen werden kann:
nagios-host# gvm-script --gmp-username="user name" --gmp-password="password" \
ssh --hostname 192.168.10.169 /.../libexec/check-gmp.gmp.py \
-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

Das Skript unterstützt mehrere Befehlszeilenoptionen. Diese können wie folgt dargestellt werden:

nagios-host# gvm-script -c /.../etc/gvm-tools.conf ssh --hostname
  192.168.10.169 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. Falls die Tests erfolgreich waren, kann der Check in den Nagios-Monitor integriert werden.

    Host, der überwacht werden soll, der Nagios-Konfigurationsdatei /.../etc/objects/localhost.cfg im Abschnitt HOST DEFINITIONS hinzufügen.

    In diesem Beispiel ist der Host ein Metasploitable Linux.

define host{
     use                     linux-server
     host_name               metasploitable
     alias                   metasploitable
     address                 192.168.10.130
     }
  1. In der gleichen Konfigurationsdatei im Abschnitt SERVICE DEFINITIONS einen neuen Dienst, der den Nagios-Befehl check_gmp_status aufruft, festlegen.

    Wie das Beispiel zeigt, wird der Name der Aufgabe, von der der Bericht abgerufen wird, als Argument an den Befehl übergeben.

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. Befehl check_gmp_status in der Datei /.../etc/objects/commands.cfg erstellen.
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.py -F $HOSTADDRESS$
         --last-report -T $ARG1$ --status
    }

Bemerkung

In der Kommandozeile ist sichtbar, dass kein Benutzername- und Passwortoptionen, sondern eine Konfigurationsdatei an das Tool gvm-script übergeben wird (sie Kapitel 15.3).

  1. Zum Anwenden der neuen Konfiguration Nagios neu starten.
nagios-host# systemctl restart nagios
_images/nagios-service-status.png

Abb. 18.9 Status der überwachten Hosts in Nagios

18.3.3 Caching und Multiprocessing

Das Skript check-gmp.gmp.py überstützt Caching. Alle neuen Berichten werden in einer SQLite-Datenbank zwischengespeichert. Der erste Aufruf mit einem unbekannten Host dauert länger, da der Bericht erst vom GSM abgerufen werden muss. Darauffolgende Aufrufe holen nur dann den aktuellen Bericht vom GSM, falls sich die Endzeit vom Scan unterscheidet. Andernfalls wird die Information aus der Datenbank genutzt. Dies reduziert die Belastung auf dem überwachenden Server sowie dem GSM.

Die Cachedatei wird standardmäßig auf /tmp/check_gmp/reports.db geschrieben. Ein anderer Speicherort der Datenbank kann mithilfe der Befehlszeilenoption --cache bestimmt werden.

Um die Belastung des überwachenden Servers sowie des GSMs weiter zu reduzieren, kann das Plug-in die maximale Anzahl gleichzeitig laufender Plug-in-Instanzen beschränken. Zusätzlich gestartete Instanzen werden gestoppt und warten auf Fortsetzung. Der Standardwert von MAX_RUNNING_INSTANCES ist 10 und kann mithilfe der Befehlszeilenoption -I geändert werden.

18.4 Das Cisco Firepower Management Center nutzen

Das Cisco Firepower Management Center (früher Sourcefire Intrusion Prevention System (IPS)) ist eine der führenden Lösungen für Eindringungserkennung und -abwehr in Computernetzwerken. Als ein Network Intrusion Detection System (NIDS) sind seine Aufgaben die Erkennung von Gefährdungen, die Alarmierung und die Verteidigung gegen Angriffe auf das Netzwerk.

Um Angriffe korrekt zu identifizieren und klassifizieren, benötigt das Firepower Management Center so viele Informationen wie möglich über die Systeme im Netzwerk, die auf den Systemen installierten Anwendungen und die potentiellen Schwachstellen für beides. Zu diesem Zweck hat das Firepower Management Center seine eigene Asset-Datenbank, welche mit Informationen vom GSM erweitert werden kann. Zusätzlich kann das Firepower Management Center automatisch Scans starten, falls es einen Verdacht hat.

Die folgenden Verbindungsmethoden sind verfügbar:

Automatische Datenübertragung vom GSM zum NIDS/IPS
Falls der GSM und das NIDS/IPS entsprechend konfiguriert sind, kann die Datenübertragung vom GSM zum NIDS/IPS einfach wie jede andere Benachrichtigungsfunktion des GSMs durchgeführt werden. Nach dem Abschluss des Scans wird der Bericht als Benachrichtigung bezüglich der gewünschten Kriterien an das NIDS/IPS weitergeleitet. Falls die Scanaufgabe automatisch auf wöchentlicher Basis läuft, wird ein vollautomatisches Benachrichtigungs- und Optimierungssystem erzielt.
Aktive Steuerung des GSMs durch das NIDS/IPS
Beim Betrieb des NIDS/IPS können Verdachtsfälle auf Systemen mit hoher Gefährdung auftreten. Das NIDS/IPS kann in einem solchen Fall den GSM anweisen, das System zu überprüfen 1.

Um die Verbindungsmethoden zu nutzen, müssen sowohl der GSM als auch das Firepower Management Center vorbereitet werden. Auf dem GSM muss ein Berichtformat-Plug-in installiert werden. Im Firepower Management Center muss die Option zum Erhalt der Daten aktiviert sein.

Bemerkung

Das Berichtformat Sourcefire wird über den Feed bereitgestellt.

Berichtformate sind möglicherweise noch nicht verfügbar, werden aber zu einem späteren Zeitpunkt hinzugefügt.

Falls ein Berichtformat nicht verfügbar ist, kann der Greenbone Networks Support (support@greenbone.net) kontaktiert werden.

18.4.1 Die Clients der Host-Eingabe-API konfigurieren

Die Host-Eingabe-API ist eine Schnittstelle durch die das Firepower Management Center Daten von anderen Anwendungen für seine Asset-Datenbank akzeptiert.

  1. In das Firepower Management Center einloggen.

  2. System > Integration in der Menüleiste wählen.

  3. Register Host Input Client wählen.

  4. IP-Adresse des GSMs in das Eingabefeld Hostname eingeben (siehe Abb. 18.10).

    _images/host-input-api1.png

    Abb. 18.10 Erstellen eines Host-Eingabe-Clients

  5. Passwort in das Eingabefeld Password eingeben.

  6. Auf Save klicken.

    Bemerkung

    Die Verbindung ist TLS-verschlüsselt.

    → Das Firepower Management Center erstellt automatisch einen privaten Schlüssel und ein Zertifikat.

    Im Zertifikat wird die oben eingegebene IP-Adresse als gemeinsamer Name genutzt und verifiziert, wenn der Client eine Verbindung herstellt. Falls der Client eine andere IP-Adresse nutzt, schlägt die Verbindung fehl.

    Die erstellte PKCS#12-Datei kann optional durch ein Passwort geschützt werden.

    Anschließend werden das Zertifikat und der Schlüssel erstellt und können heruntergeladen werden.

  7. Datei durch Klicken auf sourcefire_download herunterladen (siehe Abb. 18.11).

    _images/host-input-api2.png

    Abb. 18.11 Herunterladen der erstellten PKCS#12-Datei

18.4.2 Eine Benachrichtigung durch eine Sourcefire-Schnittstelle konfigurieren

Nun muss die entsprechende Benachrichtigung auf dem GSM eingerichtet werden.

  1. Konfiguration > Benachrichtigungen in der Menüleiste wählen.

  2. Neue Benachrichtigung durch Klicken auf new erstellen.

  3. Benachrichtigung definieren (siehe Abb. 18.12).

    Tipp

    Für die Informationen, die in die Eingabefelder eingegeben werden müssen, siehe Kapitel 10.12.

  4. Sourcefire-Schnittstelle in der Drop-down-Liste Methode wählen.

    _images/alert_sourcefire-de.png

    Abb. 18.12 Erstellen einer Benachrichtigung durch eine Sourcefire-Schnittstelle

  5. PKCS#12-Datei durch Klicken auf Browse… bereitstellen.

    Bemerkung

    Falls beim Erstellen des Clients ein Passwort eingegeben wurde, muss die PKCS#12-Datei vor dem Laden in den GSM entschlüsselt werden.

    Dafür kann der folgende Befehl in Linux genutzt werden:

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

18.5 Alemba vFire nutzen

vFire ist eine Enterprise-Service-Management-Anwendung, die von Alemba entwickelt wurde.

Der GSM kann konfiguriert werden, sodass er Tickets in einer Instanz von vFire erstellt, beispielsweise basierend auf beendeten Scans.

18.5.1 Voraussetzungen für Alemba vFire

Damit die Integration korrekt funktioniert, müssen die folgenden Voraussetzungen auf dem vFire-System gegeben sein:

  • Die vFire-Installation muss die RESTful-AlembaAPI unterstützen, welche in Version 9.7 zu vFire hinzugefügt wurde. Die veraltete API älterer Versionen wird nicht von der Greenbone-Verbindung unterstützt.
  • Ein Alemba-API-Client mit dem korrekten Sitzungstyp (analyst/user) und Passwort-Login muss aktiviert sein.
  • Der Benutzeraccount, der genutzt werden soll, benötigt die Berechtigung, die Alemba-API zu nutzen.

18.5.2 Eine Benachrichtigung durch Alemba vFire konfigurieren

Damit der GSM automatisch Tickets (sogenannte „Calls“) in vFire erstellen kann, muss die Benachrichtigung wie folgt eingerichtet werden:

  1. Konfiguration > Benachrichtigungen in der Menüleiste wählen.

  2. Neue Benachrichtigung durch Klicken auf new erstellen.

  3. Benachrichtigung definieren (siehe Abb. 18.13).

    Tipp

    Für die Informationen, die in die Eingabefelder eingegeben werden müssen, siehe Kapitel 10.12.

  4. Alemba vFire in der Drop-down-Liste Methode wählen.

    _images/alert_alemba-de.png

    Abb. 18.13 Erstellen einer Benachrichtigung durch Alemba vFire

  5. Auf Speichern klicken.

Die folgenden Details der Benachrichtigung können festgelegt werden:

Berichtformate
Die für Anhänge genutzten Berichtformate. Mehrere Berichtformate können gewählt werden oder die Auswahl kann leer gelassen werden, falls keine Anhänge erwünscht sind.
Basis URL
Dies ist die URL der Alemba-Instanz, einschließlich des Servernamen und des virtellen Verzeichnisses. Falls beispielsweise über https://alemba.example.com/vfire/core.aspx auf die Benutzerschnittstelle zugegriffen wird, wäre die Basis-URL https://alemba.example.com/vfire.
Anmeldedaten
Benutzername und Passwort für das Einloggen in Alemba vFire.
Sitzungstyp

Genutzer Sitzungstyp. Dies kann entweder „analyst“ oder „user“ sein.

Als „analyst“ ist es möglich einige Aktionen durchzuführen, die als „user“ nicht verfügbar sind. Der „user“ benötigt besondere Berechtigungen für diese Aktionen und die Anzahl aufeinanderfolgender Logins könnte begrenzt sein.

Alemba-Client-ID
Dies ist die ID des Alemba-Clients (siehe Kapitel 18.5.1).
Partition
Die Partition, in der das Ticket erstellt wird. Die Alemba-vFire-Hilfe enthält weitere Informationen über die Partitionierung .
Beschreibung (Call Description)
Dies ist die Vorlage für den Beschreibungstext, der für neu erstellte Calls genutzt wird. Dieselben Platzhalter wie für das Eingabefeld der Nachricht einer E-Mail-Benachrichtigung können genutzt werden (siehe Kapitel 10.12).
Vorlage (Call Template)
Der Name der Call-Vorlage, die für durch die Benachrichtigung erstellte Calls genutzt wird. Eine Call-Vorlage kann in vFire so konfiguriert werden, dass alle Felder ausgefüllt werden, die nicht direkt in der Benachrichtigung festgelegt werden können.
Typ (Call Type)
Der Name eines Call-Typs, der für durch die Benachrichtigung erstellte Calls genutzt wird.
Auswirkungen
Der vollständige Name eines Auswirkungswerts.
Dringlichkeit
Der vollständige Name eines Dringlichkeitswerts.

18.6 Splunk nutzen

Der GSM so konfiguriert werden, dass er die Scanergebnisse für die weitere Untersuchung und Zuordnung an eine Splunk-Enterprise-Installation weiterleitet.

Die Verbindung eines GSM mit einer Splunk-Lösung ist nicht Teil der GSM-Kernfunktionalität. Als Add-On stellt Greenbone Networks eine App für die Integration mit On-Premise-Lösungen von Splunk Enterprise zur Verfügung. Die App ist derzeit unter https://download.greenbone.net/tools/Greenbone-Splunk-App-1.0.1.tar.gz verfügbar.

Wichtig

Externe Links zur Greenbone-Downloadseite unterscheiden Groß- und Kleinbuchstaben.

Großbuchstaben, Kleinbuchstaben und Sonderzeichen müssen exakt so, wie sie in den Fußnoten stehen, eingegeben werden.

Bemerkung

Falls es Probleme beim Herunterladen oder Testen der App gibt, kann der Greenbone Networks Support kontaktiert werden.

Im Folgenden wird Splunk Enterprise Version 8.5 genutzt. Die Installation der App auf Splunk Light wird nicht unterstützt. Das Verbinden eines GSM mit Splunk Cloud wird nicht unterstützt.

18.6.1 Die Greenbone-Splunk-App einrichten

18.6.1.1 Die App installieren

Die Greenbone-Splunk-App kann wie folgt installiert werden:

  1. Splunk Enterprise öffnen.
  2. Im linken Menüpanel auf splunk_apps klicken (siehe Abb. 18.14).
_images/splunk1.png

Abb. 18.14 Installieren der Greenbone-Splunk-App

  1. Auf Install app from file klicken.
  2. Auf Browse… klicken.
  3. TAR-Datei der Greenbone-Splunk-App wählen.
  4. Auf Upload klicken.

18.6.1.2 Die Greenbone-Splunk-App konfigurieren

Der Port der Greenbone-Splunk-App wird für die Konfiguration auf dem GSM benötigt.

Port der Greenbone-Splunk-App wie folgt überprüfen:

  1. Greenbone-Splunk-App im linken Menüpanel wählen.
  2. Settings > Data inputs in der Menüleiste wählen.
  3. Auf TCP klicken (siehe Abb. 18.15).

Bemerkung

Die Greenbone-Splunk-App richtet einen Dateneingang auf Port 7680/tcp (Standardport) ein und kennzeichnet die eingehenden Daten als Greenbone Scan Results und ordnet sie in den Index default ein.

_images/splunk4.png

Abb. 18.15 Prüfen des Ports der Greenbone-Splunk-App

Um die Daten benutzerfreundlicher machen, können die Feldnamen wie folgt ersetzt werden:

  1. Im linken Menüpanel auf splunk_apps klicken.

  2. In der Zeile von Greenbone auf View objects klicken.

  3. Auf Greenbone Scan Results: FIELDALIAS-reportfields klicken.

  4. Feldnamen-Alias in die entsprechenden Eingabefelder eingeben (siehe Abb. 18.16).

    _images/splunk5.png

    Abb. 18.16 Ändern der Feldnamen-Alias

18.6.2 Eine Benachrichtigung durch Splunk konfigurieren

Das GSM überträgt die Scanergebnisse in Form eines XML-Berichts über eine Benachrichtigung direkt an den Splunk-Hauptserver.

Bemerkung

Das Dashboard der Greenbone-Splunk-App zeigt nur Ergebnisse von Berichten an, die weniger als 7 Tage alt sind.

Falls ein Bericht gesendet wird, der älter als 7 Tage ist, zeigt das Dashboard die Ergebnisse nicht an. Die Ergebnisse befinden sich jedoch im Hauptindex des Splunk-Servers.

18.6.2.1 Die Splunk-Benachrichtigung erstellen

Die Benachrichtigung kann wie folgt erstellt werden:

  1. Konfiguration > Benachrichtigungen in der Menüleiste wählen.

  2. Neue Benachrichtigung durch Klicken auf new erstellen.

  3. Benachrichtigung definieren (siehe Abb. 18.17).

    Tipp

    Für die Informationen, die in die Eingabefelder eingegeben werden müssen, siehe Kapitel 10.12.

  4. Sende an Host in der Drop-down-Liste Methode wählen.

  5. IP-Adresse des Splunk-Servers in das Eingabefeld Sende an Host und 7680 in das Eingabefeld auf Port eingeben.

    Bemerkung

    Der TCP-Port ist standardmäßig 7680.

    Die Einstellung kann in der Greenbone-Splunk-App, wie in Kapitel 18.6.1.2 beschrieben, geprüft werden.

  6. XML in der Drop-down-Liste Bericht wählen.

    _images/alert_splunk-de.png

    Abb. 18.17 Konfiguration der Benachrichtigung durch Splunk

  7. Auf Speichern klicken.

18.6.2.2 Die Splunk-Benachrichtigung zu einer Aufgabe hinzufügen

Die Benachrichtigung kann nun beim Erstellen einer neuen Aufgabe gewählt (siehe Kapitel 10.2.2) oder zu einer bestehenden Aufgabe hinzugefügt (siehe Kapitel 10.12.2) werden.

18.6.2.3 Die Splunk-Benachrichtigung testen

Zu Testzwecken können Berichte von der Benachrichtung verarbeitet werden.

  1. Scans > Berichte in der Menüleiste wählen.

  2. Auf das Datum eines Berichts klicken.

  3. Auf start klicken.

  4. Benachrichtigung in der Drop-down-Liste Benachrichtigung wählen (siehe Abb. 18.18).

    _images/alert_report_splunk-de.png

    Abb. 18.18 Auslösen der Benachrichtigung

  5. Auf OK klicken.

18.6.3 Die Greenbone-Splunk-App nutzen

18.6.3.1 Auf die Informationen in Splunk zugreifen

Um in Splunk auf die Informationen zuzugreifen, kann das Greenbone-Dashboard wie folgt geöffnet werden:

  1. Splunk Enterprise öffnen.

  2. Greenbone-Splunk-App im linken Menüpanel wählen.

  3. Dashboards in der Menüleiste wählen.

  4. Auf Greenbone Dashboard klicken.

    Bemerkung

    Das Dashboard der Greenbone-Splunk-App zeigt nur Ergebnisse von Berichten an, die weniger als 7 Tage alt sind.

    Falls ein Bericht gesendet wird, der älter als 7 Tage ist, zeigt das Dashboard die Ergebnisse nicht an. Die Ergebnisse befinden sich jedoch im Hauptindex des Splunk-Servers.

_images/splunk7.png

Abb. 18.19 Greenbone-Dashboard in der Greenbone-Splunk-App

Das Eingabefeld CVE-ID unterhalb des Dashboards kann verwendet werden, um die Anzahl der von einer bestimmten CVE betroffenen Hosts im Laufe der Zeit anzuzeigen.

Bemerkung

Falls das Eingabefeld leer gelassen und Enter gedrückt wird, wird die Anzahl der von allen CVEs betroffenen Hosts angezeigt.

18.6.3.3 Ein Dashboard für die 5 am stärksten betroffenen Hosts und für eingehende Berichte erstellen

Es kann ein neues Dashboard erstellt werden, das die 5 am stärksten betroffenen Hosts aller Zeiten und die eingehenden Berichte vom GSM anzeigt. Das Dashboard zeigt für das vergangene Jahr jeden Zeitpunkt an, zu dem ein neuer Bericht auf dem Splunk-Server einging.

  1. Splunk Enterprise öffnen.

  2. Greenbone-Splunk-App im linken Menüpanel wählen.

  3. Dashboards in der Menüleiste wählen.

  4. Auf Create New Dashboard klicken.

  5. Einen Titel in das Eingabefeld Title eingeben, z. B. Greenbone incoming stats.

  6. Auf Create Dashboard klicken.

  7. Auf Source klicken.

  8. Das Folgende kopieren und in das Eingabefeld einfügen (ersetzt alles):

    <dashboard>
      <label>Greenbone incoming stats</label>
      <row>
            <panel>
              <title>Top 5 all time</title>
              <chart>
                    <search>
                      <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>
                      <earliest>0</earliest>
                      <latest></latest>
                    </search>
                    <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>
              </chart>
            </panel>
      </row>
      <row>
            <panel>
              <chart>
                    <title>Incoming feed to Greenbone App</title>
                    <search>
                      <query>| tstats count where sourcetype = "Greenbone Scan Results" by sourcetype _time | timechart span=1d count by  sourcetype</query>
                      <earliest>@y</earliest>
                      <latest>now</latest>
                    </search>
                    <option name="charting.chart">line</option>
                    <option name="refresh.display">progressbar</option>
              </chart>
            </panel>
      </row>
    </dashboard>
    
  9. Auf Save klicken.

    _images/splunk9.png

    Abb. 18.21 Dashboard für die 5 am stärksten betroffenen Hosts und für eingehende Berichte

Fußnoten

[1]Diese Steuerung existiert nicht als fertige Remediation für das Firepower Management Center, aber kann mithilfe von GMP implementiert werden (siehe Kapitel 15).