Brand ClaimErleben, was verbindet
Hinweis zur Verwendung von Cookies

Diese Website verwendet ausschließlich nur die technisch erforderlichen Cookies, um Ihnen den bestmöglichen Service zu gewährleisten.
Ihre Sitzung wird durch ein sogenanntes Session-Cookie identifiziert, damit Ihre Spracheinstellung bestehen bleibt und damit Formulare komfortabel genutzt werden können. Weiterhin ist eine Anmeldung nur unter Verwendung eines Cookies möglich.
Weitere Informationen finden Sie in den Datenschutzhinweisen.Zustimmen

Häufig gestellte Fragen

Wie kommen Ihre CVSS Bewertungen zustande? Warum weichen diese manchmal von den Herstellerangaben oder der CVE-Datenbank ab?

CVSS stellt im Wesentlichen die Eigenschaften von Schwachstellen in einem automatisiert auswertbaren Format dar. Unser System ist in der Lage, CVSS anhand der erfassten Schwachstelleneigenschaften zu generieren.

Wenn zum Zeitpunkt der Meldungserfassung bereits ein CVSS Vektor bekannt ist, übernehmen wir diesen in der Regel, prüfen aber dennoch, ob die Angaben zum Text der Quelle passen, da die Hersteller in Einzelfällen den Vektor zugunsten einer geringeren Kritikalität definieren. Wir achten darauf, dass die Angaben im CVSS konsistent zu den Texten sind.

Es gibt Fälle, wo es für eine Schwachstelle bereits in den Quellen unterschiedliche Vektoren gibt. Wir übernehmen in solchen Fällen nach unserem "Worst Case Prinzip" zunächst den Vektor mit der höheren Kritikalität, prüfen diesen jedoch bei der Meldungserstellung.

Die CVSS Angaben können daher durchaus von der offiziellen CVE Datenbank abweichen. Einen nachträglichen Abgleich führen wir nicht durch. Eine Korrektur in Einzelfällen ist möglich und wird bei Bedarf durchgeführt.

Wie kommen Ihre Bewertungen für Angriffswahrscheinlichkeit und Schadenshöhe zustande?

Wir haben ein seit 1999 bestehendes, eigenes Schema (nachfolgend "VAS Schema"). Dieses wurde über die Jahre immer wieder den Gegebenheiten angepasst. Eine Bewertung besteht aus den Komponenten Angriffswahrscheinlichkeit und potenzieller Schadenshöhe. Beide Komponenten werden auf einer Skala von 1 (gering) bis 5 (hoch) bewertet. Die nachfolgenden Tabellen zeigen auf, wie die Bewertung aufgebaut ist.

Angriffswahrscheinlichkeit

Angriff Grundwert   Anpassung
entfernt anonym 4 Exploit/Proof-of-Concept-Code / detailliert beschrieben / verfügbar, auch wenn Exploit nicht "sichtbar" ist, d. h. eine verlässliche Quelle von Ausnutzung redet +1
Nutzeraktion trivial (bestimmungsgemäß, 1-Klick (Mail etc.) -1
Nutzeraktion komplex /administrativer User -2
keine Info -1
Begr. Reichweite (nicht routbar / Lan / Wlan) -1
entfernt unbekannt 3 Exploit/Proof-of-Concept-Code / detailiert beschrieben / verfügbar, auch wenn Exploit nicht "sichtbar" ist, d. h. eine verlässliche Quelle von Ausnutzung redet +1
Nutzeraktion trivial (bestimmungsgemäß, 1-Klick (Mail etc.) -1
Nutzeraktion komplex /administrativer User -2
keine Info (Patch reverse engeneering) -1
Begr. Reichweite (nicht routbar / Lan / Wlan) -1
entfernt authentisiert
Anmeldung über Netzwerkzugriff
(Authentisiert für Anwendung)
z. B. Oracle Account
2 Exploit/Proof-of-Concept-Code / detailiert beschrieben / verfügbar, auch wenn Exploit nicht "sichtbar" ist, d. h. eine verlässliche Quelle von Ausnutzung redet +1
Nutzeraktion trivial (bestimmungsgemäß, 1-Klick (Mail etc.) -1
Nutzeraktion komplex / administrativer User -2
keine Info -1
Begr. Reichweite (nicht routbar / Lan / Wlan) -1
lokal
(Shell / Betriebssystemaccount )
schließt SSH, Telnet ein
2 Exploit/Proof-of-Concept-Code / detailiert beschrieben / verfügbar, auch wenn Exploit nicht "sichtbar" ist, d. h. eine verlässliche Quelle von Ausnutzung redet +1
keine Info -1
Nutzeraktion -1
privilegierter Account nötig -1
physisch 1 Exploit/Proof-of-Concept-Code / detailiert beschrieben / verfügbar, auch wenn Exploit nicht "sichtbar" ist, d. h. eine verlässliche Quelle von Ausnutzung redet +1

Schadenshöhe

Ziel Grundwert   Anpassung
Admin / System 5    
User / Anwendung 4 extrem eingeschränkt (bsp. in virt. Umgebung) -1
DoS 3 Client Anwendung: Word, Excel, Browser, singuläre Anwendung -1
Kritisches System (Netzinfrastruktur,AAA. IOS, Betriebssystem Windows SERVER und Unix generisch) +1
Server Anwendungen (Bsp.Apache Server) 0
Zugriff auf Daten / Manipulation 2 SQL Injection +2
Systemauthentisierung +2
schreibender Zugriff (CSRF oder XSS + Meta:Benutzeraktion)
Zugriff auf Anwendungsauthentisierung
+1
Infogewinn/Unwichtige Daten -1
Umgehung 3 Sicherheitskomponente (Firewall) +1
auch bei AntiVirus 0
Kryptographie +2

Mir ist aufgefallen, dass Ihre CVSS Vektoren von der Bewertung nach VAS Schema immer mal wieder stark abweichen. Wie kommt es dazu?

Unser VAS Schema kennt 5x5 verschiedene Abstufungen (bzw. letztendlich 5 Risikostufen), CVSS dagegen kennt durch die Nachkommastelle 100 verschiedene Scores. Unser Schema ist einfach erklärbar und auf max. zwei A4 Seiten nachvollziehbar. Hinter CVSS steckt komplexe Mathematik.

Weiterhin gibt es unterschiedliche Gewichtungen einzelner Schwachstelleneigenschaften. Beispiele:

Ihr Advisory gibt eine CVSS Bewertung mit lokalem Angreifer an, in der Beschreibung jedoch die Rede von einem "entfernten Angreifer" - wie passt das zusammen?

Der Begriff "entfernter Angreifer" in unseren Advisories bezeichnet den Standort des Angreifers. Die Metrik "AV" im CVSS v3.1 Vektor gibt wiederum an, über welche Schnittstelle (remote/lokal) der Angriff erfolgt. Der Angriff selbst wird in diesem Fall lokal ausgeführt.
 
Wenn CVSS beispielsweise angibt, dass der Angriffsvektor lokal (AV:L) ist und eine Benutzerinteraktion erfordert (UI:R), beschreibt dies in der Regel einen Angriff, bei dem das Opfer z. B. durch Social Engineering dazu gebracht wird, eine speziell gestaltete Datei zu öffnen, was zu einem lokalen Angriff auf den Computer führt.
 
In diesem Punkt unterscheiden sich CVSS v2 und v3.1 - während Version 2 den Standort des Angreifers nennt, bezieht sich Version 3.1 auf die Schnittstelle, die für den Angriff genutzt wird.
 

Was ist CVE? Wie steht CVE im Zusammenhang mit Ihren Advisory-Nummern?

Die CVE Nummer identifiziert eine Schwachstelle weltweit eindeutig (CVE = Common Vulnerability Enumeration), diese kann aber in mehreren Produkten auftreten. Umgekehrt werden oft mehrere CVE in einer Meldung zu einem bestimmten Produkt zusammengefasst.

Jede Meldung kann daher beliebig viele CVE enthalten, eine CVE kann aber auch in mehreren Meldungen genannt sein (z.B. Android hat oft CVE Nummern, die wir bereits in Linux Kernel, libxml usw. gemeldet hatten, da diese Komponenten und deren Schwachstellen wiederum Bestandteil von Android sind).

Gibt es Ihre Advisories auch in einem maschinenlesbaren Format?

Ja. Wir geben alle Advisories auch in einem XML Format heraus, das sich am "Common Vulnerability Reporting Framework" (CVRF) orientiert. Dieses können Sie wahlweise über unseren Webserver herunterladen oder als tägliche E-Mail erhalten.

Kunden können mittels ihres Logins folgende URLs benutzen, um CVRF herunter zu laden:

https://www.dcert.de/customer/cvrf_v2/index.txt => Index mit Dateinamen für Einzel-Download

https://www.dcert.de/customer/cvrf_v2/cvrf2_YYYY-MM-DD.zip => Alle Meldungen von Tag YYYY-MM-DD in einer ZIP-Datei