Überblick

Die OpenSSH RCE Schwachstelle, bekannt als “regreSSHion” (CVE-2024-6387), stellt eine beunruhigende Bedrohung für Millionen von Systemen weltweit dar. Diese Sicherheitslücke, die von der Qualys Threat Research Unit entdeckt wurde, ist eine Race-Condition im Signal-Handler des OpenSSH-Servers (sshd) auf glibc-basierten Linux-Systemen. Sie ermöglicht unauthentifizierte Remote-Code-Ausführung (RCE) mit Root-Rechten, was sie zu einem schwerwiegenden Problem Millionen Systeme weltweit macht.

Exkurs: glibc-basierte Linux-Systeme

“glibc” steht für die GNU C Library, die grundlegende Bibliothek für die meisten Linux-Distributionen. Sie bietet die grundlegenden Funktionen und Systemaufrufe, die für den Betrieb von Linux-Anwendungen erforderlich sind. Ein glibc-basiertes Linux-System verwendet diese Bibliothek als zentrale Komponente seines Betriebssystems. Bekannte Distributionen, die auf glibc basieren, sind unter anderem Ubuntu, Fedora, Debian und CentOS.

Was ist OpenSSH?

OpenSSH ist eine weit verbreitete Suite sicherer Netzwerkdienste, die auf dem SSH-Protokoll basieren. Sie bietet robuste Verschlüsselung, sichere Dateiübertragungen und Remote-Server-Management. OpenSSH ist ein integraler Bestandteil der Sicherheitsinfrastruktur vieler Organisationen, was Sicherheitslücken in diesem System besonders besorgniserregend macht.

Details zur OpenSSH RCE Schwachstelle CVE-2024-6387

Die regreSSHion-Sicherheitslücke resultiert aus einer Race-Condition im Signal-Handler der sshd-Komponente von OpenSSH. Wenn sich ein Client innerhalb der festgelegten LoginGraceTime (standardmäßig 120 Sekunden) nicht authentifiziert, wird der SIGALRM-Handler asynchron aufgerufen. Dieser Handler ruft verschiedene Funktionen auf, die nicht für asynchrone Signal-Kontexte sicher sind, was zu potenzieller Remote-Code-Ausführung als Root führt. Die Ausnutzung dieser Sicherheitslücke erfordert in der Regel präzises Timing und mehrere Versuche, was sie zu einer komplexen, aber potenziell sehr gefährlichen Bedrohung macht.

Exkurs: Race-Condition

Eine Race-Condition tritt auf, wenn das Ergebnis eines Prozesses von der zeitlichen Reihenfolge abhängt, in der bestimmte Ereignisse eintreten. In einem Computerkontext kann dies dazu führen, dass zwei oder mehr Prozesse auf eine Weise interagieren, die zu unerwarteten Ergebnissen führt, insbesondere wenn sie gleichzeitig auf gemeinsame Ressourcen zugreifen. Ein bekanntes Beispiel für eine Race-Condition in der IT-Sicherheit ist der TOCTOU-Angriff (Time of Check to Time of Use), bei dem ein Angreifer eine Sicherheitsprüfung zwischen der Überprüfung und der Nutzung eines Ressourcenobjekts manipuliert.

OpenSSH RCE Schwachstelle CVE-2024-6387 – CVSS Base Score und Erläuterung

Die Sicherheitslücke CVE-2024-6387 hat einen CVSS (in diesem Artikel wird CVSS erläutert – Was ist CVSS) Base Score von 8.1. Dieser Score wird durch mehrere Faktoren bestimmt, die die Schwere der Schwachstelle bewerten:

1. Angriffsvektor (AV): Netzwerk (N) – Die Schwachstelle kann über das Netzwerk ausgenutzt werden, was die Angreifbarkeit erhöht.
2. Angriffs-Komplexität (AC): Hoch (H) – Die Ausnutzung der Schwachstelle erfordert präzises Timing und mehrere Versuche, was die Komplexität erhöht.
3. Rechteerweiterung (PR): Keine (N) – Der Angreifer benötigt keine speziellen Rechte oder Berechtigungen, um die Schwachstelle auszunutzen.
4. Benutzerinteraktion (UI): Keine (N) – Die Ausnutzung erfordert keine Interaktion von einem Benutzer.
5. Auswirkungen auf Vertraulichkeit (C): Hoch (H) – Ein erfolgreicher Angriff führt zu einem vollständigen Verlust der Vertraulichkeit.
6. Auswirkungen auf Integrität (I): Hoch (H) – Ein erfolgreicher Angriff führt zu einem vollständigen Verlust der Integrität.
7. Auswirkungen auf Verfügbarkeit (A): Hoch (H) – Ein erfolgreicher Angriff führt zu einem vollständigen Verlust der Verfügbarkeit.

Erläuterung zum CVSS Base Score der OpenSSH RCE Schwachstelle CVE-2024-6387

Der CVSS Base Score von 8.1 zeigt, dass diese Schwachstelle als hochgradig schwerwiegend eingestuft wird. Obwohl die Ausnutzung der Schwachstelle aufgrund der hohen Angriffs-Komplexität (AC) nicht trivial ist, macht der Mangel an erforderlichen Rechten (PR) und Benutzerinteraktion (UI) sie zu einer attraktiven Zielscheibe für Angreifer. Die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit sind ebenfalls hoch, was bedeutet, dass ein erfolgreicher Angriff schwerwiegende Konsequenzen für das betroffene System haben kann.

Weitere Informationen bietet die National Vulnerability Database (NVD).

Betroffene Versionen

Die Sicherheitslücke betrifft OpenSSH-Versionen von 8.5p1 bis 9.7p1 sowie Versionen älter als 4.4p1, falls diese nicht für CVE-2006-5051 und CVE-2008-4109 gepatcht wurden. OpenBSD-Systeme sind aufgrund eines speziellen Sicherheitsmechanismus, der im Jahr 2001 eingeführt wurde, nicht betroffen.

Auswirkungen und Ausnutzung

Erfolgreiche Ausnutzung dieser Sicherheitslücke kann zur vollständigen Kompromittierung des Systems führen. Angreifer können Malware installieren, sensible Daten exfiltrieren und persistente Hintertüren schaffen. Forscher haben über 14 Millionen potenziell gefährdete OpenSSH-Instanzen identifiziert, die dem Internet ausgesetzt sind, mit 700.000 bestätigten Fällen laut Qualys-Daten​​​​.

OpenSSH RCE Schwachstelle – Vergleich mit anderen Schwachstellen

Während regreSSHion eine ernsthafte Bedrohung darstellt, wird sie oft mit der Log4Shell-Sicherheitslücke (CVE-2021-44228) verglichen. Log4Shell war aufgrund seiner breiteren Reichweite und einfacheren Ausnutzung weitaus kritischer. Es betraf zahlreiche Anwendungen und Dienste, die die Apache Log4j-Bibliothek verwenden, und führte zu sofortiger und weit verbreiteter bösartiger Aktivität. Im Gegensatz dazu zielt regreSSHion auf spezifische OpenSSH-Serverinstanzen auf glibc-basierten Linux-Systemen ab und erfordert komplexe Ausnutzungsversuche​​.

Indikatoren für Kompromittierungen (IOCs) – Potenzielle Anzeichen für Ausnutzung

Klare und offen kommunizierte IOCs wurden bislang nicht kommuniziert. Folgende allgemeine Indikatoren, können jedoch auf verdächtige Aktivitäten hinweisen:

• Ungewöhnliche SSH-Anmeldeversuche
  • Ein Anstieg fehlgeschlagener SSH-Anmeldeversuche, insbesondere von unbekannten IP-Adressen, könnte eine Untersuchung rechtfertigen. Sie können Exploit-Versuche für diese Schwachstelle identifizieren, indem Sie die Protokolle auf zahlreiche “Timeout vor der Authentifizierung”-Zeilen überprüfen. Beispiel Log-Eintrag:
    • sshd[132456]: fatal: Timeout before authentication for 198.51.100.23 port 41022
• Unerwartete Prozesse
  • Das Vorhandensein von nicht autorisierten oder unbekannten Prozessen, die auf dem System ausgeführt werden, insbesondere mit Root-Rechten, ist ein Warnsignal.
• Dateiänderungen
  • Ungeklärte Änderungen an Systemdateien, insbesondere an denen, die mit der SSH-Konfiguration oder Benutzerkonten verbunden sind, könnten auf Manipulationen hinweisen.

Maßnahmen zur Schadensbegrenzung

Um das Risiko der regreSSHion-Sicherheitslücke zu mindern, werden folgende Schritte empfohlen:

• OpenSSH aktualisieren – das neueste verfügbare Update (Version 9.8p1), das die Sicherheitslücke behebt, installieren.
• SSH-Zugriff beschränken – netzwerkbasierte Sicherheitsmaßahmen wie Firewalls und Netzwerksegmentierung, um laterale Bewegungen zu verhindern, benutzen. Defense in Depth!
• Konfiguration ändern – Falls sofortige Updates nicht möglich sind, den LoginGraceTime-Parameter in der sshd-Konfigurationsdatei auf 0 setzen. Achtung! Dies erhöht das Risiko von Denial-of-Service-Angriffen.

OpenSSH RCE Schwachstelle CVE-2024-6387 – Fazit

Die regreSSHion-Sicherheitslücke stellt aufgrund ihrer potenziellen Ausnutzung und der großen Anzahl betroffener Systeme eine erhebliche Bedrohung dar. Organisationen sollten sofortige Maßnahmen ergreifen, um ihre OpenSSH-Installationen zu aktualisieren und zusätzliche Sicherheitsmaßnahmen zu implementieren. Regelmäßige Überwachung der SSH-Authentifizierungsprotokolle auf Anzeichen von Ausnutzungsversuchen und die Pflege eines robusten Asset-Inventars sind entscheidend für ein effektives Schwachstellenmanagement.

Der Beitrag OpenSSH RCE Schwachstelle CVE-2024-6387 erschien zuerst auf Ilja Schlak InfoSec Blog.

Einführung

Das Common Vulnerability Scoring System (CVSS) ist ein weltweit anerkanntes Bewertungssystem zur Bestimmung der Schwere von Sicherheitslücken in Computersystemen. Es bietet eine einheitliche Methode, einen Standard, zur Bewertung und Priorisierung von Schwachstellen, die IT-Sicherheitsprofis bei der Entscheidungsfindung unterstützt. CVSS hilft dabei, die Kritikalität von Schwachstellen objektiv zu beurteilen.

Geschichte und Entwicklung

Das CVSS wurde erstmals 2005 eingeführt, um eine standardisierte Bewertungsmethode für Sicherheitslücken zu schaffen. Vor der Einführung von CVSS verwendeten verschiedene Anbieter eigene, oft inkompatible Bewertungssysteme, was verständlicherweise zu Inkonsistenzen führte. Die National Infrastructure Advisory Council (NIAC) erkannte die Notwendigkeit einer Standardisierung und wählte das Forum of Incident Response and Security Teams (FIRST) als Hüter des CVSS für zukünftige Entwicklungen.

• CVSS v1 (2005) – Die erste Version wurde von wenigen Pionieren entwickelt und hatte das Ziel, eine breite Akzeptanz in der Industrie zu erreichen. Diese Version erhielt jedoch wenig Peer-Review und viel Kritik nach ihrer Veröffentlichung.
• CVSS v2 (2007) – Über ein Dutzend Mitglieder der CVSS-SIG (Special Interest Group) arbeiteten zusammen, um die erste Version zu überarbeiten und zu verbessern. CVSS v2 bot zusätzliche Granularität und reflektierte die Vielfalt der zu dieser Zeit bekannten Schwachstellen genauer.
• CVSS v3.0 (2015) – Einführung des Konzepts des „Scope“, um die Bewertung von Schwachstellen zu ermöglichen, die in einer Softwarekomponente existieren, aber eine andere Komponente beeinflussen. Zudem wurden Begriffe aktualisiert und neue Metriken wie „Privileges Required“ hinzugefügt.
• CVSS v3.1 (2019) – Diese Version brachte Klarstellungen und Verbesserungen an Version 3.0, ohne neue Metriken oder Werte einzuführen. Zudem wurde das CVSS-Erweiterungs-Framework hinzugefügt und das Glossar der Begriffe aktualisiert.
• CVSS v4.0 (2023) – Die neueste Version bringt weitere Verfeinerungen und neue Funktionen zur besseren Anpassung an moderne Bedrohungslandschaften. Zu den Neuerungen gehören eine feinere Granularität in den Basis-Metriken, die Einführung neuer Bedrohungsmetriken und zusätzliche Anwendbarkeit für OT/ICS/IoT.

Ziele und Nutzen

Das Ziel von CVSS ist es, ein universelles Bewertungssystem zu schaffen, das in verschiedenen Organisationen und Branchen anwendbar ist. Es fördert die Transparenz und Nachvollziehbarkeit bei der Bewertung von Schwachstellen und unterstützt die Priorisierung von Maßnahmen zur Behebung. Durch die Verwendung von CVSS können Unternehmen ihre Ressourcen effizienter einsetzen und sich auf die dringendsten Bedrohungen konzentrieren.

• Transparenz
  • CVSS bietet eine einheitliche und transparente Methode zur Bewertung von Sicherheitslücken, was die Kommunikation und Zusammenarbeit zwischen verschiedenen Teams und Organisationen erleichtert.
• Priorisierung
  • Mit dem Common Vulnerability Scoring System können Schwachstellen objektiv bewertet und priorisiert werden, was es ermöglicht, die begrenzten Ressourcen auf die kritischsten Probleme zu konzentrieren.
• Standardisierung
  • Durch die Standardisierung der Bewertungsmethoden können Sicherheitsbewertungen konsistenter und vergleichbarer gemacht werden, was die Entscheidungsfindung verbessert.

Das Common Vulnerability Scoring System ist ein essenzielles Werkzeug im Arsenal eines jeden Security Experten und hilft dabei, die Sicherheitslage einer Organisation zu verstehen und gezielte Maßnahmen zur Verbesserung zu ergreifen.

Die Struktur des CVSS

Um besser verstehen, was CVSS ist, sollte man die Struktur des Common Vulnerability Scoring Systems untersuchen. Diese besteht aus drei Hauptmetriken: Basis-, Temporale- und Umweltmetriken.

Basismetriken

Die Basismetriken sind die Grundkomponenten der Common Vulnerability Scoring System-Bewertung. Sie bestehen aus folgenden Kategorien:

• Angriffsvektor (AV) beschreibt, wie ein Angreifer auf das System zugreifen kann. Ein Netzwerkangriff ist schwerwiegender als ein lokaler Angriff, da er aus der Ferne durchgeführt werden kann.
• Angriffs-Komplexität (AC) bewertet die Schwierigkeit, die Schwachstelle auszunutzen. Einfache Ausnutzung bedeutet einen höheren Score.
• Privilegien erforderlich (PR) beschreibt, welche Rechte ein Angreifer benötigt, um die Schwachstelle auszunutzen. Keine erforderlichen Privilegien resultieren in einem höheren Score.
• Benutzerinteraktion (UI) gibt an, ob die Ausnutzung der Schwachstelle Benutzerinteraktion erfordert. Wenn keine Interaktion erforderlich ist, steigt der Score.
• Vertraulichkeit (C), Integrität (I), Verfügbarkeit (A) – diese Metriken bewerten die Auswirkungen eines erfolgreichen Angriffs auf die Vertraulichkeit, Integrität und Verfügbarkeit des Systems.

Temporale Metriken

Die temporalen Metriken berücksichtigen Faktoren, die sich im Laufe der Zeit ändern können:

• Ausnutzbarkeit (E) bewertet, wie einfach es für Angreifer ist, die Schwachstelle auszunutzen.
• Reifegrad der Gegenmaßnahmen (RL) beschreibt den Verfügbarkeitsstatus von Patches oder anderen Gegenmaßnahmen.
• Vertrauenswürdigkeit des Berichts (RC) bewertet die Zuverlässigkeit der Informationen über die Schwachstelle.

Umweltmetriken

Die Umweltmetriken berücksichtigen die spezifischen Umgebungsbedingungen, unter denen die Schwachstelle existiert:

• Angepasste Vertraulichkeit (CR), Integrität (IR), Verfügbarkeit (AR): Diese Metriken passen die Grundwerte der Auswirkungen an die jeweilige Umgebung an.
• Auswirkung auf Modifikationen (MAV, MAC, MPR, MUI): Diese Metriken modifizieren die Basiswerte für die Umgebungsbedingungen.

Beispiele zur CVSS-Bewertung

Beispiel 1: Remote Code Execution (RCE) – Log4Shell (CVE-2021-44228)

Log4Shell war eine schwerwiegende Schwachstelle in der Java-basierten Logging-Bibliothek Log4j. Sie ermöglichte es Angreifern, aus der Ferne beliebigen Code auszuführen.

• AV: Netzwerk
• AC: Niedrig
• PR: Keine
• UI: Keine
• C: Hoch
• I: Hoch
• A: Hoch
• Score: 10.0 (Kritisch)

Beispiel 2: Remote Code Execution (RCE) – BlueKeep (CVE-2019-0708)

BlueKeep war eine Schwachstelle im Remote Desktop Protocol (RDP) von Windows, die ausgenutzt werden konnte, um Remote Code Execution zu ermöglichen.

• AV: Netzwerk
• AC: Hoch
• PR: Keine
• UI: Keine
• C: Hoch
• I: Hoch
• A: Hoch
• Score: 9.8 (Kritisch)

Beispiel 3: Denial-of-Service (DoS) – Heartbleed (CVE-2014-0160)

Heartbleed war eine Schwachstelle in der OpenSSL-Bibliothek, die es ermöglichte, sensible Informationen aus dem Speicher eines Servers auszulesen.

• AV: Netzwerk
• AC: Niedrig
• PR: Keine
• UI: Keine
• C: Hoch
• I: Keine
• A: Keine
• Score: 7.5 (Hoch)

Beispiel 4: OpenSSH RCE Schwachstelle CVE-2024-6387

Im Artikel OpenSSH RCE Schwachstelle CVE-2024-6387.

Tipps zur Arbeit mit Common Vulnerability Scoring System

1. Verwendung von CVSS-Rechnern – Offizielle CVSS-Rechner wie der von FIRST ermöglichen die genaue Berechnung von Basis-, Temporale- und Umweltmetriken. Dies fördert präzise und konsistente Scores.
2. Priorisierung nach CVSS-Score – Regelmäßige Bewertung aller erkannten Schwachstellen und Priorisierung der Behebung basierend auf den Scores. Höher bewertete Schwachstellen sollten zuerst behoben werden.
3. Berücksichtigung von Umweltmetriken – Anpassung der CVSS-Bewertungen an spezifische Umgebungsbedingungen. Schwachstellen können in unterschiedlichen Umgebungen variierende Kritikalität aufweisen.
4. Dokumentation aller Bewertungen – Detailaufzeichnungen aller CVSS-Bewertungen und der damit verbundenen Entscheidungen. Diese Dokumentation unterstützt zukünftige Bewertungen und Überprüfungen.
5. Kontinuierliche Überwachung und Aktualisierung – Ständige Überwachung der Systeme auf neue Schwachstellen und regelmäßige Aktualisierung der CVSS-Bewertungen. Dies ist wichtig, da sich Sicherheitslücken und Bedrohungen ständig weiterentwickeln.

Verschiedene Versionen von CVSS

Es gibt mehrere Versionen des Common Vulnerability Scoring Systems, die entwickelt wurden, um den sich ändernden Anforderungen und Bedrohungslandschaften gerecht zu werden:

• CVSS v1: Die erste Version, eingeführt im Jahr 2005, legte die Grundlagen für die standardisierte Bewertung von Schwachstellen.
• CVSS v2: Diese Version, veröffentlicht 2007, führte Verbesserungen in der Granularität und Genauigkeit der Bewertungen ein.
• CVSS v3.0: Veröffentlicht 2015, bot diese Version eine detailliertere und genauere Bewertung der Schwachstellen.
• CVSS v3.1: Diese Version, veröffentlicht 2019, baute auf den Verbesserungen von v3.0 auf und bot zusätzliche Klarheit und Konsistenz in der Bewertung. Die Unterschiede zwischen v3.0 und v3.1 beinhalten:

Unterschiede zwischen CVSS v3.0 und v3.1

1. Klarheit und Konsistenz:
   • Common Vulnerability Scoring System v3.1 bietet präzisere Definitionen und Beispiele, um die Konsistenz bei der Bewertung zu verbessern.
   • Begriffe und Konzepte wurden klarer formuliert, um Missverständnisse zu vermeiden.
2. Modifikationen bei Metriken:
   • Anpassungen bei bestimmten Metriken, um realistischere Bewertungen zu ermöglichen.
   • Verfeinerung der Metriken für temporäre und Umweltfaktoren.
3. Dokumentation und Anleitung:
   • Verbesserte Dokumentation und zusätzliche Leitfäden zur Unterstützung der Benutzer bei der korrekten Anwendung des Systems.
   • Neue Beispiele und Szenarien, die die Anwendung der Metriken verdeutlichen.
4. Feedback und Community-Integration:
   • Berücksichtigung von Feedback aus der Sicherheits-Community, um die Benutzerfreundlichkeit und Anwendbarkeit des Systems zu erhöhen.

CVSS v4.0: Neuerungen und Verbesserungen

Mit der Einführung von Common Vulnerability Scoring System v4.0 gibt es mehrere bedeutende Neuerungen und Verbesserungen, die das Bewertungssystem für Schwachstellen weiterentwickeln und präzisieren:

• Erweiterte Metrikgruppen –  Basis-Metriken wurden verfeinert, einschließlich detaillierterer Unterscheidungen der erforderlichen Privilegienstufen (PR) und klarerer Differenzierungen bei der Benutzerinteraktion (UI). Temporale Metriken wurden durch neue Schweregradmodifikatoren ergänzt.
• Verbesserte Umweltmetriken – Anpassung an spezifische Umgebungen und erweiterte Flexibilität bei der Bewertung.
• Einführung von Anwendungsmetriken – Berücksichtigung von Faktoren wie Nutzungshäufigkeit und Anzahl der betroffenen Nutzer.
• Detailliertere Dokumentation – Verbesserte und erweiterte Dokumentation mit klareren Definitionen und Beispielen zur Erhöhung der Konsistenz bei der Bewertung.
• Anpassungen und Klarstellungen – Präzisere Definitionen und zusätzliche Leitfäden zur Unterstützung der Benutzer bei der Anwendung der Metriken. Neue Beispiele und Szenarien verdeutlichen die Anwendung.

Diese Änderungen machen CVSS v4.0 zu einem leistungsfähigeren Tool für die Bewertung und Priorisierung von Sicherheitslücken, indem präzisere und kontextbezogenere Bewertungen ermöglicht werden. Für weitere Informationnen wird an dieser stelle die offizielle CVSS v4.0 Dokumentation empfohlen.

Glossar der Metriken im CVSS v4.0

• Base Metric Group
  • AV – Attack Vector (Angriffsvektor)
  • AC – Attack Complexity (Angriffskomplexität)
  • AT – Attack Requirements (Angriffsvoraussetzungen)
  • PR – Privileges Required (Erforderliche Privilegien)
  • UI – User Interaction (Benutzerinteraktion)
  • VC – Vulnerable System Confidentiality Impact (Vertraulichkeit des anfälligen Systems)
  • VI – Vulnerable System Integrity Impact (Integrität des anfälligen Systems)
  • VA – Vulnerable System Availability Impact (Verfügbarkeit des anfälligen Systems)
  • SC – Subsequent System Confidentiality Impact (Vertraulichkeit des nachfolgenden Systems)
  • SI – Subsequent System Integrity Impact (Integrität des nachfolgenden Systems)
  • SA – Subsequent System Availability Impact (Verfügbarkeit des nachfolgenden Systems)
• Threat Metric Group
  • E – Exploit Maturity (Ausnutzungsreife)
• Environmental Metric Group
  • CR – Confidentiality Requirement (Vertraulichkeitsanforderung)
  • IR – Integrity Requirement (Integritätsanforderung)
  • AR – Availability Requirement (Verfügbarkeitsanforderung)
  • MAV – Modified Attack Vector (Modifizierter Angriffsvektor)
  • MAC – Modified Attack Complexity (Modifizierte Angriffskomplexität)
  • MAT – Modified Attack Requirements (Modifizierte Angriffsvoraussetzungen)
  • MPR – Modified Privileges Required (Modifizierte erforderliche Privilegien)
  • MUI – Modified User Interaction (Modifizierte Benutzerinteraktion)
  • MVC – Modified Vulnerable System Confidentiality (Modifizierte Vertraulichkeit des anfälligen Systems)
  • MVI – Modified Vulnerable System Integrity (Modifizierte Integrität des anfälligen Systems)
  • MVA – Modified Vulnerable System Availability (Modifizierte Verfügbarkeit des anfälligen Systems)
  • MSC – Modified Subsequent System Confidentiality (Modifizierte Vertraulichkeit des nachfolgenden Systems)
  • MSI – Modified Subsequent System Integrity (Modifizierte Integrität des nachfolgenden Systems)
  • MSA – Modified Subsequent System Availability (Modifizierte Verfügbarkeit des nachfolgenden Systems)
• Supplemental Metric Group
  • S – Safety (Sicherheit)
  • AU – Automatable (Automatisierbar)
  • R – Recovery (Wiederherstellung)
  • V – Value Density (Wertdichte)
  • RE – Vulnerability Response Effort (Aufwand für die Reaktion auf Schwachstellen)
  • U – Provider Urgency (Dringlichkeit des Anbieters)

Was ist CVSS – Fazit

Das CVSS stellt einen bedeutenden Fortschritt in der IT-Sicherheit dar, da es eine standardisierte Methode zur Bewertung und Priorisierung von Schwachstellen bietet. Diese Standardisierung ermöglicht Organisationen eine konsistente und transparente Bewertung von Schwachstellen und verbessert die Kommunikation und Zusammenarbeit zwischen verschiedenen Teams und Geschäftsbereichen. Durch die objektive Bewertung und Priorisierung von Risiken können Unternehmen ihre Ressourcen effizienter einsetzen und sich auf die kritischsten Bedrohungen konzentrieren.

Mit der Version 4.0 wird die Anwendbarkeit auf OT-, ICS- und IoT-Systeme ermöglicht, was im Hinblick auf die NIS2-Richtlinien für kritische Infrastrukturen und produzierende Unternehmen von großer Bedeutung ist. CVSS ist somit ein unverzichtbares Werkzeug für IT-Sicherheitsexperten, um den Sicherheitsstatus ihrer Systeme zu verstehen und gezielte Maßnahmen zur Verbesserung zu ergreifen.

Weiterführend

• CVSS-Rechner
• NVD-Datenbank

Der Beitrag Was ist CVSS erschien zuerst auf Ilja Schlak InfoSec Blog.