Ü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.

Ein Directory Traversal Angriff, auch als Path Traversal oder “Punkt-Punkt-Schrägstrich” (“dot-dot-slash“) bekannt, ermöglicht es Angreifern, auf Verzeichnisse und Dateien zuzugreifen, die außerhalb des Webroot-Verzeichnisses liegen. Dies geschieht oft durch die Ausnutzung von Sicherheitslücken in Webanwendungen oder unzureichend konfigurierten Webservern.

Gefahren von Directory Traversal Angriffen

Directory Traversal Angriffe bergen signifikante Risiken und können schwerwiegende Konsequenzen für Webanwendungen und die dahinterstehenden Systeme mit sich bringen. Im Folgenden werden die verschiedenen Gefahren detailliert erläutert:

Zugriff auf sensible Daten

Durch einen erfolgreichen Directory Traversal Angriff können Angreifer Zugang zu vertraulichen Daten erlangen. Dazu zählen Konfigurationsdateien, die kritische Informationen wie Datenbankzugangsdaten, API-Schlüssel oder Verschlüsselungsschlüssel enthalten können. Zudem könnten persönliche Benutzerdaten wie Nutzernamen und Passwörter kompromittiert werden, was zu Datenschutzverletzungen und Identitätsdiebstahl führen kann.

Erkundung der Verzeichnisstruktur

Angreifer können durch einen Directory Traversal Angriff die Struktur des Serverdateisystems erkunden und Schwachstellen oder ungeschützte Bereiche aufdecken. Diese Informationen können sie nutzen, um weitere Angriffe zu planen oder um zusätzliche vertrauliche Informationen zu sammeln, die in anderen Verzeichnissen gespeichert sind.

Ausführung von Befehlen

In manchen Fällen ermöglichen Directory Traversal Angriffe Angreifern, Befehle auf dem Server auszuführen. Dies kann von der Manipulation von Webinhalten bis hin zur vollständigen Übernahme des Servers reichen. Solche Angriffe könnten auch zur Verbreitung von Malware, zum Aufbau von Botnetzen oder zur Durchführung von DDoS-Angriffen genutzt werden.

Systemkompromittierung

Ein erfolgreicher Directory Traversal Angriff, der es Angreifern ermöglicht, höhere Systemprivilegien zu erlangen, kann zu einem vollständigen Systemkompromiss führen. In diesem Fall erlangt der Angreifer die Kontrolle über das gesamte System und kann beliebige Aktionen ausführen, einschließlich dem Löschen kritischer Daten, dem Ändern von Systemkonfigurationen oder dem Stehlen weiterer Daten.

Wie funktioniert der Directory Traversal Angriff?

Der Angriff nutzt die HTTP-Protokollstruktur, um durch speziell manipulierte URL-Anfragen auf Systemverzeichnisse zuzugreifen. Angreifer verwenden typischerweise die Sequenz “../” (Punkt-Punkt-Schrägstrich), um schrittweise aus dem Webroot-Verzeichnis heraus zu navigieren.

Beispiele für Directory Traversal Angriffe

Zugriff auf Systemdateien

http://www.beispielwebsite.com/../../../../etc/passwd

Erhalten vertraulicher Dokumente

http://www.beispielunternehmen.com/documents/../../confidential/report.pdf

Umgehung von Authentifizierungsmechanismen

http://www.beispielseite.com/login/../../../admin/dashboard.html

Sicherheitsrisiken und Auswirkungen

Die Konsequenzen eines Directory Traversal Angriffs können tatsächlich verheerend, weitreichend und schwer im Vorfeld kalkulierbar sein. (Zur Quantifizierung von Risiken: hier klicken). Sie erstrecken sich von gravierenden Datenlecks bis hin zum unberechtigten Zugriff auf hochsensible Informationen. Darüber hinaus besteht die ernsthafte Möglichkeit, dass Angreifer serverseitigen Code ausführen können, was letztendlich zu einem vollständigen Kompromiss des gesamten Systems führen kann. Die Auswirkungen solcher Angriffe unterstreichen die dringende Notwendigkeit, robuste Sicherheitsmaßnahmen zu implementieren, um solche gravierenden Sicherheitsverletzungen zu vermeiden.

Schadensbeispiele und Fallstudien zu Directory Traversal Angriffen

Directory Traversal Angriffe können eine Reihe schwerwiegender Konsequenzen haben, darunter Datenexfiltration, Systemübernahme und Reputationsschaden. Folgende Fälle zeigen die Schwere dieser Vulnerability:

CVE-2019-11246 – Wiederkehrende Path Traversal Schwachstelle in kubectl

Eine neue Schwachstelle, CVE-2019-11246, wurde in `kubectl`, der Kommandozeilen-Schnittstelle für Kubernetes-Cluster, aufgedeckt. Diese ermöglichte einen Path Traversal-Angriff durch manipulierte tar-Dateien, die relative Pfade enthalten. Erstmals entdeckt von Michael Hanselmann, erlaubte diese Schwachstelle einem Angreifer, speziell präparierte tar-Dateien zu verwenden, um Dateien auf dem Client-Rechner zu ersetzen oder Code auszuführen. Interessanterweise war dies der dritte Vorfall einer ähnlichen Schwachstelle innerhalb eines Jahres. Die ersten beiden Schwachstellen (CVE-2018-1002100 und CVE-2019-1002101) betrafen ebenfalls `kubectl` und wurden durch Patches behoben, die jedoch unvollständig waren und weitere Sicherheitslücken offen ließen.

Kubernetes veröffentlichte mehrere Fix-Versionen, und die Community trug durch kontinuierliche Forschung und Bewusstsein für Sicherheitsprobleme zur Behebung bei. Als zusätzliche Absicherung empfiehlt sich die Verwendung des Penetrationstesting-Tools `kube-hunter`, um die aktuelle `kubectl`-Version auf Anfälligkeiten zu überprüfen und gegebenenfalls ein Update durchzuführen. Aqua’s Drift Prevention-Funktion und Image Assurance-Richtlinien bieten zusätzlichen Schutz, indem sie die Ausführung modifizierter oder unbekannter Binärdateien in Containern verhindern und somit die Ausnutzung dieser Schwachstelle eindämmen. Siehe auch diese Referenz.

CVE-2019-14994 – URL Path Traversal Schwachstelle in Jira Service Desk

Im September 2019 wurde eine Sicherheitslücke in Atlassian’s Jira Service Desk (CVE-2019-14994) bekannt, die eine URL Path Traversal Schwachstelle darstellt. Diese Schwachstelle ermöglichte es Angreifern, durch speziell gestaltete Anfragen an das Jira Service Desk Portal, Einschränkungen zu umgehen und somit geschützte Informationen einzusehen. Die Ausnutzung der Schwachstelle erforderte eine bestimmte Konfiguration der Kundenzugriffsberechtigungen. Atlassian reagierte auf diese Schwachstelle mit einem Update für Jira Service Desk Server und Data Center, um hier schnelle Abhilfe zu schaffen. Das Update betraf verschiedene Versionen von Jira Service Desk. Als Übergangslösung wurden auch temporäre Workarounds bereitgestellt, falls ein sofortiges Update nicht möglich war. Quelle: siehe hier.

Directory Traversal Angriff auf Router, NAS-Geräte und Webserver

Router,Switche, NAS-Geräte und Webserver verschiedener Hersteller weisen ebenfalls oft die Anfälligkeit für Directory Traversal Angriffe auf. Auch hier ist es den Angreifern möglich, unbefugt auf Netzwerkressourcen zuzugreifen und kritische Daten zu kompromittieren. Für Betreiber dieser Geräte ist es daher entscheidend, regelmäßig nach Sicherheitsupdates zu suchen und diese umgehend zu installieren, um die Risiken zu minimieren.

Auch bei Webserver-Software ist die Anfälligkeit für Directory Traversal Angriffe ein wiederkehrendes Problem. Obwohl Hersteller kontinuierlich Updates zur Schließung bekannter Sicherheitslücken bereitstellen, bleiben ältere Versionen oft anfällig. Dies erhöht das Risiko von Sicherheitsverletzungen erheblich, da Angreifer bekannte Schwachstellen in diesen veralteten Systemen ausnutzen können. Daher ist es für Webserver-Betreiber unerlässlich, ihre Systeme regelmäßig zu aktualisieren und zu überwachen, um ihre Infrastruktur effektiv vor Directory Traversal Angriffen zu schützen.

Präventive Maßnahmen und Best Practices gegen Directory Traversal Angriffe

Um Directory Traversal Angriffe effektiv zu verhindern, ist eine mehrschichtige Sicherheitsstrategie erforderlich. Diese Strategie sollte sowohl präventive Maßnahmen als auch Methoden zur frühzeitigen Erkennung solcher Angriffe umfassen.

Gegenmaßnahmen

OWASP-Empfehlungen

“OWASP (Open Web Application Security Project) ist eine internationale Non-Profit-Organisation, die sich der Verbesserung der Sicherheit von Software widmet.” Hier geht es zum OWASP-Artikel zu Directory Traversal Angriff.

Effektive Sicherheitsstrategien gegen Path Traversal Schwachstellen in Webanwendungen

In der modernen Webentwicklung, wo Anwendungen häufig lokale Ressourcen wie Bilder, Skripte und andere Dateien einbinden, sind Directory Traversal Schwachstellen eine relevante Bedrohung. Diese Schwachstellen entstehen oft, wenn Anwendungen externe Dateien einbinden, was Angreifern die Möglichkeit gibt, unerlaubt auf nicht autorisierte Ressourcen zuzugreifen.

Identifizierung von Sicherheitsrisiken

Um Path Traversal Schwachstellen effektiv zu identifizieren, ist ein tiefes Verständnis der Dateiverarbeitungsmechanismen des Betriebssystems erforderlich. Wichtig ist auch die sichere Aufbewahrung sensibler Konfigurationsdateien, idealerweise außerhalb des Webroot-Verzeichnisses. Insbesondere bei Windows IIS-Servern ist darauf zu achten, dass das Webroot nicht auf der Systemfestplatte liegt, um das Risiko rekursiver Traversierungen zu minimieren.

Implementierung von Schutzmechanismen

• Optimale Sicherheit wird erreicht, wenn Dateisystemaufrufe ohne direkte Benutzereingaben erfolgen.
• Für die Internationalisierung und Lokalisierung in Webanwendungen ist die Verwendung von Indizes anstelle von vollständigen Dateinamen empfehlenswert, um Sicherheitsrisiken zu minimieren.
• Es ist ratsam, den vom Benutzer beeinflussbaren Pfadteil durch fest definierte Pfadstrukturen zu ergänzen und so die Kontrolle zu behalten.
• Die Validierung der Benutzereingaben sollte sich darauf konzentrieren, nur vertrauenswürdige und bekannte Werte zuzulassen, anstatt zu versuchen, die Daten zu bereinigen.
• Die Nutzung von chrooted jails und spezifischen Code-Zugriffsrichtlinien kann den Zugriff auf Dateien effektiv einschränken.
• Wenn die Verarbeitung von Benutzereingaben für Dateioperationen erforderlich ist, sollten diese Eingaben normalisiert werden, bevor sie in Datei-IO-APIs verwendet werden.

Weiter Gegenmaßnahmen

• Sicherheitsaudits und Code-Reviews
  • Regelmäßige Überprüfungen des Codes und der Infrastruktur sind entscheidend, um Schwachstellen frühzeitig zu identifizieren. Dabei sollten sowohl statische als auch dynamische Code-Analysemethoden eingesetzt werden:
    • Statische Code-Analyse: Diese Methode analysiert den Code ohne Ausführung, um Schwachstellen wie unsichere Codierungsmuster und Sicherheitslücken zu identifizieren.
    • Dynamische Code-Analyse: Bei dieser Methode wird der Code während der Ausführung getestet, um Schwachstellen wie Laufzeitfehler und Sicherheitslücken aufzudecken, die unter bestimmten Bedingungen auftreten.
  • Die Kombination beider Ansätze bietet eine umfassende Sichtweise, die hilft, ein breites Spektrum an Sicherheitsrisiken effektiv zu identifizieren und zu beheben.
• Least-Privilege-Prinzip: Benutzerrechte sollten auf das unbedingt Notwendige beschränkt werden, um das Risiko im Falle eines Angriffs zu minimieren.
• Einsatz von Web Application Firewalls (WAF): Der Einsatz von WAFs ist ein wesentlicher Bestandteil jeder umfassenden Sicherheitsstrategie. WAFs bieten einen robusten Schutzmechanismus, indem sie potenzielle Angriffsversuche proaktiv erkennen und effektiv blockieren, um so Schäden an Webanwendungen und Serverinfrastrukturen zu verhindern.
• Regelmäßige Updates und Patches: Halten Sie Ihre Software und Systeme stets auf dem neuesten Stand, um bekannte Sicherheitslücken zu schließen.
• Eingabevalidierung: Strenge Überprüfung der Benutzereingaben, um die Ausnutzung von Schwachstellen zu verhindern.
• Einsatz von Intrusion Detection Systemen (IDS): IDS können ungewöhnliche Aktivitäten im Netzwerk erkennen und Alarm auslösen.
• Keine Benutzereingaben direkt an Dateisystem-APIs weitergegeben werden. Es ist wichtig, dass die Anwendung die Benutzereingaben zunächst validiert, bevor sie verarbeitet werden:
• Eingabevalidierung mit einer Whitelist erlaubter Werte.
• Überprüfen, ob die Eingabe nur erlaubten Inhalt enthält – beispielsweise alphanumerische Zeichen.
• Nach der Validierung sollte die Anwendung überprüfen, ob der kanonisierte (absolute) Pfad mit dem erwarteten Basisverzeichnis beginnt.

Beispiel eines Python-Snippets zur Validierung des kanonischen Pfads einer Datei:

import os

# Basisverzeichnisses
BASE_DIRECTORY = '/path/to/base/directory'

# Benutzereingabe
user_input = 'user/supplied/path'

# vollständiger Pfades
full_path = os.path.join(BASE_DIRECTORY, user_input)

# Überprüfung
if os.path.realpath(full_path).startswith(BASE_DIRECTORY):
    # Prozessdatei, da der Pfad sicher ist
    pass
else:
    # Umgang mit ungültigen Pfaden
    pass

Wie Web Application Firewalls (WAFs) gegen Directory Traversal Angriffe helfen können

Schauen wir uns etwas genauer die Rolle der WAFs an. Technisch gesehen arbeiten WAFs als Gatekeeper, die den eingehenden und ausgehenden Datenverkehr zwischen einer Webanwendung und dem Internet überwachen und filtern. Hier sind einige Schlüsselaspekte, wie WAFs gegen Directory Traversal Angriffe helfen können:

• Filterung von Anfragen: WAFs analysieren eingehende HTTP-Anfragen auf verdächtige Muster. Sie können speziell konfiguriert werden, um Anfragen zu blockieren, die Versuche eines Directory Traversal Angriffs erkennen lassen, wie z.B. ungewöhnliche oder bösartige Pfadsequenzen.
• Benutzerdefinierte Regeln und Signaturen: WAFs können mit benutzerdefinierten Regeln konfiguriert werden, um spezifische Angriffsmuster zu erkennen. Diese Regeln können auf bekannte Directory Traversal Techniken zugeschnitten sein und helfen, Angriffe frühzeitig zu erkennen und zu blockieren.
• Anomalie-Erkennung: Moderne WAFs sind mit Algorithmen ausgestattet, die speziell dafür entwickelt wurden, Muster zu identifizieren, die auf einen Directory Traversal Angriff hindeuten könnten. Dazu gehören typischerweise Pfade, die Sequenzen wie ../ (um ein Verzeichnis nach oben zu navigieren) oder ähnliche Varianten enthalten. Darüber hinaus gibt es die Möglichkeit, benutzerdefinierte Regeln zu erstellen und zu konfigurieren. Diese Regeln können auf spezifische Bedrohungsmodelle und Angriffsszenarien abgestimmt werden, um sicherzustellen, dass verdächtige Anfragen, die spezifische Zeichenfolgen oder Pfadmuster enthalten, effektiv erkannt und blockiert werden.
• Logging und Berichterstattung: WAFs protokollieren den Datenverkehr und ermöglichen eine detaillierte Analyse verdächtiger Aktivitäten. Im Falle eines Angriffs können diese Logs für forensische Untersuchungen und zur Verbesserung der Sicherheitsstrategie verwendet werden. Logs ermöglichen zudem eine spätere Analyse und helfen t bei der Identifizierung und Reaktion auf Sicherheitsvorfälle. Zudem sollte die Einstellung so gewählt werden, dass automatisierte Warnungen an das Sicherheitsteam gesendet werden, um auf potenzielle Bedrohungen aufmerksam zu machen.
• Kontinuierliches Update: Da sich Angriffstechniken ständig weiterentwickeln, ist es wichtig, dass die WAF-Regeln und Signaturen kontinuierlich aktualisiert werden, um gegen die neuesten Bedrohungen gewappnet zu sein.

Indem sie als Filter und Überwachungssysteme fungieren, bieten WAFs einen robusten Schutz gegen eine Vielzahl von Webanwendungsangriffen, einschließlich Directory Traversal Angriffe. Ihre Fähigkeit, verdächtigen Datenverkehr zu identifizieren und zu blockieren, macht sie zu einem unverzichtbaren Bestandteil jeder Webanwendungssicherheitsstrategie.

Directory Traversal Angriff detektieren

Die frühzeitige Erkennung von Directory Traversal Angriffen ist entscheidend, um Schäden zu verhindern. Folgende Maßnahmen können dabei helfen:

• Log-Analyse: Überwachung und Analyse von Server-Logs auf verdächtige URL-Muster und Zugriffsversuche. Hierzu müssen verdächtige Aktivitäten zuerst in die Protokollierung aufgenommen worden sein.
• Anomalie-Erkennung: Einsatz von KI-gestützten Systemen, die aus dem normalen Datenverkehr lernen und Anomalien erkennen können.
• Security Information and Event Management (SIEM): Integration von SIEM-Systemen zur Korrelation von Ereignissen und Identifikation potenzieller Bedrohungen.

Directory Traversal Angriffe im Analyser sehen

Ein Directory Traversal Angriff könnte in einem Paketanalysator (wie Wireshark) wie folgt aussehen:

Angenommen, ein Angreifer versucht, auf eine Datei außerhalb des Webroot-Verzeichnisses zuzugreifen. In diesem Fall könnte der HTTP-Request-Teil des Pakets eine URL enthalten, die die ../ (Punkt-Punkt-Schrägstrich) Sequenz nutzt, um in der Verzeichnisstruktur aufzusteigen.

Das entsprechende Paket könnte so aussehen:

Beispiel eines Directory Traversal Angriffs im Wireshark

GET /bilder/../config/passwd HTTP/1.1
Host: www.beispielwebsite.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, wie Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120
Pragma: no-cache
Cache-Control: no-cache

In diesem Beispiel versucht der Angreifer, durch die URL /bilder/../config/passwd auf die Datei passwd zuzugreifen, die sich normalerweise außerhalb des öffentlich zugänglichen Verzeichnisses befindet. Der Paketanalyser würde diesen Request genau so anzeigen, wie er vom Client gesendet wurde. Ein solcher Request sollte sofort Verdacht erregen, da der Pfad ../ verwendet wird, um in höhere Verzeichnisebenen zu navigieren.

Fazit:

Der Directory Traversal Angriff stellt in der Tat eine signifikante und ernsthafte Bedrohung für moderne Webanwendungen dar. Dabei ist es entscheidend, ein tiefgehendes Verständnis der technischen Grundlagen zu erlangen und dieses Wissen mit der Implementierung einer umfassenden und mehrschichtigen Sicherheitsstrategie zu kombinieren. Zudem ist die strikte Einhaltung von bewährten Best Practices und der Einsatz effektiver Erkennungsmethoden unerlässlich, um diesen komplexen Sicherheitsherausforderungen erfolgreich und effektiv begegnen zu können.

Der Beitrag Directory Traversal Angriff erschien zuerst auf Ilja Schlak InfoSec Blog.

Quantitative oder qualitative Risikoanalyse

In der heutigen Geschäftswelt ist das richtige Management von Risiken entscheidend für den Erfolg eines Unternehmens. Es gibt zwei Hauptansätze zur Risikoanalyse: die qualitative und die quantitative Methode. Doch wie entscheidet man, welche Methode am besten für das eigene Unternehmen geeignet ist? In diesem Blogbeitrag präsentieren wir Ihnen einen hilfreichen Fragebogen, der Ihnen bei der Entscheidung zwischen qualitativer und quantitativer Risikoanalyse unter die Arme greift.

Quantitative oder qualitative Risikoanalyse

Das Thema quantitative oder qualitative Risikoanalyse wurde bereits in einem Artikel beleuchtet. Dort wurden die wichtigsten Unterschiede zwischen den beiden Ansätzen mit Beispielen aufgezeigt. Um die beste Lösung für Ihre individuellen Anforderungen zu finden, hilft der Nachfolgende Fragebogen. Dieser trägt zur begründeten Entscheidung bei der Wahl der Risikoanalyse zu treffen bei.

Fragebogen zur Entscheidung zwischen qualitativer und quantitativer Risikoanalyse

Bitte beantworten Sie die folgenden Fragen, um herauszufinden, welche Art der Risikoanalyse für Ihr Unternehmen am besten geeignet ist.

Welche Art von Risiken betrachtet Ihr Unternehmen?

a) Spezifische und messbare Risiken (z.B. finanzielle Verluste, Auswirkungen auf den Marktanteil)
b) Allgemeine und schwer messbare Risiken (z.B. Reputationsrisiken, betriebliche Unsicherheiten)

Wie genau sind die Daten, die für die Risikoanalyse verfügbar sind?

a) Präzise und gut dokumentiert
b) Ungenau oder unvollständig

Welchen Grad an Detailtiefe und Komplexität wünscht Ihr Unternehmen für die Risikoanalyse?

a) Einfache und leicht verständliche Ergebnisse
b) Detaillierte und komplexe Ergebnisse

Welche Ressourcen stehen Ihrem Unternehmen für die Risikoanalyse zur Verfügung (z.B. Zeit, Geld, Personal)?

a) Begrenzt
b) Ausreichend

Wie erfahren ist Ihr Unternehmen in der Risikoanalyse?

a) Wenig oder keine Erfahrung
b) Erfahren oder Experten

Inwieweit sind Entscheidungsträger in Ihrem Unternehmen bereit, sich auf subjektive Einschätzungen zu verlassen?

a) Bevorzugt objektive Daten
b) Akzeptiert subjektive Einschätzungen

Wie wichtig ist es für Ihr Unternehmen, die Wahrscheinlichkeit und die Auswirkungen von Risiken genau zu quantifizieren?

a) Sehr wichtig
b) Nicht entscheidend

Auswertung

Wenn die Mehrheit Ihrer Antworten a) ist, ist die qualitative Risikoanalyse wahrscheinlich besser für Ihr Unternehmen geeignet. Diese Methode ist einfacher, weniger ressourcenintensiv und ideal für Unternehmen, die sich mit allgemeinen oder schwer messbaren Risiken befassen.

Wenn die Mehrheit Ihrer Antworten b) ist, ist die quantitative Risikoanalyse wahrscheinlich besser für Ihr Unternehmen geeignet. Diese Methode ist komplexer, erfordert mehr Ressourcen und eignet sich am besten für Unternehmen, die präzise und gut dokumentierte Daten haben. Die quantitative Risikoanalyse ist darüber hinaus zu empfehlen, wenn Sie die Wahrscheinlichkeit und die Auswirkungen von Risiken genau quantifizieren möchten.

Der Fragebogen zur Entscheidungsfindung als Tabelle

Frage	a) Antwort	b) Antwort
1. Welche Art von Risiken betrachtet Ihr Unternehmen?	Spezifische und messbare Risiken (z.B. finanzielle Verluste, Auswirkungen auf den Marktanteil)	Allgemeine und schwer messbare Risiken (z.B. Reputationsrisiken, betriebliche Unsicherheiten)
2. Wie genau sind die Daten, die für die Risikoanalyse verfügbar sind?	Präzise und gut dokumentiert	Ungenau oder unvollständig
3. Welchen Grad an Detailtiefe und Komplexität wünscht Ihr Unternehmen für die Risikoanalyse?	Einfache und leicht verständliche Ergebnisse	Detaillierte und komplexe Ergebnisse
4. Welche Ressourcen stehen Ihrem Unternehmen für die Risikoanalyse zur Verfügung (z.B. Zeit, Geld, Personal)?	Begrenzt	Ausreichend
5. Wie erfahren ist Ihr Unternehmen in der Risikoanalyse?	Wenig oder keine Erfahrung	Erfahren oder Experten
6. Inwieweit sind Entscheidungsträger in Ihrem Unternehmen bereit, sich auf subjektive Einschätzungen zu verlassen?	Bevorzugt objektive Daten	Akzeptiert subjektive Einschätzungen
7. Wie wichtig ist es für Ihr Unternehmen, die Wahrscheinlichkeit und die Auswirkungen von Risiken genau zu quantifizieren?	Sehr wichtig	Nicht entscheidend

Der Fragebogen ist in der nachfolgenden Mindmap visualisiert.

qualitative oder quantitative Risikoanalyse Mindmap zum Fragebogen

Eine Mindmap zum Fragebogen "qualitative oder quantitative Risikoanalyse

Der Beitrag Qualitative oder Quantitative Risikoanalyse – Fragebogen erschien zuerst auf Ilja Schlak InfoSec Blog.

Zwei fundamentale Ansätze für die Risikoanalyse sind quantitative vs. qualitative Methoden. Das Sprichwort “Drei Experten – neun Meinungen” trifft auch auf Sicherheitsexperten zu, die über aktuelle Standards und Praktiken im Risikomanagement informiert sind. Selbst wenn sie dieselbe Systembewertung vornehmen, können (und werden) sie aufgrund unterschiedlicher Bewertungsmethoden zu verschiedenen Ergebnissen in ihren Berichten gelangen.

Der quantitative Ansatz

Die quantitative Risikoanalyse verwendet konkrete, nicht-subjektive numerische Werte und statistische Analysen, um die Wahrscheinlichkeit und Auswirkungen von Risiken zu berechnen. Dabei werden numerische Werte wie Eurobeträge, statistische Zahlen und andere numerische Zuweisungen verwendet.

Ein quantitativer Ansatz folgt einem ähnlichen Muster wie die qualitative Methode. Zunächst müssen die Vermögenswerte aufgelistet werden (zusammen mit ihren Wiederbeschaffungskosten und Expositionsfaktoren). Im Folgenden muss der Auswirkungsgrad eines vollständigen oder teilweisen Verlusts des Vermögenswerts berechnet, die Wahrscheinlichkeit des negativen Ereignisses bestimmt und schließlich das Gesamtrisiko für die Organisation ermittelt werden.
Die quantitativen Methoden sind nützlich, um Risiken in monetären Werten auszudrücken und den ROI von Risikomanagemententscheidungen zu berechnen. Diese Methode wird oft in Unternehmen verwendet, bei denen eine Risikobewertung eine wichtige Rolle bei der Entscheidungsfindung spielt. Quantitative Risikoanalyse kann auch als Ergänzung zur qualitativen Methode verwendet werden, um umfassendere Erkenntnisse über die Risikosituation zu erlangen.

Der qualitative Ansatz

Qualitative (qualitative) Risikoanalyse hingegen verwendet subjektive Skalen. Diese Skalen können auch numerisch sein (eine Skala von 1 bis 10) oder aber auch subjektive Bezeichnungen aufweisen (wie beispielsweise “Hoch”, “Mittel” und “Niedrig”). Die qualitative Risikoanalyse kann auf historischen Trendanalysen, Erfahrungen, Expertenmeinungen, vorhandenen internen und externen Umweltfaktoren und anderen Eingaben basieren. Solche Faktoren sind jedoch die nicht immer quantifizierbar. Die qualitative Risikoanalyse ist angemessen, wenn Sie Risiken auf der Grundlage von Faktoren bewerten müssen, die schwer zu quantifizieren sind. Zum Beispiel solche Faktoren, die normalerweise nicht mit konkreten, wiederholbaren Werten gemessen werden.

Beispielsweise welche numerischen Werte könnten Sie einem potenziellen Verlust des Verbrauchervertrauens oder einem Reputationsschaden zuweisen? Sie könnten versuchen, es in Bezug auf entgangene Einnahmen zu formulieren oder auch am Geschäftsverlust. Sie könnten auch eine Stichprobe der Bevölkerung befragen, um festzustellen, wie viele Menschen zum Beispiel nach einem Datenverstoß Geschäfte mit der Organisation tätigen würden oder nicht. Allerdings wäre auch das subjektiv und würde nur einen kleinen statistischen Einblick in eine schwer definierbare Messung bieten.

Wann ist die qualitative Risikoanalyse geeignet?

Diese Methode eignet sich gut für kleinere Projekte oder Unternehmen, bei denen es nicht notwendig ist, eine detaillierte Risikobewertung durchzuführen. Sie ist auch dann nützlich, wenn es schwierig oder unmöglich ist, zuverlässige Daten zu sammeln oder wenn es sich um komplexe Risiken handelt, die nicht einfach quantifiziert werden können.

Die Ergebnisse der qualitativen Risikoanalyse werden oft in einer Liste von Risiken mit Bewertungen wie Rot, Gelb und Grün dargestellt. Diese Ergebnisse können als Grundlage für das Risikomanagement dienen, indem sie zur Planung und Umsetzung von Risikominderungsmaßnahmen genutzt werden.

Qualitative Risikoanalyse – als “softer” Ansatz

Die Qualitative Risikoanalyse gilt als ein “weicherer” Ansatz einer Risikoanalyse. Es werden Bewertungen für die Risiken vergeben, wie zum Beispiel Rot für hohes Risiko, Gelb für normales und Grün für niedriges Risiko. Diese Bewertungen werden basierend auf subjektiven Einschätzungen und Erfahrungen vorgenommen.

Im Gegensatz zur quantitativen Risikoanalyse, die auf der Verwendung von numerischen Daten basiert, verwendet die qualitative Methode subjektive Einschätzungen und Erfahrungen, um die Risiken zu bewerten und zu priorisieren.

Wann wird die qualitative Risikoanalyse eingesetzt?

Die qualitative Risikoanalyse eignet sich gut für kleinere Projekte oder Unternehmen, bei denen es nicht notwendig ist, eine detaillierte Risikobewertung durchzuführen. Sie ist auch dann nützlich, wenn es schwierig oder unmöglich ist, zuverlässige Daten zu sammeln. Oft wird die qualitative Risikoanalyse der quantitativen vorgezogen, wenn es sich um komplexe Risiken handelt, die nicht einfach quantifiziert werden können.

Im Bereich der Informationssicherheit ist es wichtig, potenzielle Bedrohungen innerhalb des zu schützenden Geltungsbereichs zu identifizieren und geeignete Gegenmaßnahmen zu ergreifen. Hierbei kommen verschiedene Methoden zum Einsatz, darunter die qualitative und die quantitative Risikoanalyse.

Während die quantitative Risikoanalyse Zahlen und monetäre Werte verwendet, um das Risiko zu bewerten, basiert die qualitative Risikoanalyse auf der Bewertung von Szenarien und der Einschätzung der Bedrohung durch Expertenmeinungen. Beide Methoden haben ihre Vor- und Nachteile und sollten je nach den spezifischen Anforderungen und Gegebenheiten des Unternehmens eingesetzt werden.

Ein Beispiel für die qualitative Risikoanalyse im Bereich der Informationssicherheit ist die Identifizierung von potenziellen Bedrohungen und deren Bewertung nach Eintritts­wahrscheinlichkeit und am Schadensausmaß. Anschließend werden mögliche Gegenmaßnahmen und Sicherheitsvorkehrungen bewertet und priorisiert.

Obwohl die qualitative Risikoanalyse eine nützliche Methode zur Identifizierung von Bedrohungen und Gegenmaßnahmen sein kann, ist es wichtig zu beachten, dass sie nicht so genau ist wie die quantitative Risikoanalyse. Unternehmen sollten daher sorgfältig abwägen, welche Methode am besten geeignet ist, um ihre spezifischen Anforderungen zu erfüllen.

Beispiel: Qualitative Risikoanalyse für Typ 1 Hypervisor

Im Folgenden wird eine qualitative Risikoanalyse für einen Typ 1 Hypervisor durchgeführt, auf dem die Active Directory und der Fileserver eines KMU mit 150 FTEs virtualisiert sind. Ziel der Analyse ist es, potenzielle Bedrohungen zu identifizieren und Maßnahmen zu empfehlen, um die Sicherheit des Hypervisors und der darauf gehosteten Systeme zu verbessern.

Folgende Risikomatrix ist oft bei qualitativen Risikoanalysen anzutreffen

Quantitative Risikoanalyse: Definition, Bedeutung und Vorteile

Die quantitative Risikoanalyse ist eine Methode zur Bewertung von Risiken, die in vielen Branchen und Unternehmen weit verbreitet ist. Im Gegensatz zur qualitativen Risikoanalyse, werden bei der quantitativen Risikoanalyse Zahlen und monetäre Werte verwendet. Dies ermöglicht eine genauere Bewertung des Risikos und eine bessere Entscheidungsfindung.

Die quantitative Risikoanalyse umfasst mehrere Schritte, darunter

1. die Identifizierung von Risiken,
2. die Bewertung der Wahrscheinlichkeit des Eintritts dieser Risiken und
3. die Schätzung des finanziellen Verlustes,

der bei Eintritt eines Risikos entstehen kann. Anhand dieser Schritte werden dann konkrete Maßnahmen ergriffen, um das Risiko zu minimieren oder zu vermeiden.

Ein großer Vorteil dieser Methode ist die Möglichkeit, die finanziellen Auswirkungen von Risiken zu quantifizieren. Dadurch können Unternehmen ihre Risikobereitschaft, ihr Risikoappetit besser einschätzen und fundierte Entscheidungen treffen. Zudem bietet die quantitative Risikoanalyse eine standardisierte Methode zur Bewertung von Risiken, die eine Vergleichbarkeit zwischen und auch innerhalb Branchen ermöglicht. Auch der Vergleich zwischen verschiedenen Risiken ist dank dieser Methode möglich.

Wann wird die quantitative Risikoanalyse eingesetzt

Die quantitative Risikoanalyse wird in verschiedenen Branchen eingesetzt, darunter im Finanzwesen, im Gesundheitswesen, in der Versicherungsbranche und in der Informationstechnologie. Sie wird auch häufig bei der Planung von Großprojekten eingesetzt, um Risiken und potenzielle Verluste im Vorfeld zu identifizieren und zu minimieren.

Bei der Entscheidung qualitative vs. quantitative Risikoanalyse, ist wichtig zu beachten, dass die quantitative Risikoanalyse nicht immer die beste Methode zur Bewertung von Risiken ist. In einigen Fällen kann eine qualitative Risikoanalyse sinnvoller sein, insbesondere wenn die Risiken schwer zu quantifizieren sind oder wenn die Bewertung der finanziellen Auswirkungen nicht der Hauptfokus ist.

Insgesamt bietet die quantitative Risikoanalyse eine robuste Methode zur Bewertung von Risiken, die Unternehmen und Organisationen dabei helfen kann, fundierte Entscheidungen zu treffen und potenzielle Verluste zu minimieren.

Berechnungsmethoden im Rahmen einer quantitativen Risikoanalyse

Die quantitative Risikoanalyse ist eine Methode zur Bewertung der potenziellen Auswirkungen von Risiken auf ein Unternehmen. Es beinhaltet die quantitative Bewertung von Vermögenswerten und potenziellen Verlusten, die aus einer Bedrohung entstehen können.

Asset Value (AV)

Asset Value (AV) oder Vermögenswert bezieht sich auf den Wert eines Vermögensgegenstands oder einer Ressource, die durch eine Bedrohung gefährdet werden könnte. Dieser Wert kann monetär sein, z.B. der Wert eines Gebäudes, oder nicht-monetär, z.B. der Wert des geistigen Eigentums eines Unternehmens.

Mehr zum Thema Bewertung von Assets in diesem Beitrag.

Exposure Factor (EF)

Exposure Factor (EF) oder Expositionsfaktor bezieht sich auf den Prozentsatz des Vermögenswerts, der bei einem erfolgreichen Angriff oder Ereignis gefährdet ist. Ein EF von 50% bedeutet beispielsweise, dass die Hälfte des Wertes bei einem Angriff verloren gehen kann.

Single Loss Expectancy (SLE)

Single Loss Expectancy (SLE) oder Einzelverlust-Erwartung bezieht sich auf den monetären Wert, den ein Unternehmen verliert, wenn eine Bedrohung erfolgreich ist. Es wird berechnet, indem der Vermögenswert mit dem Expositionsgrad multipliziert wird. Zum Beispiel, wenn ein Gebäude im Wert von 1 Million Euro einem EF von 50% ausgesetzt ist, dann ist das SLE 500.000 Euro.

SLE Formel

Single loss expectancy (SLE) = Asset value (AV) × Exposure factor (EF)

Annualized Rate of Occurrence (ARO)

Annualized Rate of Occurrence (ARO) oder Jahresfrequenz bezieht sich auf die Anzahl der erwarteten Vorfälle innerhalb eines Jahres. Zum Beispiel, wenn es wahrscheinlich ist, dass es im Durchschnitt alle fünf Jahre zu einem Brand im Gebäude kommt, beträgt die ARO 0,2.

Annual Loss Expectancy (ALE)

Annual Loss Expectancy (ALE) oder Jahresverlust-Erwartung bezieht sich auf den erwarteten monetären Verlust pro Jahr, der aufgrund einer Bedrohung auftritt. Es wird berechnet, indem das SLE mit der ARO multipliziert wird. Zum Beispiel, wenn das SLE 500.000 Euro beträgt und die ARO 0,2 beträgt, beträgt die ALE 100.000 Euro pro Jahr.

Diese Begriffe sind wichtig, um eine fundierte Entscheidung darüber zu treffen, welche Schutzmaßnahmen erforderlich sind, um das Unternehmen zu schützen. Durch die Berechnung der ALE können Unternehmen die potenziellen Kosten von Sicherheitsmaßnahmen im Vergleich zum erwarteten Verlust abschätzen und eine Kosten-Nutzen-Analyse durchführen.

ALE Formel

Annual loss expectancy (ALE) = SLE × ARO

Rechenbeispiel: Verlust eines Laptops.

Unternehmen: KMU mit ca. 150 Mitarbeiter, jährlich werden 2 Laptops als verloren gemeldet.

Um eine quantitative Risikoanalyse für den Verlust eines Laptops in einem Unternehmen mit 150 Mitarbeitern durchzuführen, benötigen wir einige Schätzungen und Annahmen bezüglich der Kosten, des Aufwands und der Arbeitszeit, die mit dem Verlust verbunden sind.

Asset value (AV): Schätzen Sie den Wert eines Laptops, einschließlich der Kosten für die Hardware, Software und die darin enthaltenen Informationen. Angenommen, der Wert eines Laptops beträgt 2.000 Euro.

Exposure factor (EF): Schätzen Sie den Prozentsatz des Asset-Werts, der durch den Verlust betroffen ist. Da bei einem verlorenen Laptop sowohl die Hardware- als auch die Software-Kosten betroffen sind, setzen wir den EF auf 100% oder 1.

Single loss expectancy (SLE): Berechnen Sie den SLE, indem Sie den Asset-Wert (AV) mit dem Exposure Factor (EF) multiplizieren. In diesem Fall beträgt der SLE 2.000 Euro × 1 = 2.000 Euro.

Annual rate of occurrence (ARO): Berechnen Sie die durchschnittliche Anzahl der verlorenen Laptops pro Jahr. In einem Unternehmen mit 150 Mitarbeitern gehen jährlich 2 Laptops verloren. Daher beträgt der ARO 2.

Annual loss expectancy (ALE): Berechnen Sie den ALE, indem Sie den SLE mit dem ARO multiplizieren. In diesem Fall beträgt der ALE 2.000 Euro × 2 = 4.000 Euro.

Die quantitative Risikoanalyse zeigt also, dass das Unternehmen jährlich mit einem Verlust von 4.000 Euro rechnen muss, der sich aus dem Verlust von Laptops ergibt. Dies beinhaltet jedoch noch nicht die Kosten und den Aufwand, die mit der Arbeitszeit verbunden sind.

Arbeitszeiten, Aufwand

Um die Arbeitszeit und den Aufwand zu schätzen, betrachten wir folgende Faktoren:

Zeit für die Beschaffung und Einrichtung eines Ersatzgeräts: Angenommen, es dauert 4 Stunden, um einen neuen Laptop zu beschaffen und einzurichten. Bei einem Stundensatz von 50 Euro entstehen hierdurch Kosten von 200 Euro.

Zeit für die Wiederherstellung von Daten und Projekten: Angenommen, es dauert 8 Stunden, um Daten und Projekte vom Backup auf den neuen Laptop zu übertragen. Bei einem Stundensatz von 50 Euro entstehen hierdurch Kosten von 400 Euro.

Insgesamt beträgt der Aufwand für die Arbeitszeit pro verlorenem Laptop 200 Euro + 400 Euro = 600 Euro. Da pro Jahr 2 Laptops verloren gehen, entstehen jährliche Kosten von 1.200 Euro aufgrund von Arbeitszeit und Aufwand.

Zusammenfassend belaufen sich die geschätzten jährlichen Kosten für den Verlust von Laptops in einem Unternehmen mit 150 Mitarbeitern auf 4.000 Euro (ALE) + 1.200 Euro (Arbeitszeit und Aufwand) = 5.200 Euro.

Vor- und Nachteile: qualitative vs. quantitative Risikoanalyse in der Informationssicherheit

Im Bereich der Informationssicherheit ist es wichtig, potenzielle Bedrohungen für das Netzwerk zu identifizieren und geeignete Gegenmaßnahmen zu ergreifen. Hierbei kommen verschiedene Methoden zum Einsatz, darunter die qualitative und die quantitative Risikoanalyse.

Die quantitative Risikoanalyse verwendet Zahlen und monetäre Werte, um das Risiko zu bewerten, während die qualitative Risikoanalyse auf der Bewertung von Szenarien und der Einschätzung der Bedrohung durch Expertenmeinungen basiert. Beide Methoden haben ihre Vor- und Nachteile und sollten je nach den spezifischen Anforderungen und Gegebenheiten des Unternehmens eingesetzt werden.

Vor- und Nachteile der quantitativen Risikoanalyse

Zu den Vorteilen der quantitativen Risikoanalyse gehört die Möglichkeit, das Risiko auf der Grundlage von Zahlen und monetären Werten zu bewerten, was die Diskussion von Kosten- und Nutzenaspekten erleichtert. Allerdings kann die Berechnung komplex sein und die Geschäftsleitung kann Schwierigkeiten haben, die abgeleiteten Werte zu verstehen. Ohne automatisierte Tools kann dieser Prozess auch sehr mühsam sein. Mehr Vorarbeit ist erforderlich, um detaillierte Informationen über die Umgebung zu sammeln, und es gibt keine Standards, was bedeutet, dass jeder Anbieter seine eigene Art hat, die Prozesse und Ergebnisse zu interpretieren.

Vor- und Nachteile der qualitativen Risikoanalyse

Die qualitative Risikoanalyse bietet die Möglichkeit, potenzielle Bedrohungen und Gegenmaßnahmen auf der Grundlage von Expertenmeinungen und Szenarien zu bewerten. Dies kann zu einer schnelleren und einfacheren Identifizierung von Bedrohungen führen. Allerdings sind die Bewertungen und Ergebnisse subjektiv und meinungsbasiert, was zu Einschränkungen bei der Entwicklung eines Sicherheitsbudgets führen kann. Es gibt auch keine monetären Werte, die für die Diskussion von Kosten- und Nutzenaspekten verwendet werden können. Wie bei der quantitativen Methode gibt es ebenfalls keine verpflichtende Standards.

Zusammengefasst lässt sich sagen, dass bei der Entscheidung für qualitative vs. quantitative Risikoanalyse ein Unternehmen seine spezifischen Anforderungen und Gegebenheiten berücksichtigen sollte.

Fazit: qualitative vs. quantitative Risikoanalyse

Sowohl die quantitative als auch die qualitative Risikoanalyse haben ihre Vor- und Nachteile und können je nach Situation und Umgebung unterschiedlich sinnvoll sein. Die Wahl der Methode hängt von verschiedenen Faktoren ab, wie zum Beispiel der Verfügbarkeit von Ressourcen, dem Umfang der Analyse und der Art der Risiken.

Für Unternehmen, die sich auf quantitative Daten verlassen, kann die quantitative Risikoanalyse eine bessere Wahl sein. Es ermöglicht ihnen, Risiken zu priorisieren und Entscheidungen auf der Grundlage von Zahlen zu treffen. Auf der anderen Seite kann die qualitative Risikoanalyse eine bessere Wahl für Unternehmen sein, die sich auf Expertenmeinungen und subjektive Bewertungen verlassen möchten.

Es ist auch wichtig zu beachten, dass beide Methoden keine vollständige Lösung für die Risikobewertung darstellen. Sie sind nur Werkzeuge, die zusammen mit anderen Maßnahmen wie der Implementierung von Sicherheitskontrollen und der Überwachung von Risiken verwendet werden sollten.

Unternehmen sollten insgesamt eine Risikobewertung durchführen und die am besten geeignete Methode für ihre Anforderungen auswählen. Dabei ist es entscheidend, die Analyseergebnisse als Basis für fundierte Entscheidungen zu nutzen und diese regelmäßig zu überprüfen und zu aktualisieren (KVP!). Auf diese Weise können sie effizient und zeitnah auf sich ständig verändernde Risikofaktoren reagieren.

Weiterführende Materialien

In diesem Beitrag finden Sie einen Fragebogen, der bei der Entscheidung, welche Risikoanalyse – qualitative oder quantitative – für Ihr Vorhaben am besten geeignet ist, hilft.

Der Beitrag Qualitative vs. quantitative Risikoanalyse erschien zuerst auf Ilja Schlak InfoSec Blog.

Optimale Bewertung von Assets Mindmap

Diese Mindmap stellt wichtige Punkte und Schritte für die optimale Bewertung von Assets dar

Der Beitrag Bewertung von Assets erschien zuerst auf Ilja Schlak InfoSec Blog.

OCTAVE-Risikomanagement: Umfassende Methode zur Identifizierung und Steuerung von Informationssicherheitsrisiken

Die Bedeutung der Informationssicherheit in der digitalen Welt von heute ist für Unternehmen unbestreitbar. Um Risiken effektiv zu managen, ist der Einsatz einer geeigneten Risikobewertungsmethode entscheidend. In diesem Artikel dreht sich alles um die OCTAVE-Risikomanagementmethode. OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) hat sich als wertvolles Instrument für das Risikomanagement in Organisationen etabliert.

Was ist OCTAVE-Risikomanagement?

Entwickelt vom Software Engineering Institute (SEI) der Carnegie Mellon University, ist OCTAVE eine Methode zur Risikobewertung im Bereich der Informationssicherheit. OCTAVE legt besonderen Wert darauf, dass die Mitarbeiter innerhalb einer Organisation am besten wissen, welche Sicherheitsanforderungen notwendig sind und welche Risiken vorliegen.
Es gibt viele Frameworks und Methoden für das Risikomanagement, aber OCTAVE bietet einen umfassenderen Ansatz. OCTAVE betrachtet alle Systeme, Anwendungen und Geschäftsprozesse innerhalb einer Organisation.

Die verschiedenen OCTAVE-Methoden: OCTAVE, OCTAVE-S und OCTAVE Allegro

Es gibt drei unterschiedliche OCTAVE-Methoden für den öffentlichen Gebrauch: OCTAVE, OCTAVE-S und OCTAVE Allegro. Jede Methode hat eine breite Anwendbarkeit. Organisationen sollten jedoch den Ansatz wählen, der am besten zu ihren Anforderungen für die Bewertung von Informationssicherheitsrisiken passt.

OCTAVE

Die OCTAVE-Methode richtet sich an große Organisationen mit 300 oder mehr Mitarbeitern und wird in Workshops durchgeführt. Sie besteht aus drei Phasen und wurde für Organisationen mit mehrschichtiger Hierarchie entwickelt, die zudem noch ihre eigene IT-Infrastruktur betreiben und Schwachstellenbewertungen durchführen können.

OCTAVE-S

OCTAVE-S ist für Organisationen mit etwa 100 oder weniger Mitarbeitern konzipiert und wird von einem Analyseteam durchgeführt, das über umfangreiches Wissen über die Organisation verfügt. Im Gegensatz zur OCTAVE-Methode ist OCTAVE-S stärker strukturiert und erfordert eine weniger umfangreiche Untersuchung der Informationsinfrastruktur.

OCTAVE Allegro

OCTAVE Allegro konzentriert sich hauptsächlich auf Informationsvermögenswerte im Kontext ihrer Nutzung, Speicherung, Transport und Verarbeitung sowie ihrer Anfälligkeit für Bedrohungen, Schwachstellen und Störungen. Diese Methode besteht aus acht Schritten, die in vier Phasen organisiert sind und sowohl in einem Workshop-ähnlichen Umfeld als auch von Einzelpersonen ohne umfangreiche organisatorische Beteiligung durchgeführt werden können.
In diesem Beitrag betrachten wir OCTAVE Allegro näher.

OCTAVE Allegro: Vier Phasen, acht Schritte

Die OCTAVE-Methodik umfasst acht aufeinander aufbauende Schritte, die in vier Phasen unterteilt sind:

Phase 1: Bestimmende Faktoren festlegen

Schritt 1: Kriterien zur Risikomessung etablieren.
In dieser Phase geht es darum, die Methoden und Bewertungskriterien für die Risikoanalyse innerhalb einer Organisation zu entwickeln und zu definieren. OCTAVE setzt auf eine qualitative Bewertungsweise und Messungen, ermöglicht jedoch den Einsatz quantitativer Verfahren für spezifische Elemente des gesamten Prozesses, wie etwa die Ermittlung von Eintrittswahrscheinlichkeiten und Folgen.

Phase 2: Vermögenswert-Profile erstellen

Schritt 2: Profil für Informationsvermögenswerte anlegen.
Während dieses Schrittes erarbeitet die Organisation ein Profil für ihre Vermögenswerte, welches eine Sammlung von Informationen umfasst, die den jeweiligen Vermögenswert charakterisieren – darunter zählen Aspekte wie Eigenschaften, Prioritäten, Auswirkungen auf die Organisation und dessen Wert. Das Profil beinhaltet zudem potenzielle Sicherheitsanforderungen, die für den Vermögenswert relevant sein könnten.

Schritt 3: Speicherorte für Informationsvermögenswerte ermitteln.
Der Speicherort eines Informationsvermögenswerts zeigt, wie Daten aufbewahrt, bearbeitet und übermittelt werden. Solche Speicherorte umfassen in der Regel Netzwerke und Systeme, sowohl solche, die von der Organisation selbst betrieben werden, als auch solche, die ausgelagert sind.

Phase 3: Gefahren erkennen

Schritt 4: Kritische Bereiche aufdecken.
In diesem Schritt werden mögliche Risikofaktoren erfasst und für die Erstellung von Gefahrenszenarien genutzt.

Schritt 5: Gefahrenszenarien ausfindig machen.
Im Rahmen von OCTAVE stellen Gefahrenszenarien verschiedene Kategorien von Beteiligten und die zugehörigen Gefahren jeder Kategorie dar. Üblicherweise werden diese Szenarien durch einen Gefahrenbaum ermittelt, der Beteiligte und Szenarien veranschaulicht.

Phase 4: Risiken identifizieren und reduzieren

Schritt 6: Risiken identifizieren.
In diesem Schritt werden Folgen, wie etwa Auswirkungen und Eintrittswahrscheinlichkeiten, ermittelt und bewertet, um das Risiko besser einschätzen zu können.

Schritt 7: Risiken auswerten.
Nachdem die Auswirkungen und Wahrscheinlichkeiten erfasst und bewertet wurden, erfolgt die Analyse der Risiken. In diesem Schritt entstehen Risikoeinschätzungen, die auf der Bewertung von Auswirkungen und Wahrscheinlichkeiten basieren. Dabei liegt der Fokus insbesondere auf den Auswirkungen, da die Bewertung vermögensorientiert ist.

Schritt 8: Minderungsmaßnahmen auswählen.
In diesem Schritt werden Strategien zur Risikominderung entwickelt, geprüft und vorgeschlagen.

OCTAVE-Risikomanagement-Mindmap

Dieses Bild zeigt die Phasen und Schritte der OCTAVE Methode zur Risikoidentifikation und Risikomanagement

Der Beitrag OCTAVE – Risikomanagement erschien zuerst auf Ilja Schlak InfoSec Blog.

Informations­sicherheitsleitlinie eines Unternehmens

Die Informationssicherheitsleitlinie eines Unternehmens ist ein wichtiges Dokument, das die Grundsätze der Informationssicherheit und die Erwartungen des Unternehmens in Bezug auf den Umgang mit Informationen darlegt. Die Leitlinie ist ein wesentlicher Bestandteil des Informationssicherheits­managementsystems (ISMS) eines Unternehmens und sollte von allen Mitarbeitern und Führungskräften verstanden und umgesetzt werden.

Übernahme der Verantwortung durch das Top-Management

Bei der Anpassung von organisationsweiten Prozessen spielt die Zustimmung und Unterstützung der Leitungsebene eine entscheidende Rolle. Viele Informationssicherheitsstandards – wie zum Beispiel die ISO/IEC 27001 fordern explizit, dass das Topmanagement die Gesamtverantwortung für die Informationssicherheit innerhalb der Organisation nachweislich übernehmen muss. Zudem muss es die Bedeutung eines effektiven ISMS sowie die Einhaltung der Anforderungen an die betroffenen Mitarbeiter kommunizieren. Eine wichtige Rolle bei der Kommunikation dieser Anforderungen spielt die Informationssicherheits­leitlinie (Information Security Policy).

Businessziele

Die Businessziele sollten die Erstellung, Implementierung und Durchsetzung der Leitlinie antreiben. Ein wichtiger Aspekt bei der Erstellung der Informationssicherheitsleitlinie ist, dass die Businessziele des Unternehmens im Mittelpunkt stehen sollten. Die Informationssicherheitsleitlinie sollte nicht die Businessziele des Unternehmens beeinflussen oder vorschreiben, sondern vielmehr sicherstellen, dass die Businessziele auf eine sichere und verantwortungsvolle Weise erreicht werden. Die Leitlinie sollte demnach in enger Zusammenarbeit mit dem Management und den Fachbereichen des Unternehmens erstellt werden. So ist es gewährleistet, dass das zu erstellende Dokument den Bedürfnissen des Unternehmens entspricht.

Die Informations­sicherheits­leitlinie sollte leicht verständlich sein und als Referenzpunkt dienen

Ein weiterer wichtiger Aspekt der Informationssicherheitsleitlinie ist, dass sie leicht verständlich sein sollte. Das Dokument sollte als Referenzpunkt für alle Mitarbeiter und Führungskräfte dienen und klar und deutlich formuliert sein. Darüber hinaus sollte die Informationssicherheitsleitlinie auch regelmäßig aktualisiert werden, um sicherzustellen, dass sie auf dem neuesten Stand ist und den sich ändernden Bedürfnissen des Unternehmens entspricht.

Integration in alle Geschäftsfunktionen und -prozesse

Ein wichtiger Aspekt der Informationssicherheitsleitlinie ist, dass sie in alle Geschäftsfunktionen und -prozesse integriert werden sollte. Die Leitlinie sollte sicherstellen, dass die Informationssicherheit in alle Aspekte des Unternehmens eingebettet ist, von der Beschaffung über die Entwicklung bis hin zur Wartung von IT-Systemen und der Sicherstellung der physischen Sicherheit von Räumlichkeiten und Geräten.

Berücksichtigung aller geltenden Gesetze und Vorschriften

Ein weiterer wichtiger Aspekt der Informationssicherheitsleitlinie ist, dass sie alle geltenden Gesetze und Vorschriften berücksichtigen sollte, die für das Unternehmen relevant sind.

Regelmäßige Überprüfung und Anpassung

Die Informationssicherheitsleitlinie eines Unternehmens sollte regelmäßig überprüft und angepasst werden, um sicherzustellen, dass sie den aktuellen Bedürfnissen und Anforderungen des Unternehmens entspricht. Änderungen des Geltungsbereiches, Änderungen im Geschäftsmodell, Fusionen oder Übernahmen sowie Veränderungen in der Unternehmensführung können Änderungen an der Leitlinie erfordern.

Datierung und Versionierung der Leitlinie

Um sicherzustellen, dass alle Mitarbeiter die aktuelle Version der Leitlinie verwenden, sollte jede Überarbeitung der Leitlinie datiert und versioniert werden. Auf diese Weise kann auch nachvollzogen werden, wann und welche Änderungen vorgenommen wurden. Hierzu gehören beispielsweise der Verfasser, der Überprüfer, Unterzeichner und so weiter.

Bekanntmachung

Die Art der Bekanntmachung der Informationssicherheitsleitlinie hängt von den spezifischen Anforderungen und Bedürfnissen des Unternehmens ab. In vielen Fällen wird die Leitlinie über interne Kommunikationskanäle wie das Intranet oder E-Mail-Verteiler veröffentlicht. Dabei ist es wichtig, dass die Leitlinie für alle Mitarbeiter leicht zugänglich ist und regelmäßig aktualisiert wird. Darüber hinaus kann es sinnvoll sein, eine Schulung oder ein Training für Mitarbeiter zu organisieren, um sicherzustellen, dass sie die Leitlinie vollständig verstehen und umsetzen können.

Beispielsweise könnte die Informationssicherheitsleitlinie eines Unternehmens in Form eines PDF-Dokuments auf dem Intranet zur Verfügung gestellt werden, das regelmäßig aktualisiert wird, um sicherzustellen, dass alle Mitarbeiter Zugriff auf die neueste Version haben. Das Unternehmen könnte auch eine regelmäßige E-Mail an alle Mitarbeiter senden, in der sie auf die Leitlinie und Änderungen hingewiesen werden. Eine Schulung oder ein Training könnte durchgeführt werden, um sicherzustellen, dass alle Mitarbeiter das Bewusstsein und Verständnis für die Sicherheitsrisiken haben und wissen, wie sie sich in Übereinstimmung mit der Leitlinie verhalten sollen.

Zugänglichkeit der Leitlinie für alle betroffenen Einheiten und Mitarbeiter

Es ist wichtig, dass alle Abteilugen und Mitarbeiter einfachen Zugang zu ihr haben. Die Leitlinie sollte daher auf einem Portal im Intranet des Unternehmens veröffentlicht werden. Dadurch können alle Mitarbeiter schnell und einfach auf die Leitlinie zugreifen und sie überprüfen, wenn sie Fragen zur Informationssicherheit haben. Es ist notwendig, dass die Mitarbeiter genau wissen, an wen sie sich bei Fragen zur Leitlinie wenden sollen. In der Regel sind es Informationssicherheitskoordinatoren, Information Security Officer (ISO), Chief Information Security Officer (CISO), Informationssicherheitsbeauftragte (ISB) und ähnlich gelagerte Positionen.

Die Implementierung einer umfassenden Informationssicherheitsleitlinie kann Unternehmen helfen, ihre vertraulichen Daten und Informationen zu schützen und das Vertrauen ihrer Kunden zu stärken. Indem die Leitlinie regelmäßig aktualisiert und angepasst wird und allen Mitarbeitern leicht zugänglich gemacht wird, kann das Unternehmen sicherstellen, dass es immer auf dem neuesten Stand der Informationssicherheit bleibt.

Exkurs: Dokumentenlenkung

In der Dokumentenlenkung geht es darum sicherzustellen, dass Dokumente systematisch und nachvollziehbar erstellt, geprüft, verteilt und entsorgt werden. Diese Praktiken werden auch als “Lenkung von Aufzeichnungen” oder “Lenkung von Dokumenten” bezeichnet. Im Qualitätsmanagement spricht man seit der DIN EN ISO 9001:2015 von der “Lenkung dokumentierter Information”, die Dokumente, Daten, externe Dokumente, Formulare, Checklisten, Aufzeichnungen, Prozessbeschreibungen und Arbeitsanweisungen umfasst. Die Dokumentenlenkung gewährleistet die Integrität und Nachvollziehbarkeit von Dokumenten und ist damit ein entscheidender Bestandteil der Organisation.

Verschiedene Aspekte der Dokumentenlenkung

Um verschiedene Aspekte von Dokumenten zu steuern, fordert die ISO 9001:2015 (genaueres zur ISO 9001) ein dokumentiertes Verfahren, das die Identifizierung, Aufbewahrung, Schutz, Wiederauffinden, Aufbewahrung, Überprüfung, Freigabe, Disposition, Lesbarkeit und Nachverfolgung von Änderungen umfasst. Die Dokumentenlenkung unterstützt Unternehmen dabei, organisiert und agil zu bleiben, insbesondere wenn sie wachsen. ISO 9001-zertifizierte Unternehmen müssen diese Praktiken lückenlos und umfassend umsetzen, um ein erfolgreiches Qualitätsmanagement-Audit zu bestehen.

Wann gilt ein Dokument als “gelenkt”?

Ein Dokument gilt im Sinne der ISO 9001 als gelenkt, wenn jeder Schritt seines Werdegangs, von der Erstellung über die Überprüfung, Genehmigung, Verteilung bis hin zum Einzug alter Versionen, festgelegt und jederzeit nachvollziehbar ist. Wie genau diese Praktiken umgesetzt werden, bleibt den Unternehmen selbst überlassen. Die ISO 9001 gibt keine Vorgaben dazu, wer Dokumente erstellen oder freigeben darf, wann Dokumente überprüft werden müssen und welche Dokumente gelenkt werden müssen. Es genügt, sich auf die wesentlichen Dokumente zu beschränken, um die Dokumentenlenkung effektiv umzusetzen. Weniger ist mehr.

Langlebigkeit der Informationsicherheitsleitlinie

Die Erstellung einer Informationsicherheitsleitlinie sollte mit der Absicht erfolgen, dass diese über mehrere Jahre hinweg bestehen bleibt.

Exkurs: Entwicklung einer Leitlinie

Die Entwicklung einer Leitlinie erfordert sorgfältige Überlegungen und sollte in Übereinstimmung mit den bestehenden Leitlinien-Entwicklungsmechanismen im Unternehmen erfolgen.

Input von relevanten Stakeholdern einholen

Um sicherzustellen, dass die Leitlinie von allen Mitarbeitern akzeptiert und umgesetzt wird, ist es wichtig, Input von allen relevanten Stakeholdern einzuholen. Die Perspektiven aller Führungskräfte und Teams, die von der Leitlinie betroffen sind, sollten sorgfältig berücksichtigt werden, auch wenn nicht jeder im Unternehmen mit der vorgeschlagenen Leitlinie einverstanden ist.

Befolgung der Hierarchie

Ein Verständnis der Organisationsstruktur ist unerlässlich für den Erfolg einer Leitlinie. Die Einhaltung der offiziellen Governance-Linien und der informellen Mechanismen im Unternehmen sind wichtig, um Unterstützung für die Leitlinie zu gewinnen.

Anpassung an die Organisationskultur

Es gibt keinen universellen Sicherheitsleitfaden, der für alle Unternehmen geeignet ist, da jeder Betrieb anders ist. Daher müssen die Leitlinien auf die Organisationskultur und die “Tonlage an der Spitze” anderer Führungskräfte abgestimmt werden. Aus diesen Überlegungen wird von der Nutzung vorgefertigter Vorlagen oder Templates abgeraten.

Erfüllung interner und externer Anforderungen

IT-Sicherheitsprogramme werden stark von internen Governance-Prozessen und externen Gesetzen und Vorschriften reguliert. Sei es das BSIG, TKG, KRITIS-Verordnungen, in vielen Fällen können diese Anforderungen den Inhalt von Sicherheitsleitlinien vorgeben oder beeinflussen. Die Leitlinien sollten jedoch nicht im Widerspruch zu diesen Anforderungen stehen.

Nach der Erstellung der Leitlinie muss diese durch die Genehmigungsmechanismen des Unternehmens geprüft werden. Nachdem die Leitlinie endgültig genehmigt wurde, kann der CISO oder der ISB die Leitlinie den betroffenen Personen und Teams kommunizieren und mit der Umsetzung beginnen. Je nach Art der Änderung kann dies einen schrittweisen Ansatz erfordern, um das Unternehmen allmählich an die neuen Anforderungen anzupassen.

Zukunftsorientierte Leitlinie

Es ist wichtig, bei der Erstellung einer Informationsicherheitsleitlinie die Zukunft im Blick zu behalten. Technologische Fortschritte und sich ändernde Geschäftsmodelle bringen Veränderungen mit sich. Diese Veränderungen haben oft Auswirkungen auf die Informationsicherheit des Unternehmens. Daher sollten die Richtlinien so gestaltet werden, dass sie flexibel genug sind, um sich an potenzielle Veränderungen anzupassen.

Professionelle Präsentation

Die Präsentation der Informationsicherheitsleitlinie ist ein weiterer wichtiger Aspekt. Eine professionelle Präsentation zeigt, dass das Unternehmen die Bedeutung der Informationsicherheit ernst nimmt. Es ist auch eine Möglichkeit, das Bewusstsein der Mitarbeiter für die Wichtigkeit der Leitlinie zu erhöhen. Eine klare, leicht verständliche Sprache und ein ansprechendes Design können dazu beitragen, die Akzeptanz der Leitlinie zu verbessern.

Zugänglichkeit der Leitlinie

Die Leitlinie sollte für alle Mitarbeiterinnen und Mitarbeiter des Unternehmens leicht zugänglich sein. Eine Möglichkeit ist die Veröffentlichung der Leitlinie auf einem Portal im Intranet. Darüber hinaus ist es wichtig, dass die Mitarbeiterinnen und Mitarbeiter regelmäßig auf die Leitlinie aufmerksam gemacht werden und sich bewusst sind, wo sie zu finden ist. Dadurch wird sichergestellt, dass die Leitlinie jederzeit zur Verfügung steht und die Mitarbeiterinnen und Mitarbeiter in der Lage sind, sie bei Bedarf zu konsultieren.

Klare und verständliche Sprache verwenden

Die Informationssicherheitsleitlinie in einer klaren und verständlichen Sprache zu verfassen, hat enorme Vorteile. Alle Mitarbeiter können sie dadurch verstehen und im Folgenden umsetzen. Die Verwendung von einfachen und prägnanten Aussagen trägt dazu bei, die Bedeutung und Relevanz der Leitlinie zu betonen.

Regelmäßige Überprüfung und Aktualisierung

Die regelmäßige Überprüfung und Aktualisierung der Informationssicherheitsleitlinie ist ein wichtiger Bestandteil des kontinuierlichen Verbesserungsprozesses (KVP). Ein KVP-Prozess ermöglicht es Unternehmen, ihre Leitlinien kontinuierlich zu verbessern.

Eine bewährte Methode zur Durchführung eines KVP ist die Anwendung des PDCA-Zyklus. Der PDCA-Zyklus besteht aus den vier Schritten:

1. Planung (Plan),
2. Durchführung (Do),
3. Überprüfung (Check) und
4. Verbesserung (Act).

Dieser Zyklus kann genutzt werden, um die Informationssicherheitsleitlinie zu überprüfen und zu aktualisieren.

Die Überprüfung sollte auch dazu dienen, festzustellen, ob die Leitlinie tatsächlich umgesetzt wird und ob sie in der Praxis noch immer relevant ist. Gegebenenfalls müssen Änderungen vorgenommen werden, um sicherzustellen, dass die Leitlinie den aktuellen Bedrohungen und Herausforderungen entspricht.

Durch eine regelmäßige Überprüfung und Aktualisierung der Leitlinie kann das Unternehmen sicherstellen, dass es immer auf dem neuesten Stand in Bezug auf die Informationssicherheit ist. Die fortlaufende Aktualisierung des Dokumentes zeigt auch, dass das Unternehmen die notwendigen Maßnahmen zur Wahrung der der Vertraulichkeit, Integrität und Verfügbarkeit seiner Assets ergreift.

Zusammenfassung

Die Erstellung einer Informationssicherheits­leitlinie ist ein wichtiger Schritt für jedes Unternehmen, um die Sicherheit von Informationen und Daten zu gewährleisten. Dabei sind folgende Punkte zu beachten:

• Business-Ziele sollten die Erstellung, Umsetzung und Durchsetzung der Leitlinie bestimmen.
• Top-Down Prinzip. Die Informationssicherheitsleitlinie wird vom Top-Management verabschiedet.
• Informationssicherheit sollte in alle Geschäftsprozesse und -funktionen integriert werden.
• Die Leitlinie sollte von relevanten Gesetzen und Vorschriften des Unternehmens abgeleitet und unterstützt werden.
• Die Leitlinie sollte regelmäßig überprüft und angepasst werden.
• Jede Version der Leitlinie sollte datiert und unter Versionskontrolle stehen.
• Dokumentenlenkung.
• Leicht Zugänglich.
• Die Leitlinie sollte so gestaltet sein, dass sie mehrere Jahre lang in Kraft bleiben kann.
• Berücksichtigung potenzieller Veränderungen.
• Die Leitlinie sollte klare und verständliche Aussagen enthalten.

Schlusswort

Die Implementierung einer Informationssicherheitsleitlinie ist ein wichtiger Schritt, um die Sicherheit von Informationen und Daten in einem Unternehmen zu gewährleisten. Eine sorgfältige Erstellung und regelmäßige Überprüfung der Leitlinie ist von entscheidender Bedeutung. Dies hilft sicherzustellen, dass sie den aktuellen Bedrohungen und Entwicklungen in der IT-Sicherheit gerecht wird. Eine gute Leitlinie sollte klar und verständliche sein. Zudem muss sie von allen Mitarbeitern und dem Management befolgt werden. Dies kann das Vertrauen der Kunden und Partner des Unternehmens stärken und zum Erfolg des Unternehmens beitragen.

Der Beitrag Informations­sicherheitsleitlinie erschien zuerst auf Ilja Schlak InfoSec Blog.

Der Beitrag Die neue ISO 27001 – Änderungen 2022 erschien zuerst auf Ilja Schlak InfoSec Blog.

WINDOWS SERVER ABSICHERN UND HÄRTEN – WEG MIT UNSICHEREN UND ALTEN PROTOKOLLEN UND DIENSTEN

Ein sehr wichtiger Punkt, wenn es um das Absichern und Härten von Windows Servern geht, ist das Deaktivieren unsicherer Protokolle. Das Deaktivieren alter und überholter Dienste.

SMB 1.0

Erstaunlich aber wahr! Wir reden darüber, ob und wie man die Windows Server absichert und härtet, doch es wird tatsächlich immer noch SMB 1.0 eingesetzt. Sogar Microsoft selbst versucht seit 2017 dieses völlig unsicher Protokoll zu meiden. Der großflächige WannaCry Angriff nutzte gerade diese Sicherheitslücke im Jahre 2017.

• Das Protokoll ist schlicht und ergreifend nicht effizient, die Versionen 3.ff. verfügen über viel mehr Performance-Vorteile im Vergleich zu ihrem Vorgänger, siehe Microsoft Docs
• SMB 1.0 hat schon längst EOS erreicht. Das bedeutet keine Updates mehr, keine Fixes. Das ist sicherlich ein wichtiger Grund, um SMB 1.0 nicht mehr zu benutzen.
• Keine Verschlüsselung, wie diese in älteren Protokollen gegeben ist. Auch andere Sicherheitsfeatures fehlen bei SMB 1.0.
• Keine Vorauthentifizierungsintegrität (pre-authentication integrity) und somit kein Schutz vor einem Man-in-the-Middle Angriff.

So findet man heraus, ob SMB 1.0 noch auf dem Windows Server eingesetzt wird

Serverseitig lässt sich das Protokoll mit der Powershell am bequemsten ausfindig machen (es gibt noch andere Wege, z.B. über die Registry und die GPOs):

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Ein Screenshot, an dem man die Ausgabe mit “False” gut sehen kann:

SBM 1.0 deaktivieren

Genau so lässt sich der Dienst mit der Powershell deaktivieren:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Selbstverständlich sollte man die Nutzung des Protokolls im Vorfeld auditieren. Denn falls das Protokoll noch benutzt wird und es zu einer Deaktivierung kommt, kompromittiert es die Produktivität des (Firmen)Netzes.

SMB-Protokolle mit erhöhter Sicherheit

SMB-Protokolle können digital signiert werden. Das hilft enorm beim Vorhaben unsere Windows Server abzusichern und zu härten. Die Signierung hilft das Risiko eines Man-in-the-Middle Angriffes zu minimieren. Zumal

Am einfachsten aktiviert man die Signierung über die Gruppenrichtlinienobjekte – GPO.

Im Grunde genommen gibt es hierfür vier Richtlinien:

• a: Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer),
• b: Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt),
• c: Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer),
• d: Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Serverzustimmt).

Um die Signierung einzurichten sollte man alle vier Richtlinien in Angriff nehmen. Um die Windows Server abzusichern und zu härten müsste man die Einrichtung sowohl server- als auch clientseitig vornehmen. Wenn man nur die Richtlinien mit dem Zusatz “immer” aktiviert, wird folgerichtig die Kommunikation mit den Clients, die die Pakete nicht signieren, nicht stattfinden können. Die Variante “wenn Client zulässt” würde die nicht signierte Kommunikation als eine Art “fallback” nutzen.

Auch bei diesem Schritt sollte man vorher gut überlegen, ob das Produktivnetz die Protokolle benutzt und nicht noch auf SMB 1.0 läuft. Vorherige Sicherung der Einstellungen oder Erstellung von Snapshots wären sicherlich nicht verkehrt.

SMB – Verschlüsselung

Die Kommunikation via SMB lässt sich verschlüsseln. Auch hier gibt es mehrere Möglichkeiten die Verschlüsselung zu aktiveren.

Zum einen ist es natürlich die Powershell:

Set-SmbServerConfiguration -EncryptData $true -Force

Genau so lässt sich die Verschlüsselung in der GUI aktivvieren. Klickt man mit der rechten Maustaste auf eine Freigabe, kann man die Eigenschaften von dieser aufrufen. Im Unterpunkt “Einstellungen” kann die Verschlüsselung aktiviert werden:

Ist die Verschlüsselung aktiviert?

Der schnellste Weg herauszufinden, ob die Verschlüsselung bereits aktiviert ist, bietet die Powershell.

Mit dem Befehl

Get-SmbServerConfiguration

kriegt man die SBM-Einstellungen des Servers recht übersichtlich zu sehen:

Fazit – Windows Server Absichern und härten – SMB

Das Protokoll ist wichtig und wird für den Zugriff auf die Netzwerkfreigaben eingesetzt. Es ist jedoch sehr wichtig die Nutzung des Protokolls zu auditieren. SMB 1.0 wird von Microsoft nur bei wirklich gravierenden Sicherheitsrisiken oder -lücken mit Updates versorgt. Wie lange die Updates für SMB 1.0 überhaupt noch geben wird, ist eher unklar. Die Tendenz geht in die Richtung, dass diese bald eingestellt werden.

Das Protokoll ist darüber hinaus nicht mehr fester Bestandteil des Betriebssystems. Sollte jemand noch SMB 1.0 brauchen, muss das Protokoll als Feature installiert werden.

SMB 1.0 ist ein ernst zu nehmendes Sicherheitsrisiko. Auf die Nutzung des SMB 1.0 zu verzichten, ist ein wichtiger Schritt, um die Windows Server abzusichern und zu härten.

Der Beitrag Windows Server absichern und härten – SMB erschien zuerst auf Ilja Schlak InfoSec Blog.