Die Intransparenz der Software-Supply-Chain, lange Zeit ein vernachlässigbares Sicherheitsrisiko, ist seit Beginn des Ukraine-Krieges und der Zunahme von Angriffen staatlicher Cyberkrimineller zum Hochrisikofaktor geworden. Inzwischen ist bekannt, dass insbesondere Baugruppen und deren Software von kleineren, oft wenig bekannten Zulieferern den Angreifern als Einstieg in die ansonsten meist gut geschützte OT (Operational Technology) dienen.
Zusätzlich steckt der Bedrohungs-Teufel im digitalen Detail. Bedingt durch den Einsatz digitaler Systeme steigt die Anzahl von Software-Komponenten in OT-Systemen und damit die Anzahl an Fehlern (Bugs) in Software-Komponenten. Gleichzeitig wächst damit die Anzahl an bekannten Schwachstellen (CVEs) sowie das Potential unbekannter Angriffsmöglichkeiten (Zero Day Exploits). Das Ausmaß dieses Anwachsens der Angriffsoberfläche lässt sich sehr gut im Anstieg der Code-Zeilen in digitalen Produkten verdeutlichen: Die Software im Bordcomputer der Apollo 11 zur Mondlandung im Jahr 1969 umfasste 145.000 Zeilen Code, ein Boing Dreamliner, Indienststellung 2011, benötigt zum sicheren Flug 14 Millionen Zeilen Source-Code, die in der Beschaffung genutzte SAP NetWeaver Plattform hatte 2007 bereits 238 Millionen LOC und ein modernes vernetztes Fahrzeug (Software Defined Vehicle) wird mit bis zu 100 Millionen Zeilen Software Code ausgeliefert.
Drei Fehler pro 1000 Code-Zeilen verlangen Korrektur
Studien der Universität Oldenburg gehen davon aus, dass durchschnittlich etwa drei Fehler pro 1000 Zeilen geschriebenem Softwarecode existieren. In sicherheitskritischen Anwendungen sind es ungefähr 0,5 Fehler in 1000 Code-Zeilen. Für eine komplexe Beschaffungslösung mit SAP- und weiteren Anteilen aus Open-Source-Paketen, anderer kommerzieller Software, Infrastructure-as-code- bzw. IaC-Dateien, Containern oder Betriebssystem-Images bedeutet dies, dass grob gerechnet etwa 119.000 potenzielle Fehler im Source-Code enthalten sind. Dieser Anstieg ist teilweise bedingt durch den Einsatz von Hypervisor-Architekturen, die die Software-Entwicklung und Pflege rationalisieren, aber gleichzeitig zu einer redundanten Verwendung von Software-Code in virtualisierten Systemen führen und damit auch die absolute Anzahl von vorhandenen Schwachstellen erhöht.
Ein CVE-Scan auf Komponenten einer Einkaufslösung führt daher in der Betrachtung aller Komponenten zu Ergebnislisten mit mehreren hunderttausend Einträgen. Das Ranking dieser Einträge nach dem freien und offenen Industriestandard zur Bewertung des Schweregrads von Sicherheitslücken in Computersystemen „Common Vulnerability Scoring System“ (CVSS) führt zu einer Eingrenzung von mehreren tausend kritischen Schwachstellen und damit zur praktischen Frage, welche bekannten Schwachstellen mit welcher Priorität geschlossen werden müssen. Hierbei ist das Schließen von Sicherheitslücken praktisch limitiert durch die vorhanden Entwicklungsressourcen bei Betreibern, Herstellern und Zulieferern. In Folge bleiben kritische Schwachstelle offen oder deren Schließung erfolgt stark zeitverzögert. Aus Sicht der Betreiber ist das System damit in einem permanenten Bereich der Unsicherheit, bedingt durch offene CVEs.
Priorisierung beim Schwachstellen-Management
Hinzu kommt, dass ökonomische und technische Grenzen kein vollständiges Schließen aller als kritisch klassifizierten Software-Risiken erlauben. Vollkommen unbeachtet ist hierbei zudem das Dunkelfeld der unerkannten (Zero-Day) Risiken im Software-Stack. Betrachtet man nicht nur einzelne Assets (z.B. ein Lieferantensystem oder einen elektronischen Marktplatz) sondern betrachtet diese als Teil eines komplexen Anwendungssystems, potenzieren sich die Risiken. Bestehende Cyber-Threat-Intelligence (CTI) auf Basis von CVE/CVSS Metriken haben damit in der Praxis ihre Grenzen erreicht.
Solche Systeme sind nicht dafür geeignet, Risiken in einer Form abzubilden, die die Lagebeurteilung und Planungen zur Risiko-Minimierung effektiv unterstützen. Im Gegenteil: die Fokussierung bestehender Systeme auf den Schweregrad (CVSS) einer Schwachstelle, ohne den Kontext der Verwendung des betroffenen Assets, führt unter Umständen zu einer unzureichenden Priorisierung von Ressourcen und Maßnahmen im Risiko-Management. Assets mit faktisch untergeordneter Gefährdung (z.B. durch eingeschränkte Konnektivität) werden zunächst gleichbehandelt und dargestellt, wie Assets mit einem faktisch hohen Gefährdungsprofil (z.B. mit Hyperkonnetivität).
Vor diesem Hintergrund hat das Cybersecurity-Unternehmen Asvin eine neue Methode zur Erfassung, Bewertung und Aufbereitung von Cybersicherheitsrisiken in komplexen Beschaffungssystemen entwickelt: Risk by Context (RBC). Risk by Context erweitert die Grenzen von CVE-bezogenen Threat Intelligence- und Risk Management-Systemen. Es ermöglicht eine optimale Entscheidungsgrundlage zur Priorisierung von Maßnahmen zur Risiko-Minimierung und liefert Möglichkeiten zur Simulation von Entscheidungen und deren Auswirkungen auf die Sicherheit von Assets. Risk by Context betrachtet das Potential von Cyberrisiken im Zusammenhang von operativen Risiken und Zielen. Dadurch entsteht ein topologischer Kontext-Raum, der durch algorithmische Verfahren eine reproduzierbare und nachvollziehbare Priorisierung von Cyberrisiken ermöglicht. Ein solches Kontext-bezogenes Cyber-Lagebild ermöglicht eine bessere Datenbasis zur Priorisierung von Entscheidungen und für die Zuweisung von Ressourcen in der Cyberabwehr.
Schwachstellen oder Befall schon im Keim erkennen und ersticken
Beschaffungsprozesse, die Produktion und Handel versorgen, machen allein in Deutschland etwa 20 Prozent der Wirtschaftsleistung aus. Soweit bekannt, gehen dabei mittlerweile rund zehn Prozent davon pro Jahr durch Cyberangriffe verloren. Das bisher wenig bekannte Problem dabei ist, dass Transparenz auf der kompletten Lieferketten lange Zeit nicht als nicht besonders notwendig erschien. Es gab keine oder nur unwesentliche Vorfälle, also ließ man sie laufen. Diese „Wird schon“-Haltung wird kritisch, seit Angreifer die bisher kaum im Fokus stehenden dunklen Zonen der Lieferkette als Einstiegsluken erkannt haben.
Nächstes Problem: Ein Befall führt nicht sofort zu einem Angriff. Oft warten Hacker monatelang auf den richtigen Moment, um die installierte Schadsoftware freizuschalten. Beispiel Angriff auf ukrainische Kommunikations-Infrastruktur zu Beginn des Ukraine-Krieges: Wie später bekannt wurde, residierte die hierfür benutzte Schadsoftware bereits mehrere Monate vor Scharfschalten auf dem Update-System des Satelliten-Anbieters. Der Hack erfolgte über eine bekannte und ungepatchte Schwachstelle in deren VPN-Router. Danach verteilten sich Wiper-Updates an alle Satelliten-Modems. Das legte nicht nur ukrainische Kommunikationsnetze lahm, sondern auch deutsche Windkraft-Anlagen, weil sich die Ransomware einfach über das primäre Ziel hinaus weiter fraß.
Wichtig ist also in mehrfacher Hinsicht der Blick auf den Kontext von Bedrohungssituationen. Wer neben dem Befall einzelner Komponenten auch deren Umfeld, also die Vernetzung und Interaktionsweise mitbetrachten und auf Befall-Wege oder Inkubations-Zustände analysieren kann, ist im Vorteil, weil er Betroffenheit schon im Keim erkennt: Hatte das kritische Bauteil das erforderliche Update bekommen? Verhält es sich minimal anders als gewünscht, interagiert es öfter als geplant oder mit nicht eingestellten Komponenten? So lassen sich Angriffe oft schon im Keim ersticken.
Kontext-Analyse hilft gegen den SBOM-Schock
Ein weiterer und wesentlicher Vorteil von Risk by Context ist die Eingrenzung von Schadensfällen bzw. der Bedrohungs-Kritikalität. Üblicherweise ist das Ergebnis des ersten tieferen Blicks auf die Software-Lieferkette ein Schlag in die Magengrube des CISO. Er erhält meist eine so genannte Software-Stückliste [Fachbegriff SBO (Software bill of material)] mit einer meist großen Zahl von Schwachstellen und Verwundbarkeiten. Dann ist er zwar informierter als zuvor, steht aber vor einem Berg neuer Aufgaben und Herausforderungen. Auch hier hilft Kontext-basierte Risikoanalyse, weil sich seine Aufgaben durch Priorisierung – Bereiche mit hoher Kritikalität zuerst! – in “Sofort” und “Später” aufteilen lassen. Hierdurch können Unternehmen mehr als die Hälfte ihrer Kosten sparen und den Workload mit bestehendem Personal abarbeiten.
Nicht zuletzt bietet gute Risk by Context-Software jede Menge individueller Anpassungsmöglichkeiten bezüglich Kritikalität, Umgebungsparametern oder Auswertungsverfahren. Lieferketten haben branchenspezifische Ausprägungen mit je nach Anwendungsweise sehr unterschiedlichen Anforderungen. Gemeinsame Klammer ist hierbei immer die Kernfunktion der RBC-Methode: je offener die Technologie-Plattform, desto modularer die Nutzbarkeit. Asvin-RBC hat einen sicheren funktionalen Kern, das so genannte „Data Science Modul“, das alle Transaktionen anonym, fälschungssicher und dennoch eindeutig durchführt. Seine Variationsmöglichkeiten sind nahezu unbegrenzt und dadurch auf jede gewünschte Funktion modifizierbar. Das macht RBC flexibel einsetzbar und Angriffe auf Lieferketten lassen sich einfacher beherrschen.
*Die Risk-by-Context-Methode erstellt ein Gewichtungsmodell, das das individuelle Risiko eines Assets bestimmt. Dabei können Risiken von verbundenen Assets oder ganzen Segmenten vererbt werden. Dies erlaubt es, auch für OT-Systeme mit Assets, die weitestgehend unbekannte Eigenschaften haben, eine Risiko-Einschätzung zu erstellen.
Der Autor:
Konrad Buck, IT-Fachjournalist, Pressesprecher der Asvin
