Teheran Verkehrskameras gehackt: Bericht über jahrelange Überwachung

Der Vorwurf ist brisant – und derzeit nur eingeschränkt verifizierbar: Nahezu alle Verkehrskameras in Teheran sollen über Jahre kompromittiert gewesen sein. Die zentrale Behauptung lautet, dass Videodaten verschlüsselt abgegriffen und an Server in Tel Aviv sowie im Süden Israels übertragen worden seien. Als Quelle wird dabei eine Recherche der Financial Times genannt, die sich auf anonyme Personen aus dem Umfeld israelischer Dienste sowie weitere mit der Operation vertraute Informanten stützt.

Am 3. März 2026 zirkuliert die Geschichte breit in politischen Briefings und Sekundärzusammenfassungen – unter anderem im Overnight Brief der Foundation for Defense of Democracies (FDD). Parallel greifen weitere Medien die Kernaussage auf und verweisen dabei ebenfalls auf die FT-Recherche. Gleichzeitig gilt: Bislang sind keine öffentlich belastbaren technischen Artefakte verfügbar, die den behaupteten Zugriff in der Breite belegen würden – etwa Indicators of Compromise, Malware-Samples, nachvollziehbare Log-Auszüge, Herstellerwarnungen oder offizielle Stellungnahmen der betroffenen Betreiberseite.

Was zum Verkehrskamera Hack in Teheran behauptet wird und was offen bleibt

Im Kern steht die Darstellung einer langfristigen Ausspähung über städtische Sensorik. Verkehrskameras sollen demnach nicht nur punktuell, sondern flächig als Echtzeit-Quelle genutzt worden sein, um Routinen, Bewegungen und Sicherheitsabläufe zu rekonstruieren. Ergänzend ist in der Berichterstattung teils von begleitenden Störungen oder Zugriffsversuchen auf Kommunikationsinfrastruktur die Rede. Wie der Zugriff technisch erreicht worden sein soll (Zugangsweg, Exploit-Kette, Supply-Chain, Insider, physischer Zugriff), bleibt öffentlich unklar. Auch der Umfang – „nahezu alle Kameras“ – ist ohne unabhängige Belege schwer zu prüfen.

Die israelische Zeitung Haaretz greift am 3. März 2026 eine ähnliche Einordnung auf und beschreibt eine breitere Cyber-Komponente, verweist dabei aber ebenfalls auf die zugrunde liegenden Medienangaben.

Warum Verkehrskameras als Ziel so attraktiv sind

Auch ohne bestätigte Details ist der grundsätzliche Reiz solcher Systeme aus Angreifersicht nachvollziehbar: Verkehrskameras und Video-Management-Lösungen sind häufig heterogene IoT/OT-Landschaften. Dazu gehören Edge-Geräte, Funk- und Glasfaseranbindungen, zentrale Video-Management-Systeme (VMS), Network Video Recorder (NVR), Wartungszugänge, Integrator-Zugriffe sowie Mischumgebungen aus IT- und OT-Netzen. Solche Umgebungen wachsen über Jahre (yikyk: “historisch gewachsene Umgebungen”), werden unter Kostendruck erweitert und sind operativ schwer vollständig zu härten.

Ein erfolgreicher Zugriff kann dem Angreifer dann mehrere Vorteile bringen: Echtzeit-Lagebilder, Mustererkennung („pattern of life“), Metadaten über Einsatzrhythmen und indirekte Hinweise auf Sicherheitsstrategien. Entscheidend ist weniger die einzelne Kamera als der Übergang vom Gerät zur zentralen Verwaltung –> wer VMS/NVR oder Wartungszugänge kontrolliert, kann teilweise ungefilterte Echtzeitdaten verwenden.

Wahrscheinliche Angriffsflächen bei Video- und Verkehrssystemen

Wie die Verkehrskameras in Teheran gehackt wurden, ist nicht ganz klar. Da keine technische Kette veröffentlicht ist, lässt sich nur die typische Angriffsoberfläche benennen: unsichere Remote-Management-Pfade, ungepatchte Firmware, verwundbare VMS-Komponenten, zu weitreichende Dienstleisterkonten, schwache Segmentierung und übersehene „Schatten“-Anbindungen (z. B. separate Service-Links). In der Praxis sind es oft nicht spektakuläre Zero-Days, sondern Kombinationen aus Standardproblemen, die Persistenz ermöglichen: schwache Identitäten, fehlende Sichtbarkeit, zu viele implizit vertraute Netzübergänge. Des Weiteren sind Angriffe über die Lieferkette, der Austausch von Systemen oder Systemkomponenten denkbar.

Für Betreiber, die Video- und Verkehrsinfrastruktur verantworten, bleibt daher die Baseline entscheidend: segmentierte Netze, minimierte Fernzugriffe, harte Identitäten (MFA/Device-Binding), belastbare Patch- und EoL-Prozesse, Lieferkettensicherheit sowie Telemetrie auf Abflussindikatoren. Gerade bei Video-Streams ist „Datenabfluss“ nicht zwingend ein großer, auffälliger Datentransfer – häufig reicht ein kontinuierlicher, verschlüsselter Strom, der im Grundrauschen untergeht, wenn Monitoring und Schwellenwerte fehlen.

Wie sicher sind die Verkehrskameras in Deutschland?

Ein zusätzlicher Blick auf deutsche KRITIS-Realitäten illustriert, warum stille Exfiltration in der Praxis lange unentdeckt bleiben kann – selbst in regulierten Sektoren. Das BSI veröffentlicht mit „KRITIS in Zahlen“ Auswertungen auf Basis der jeweils zuletzt eingereichten Nachweise. In der Darstellung zu Systemen zur Angriffserkennung im Sektor Transport und Verkehr (Stichtag 31.12.2025) wird eine Verteilung ausgewiesen, die auf strukturelle, nahezu gravierende Detektionslücken hindeutet.

Unterhalb von Reifegrad 3 (also Umsetzungsgrad 0–2) liegen 61 kritische Anlagen – das entspricht rund 73,5 Prozent! Anders formuliert: Fast drei Viertel befinden sich in einem Bereich, der per Definition über keine nennenswerte Angriffserkennung verfügt. In Kombination mit Business-Continuity- und Informationssicherheitsmanagementsystemen, die nur auf Konformität ausgerichtet sind, ist dies eine äußerst ungünstige und beunruhigende Situation.
gebe den ganzen part, der den deutschen sektor betrifft aus

Wie sicher sind Verkehrskameras in Deutschland?

Verkehrskameras sind in Deutschland selten isolierte Endgeräte. In der Praxis sind sie Teil gewachsener ITS-/OT-Systemverbünde aus Verkehrsrechnern, Leitstellen, Tunnelleitzentralen, Netzwerk- und Funkanbindungen, Wartungszugängen sowie Video-Management-Systemen. Das Risiko entscheidet sich daher weniger am einzelnen Gerät, sondern an zentralen Management-Komponenten, privilegierten Remote-Zugängen und den Netzübergängen zwischen IT und OT.

BSI-Perspektive im Sektor Transport und Verkehr – Systeme zur Angriffserkennung sind der Flaschenhals

Ein harter Indikator für Detektionsfähigkeit ist die Umsetzung und der wirksame Betrieb von Systemen zur Angriffserkennung (SzA). In der BSI-Auswertung „KRITIS in Zahlen“ zu den Umsetzungsgraden der SzA im Sektor Transport und Verkehr (Stichtag 31.12.2025) liegen 61 von 83 kritischen Anlagen unterhalb von Umsetzungsgrad 3. Rund 73,5 Prozent der vom BSI geprüften KRITIS-Anlagen im Sektor Transport und Verkehr sind derzeit nicht mit einer nennenswerten Angriffserkennung ausgestattet.

Der Umsetzungsgrad 2 gemäß der Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung lautet:

In allen Bereichen wurde mit der Umsetzung von Maßnahmen zur Erfüllung der Anforderungen begonnen. Es sind noch nicht alle MUSS-Anforderungen erfüllt worden.

Das bedeutet also: es sind nicht einmal die Basics der Basics umgesetzt!

Rechnungshof-Kritik an der Autobahn GmbH – Cyberrisiko wird physisch

Wie schnell sich „Cyber“ in operativen und physischen Impact übersetzt, zeigt die Berichterstattung über einen vertraulichen Prüfbericht des Bundesrechnungshofs, wie er im Beitrag „Rechnungshof kritisiert massive Cyberrisiken bei Autobahn GmbH“ aufgegriffen wird. Demnach habe die Autobahn GmbH bei strategischen Entscheidungen wesentliche Aspekte wie Informations- und Cybersicherheit, digitale Souveränität und langfristige Wirtschaftlichkeit nicht als verbindliche strategische Ziele verankert.

Laut Bericht habe die Gesellschaft nicht systematisch geprüft, ob die erhöhten IT-Sicherheitsanforderungen Konsequenzen für ihre IT-Strategie haben müssen. Das ist bemerkenswert, weil das Unternehmen über digitale Systeme den Verkehr auf mehr als 13.000 Kilometern Autobahn steuert, einschließlich dezentraler Leitstellen und überregionaler Tunnelzentralen.

Im Kern ist das ein Governance-Befund. Der Rechnungshof kritisiert, dass bis heute keine klare IT-Gesamtverantwortung etabliert sei. Es fehle eine zentrale Organisationseinheit mit durchgängiger Zuständigkeit, stattdessen seien mehrere Geschäftsführungsbereiche fragmentiert verantwortlich gewesen. Hinweise externer Prüfer und der internen Revision seien nicht konsequent zentral umgesetzt worden, vielmehr habe man die Mängelbeseitigung den regionalen Niederlassungen überlassen.

Deutschland als logistische Drehscheibe Europas und der NATO braucht wirksame SzA

Deutschland ist die logistische Drehscheibe Europas und der NATO. Wenn Verlegung und Versorgung über Deutschland laufen, ist der Sektor Transport und Verkehr nicht nur Infrastruktur, sondern ein direkter Faktor für Einsatzfähigkeit und Resilienz.

Ein SzA-Umsetzungsgrad 2 ist dafür zu wenig. Wer Hub ist, muss Angriffe früh erkennen, sonst bleiben kompromittierte Fernwartung, laterale Bewegung oder leiser, verschlüsselter Datenabfluss zu lange unsichtbar. Das Risiko sitzt nicht an der einzelnen Kamera, sondern an Übergängen, Dienstleisterkonten und zentralen Managementsystemen, die am Ende alles miteinander verbinden.

Der Verkehrssektor ist sicherheitspolitisch relevant. Ein erfolgreicher Angriff kann demnach nicht nur Daten betreffen, sondern unmittelbar Betriebs- und Sicherheitsfunktionen, etwa durch Manipulation von Verkehrsanzeigen oder durch erzwungene Einschränkungen im Tunnelbetrieb. Zusätzlich wird die Rolle des Autobahnnetzes in Krisen- und Bündnisfällen betont, weil es für den schnellen Transport von Truppen und Material durch Deutschland eine zentrale logistische Achse darstellt.

Vorfälle im Sektor – Verfügbarkeit und Lieferkette sind Dauerbrenner

Auch ohne „Kamera-Hack“ zeigen reale Ereignisse, wie verwundbar digitale Verkehrsdienste sind. Die Deutsche Bahn dokumentiert im DB-Newsblog, dass ab dem 17.02.2026 eine DDoS-Attacke die Auskunfts- und Buchungssysteme beeinträchtigte, einschließlich bahn.de und der App DB Navigator.

Parallel bleibt die Lieferkette ein wiederkehrender Risikotreiber. Die BVG beschreibt in ihrem Statement zum IT-Angriff bei einem externen Dienstleister (Mai 2025), wie schnell Drittparteien auch ohne direkte Kompromittierung der Kernsysteme zu relevanten Auswirkungen führen können.

Warum stille Kompromittierung in Verkehrsumgebungen realistisch bleibt

Die strukturellen Bedingungen im Sektor begünstigen Persistenz. OT wurde historisch auf Robustheit und Verfügbarkeit ausgelegt, nicht auf eine dauerhaft feindliche Cyberumgebung. In der Praxis wird „Air-Gap“ zudem durch Fernwartung, Integrator-Zugänge und Diagnosepfade aufgeweicht. Für Verkehrskameras heißt das: Der primäre Risikofokus liegt auf den zentralen Plattformen, Identitäten und Netzübergängen. Wer Video-Management, Wartungskonten oder Leitstellenanbindungen kontrolliert, kann im Zweifel sowohl Vertraulichkeit (Abfluss) als auch Integrität (Manipulation) adressieren.

Der Beitrag Teheran Verkehrskameras gehackt – Wie sicher sind die Verkehrskameras in Deutschland? erschien zuerst auf Ilja Schlak InfoSec Blog.

Messbarkeit ist dabei, vom „Nice-to-have“ oder “Ja, ich hatte das mal in einer Schulung gesehen…” zum harten Erwartungswert an Security-Führung zu werden. Es kristallisiert sich ein klarer Trend heraus: CISOs sollen nicht mehr nur Anforderungskonformität nachweisen, sondern belastbar zeigen, wo ein Unternehmen wirklich angreifbar ist – und was das geschäftlich bedeutet. Genau diese Verschiebung beschreibt ein heute veröffentlichter Beitrag bei Frontier Enterprise als neue Normalität: Security wird als Governance-Thema gelesen, und Governance verlangt Metriken, Zahlen, KPIs!

Der Begriff „Exposure“ ist dabei mehr als ein neues Label für Schwachstellen-Management. Gemeint ist die quantitative Sicht auf reale Angriffsflächen: Welche Schwachstellen, Fehlkonfigurationen, Identitäten und Abhängigkeiten ergeben zusammengenommen plausible Angriffspfade – und wie priorisiert man diese Pfade so, dass sie im Business-Kontext erklärbar bleiben? Die zentrale These:

Exposure Quantification für CISOs wird zum Werkzeug, um Security-Entscheidungen über Budget, Prioritäten und Verantwortlichkeiten datenbasiert zu führen.

Was ist Exposure Quantification?

Exposure Quantification ist die systematische, fortlaufende Quantifizierung der tatsächlichen Angriffs-Exponierung einer Organisation – also nicht „wie viele Findings gibt es?“, sondern „wie nah ist ein Angreifer heute realistisch an den Kronjuwelen bzw. (zeit)kritischen Geschäftsprozessen – und wie verändert sich das messbar über Zeit?“. Dazu werden Signale aus IT, Cloud und Identitäten zusammengeführt, in Beziehung gesetzt und als Kennzahlen operationalisiert, die sich für Steuerung eignen (Trend, Priorisierung, Wirksamkeit). Der Kern ist Kontext: Ein isoliertes CVE mit hohem CVSS kann operativ nebensächlich sein, während eine mittelmäßige Schwachstelle in Kombination mit der Kritikalität des Assets, erreichbaren Services (Exponiertheit), schwachen Berechtigungen und fehlenden Segmentierungen einen belastbaren Angriffspfad ergibt – genau dieses „Verketten“ zu Attack Paths ist zentral für Quantifizierung, wie es Frontier Enterprise heute beschreibt.

Konkrete Beispiele für die Exposure Quantification

1. Ein Internet-exponierter API-Endpoint + eine Fehlkonfiguration im IAM (zu breite Rollen) + ein erreichbares Secrets-Repository: Exposure Quantification misst hier nicht drei Einzelfehler, sondern z. B. „1 bestätigter Pfad zu Produktions-Secrets“ und verfolgt, wie schnell der Pfad geschlossen wird (Zeit bis Rechteentzug, Fix-Rollout, Residual-Exposure).
2. Für Patch-Programme wird nicht nur „Patch-Rate“ berichtet, sondern der Anteil „ungepatcht & erreichbar & Pfad-relevant“ sowie die Entwicklung dieser Kennzahl – das ist vorstandstauglicher als bloße Anzahl an Findings.
3. Für Cloud-Umgebungen werden Exposures als „Blast Radius“ (potenzielle Schadensreichweite) quantifiziert, etwa: „X Workloads können lateral auf Y Datenbanken zugreifen, weil Network Policies fehlen“, inklusive Priorität nach Datenkritikalität.

Warum Exposure Quantification für CISOs jetzt zählt

Der Druck entsteht vor allem aus der Dynamik moderner Umgebungen. Hybrid-Clouds, schnelllebige Deployments und die wachsende Nutzung von KI-Tools verändern Angriffsflächen täglich – zu schnell für rein periodische Prüfungen. Der Frontier-Enterprise-Beitrag argumentiert, dass klassische, auditgetriebene Routinen in solchen Umgebungen an Grenzen stoßen und eine kontinuierliche, risikoorientierte Messung ergänzend notwendig wird.

Praktisch heißt das: Nicht „wie viele Findings“ entscheiden, sondern, ob ein Finding in einem relevanten Pfad liegt – etwa weil es mit privilegierten Identitäten, exponierten Services oder sensiblen Datenströmen gekoppelt ist. So wird Exposure Quantification für CISOs auch zur Brücke von technischen Einzelbefunden zu einer konsistenten Risikobetrachtung.

Versicherung und Aufsicht treiben die Quantifizierung

Dass Quantifizierung nicht nur ein internes Steuerungsinstrument ist, sondern auch eine externe Erwartung bedient, unterstreicht eine Analyse von WTW (24. Februar 2026). Dort wird betont, dass analytische Cyber-Risikobewertung Versicherungsstrategien präziser macht: Wer seine Exposures gezielt quantifiziert, kann Policen und Verhandlungen stärker an realen Risikotreibern ausrichten – und technische Maßnahmen in finanziellen Auswirkungen erklären.

Damit bekommt Exposure Quantification für CISOs eine zweite Funktion. Sie dient dann nämlich als „gemeinsame Sprache“ zwischen Security, Risk, Finance und Insurance. In der Praxis kann das bedeuten, dass Security-Kennzahlen stärker an betriebswirtschaftliche Größen gekoppelt werden (z. B. erwartbare Ausfallkosten, Schadensszenarien, regulatorische Folgekosten) – ohne dabei in Spekulation abzurutschen. Entscheidend ist die Nachvollziehbarkeit: Welche Daten fließen ein, wie wird gemessen, wie wird Fortschritt belegt?

Was sich im Alltag der Teams ändert könnte oder gar sollte

Aus den heutigen Trendlinien lassen sich drei sehr konkrete Verschiebungen ableiten, die viele Teams schon 2026 spüren werden:

• Von Asset-Listen zu Angriffspfaden! Sichtbarkeit bleibt Basis, aber Priorisierung folgt immer öfter dem „Path“-Denken: Was ist erreichbar, ausnutzbar und geschäftlich relevant und aus den Resillienzgesichtspunkten zeitkritisch?
• Von Reportings zu Steuerung! Exposure-Scores und vergleichbare Messgrößen werden nicht nur berichtet, sondern als Steuerungsinstrument genutzt (SLA-Tracking, Maßnahmenwirksamkeit, Risikoreduktion über Zeit).
• Von Security-Sprache zu Business-Sprache! Das Ziel ist nicht, Technik zu vereinfachen, sondern sie entscheidungsfähig zu machen – damit Vorstände nicht nur „Aktivität“, sondern Wirkung sehen.

Exposure Quantification für CISOs wird zur Disziplin, weil sie Governance-Anforderungen mit operativer Realität verbindet – und weil sie in der Lage ist, komplexe Sicherheitslage in vergleichbare, überprüfbare Messwerte zu überführen.

Der Beitrag Exposure Quantification für CISOs rückt ins Zentrum erschien zuerst auf Ilja Schlak InfoSec Blog.

Der Beitrag Quishing und Briefpost-Phishing – Warum QR-Code-Awareness jetzt Pflicht ist erschien zuerst auf Ilja Schlak InfoSec Blog.

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