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:
- Unterschiedliche Gewichtung von einzelnen Sachverhalten. Beispielsweise werten wir bei der Umgehung von Sicherheitsmechanismen (Schadenshöhe = 3) eine höhere Schadenshöhe, wenn spezielle Sicherheitskomponenten umgangen (=4) oder wenn Kryptografie umgangen werden kann (=5). CVSS unterscheidet da nicht und sieht nur allgemein die Auswirkungen auf die Schutzziele "Vertraulichkeit" und "Integrität".
- Erfordernis einer Benutzeraktion: VAS wertet -1 bei der Angriffswahrscheinlichkeit; CVSS berücksichtigt dies nur in der Metrik "AC" (Access Complexity) bei CVSSv2 in der Nachkommastelle. CVSSv3 ist diesbezüglich weiter entwickelt und hat hierfür die separate Metrik "UI" (User Interaction).
- Vorhandensein eines Exploits: VAS wertet +1 bei der Angriffswahrscheinlichkeit; CVSS berücksichtigt dies nur im "Temporal Score" in der Nachkommastelle
Ihr Advisory gibt eine CVSS Bewertung mit lokalem Angreifer an, in der Beschreibung jedoch die Rede von einem "entfernten Angreifer" - wie passt das zusammen?
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