9 Glossar#

Dieser Abschnitt definiert relevante Begriffe die immer wieder im gesamten System verwendet werden.

9.1 CERT-Bund-Advisory#

Der CERT-Bund, das Computer Emergency Response Team des Bundesamts für Sicherheit in der Informationstechnik (BSI), ist ein zentraler Kontaktpunkt für vorbeugende und reaktionsfähige Maßnahmen, die sicherheitsbezogene Computervorfälle betreffen.

Mit der Intention, Schäden zu vermeiden und potentielle Verluste einzugrenzen, umfasst die Arbeit des CERT-Bunds das Folgende:

Erstellen und Veröffentlichen von Empfehlungen für vorbeugende Maßnahmen
Aufzeigen von Schwachstellen in Hardware- und Softwareprodukten
Vorschlagen von Maßnahmen, die bekannte Schwachstellen behandeln
Unterstützen von Einrichtungen des öffentlichen Rechts beim Reagieren auf IT-Sicherheitsvorfälle
Vorschlagen unterschiedlicher Schadensminderungsmaßnahmen

Zusätzlich betreibt CERT-Bund das Nationale IT-Lagezentrum.

Die Dienste des CERT-Bunds sind hauptsächlich für Bundesbehörden verfügbar und beinhalten das Folgende:

24-Stunden-Rufbereitschaft in Zusammenarbeit mit dem IT Situation Centre
Analyse eingehender Vorfallberichte
Erstellen von Empfehlungen, die von Vorfällen abgeleitet wurden
Unterstützung von Bundesbehörden während IT-Sicherheitsvorfällen
Betreiben eines Warn- und Informationsdiensts
Aktives Benachrichtigen der Bundesverwaltung im Falle drohender Gefahr

CERT-Bund bietet einen Warn- und Informationsdienst (WID) an. Momentan stellt dieser Dienst die CERT-Bund-Advisories bereit. Dieser Informationsdienst ist nur für Bundesbehörden als nichtöffentliche Liste verfügbar. Die Advisories beschreiben aktuelle Informationen über sicherheitskritische Vorfälle in Computersystemen und detaillierte Maßnahmen zum Beseitigen von Sicherheitsrisiken.

9.2 CPE#

Die Common Platform Enumeration (CPE) ist CVE nachempfunden. Sie ist gegliedertes Benennungsschema für Anwendungen, Betriebssysteme und Hardwaredevices.

CPE wurde von MITRE eingeführt und wird von NIST als Teil der National Vulnerability Database (NVD) gewartet. NIST wartet bereits seit mehreren Jahren das offizielle CPE-Wörterbuch und die CPE-Spezifikationen. CPE basiert auf der allgemeinen Syntax des Uniform Resource Identifiers (URI) und enthält ein formales Namensformat, eine Sprache zum Beschreiben komplexer Plattformen, eine Methode zum Vergleichen von Namen mit einem System und ein Beschreibungsformat, um Texte und Tests an einen Namen zu binden.

Ein CPE-Name beginnt mit „cpe:/“, gefolgt von bis zu sieben Komponenten, die durch Doppelpunkte getrennt sind (siehe Abb. 9.1):

Part („h“ für Hardware, „o“ für Betriebssystem oder „a“ für Anwendung)
Vendor
Product
Version
Update
Edition
Language

Beispiel: cpe:/o:linux:kernel:2.6.0

_images/cpe_name_structure.png — Abb. 9.1 Namensstruktur eines CPE-Namens#

CPE besteht aus den folgenden Komponenten:

Naming
Die Naming-Spezifikation beschreibt die logische Struktur von sogenannten well-formed names (WFNs), ihre Verbindung zu URIs und formatierten Zeichenketten sowie ihre Umwandlung.
Name Matching
Die Name-Matching-Spezifikation beschreibt die Methoden, um WFNs mit anderen zu vergleichen. Dies ermöglicht die Überprüfung, ob sich einige oder alle WFNs auf das gleiche Produkt beziehen.
Dictionary
Das Wörterbuch ist ein Verzeichnis von CPE-Namen und -Metadaten. Jeder Name definiert eine einzelne Klasse von IT-Produkten. Die Dictionary-Spezifikation beschreibt die Prozesse zum Nutzen des Wörterbuchs, z. B. das Suchen nach einem bestimmten Namen oder nach Einträgen, die zu einer allgemeineren Klasse gehören.
Applicability Language
Die Applicability-Language-Spezifikation beschreibt die Erstellung komplexer, logischer Ausdrücke mithilfe von WFNs. Diese Anwendbarkeitsangaben können zum Taggen von Checklisten, Richtlinien oder anderen Dokumenten und damit für die Beschreibung, für welche Produkte die Dokumente relevant sind, genutzt werden.

9.3 CVE#

In der Vergangenheit entdeckten und meldeten unterschiedliche Organisationen Schwachstellen zur gleichen Zeit und benannten diese mit unterschiedlichen Namen. Dies führte dazu, dass die gleiche Schwachstelle von mehreren Scannern unter unterschiedlichen Namen gemeldet wurde, was die Kommunikation und den Vergleich der Ergebnisse erschwerte.

Um das zu beheben, gründete MITRE das Common Vulnerabilities and Exposure (CVE) Projekt. Jeder Schwachstelle wird eine eindeutige Kennzeichnung zugeordnet, die aus dem Veröffentlichungsjahr und einer einfachen Nummer besteht. Diese Kennzeichnung dient als zentrale Referenz.

Die CVE-Datenbank von MITRE ist keine Schwachstellendatenbank. CVE wurde entwickelt, um die Schwachstellendatenbank mit anderen Systemen zu verbinden und den Vergleich von Sicherheitswerkzeugen und -diensten zu ermöglichen.

Die CVE-Datenbank enthält keine detaillierten, technischen Informationen oder Informationen bezüglich der Risiken, Auswirkungen oder Beseitigung einer Schwachstelle. Eine CVE enthält nur die Kennzeichnungsnummer mit dem Status, einer kurzen Beschreibung und Referenzen zu Berichten und Advisories.

Die National Vulnerability Database (NVD) bezieht sich auf die CVE-Datenbank und ergänzt den Inhalt mit Informationen bezüglich der Beseitigung, des Schweregrads, der möglichen Auswirkung und der betroffenen Produkte einer Schwachstelle. Greenbone bezieht sich auf die CVE-Datenbank der NVD.

9.4 CVSS#

Um die Deutung von Schwachstellen zu unterstützen, wurde das Common Vulnerability Scoring System (CVSS) entwickelt. CVSS ist ein Industriestandard zum Beschreiben des Schweregrads eines Sicherheitsrisikos in Computersystemen.

Sicherheitsrisiken werden mithilfe unterschiedlicher Kritierien bewertet und verglichen. Dies ermöglicht das Erstellen einer Prioritätenliste von Gegenmaßnahmen.

CVSS wurde von der CVSS Special Interest Group (CVSS-SIG) des Forum of Incident Response and Security Teams (FIRST) entwickelt. Die aktuelle CVSS-Scoreversion ist 3.1.

Der CVSS-Score in Version 2 unterstützt Base-Score-Metrics, Temporal-Score-Metrics und Environmental-Score-Metrics.

Base-Score-Metrics: Base-Score-Metrics prüfen die Nutzbarkeit einer Schwachstelle und ihre Auswirkung auf das Zielsystem. Zugang, Komplexität und Anforderungen der Authentifizierung werden eingestuft. Zusätzlich bewerten die Maße, ob die Vertraulichkeit, Integrität oder Verfügbarkeit gefährdet ist.
Temporal-Score-Metrics: Temporal-Score-Metrics prüfen, ob ein vollständiger Beispielcode existiert, der Anbieter einen Patch anbietet und die Schwachstelle bestätigt. Der Score ändert sich stark im Laufe der Zeit.
Environmental-Score-Metrics: Environmental-Score-Metrics beschreiben den Effekt einer Schwachstelle innerhalb einer Organisation. Sie berücksichtigen Schaden, Verteilung der Ziele, Vertraulichkeit, Integrität und Verfügbarkeit. Die Beurteilung hängt stark von der Umgebung, in der das gefährdete Produkt genutzt wird, ab.

9.5 DFN-CERT-Advisory#

Während die einzelnen VTs, CVEs, CPEs und OVAL-Definitionen vorrangig erstellt wurden, um von Computersystemen verarbeitet zu werden, veröffentlicht DFN-CERT regelmäßig neue Advisories.

DFN-CERT ist für hunderte Universitäten und Forschungsinstitute, die mit dem Deutschen Forschungsnetz (DFN) verbunden sind, verantwortlich. Zusätzlich stellt er entscheidende Sicherheitsdienste für die Regierung und die Industrie bereit.

Ein Advisory beschreibt besonders kritische Risiken, die eine schnelle Reaktion erfordern. Der DFN-CERT-Advisory-Dienst enthält die Kategorisierung, Verteilung und Bewertung von Advisorythemen durch verschiedene Softwarehersteller und -händler.

9.6 Greenbone Enterprise Feed#

Der Inhalt des Greenbone Enterprise Feeds, der die Schwachstellentests (VTs) zum Scannen bereitstellt, kann in Greenbones SecInfo-Portal eingesehen werden.

9.7 Host#

Ein Host ist ein einzelnes System, das mit einem Computernetzwerk verbunden ist und gescannt werden kann. Ein oder mehrere Hosts bilden die Basis eines Scanziels.

Hosts in Scanzielen und Scanberichten können mithilfe ihrer Netzwerkadresse, entweder eine IP-Adresse oder ein Hostname, identifiziert werden.

9.8 Vulnerability Test (VT)#

Ein Vulnerability Test (VT) ist eine Routine, die ein Zielsystem auf das Vorhandensein von konkreten bekannten und potentiellen Sicherheitsproblemen untersucht. VTs enthalten Informationen über das Entwicklungsdatum, die betroffenen Systeme, die Auswirkungen von Schwachstellen und die Beseitigung.

9.9 OVAL-Definition#

Die Open Vulnerability and Assessment Language (OVAL) ist ein Projekt von MITRE und wird vom Centre of Internet Security (CIS) gepflegt.

OVAL ist eine Sprache zum Beschreiben von Schwachstellen, Konfigurationseinstellungen (Compliance), Patches und Anwendungen (Bestand).

Die XML-basierten Definitionen erlauben die einfache Verarbeitung durch automatisierte Systeme und beschreiben die Erkennung einzelner Systeme und Schwachstellen.

9.10 Portliste#

Eine Portliste ist eine Liste von Ports. Jedes Ziel wird mit einer Portliste verbunden. Diese bestimmt, welche Ports während eines Scans des Ziel untersucht werden.

9.11 Qualität der Erkennung (QdE)#

Die Qualität der Erkennung (QdE) ist ein Wert zwischen 0 % und 100 % und beschreibt die Zuverlässigkeit der ausgeführten Schwachstellen- oder Produkterkennung.

Obwohl der QdE-Bereich es erlaubt, die Qualität detailgenau darzustellen, nutzen die meisten Prüfroutinen eine Standardvorgehensweise. Deshalb werden den QdE-Werten QdE-Typen zugewiesen. Die aktuelle Typenliste wird möglicherweise mit der Zeit erweitert.

QdE in %	QoD-Typ	Beschreibung
100	exploit	Die Erkennung erfolgte durch die Ausnutzung einer Sicherheitslücke und ist daher vollständig bestätigt.
99	remote_vul	Aktive Prüfung auf dem Zielsystem (Codeausführung, Traversal-Angriff, SQL-Einschleusung etc.), bei welcher die Antwort eindeutig das Vorhandensein der Schwachstelle zeigt.
98	remote_app	Aktive Prüfung auf dem Zielsystem (Codeausführung, Traversal-Angriff, SQL-Einschleusung etc.), bei welcher die Antwort eindeutig das Vorhandensein der gefährdeten Anwendung zeigt.
97	package	Authentifizierte paketbasierte Prüfungen für Linux(oide) Systeme.
97	registry	Authentifizierte Prüfungen auf Basis der Registry von Microsoft Windows.
95	remote_active	Aktive Prüfung auf dem Zielsystem (Codeausführung, Traversal-Angriff, SQL-Einschleusung etc.), bei welcher die Antwort das wahrscheinliche Vorhandensein der gefährdeten Anwendung oder der Schwachstelle zeigt. „Wahrscheinlich“ bedeutet, dass die Erkennung nur in seltenen Fällen inkorrekt ist.
80	remote_banner	Prüfung von Anwendungsbannern auf dem Zielsystem, die den Patch-Status als Information anbieten. Zum Beispiel ist dies für viele proprietäre Produkte der Fall.
80	executable_version	Authentifizierte Versionsprüfung über eine ausführbare Datei für Linux(oide) und Microsoft Windows Systeme, bei denen Anwendungen den Patch-Status in der Version anbieten.
75		Während der Systemmigration wurde dieser Wert jedem Ergebnis zugeordnet, das vor der Einführung von QdE gewonnen wurde. Trotzdem haben einige VTs möglicherweise aus anderem Grund diesen Wert.
70	remote_analysis	Prüfung auf dem Zielsystem, bei welcher Analysen durchführt werden, die nicht vollständig zuverlässig sind.
50	remote_probe	Prüfung auf dem Zielsystem, bei welcher zwischenliegende Systeme wie Firewalls die korrekte Erkennung vortäuschen können, sodass nicht eindeutig ist, ob die Anwendung selbst geantwortet hat. Zum Beispiel kann dies für Verbindungen ohne TLS geschehen.
30	remote_banner_unreliable	Prüfung von Anwendungsbannern des Zielsystems, die den Patch-Status nicht als Information anbieten. Zum Beispiel ist dies für viele Open-Source-Produkte aufgrund von Backport-Patches der Fall.
30	executable_version_unreliable	Authentifizierte Versionsprüfung über eine ausführbare Datei für Linux(oide) Systeme, bei denen Anwendungen den Patch-Status nicht in der Version anbieten.
1	general_note	Allgemeine Notiz zu einer potentiellen Schwachstelle ohne konkrete Erkennung einer vorhandenen Anwendung.

9.12 Bericht#

Ein Bericht ist das Ergebnis eines Scans und enthält eine Zusammenfassung dessen, was die ausgewählten VTs für jeden der Zielhosts erkannt haben.

Ein Bericht ist immer mit einer Aufgabe verknüpft. Die Scan-Konfiguration, die den Umfang des Berichts festlegt, ist Teil der verknüpften Aufgabe und kann nicht verändert werden. Daher ist für jeden Bericht sichergestellt, dass die ausführende Konfiguration erhalten bleibt und verfügbar ist.

9.13 Ergebnis#

Ein einzelnes Ergebnis, das vom Scanner als Teil des Berichts erzeugt wurde, z. B. eine Schwachstellenwarnung oder eine Log-Nachricht.

9.14 Scan#

Ein Scan ist eine Aufgabe, die ausgeführt wird. Für jede Aufgabe kann jeweils nur ein Scan aktiv sein. Das Ergebnis ist ein Scanbericht.

Die Status aller aktiven Scans sind auf der Seite Scanverwaltung sichtbar.

Wenn ein Scan ausgeführt wird, wird der Fortschritt als Prozentangabe der Gesamtanzahl aller auszuführenden Tests angezeigt. Die Dauer eines Scans wird aus der Anzahl von Zielen und der Komplexität der Scan-Konfiguration bestimmt und reicht von wenigen Minuten bis zu einigen Stunden oder sogar Tagen.

Die Seite Scanverwaltung bietet die Möglichkeit, einen Scan zu stoppen.

9.15 Scanner#

Ein Scanner ist ein OpenVAS-Scanner-Daemon oder ein kompatibler OSP-Daemon, auf dem der Scan läuft.

9.16 Scan-Konfiguration#

Eine Scan-Konfiguration deckt die Auswahl an VTs sowie genereller und spezieller Parameter für den Scanserver und für einige der VTs ab.

Die Scan-Konfiguration beinhaltet nicht die Auswahl der Ziele.

9.17 Zeitplan#

Ein Zeitplan legt fest, zu welcher Zeit eine Aufgabe automatisch starten soll, nach welcher Zeitspanne die Aufgabe automatisch wiederholt werden soll und welche maximale Laufzeit eine Aufgaben haben darf.

9.18 Schweregrad#

Der Schweregrad ist ein Wert zwischen 0.0 (kein Schweregrad) und 10.0 (höchster Schweregrad) und zeigt auch die Schweregradklasse (Log, Niedrig, Mittel oder Kritisch).

Dieses Konzept basiert auf CVSS, aber wird auch in Fällen angewendet, in denen kein vollständiger CVSS-Basisvektor verfügbar ist. Beispielsweise werden beliebige Werte in diesem Bereich für Übersteuerungen angewendet und von OSP-Scannern genutzt, ohne dass es eine Vektordefinition gibt.

Der Vergleich, die Gewichtung und die Priorisierung aller Scanergebnisse oder VTs ist möglich, da das Schwachstellenkonzepts konsequent über das ganze System hinweg angewendet wird. Jedem neuen VT wird ein vollständiger CVSS-Vektor zugewiesen, selbst wenn CVE keinen zur Verfügung stellt und jedem Ergebnis von OSP-Scannern wird ein entsprechender Schweregrad zugeordnet, selbst wenn der Scanner ein anderes Schweregradschema nutzt.

Die Schweregradklassen Log, Niedrig, Mittel und Kritisch werden als Unterbereiche des Hauptbereichs 0.0 – 10.0 definiert.

Scanergebnissen, die gefunden werden, wird ein Schweregrad zugewiesen. Der Schweregrad des zugehörigen VTs ändert sich möglicherweise mit der Zeit.

9.19 Lösungstyp#

Diese Information zeigt mögliche Lösungen für die Beseitigung einer Schwachstelle.

Temporäre Lösung: Eine Problemumgehung (Informationen über Konfigurationen oder bestimmte Einsatzszenarien, die die Belastung durch die Schwachstelle vermeiden) ist verfügbar, um die Schwachstelle temporär zu beseitigen. Es können keine, eine oder mehrere Problemumgehungen verfügbar sein. Dies ist normalerweise die „erste Verteidigungslinie“ gegen neue Schwachstellen, bevor eine Risikominderung oder offizielle Lösung entdeckt oder ausgegeben wurde.
Risikominderung: Es sind Informationen über Konfigurationen oder Einsatzszenarien verfügbar, die das Risiko der Schwachstelle reduzieren, was die Schwachstelle auf dem betroffenden Produkt allerdings nicht entfernt.
Offizielle Lösung: Eine offizielle Herstellerlösung ist verfügbar. Sofern nicht anders vermerkt, wird angenommen, dass die Lösung die Schwachstelle komplett beseitigt.
Lösung wird gesucht: Es ist momentan keine Lösung verfügbar, um die Schwachstelle zu beseitigen, möglicherweise gibt es aber zukünftig eine.
Keine Lösung verfügbar: Es gibt keine Lösung für die Schwachstelle und es wird auch zukünftig keine geben. Dies ist oft der Fall, wenn ein Produkt verwaist ist, nicht länger gewartet wird oder andersweitig überholt ist.

9.20 Ziel#

Ein Ziel definiert ein Set aus Systemen (Hosts), das gescannt wird. Die Systeme werden entweder durch ihre IP-Adresse, durch ihre Hostnamen oder mithilfe einer CIDR-Netzwerkschreibweise gekennzeichnet.

9.21 Aufgabe#

Eine Aufgabe wird zunächst duch ein Ziel und eine Scan-Konfiguration gebildet. Das Ausführen der Aufgabe leitet den Scan ein. Jeder Scan erzeugt einen Bericht. Als Ergebnis sammelt eine Aufgabe eine Reihe von Berichten.

Das Ziel und die Scan-Konfiguration einer Aufgabe sind statisch. Deshalb beschreibt eine Folge von Berichten die Änderung des Sicherheitsstatus mit der Zeit.