SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 1: Über den nachlässigen Umgang mit bekannten Sicherheitslücken
2017 wurde die größte Wirtschaftsauskunftei in den USA, Equifax, gehackt. Dabei wurden 143 Millionen Personendaten inklusive Sozialversicherungsnummer und teilweise Führerscheinnummer gestohlen. Darüber hinaus Kreditkartennummern von 209.000 US-Bürger:innen. Des Weiteren hatten 182.000 US-Bürger:innen Korrekturen an ihren Daten verlangt – auch die dazu nötigen Detailinformationen wurden von den Hackern entwendet. Die Plattform wurde zeitweise abgeschaltet. Vermutet wird, dass eine zum Zeitpunkt bekannte Sicherheitslücke in Apache Struts für den Einbruch genutzt wurde. Einen Fix der Sicherheitslücke gab es bereits, dieser wurde aber bei Equifax über längere Zeit nicht eingespielt.
Auch die beiden folgenden Sicherheitslücken gingen durch die Presse:
Ende 2021: Die Sicherheitslücke Log4Shell (CVE-2021-44228) führte zu zahlreichen Angriffen auf unterschiedlichste Systeme, darunter vieleVMWare Produkte. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) ging auf Warnstufe Rot und rief eine kritische Bedrohungslage aus. Weltweit prüften Hersteller und Betreiber, ob sie betroffen sind. Laut verschiedener Schätzungen lagen die summarischen Kosten möglicherweise im Bereich mehrerer Milliarden Dollar.
2022: Die kritische Zero-Day-Sicherheitslücke Spring4Shell (CVE-2022-22965) hatte ein ähnliches Gefahrenpotential. Da Spring in sehr vielen Applikation genutzt wird, findet man noch heute im Internet Statements in denen Firmen erklären, ob sie von dieser Lücke betroffen waren oder nicht.
Sicherheitsprobleme großer Anbieter oder Plattformen aber auch kleinerer Software-Komponenten, die aber in Tausenden von Software-Instanzen verwendet werden, gehen mittlerweile durch die Presse und schaffen es in die Tagesschau. Gleiches gilt für Einbrüche in IT-Systeme, die zu Datendiebstählen im sechsstelligen Bereich oder größer führen. In einer dritten, weiteren Variante brechen Hackerbanden in IT-Systeme ein und verschlüsseln Daten, um für die Freischaltcodes Geld zu erpressen.
Die Lage wird brenzliger
Dies hat in den Vereinigten Staaten aber auch in Deutschland dazu geführt, dass IT-Systeme nach einem Vorfall über längere Zeit heruntergefahren werden mussten. Gefühlt ist aktuell in Deutschland immer mindestens eine kommunale Stadtverwaltung „down“. Zum Zeitpunkt dieses Artikels ist die „Südwestfalen-IT“ nach einem Cyberangriff Ende Oktober 2023 nur mit Basisdiensten online. Rund 170 Personen arbeiten – nach eigenen Angaben – weiterhin an der Bewältigung der Folgen.
In die Presse gelangen solche Vorfälle auch deshalb, weil sie zu merkbarem gesellschaftlichen Schaden und Beeinträchtigungen führen. Bürgerinnen und Bürger aber auch Firmen sind großflächig betroffen und müssen temporäre Einschränkung in ihrem Leben hinnehmen.
Welche Ursachen stehen dahinter?
Was sind die Ursachen dafür, dass sich solche Vorfälle häufen und die Auswirkungen massiver werden? Eine Reihe von Punkten lassen sich hier nennen:
1. Fortschreitende Digitalisierung
Grundsätzlich sorgt die fortschreitende Digitalisierung dafür, dass es einfach immer mehr IT-Systeme gibt. Durch die Digitalisierung stehen viele dieser Systeme direkt oder indirekt auch im Internet und sind stärker untereinander vernetzt, damit Kunden oder konkret auch Bürger über eine Webseite oder per App den Dienst nutzen können. Die Angriffsfläche ist so sicherlich einfach erheblich größer als sie es noch vor 10 oder 20 Jahren war.
2. Komplexere Systeme
Gründe dafür, dass IT-Systeme komplexer werden, sind ebenfalls in der Digitalisierung zu finden (einfach „mehr machen mit Software“). Aber auch im wachsenden Anspruch an die Software bzgl. Funktionalität und Qualität. Komplexität kommt aber auch durch die stärkere Vernetzung von System und Datenquellen zustande. Für die Systemsicherheit ist der letzte Punkt, also die übergreifende Vernetzung, sicherlich ein besonders kritischer Faktor.
3. Kostendruck
Software in ihrer Komplexität anzugehen wie ein in der Komplexität vergleichbares „klassisches“ Planungsprojekt („Hochhaus? Flugzeugbau? Raumschiff?) ist oft nicht bezahlbar oder methodisch nicht durchführbar. Dennoch wird entsprechende Software erstellt, was Risiken mit sich bringt. Das es zu Qualitätsmängeln kommt und Risiken tendenziell eher unterschätzt werden, ist daher nicht überraschend.
4. Einsatz von Standards
Der Komplexitätsreduzierer „Standards“ wird nicht so stark genutzt wie in andere Branchen. Software will man, um sich abzugrenzen (die Software soll es ja explizit anders – nämlich „besser machen“, als bei der Konkurrenz).
5. Stetige Veränderung
Die IT ist Innovationstreiber und unterliegt einem stetigen, hohen Verbesserungs- und Änderungsprozess, der darin resultiert, dass 100% Qualität und Stabilität oft eher sekundäre Faktoren sind. Software hat oft nicht mehr die Zeit, „fertig“ zu werden.
Sicherheit als essenzielles Qualitätsmerkmal
Lange Zeit wurde IT-Sicherheit eher als „sekundärer Faktor“ betrachtet; die IT unterlag dem Irrglauben, dass es ausreicht, entsprechende Risiken aufzunehmen, die sich managen und kontrollieren lassen. Die oben gezeigten Fälle zeigen, dass dies nicht immer gelingt.
Wenn wir wollen, dass Digitalisierung erfolgreich ist, müssen wir unsere Sichtweise auf IT-Sicherheit ändern.
Mangelnde Sicherheit im Software-Umfeld ist in den letzten Jahren unternehmenskritisch und in Teilen sogar gesellschaftskritisch geworden. Sowohl Hersteller als auch Nutzende und Beauftragende einer Software sind dabei unterschiedlich aber am Ende doch gleichermaßen betroffen.
Häufige Folgen:
- Erhebliche Datenverluste und damit Datenschutzverletzung mit entsprechenden Strafen
- Reputationsverlust bei Kunden
- Arbeit und Weiterentwicklung stehen still und müssen aufgeholt werden. Die Konsequenz sind Stress, Unzufriedenheit, Überstunden, hohe Kosten – d. h. die Bilanz eines solchn Quartals kann man schon mal vergessen.
- Ungeplante Kosten, weil im Worst Case ganze IT-Infrastrukturen neu aufgesetzt werden müssen, man sich mindestens sehr gut bezahlte Fachleute ins Haus geholt hat oder einfach ein Großteil der Belegschaft seine Arbeit über einen längeren Zeitraum nicht machen kann.
Typische Reaktionen nach dem Bekanntwerden einer großen potentiellen Sicherheitslücke
Geht ein Sicherheitsproblem durch die Presse – und ist das eigene Unternehmen, die eigene IT ein mögliches „Opfer“ der Zustände, die wir selbst geschaffen haben – folgen darauf meist typische Handlungsmuster:
- Zunächst brechen Hektik und Panik auf Grund von mangelnder prozessualer Vorbereitung aus.
- Es folgen Fragen wie „Sind wir betroffen?“ „Benutzen wir potenziell verwundbare Komponenten?“
- Darauf folgt die Gründung einer Task Force oder ähnlicher Konstrukte, die untersuchen, ob und wo in genutzten, releasten, verkauften Applikationen oder Systemen das verwundbare Softwareartefakt verwendet wird.
- In der Regel sind die Fragen aus Punkt 2 dann nicht schnell eindeutig zu beantworten („Ja, aber …“, „Müssen wir uns genauer anschauen“), was spätestens jetzt dazu führt, dass Systeme sicherheitshalber heruntergefahren werden. Oft ist der Exploit ja trickreich und die Antwort keine einfache Ja/Nein-Frage. Eine potenzielle Mitigation kommt ggf. erst Tage später.
- Schnell steht damit die Frage im Raum, ob ein Update gemacht werden muss oder eine Mitigation zu erhoffen ist. Bei einer Fremdsoftware ist hier in der Regel spätestens Schluss. Denn hier kann weder sicher gesagt werden, ob die Komponente genutzt wurde, noch ob das System angreifbar ist. Es kann also nichts weiter getan werden, als das System auf Verdacht herunterzufahren oder den entsprechenden Dienstleister zu kontaktieren.
- Wildes Blättern im Branchen-Buch nach einem Sicherheitsexperten.
- Wenn schließlich alle Fakten auf dem Tisch liegen, ist die Frage, wie und vor allem wie schnell man in der Lage ist, die identifizierten Probleme an den unterschiedlichen Stellen zu beseitigen. Dabei hat man manches selbst in der Hand (selbstentwickelte Software), anderes hingegen nicht (COTS-Lösungen).
- Wenn man Glück hat, ist man mit den Updates in wenigen Monaten durch und es ist nichts passiert. Zweiteres wird aber leider seltener.
Das meiste davon muss nicht zwingend so passieren. Dieses fiktive Drehbuch zeigt sich aber leider immer noch viel zu oft in der Realität und offenbart grundlegende Probleme mit dem Thema Security in der IT.
Kurz: Unternehmen sind nicht gut auf solche Situationen vorbereitet, Prozesse und Vorgehen sind oft nicht klar oder zu behäbig. Die Datenbasis ist im Fall der Fälle nicht ausreichend, was zu längeren Recherchen und Analysen führen kann. Und grundsätzlich hätte man ggf. schon früher reagieren können, bevor man durch die Presse aufmerksam gemacht wird.
Wir alle sind betroffen
Längst nicht jedes Sicherheitsproblem geht durch die Presse. Schaut man für den 12.01.2024 auf cvedetails.com steht dort:
- 201 CVEs seit gestern(!) angelegt und 642 wurden aktualisiert!
- 846 CVEs in den letzten 7 Tagen angelegt und 1755 wurden aktualisiert.
- Aktuell gibt es 7 ausgenutzte „Vulnerabilities“, 11 in den letzten 30 Tagen!
Und wer auf die Statistik der letzten 10 Jahre schaut, sieht, dass die Tendenz bei CVEs im Schnitt eher bei „schwerwiegend“ als bei „unkritisch“ liegt. Wobei ja nur die bekannten Sicherheitslücken betroffen sind. Jede Lücke davon könnte uns selbst angehen!
Fazit
Sei es in selbstentwickelten Lösungen oder in zugekauften Systemen: Wir müssen sensibel mit dem Thema umgehen. Dazu gehört vor allem, Transparenz darüber zu schaffen, welche Abhängigkeiten der genutzten Softwarelösungen existieren.
Hier wäre es hilfreich, eine Art „Inhaltsangabe“ für Software zu haben und diese „Inhaltangaben“ an zentraler Stelle für möglichst jede erstellte oder genutzte Software zu sammeln und einfach auswertbar zu haben. So könnte man an entscheidenden Stellen im obigen Szenario schneller reagieren. Hierfür gibt es tatsächlich bereits Lösungen: Stichwort SBOMs. Mehr darüber im nächsten Teil …
Quellen
https://www.heise.de/news/Hacker-Jackpot-Credit-Bureau-Equifax-gehackt-3824607.html
https://www.wired.com/story/equifax-breach-no-excuse/
https://github.com/YfryTchsGD/Log4jAttackSurface
Alle Teile ansehen:
Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX
Teil 4: Was ist eine gute SBOM? – Das Versuchssetting
Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks
Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess
4 Kommentare
Pingback: The Cattle Crew Blog Mit SBOMs die Lizenzierung überprüfen -
Pingback: Was machen SBOMs mit der Softwareentwicklung? -
Pingback: SBOM-Formate im Vergleich - The Cattle Crew Blog
Pingback: Mit welchen Werkzeugen werden gute SBOMs gemacht? -