Wie wir bereits im Beitrag über den CVSS-Basescore ausgeführt haben, wird bei der Schwachstellenbewertung oft nur auf CVSS und dort auch nur auf den Base-Score geschaut. Das Ergebnis ist dann eine Kategorisierung der Schwachstellen in die Kritikalitäten (oder Severities) Critical, High, Medium und Low. Schwupps, schon ist meine Priorisierung fertig. Oder nicht?
Man braucht nicht lange zu überlegen, um zu sehen, dass dieser Ansatz viel zu kurz greift. Bei der Remote-Code-Execution-Lücke mit einem CVSS-Basescore von 10.0 sollte ich bei meinem Webserver ganz fix prüfen, ob ich betroffen bin und die Lücke schließen (und ggf. auch prüfen, ob es erfolgreiche Exploit-Versuche gab…). Die gleiche Schwachstelle, auf einem Server, der ganz ohne Netzwerkanbindung oder stark isoliert in einer Kammer steht, kann ich dahingegen sehr viel entspannter angehen.
Doch was sind denn nun Faktoren, mit denen man wirklich einschätzen kann, wie kritisch eine Schwachstelle ist?
Wie so oft: Es gibt keine einfache Antwort bzw. es kommt darauf an!
Einfache Antworten gibt es natürlich (oder leider) nicht. Jede Organisation muss hier ihren eigenen Weg und eigene Faktoren finden.
Trotzdem wollen wir ein paar Vorschläge machen.
Bin ich überhaupt betroffen?
Die Frage klingt trivial, steht aber nicht ohne Grund am Anfang. Gerade bei Schwachstellen mit hoher Medienaufmerksamkeit folgen häufig Fragen aus dem Management, von Kollegen oder Kunden, ob man denn von der Schwachstelle betroffen ist.
Stefan Pfeil
TemptoSec
Am Beginn jeder Schwachstellenbewertung sollten die Fragen stehen: Welche Assets und Software habe ich? Nur dann kann ich die Frage beantworten: Bin ich überhaupt betroffen?
- Setze ich die entsprechende Software überhaupt ein?
- Ist nur eine bestimmte Konfiguration betroffen, die von mir gar nicht eingesetzt wird? (besonders relevant bei nicht standardmäßigen Konfigurationen)
- Habe ich bereits im Vorfeld bzw. bei ähnlichen Schwachstellen Maßnahmen getroffen, die eine Ausnutzung der Schwachstelle von vorneherein unmöglich machen? (z.B. ein Reverse Proxy, der einen ungültigen Request bereits herausfiltern würde)
Um hier rasch einen Überblick zu behalten, ist ein gut gepflegtes Asset- und Softwareverzeichnis unabdingbar. Wenn ich mit einem Blick sehen kann, dass mein Unternehmen keine Cisco-Router einsetzt, kann mir die neue kritische Schwachstelle egal sein (es sei denn, meine Dienstleister setzen die Geräte ein…).
Faktoren für eine detaillierte Schwachstellenbewertung
Im folgenden eine Liste von Faktoren, die wir für eine Schwachstellenbewertung für relevant halten. Wir geben auch eine Modifikator von — bis +++ an, als Vorschlag, wie stark der einzelne Faktor das Bedrohungspotential verringern bzw. erhöhen könnte.
Ausnutzungsgefahr und Bedrohung (Exploitablility and Threat)
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Exploit in the Wild | +++ | Es gibt Berichte, dass der Exploit aktiv ausgenutzt wird |
| Bestehende oder zu erwartende Exploit Kampagne | +++ | Diese oder vergleichbare Schwachstellen werden bzw. wurden in der Vergangenheit von APT- oder Ransomwaregruppen in größerem Maßstab aktiv ausgenutzt (z.B. Lücken in Microsoft Exchange, log4j, Citrix Netscaler/Gateway,…) |
| Threat Intelligence | +++ | Es gibt z.B. Anzeichen, dass die Lücke von Gruppen ausgenutzt wird, die meine Branche bzw. mein Unternehmen gezielt angreifen oder andere Hinweise, die eine Ausnutzung der Schwachstelle besonders wahrscheinlich machen |
| Einfachheit der Ausnutzung (Ease of Exploit) | ++ | Wie einfach ist es für einen Angreifer, die Schwachstelle auszunutzen bzw. einen funktionieren Exploit zu entwickeln? |
| Proof-of-Concept-Exploit (PoC) | + | Ein bereits vorhandener PoC erhöht die Gefahr, eines baldigen Ausnutzen der Schwachstelle |
Möglicher Schaden
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Kritische Infrastruktur betroffen | +++ | Die Schwachstelle betrifft Systeme, die durch das IT-Sicherheitsgesetz 2.0 oder andere Gesetzgebung als kritische Infrastruktur eingestuft sind. |
| Risiko eines Abflusses/Leaks wichtiger Kategorien von personenbezogenen Daten | +++ | Durch erfolgreiche Ausnutzung der Schwachstelle sind besonders schützenswerte personenbezogene Daten bedroht (z.B. Gesundheitsdaten) |
| Risiko der Gefährdung einer großen Menge personenbezogener Daten | +++ | Durch erfolgreiche Ausnutzt der Schwachstelle ist eine besonders große Menge an personenbezogenen Daten gefährdet |
| Essentielle Systeme bedroht („Mission Critical Systems“) | +++ | Die Schwachstelle bedroht Systeme, deren Beeinträchtigung das gesamte Unternehmen in Mitleidenschaft ziehen würde (z.B. Domain Controller oder zentrale Produktionssysteme) |
| Kronjuwelen bedroht | ++ | Die Schwachstelle gefährdet Systeme, die das Unternehmen als Kronjuwelen definiert hat |
| SOX relevante Systeme bzw. Daten gefährdet | ++ | Die Schwachstelle betrifft Systeme, die vom Sarbanes-Oxley Act erfasst sind |
| Risiko der Gefährdung vertraulicher Daten | ++ | Durch die Schwachstelle besteht eine Gefährdung vertraulicher Daten (z.B. Unternehmensgeheimnisse) |
| Möglicher Öffentlichkeitsschaden | ++ | Eine Ausnutzung der Schwachstelle könnte einen erheblichen Publicity-Schaden zur Folge haben |
| Direkte Auswirkung auf Geräte von Kunden möglich | ++ | Die Schwachstelle bedroht die Geräte von Kunden (z.B. eine Lücke in einer Bibliothek, die in einer mobile Applikation genutzt wird) |
Zugriff/Erreichbarkeit
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Internet | +++ | Das System ist für jeden aus dem Internet zugänglich |
| Begrenzte Gruppe externer Nutzer | + | Das gefährdete System ist zwar über das Internet erreichbar, der Zugriff ist aber auf eine kleinere Gruppe externer Nutzer beschränkt (z.B. Zugriff per Firewall auf für bestimmte IPs begrenzt) |
| Größeres internes Netzwerk | + | Die Schwachstelle ist nur intern angreifbar, Zugriff haben allerdings alle bzw. ein Großteil der internen Nutzer |
| Kleineres Netzwerk/Subnetz | – | Die Schwachstelle ist nur innerhalb eines kleinen Netzwerkbereiches bzw. Subnetzes ausnutzbar |
| Management Netzwerk bzw. Port | — | Die Schwachstelle ist nur in einem beschränkten und besonders gesicherten Netzwerk ausnutzbar |
| Isolierte Systeme | — | Die Systeme sind nicht direkt erreichbar (Zugriff nur direkt bzw. über eine dedizierte Konsole möglich) |
Physischer Zugriff auf die betroffenen Systeme
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Leichter bzw. sehr wahrscheinlicher Zugang | + | Das System ist leicht zugänglich (z.B. Mitarbeiter-Laptops oder -Clients) |
Anzahl der betroffenen Systeme
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Hohe Anzahl betroffener Systeme | + | Eine hohe Anzahl von Systemen ist betroffen |
| Niedrige Anzahl betroffener Systeme | – | Eine niedrige Anzahl von Systemen ist betroffen |
Vorhandener Schutz/Mitigationen
| fAKTOR | mODIFIKATOR | kOMMENTAR |
|---|---|---|
| Guter Schutz durch vorhandene Sicherheitssysteme (z.B. Firewall, IPS, WAF) oder andere Maßnahmen | — | |
| Begrenzter Schutz durch vorhandene Sicherheitssysteme (z.B. Firewall, IPS, WAF) oder andere Maßnahmen | – |
Die Last reduzieren
Diese Kriterien bei allen Schwachstellen anzuwenden, dürfte – insbesondere bei kleineren IT-Abteilungen oder Cybersecurity-Teams und einer diversen Systemlandschaft – schwierig werden.
Wer sich bereits in der bequemen – und seltenen – Situation befindet, eine Schwachstellenmanagement-Lösung einzusetzen, die Threat-Intelligence mit (vollständigen) Asset-Daten kombiniert, ist sowieso fein raus und kann den Großteil der Arbeit der Software überlassen.
Doch auch für alle anderen gibt es Möglichkeiten die Last zu verringern. Eine Liste, der besonders wichtigen oder besonders exponierten Systeme zu erstellen, ist unabdingbar. Dann prüft man die vorhandene Software und kombiniert sie mit Daten zu Software, für die es häufig Exploit-Kampagnen gibt bzw. bei denen Exploits besonders schwerwiegende Folgen hätte. Eine Basis kann hier z.B. der Katalog der ausgenutzten Schwachstellen der US-Behörde CISA dienen.
Danach kann die Bewertung auf Schwachstellen der erstellten Liste und Hersteller-Advisories, die als besonders kritisch eingestuft werden, beschränkt werden. Um auf dem aktuellen Stand zu bleiben, empfiehlt sich der SANS Internet Security Stormcast, der werktäglich kurz über die wichtigsten Geschehnisse und Schwachstellen informiert.
Fazit
Wie praktisch überall in der Cybersecurity ist der wichtigste – und oft schwierigste Faktor die eigene Umgebung, die Systeme und die verwendete Software zu kennen. Ist dieses Wissen vorhanden, können Schwachstellen vorsortiert und die wichtigsten oder neuesten Schwachstellen genauer bewertet werden.
Ihr braucht Unterstützung beim Schwachstellenmanagement?