Software-Risiken sind unternehmerische Risiken 

Illustration: Absmeier MrGanso

Dennoch weisen 95 % aller Anwendungen mindestens eine Schwachstelle auf oder sind fehlerhaft konfiguriert.

 

Software – die Welt ist von ihr abhängig und praktisch jedes Unternehmen darauf angewiesen. Das heißt, man sollte der Software, mit der ein Unternehmen arbeitet, vertrauen können – andernfalls drohen nicht zu unterschätzende Risiken. Auch wenn es hier um digitale Werte geht, kann es nicht schaden, den Rat eines der berühmtesten Krieger der Antike, dem chinesischen General Sun Tzu, zu beherzigen: Kenne deinen Feind.

Anzeige

 

 

Ein Blickwinkel, den auch der »Software Vulnerability Snapshot« für 2022, ein aktueller Bericht des Synopsys Cybersecurity Research Center (CyRC), einnimmt. Hier wurden die Daten von rund 4.400 Software-Sicherheitstests analysiert, durchgeführt an 2.700 spezifischen Web- oder Mobilanwendungen, Quellcodedateien und Systemen. Sämtliche Tests verwendeten dazu die Application Security Testing (AST) Services von Synopsys, vor allem intrusive »Black Box«- und »Gray Box«-Tests. Sie untersuchen laufende Anwendungen wie es ein tatsächlicher Angreifer tun würde. Dabei werden die Schwachstellen nicht nur identifiziert, sondern auch Hinweise zur Priorisierung und Behebung gegeben.

 

Bei diesen Tests sind zahlreiche Mängel zutage getreten: 95 % der Anwendungen wiesen mindestens eine Schwachstelle oder Fehlkonfiguration auf, und 25 % der identifizierten Schwachstellen werden als hohes oder kritisches Risiko eingestuft. Einerseits ist es gut, dass solche Schwachstellen bereits mittels AST identifiziert worden sind. Das ist allerdings auch eine deutliche Warnung. Denn die Wahrscheinlichkeit, dass eine Software mit Schwachstellen behaftet ist, liegt bei nahezu 100 %, und ein Viertel von ihnen verursacht potenziell erhebliche Schäden.

 

78 % der Ziele wiesen Schwachstellen auf, die in der Top 10-Liste des OWASP (Open Web Application Security Project) als die häufigsten vorkommenden Schwachstellen überhaupt aufgeführt sind. Ganz oben auf der Liste stehen Schwachstellen, die Cross-Site-Scripting (XSS) gestatten – eine gängige Methode, mit der sich Angreifer Zugriff auf Ressourcen und Daten verschaffen. Dem Bericht zufolge »ermittelten die AST-Services von Synopsys, dass 22 % der Testziele reflektierte, gespeicherte oder DOM (Document Object Model) -basierte XSS-Schwachstellen aufwiesen«. Die ermöglichen es einem Angreifer, bösartige Payloads in eine Webseite einzuschleusen. Andere kritische Schwachstellen wie Remote-Code-Ausführung und SQL-Injection erlauben es, Code in einer Webanwendung oder auf einem Application Server auszuführen und auf sensible Daten zuzugreifen.

 

Angesichts der vielen Möglichkeiten, die Hacker dank dieser Schwachstellen haben, spricht der Bericht einige Empfehlungen aus, mit der sich die Gefahren zumindest entschärfen lassen:

 

  • Nutzen Sie alle verfügbaren Testwerkzeuge – automatisiert und manuell. Verschiedene Tools suchen mit unterschiedlichen Methoden nach Schwachstellen. Unternehmen sollten sämtliche der ihnen zur Verfügung stehenden Methoden nutzen. Eine davon ist das Static Application Security Testing (SAST). Dieser Test hilft dabei, Fehler im Code bereits beim Schreiben zu erkennen. Die Software Composition Analysis (SCA), dagegen hilft Entwicklern, Open-Source-Komponenten, deren Ursprung und die verwendete Version zu ermitteln und herauszufinden, ob sie bekannte Schwachstellen oder Lizenzkonflikte enthalten.

 

Das Synopsys AST-Team nutzte außerdem Dynamic Application Security Testing (DAST) und Mobile Application Security Testing (MAST) sowie Penetrationstests, also simulierte Angriffe, um die Sicherheit von Anwendungen oder Systemen zu bewerten. DAST und MAST werden größtenteils mit automatisierten Tools durchgeführt, die Fehler im laufenden Code aufspüren. Penetrationstests hingegen werden manuell durchgeführt und unterstützen Unternehmen dabei, Laufzeitschwachstellen in den letzten Entwicklungsphasen einer Software oder nach deren Bereitstellung zu finden – und sie zu beheben.

 

Die Untersuchung bestätigt, dass intrusive Black-Box-Tests wie DAST sowie Penetrationstests besonders effektiv darin sind, ausnutzbare Schwachstellen im Lebenszyklus der Softwareentwicklung (SDLC) aufzudecken. Im Idealfall sind die Tests immer Teil eines abgerundeten Testprogramms zur Anwendungssicherheit.

 

  • Schützen Sie Ihre Lieferkette durch Software Bills of Materials (SBOMs). Softwareprodukte werden heute eher assembliert als geschrieben und basieren auf einer Kombination aus unternehmenseigenem, fremdem und Open Source Code. Im Durchschnitt besteht jede Codebasis zu etwa 77 % aus Open Source Software – und wie jede andere Software auch, ist sie nicht perfekt. Dennoch haben zu viele Unternehmen wenig bis keine Ahnung, welche Komponenten in den von ihnen verwendeten Softwareprodukten enthalten sind oder von welchen anderen Komponenten sie abhängig sind. Eine entsprechende Lieferkette kann sich über mehrere Ebenen erstrecken und Hunderte bis Tausende von sogenannten Abhängigkeiten umfassen. Das macht sie zu einer ausgedehnten und attraktiven Angriffsfläche, die man deutlich besser schützen sollte, als das bislang der Fall war.

 

Sicherheitsexperten predigen schon seit Jahrzehnten: Wenn man nicht weiß, was man benutzt, kann man es auch nicht schützen. Ein Unternehmen ist umso anfälliger, je weniger es über die Versionen aller verwendeten Komponenten weiß. Und dies erst recht, wenn der verwendete Code nicht mehr unterstützt wird oder veraltet ist. Zudem ist es wichtig, die Lizenzen zu kennen, die mit jedem einzelnen Open-Source-Bestandteil innerhalb der genutzten Anwendungen verbunden ist.

 

SBOMs liefern ein vollständiges Inventar sämtlicher Softwarekomponenten, die ein Unternehmen einsetzt. Sie dienen somit als Sicherheits- und Qualitätsgrundlage. In anderen Industriebereichen sind Stücklisten längst ein unverzichtbarer Bestandteil. Ein Fahrzeughersteller beispielsweise würde kaum lange im Geschäft bleiben, wenn er nicht für jedes Fahrzeug eine Stückliste führen und akribisch nachverfolgen würde, woher die Teile stammen.

 

Die Entdeckung einer katastrophalen Sicherheitslücke in der Open-Source-Protokollierungsbibliothek Log4j von Apache, Log4Shell, vom Dezember 2021 ist eines der jüngsten Beispiele für die mit der Software-Lieferkette verbundenen Risiken.

Viele Log4j-Nutzer wussten nicht, ob sie eine Schwachstellen-behaftete Version verwenden oder nicht. Sie hatten schlicht keinen Überblick über ihre Lieferkette. Das war einer der Gründe, warum sich die Lücke als so schwerwiegend erwiesen hat.

 

Im Software Vulnerability Snapshot heißt es dazu: »Da viele Unternehmen Hunderte von Anwendungen oder Softwaresystemen im Einsatz haben, von denen jedes selbst oft Hunderte bis Tausende verschiedener Komponenten von Drittanbietern und Open-Source-Komponenten enthält, ist eine genaue, aktuelle SBOM dringend erforderlich, um all das effektiv nachzuverfolgen.«

 

Immerhin, es gibt auch gute Nachrichten: Das Bewusstsein für Softwaresicherheit und die zentrale Rolle einer SBOM, ist immens gestiegen. Laut einem weiteren Synopsys-Bericht, betitelt »Walking the Line: GitOps and Shift Left Security«, haben stolze 73 % der Umfrageteilnehmer ihre Bemühungen für eine sicherere Software-Lieferkette verstärkt. Die »Executive Order on Improving the Nation’s Cybersecurity«, im Mai 2021 von US-Präsident Biden veröffentlicht, fordert ausdrücklich, dass sowohl öffentliche als auch private Organisationen SBOMs für ihre Softwareprodukte erstellen und pflegen müssen. Jedenfalls, wenn sie ihre Produkte an die US-Bundesregierung verkaufen wollen.

 

  • Sorgen Sie dafür, dass Fehler mit niedrigem Risiko nicht zu einem hohen Risiko werden. Schwachstellen mit einer niedrigen Risikoeinstufung sind in der Regel solche, bei denen man davon ausgeht, dass sie keinen großen Schaden anrichten oder es unwahrscheinlich ist, dass ein Angreifer sie ausnutzen kann/wird. Der Bericht weist allerdings darauf hin, dass eine Schwachstelle je nach Profil einer Organisation sich sehr wohl schwerwiegend auswirken kann oder die Wahrscheinlichkeit steigt, dass sie ausgenutzt wird. Ein Beispiel ist die Sicherheitslücke »Verbose Server Banners«, die zwar als niedriges Risiko eingestuft wird, aber Informationen wie Servername, Typ und Versionsnummer liefert, mit denen Angreifer gezielte Angriffe auf bestimmte Technologie-Stacks durchführen können.

 

  • Aus Testdaten gewonnene Erkenntnisse anwenden. Sammeln und kombinieren Sie Daten der Sicherheitstest-Tools darüber, welche Tests durchgeführt und welche Fehler entdeckt wurden. Dadurch lassen sich Sicherheitsverbesserungen sowohl im SDLC als auch in übergreifenden Governance-Prozessen vorantreiben. Die Anpassung einer Sicherheits-Checkliste für Entwickler ist ein Beispiel, wie sich übliche Schwachstellenmuster bekämpfen lassen.

 

  • Entscheiden Sie sich für den richtigen Testanbieter. Suchen Sie sich einen Anbieter aus, der Ihnen umfassende Berichte zur Verfügung stellt. Und zwar solche, die Führungskräften die Risikoexposition des Unternehmens insgesamt aufzeigen und die andererseits zur Einhaltung gesetzlicher Vorschriften beitragen.

 

Stanislav Sivak, Associate Managing Security Consultant, Synopsys Software Integrity Group