AppSec Decoded
Ein Gespräch mit Florian Thurmann, Technical Director EMEA bei Synopsys über das BSIMM-Modell und dem Stand der Anwendungssicherheit
Herr Thurmann, ein Konzept, das schon seit über einem Jahrzehnt existiert und immer wieder Gegenstand von Branchengesprächen ist, ist das des Shift Left. Ein Konzept, nach dem Sicherheitstests früher im Lebenszyklus der Softwareentwicklung eingeführt werden. Jetzt hören wir von einem neuen Konzept: Shift Everywhere. Worin unterscheiden sich die beiden Konzepte?
Das Shift Left-Mantra ist mit gutem Grund entstanden. Entwicklungsteams haben nicht selten mit Sicherheitstests gewartet, bis die betreffende Anwendung oder Software kurz davor war, in Produktion zu gehen. Wenn dann Pen-Tester ins Haus kommen, finden sie Dutzende, wenn nicht Hunderte von Schwachstellen. Einige davon kritisch, viele mindestens hochriskant.
Das verzögert die Produktion, und Entwickler müssen unter Umständen weit zurückgehen und versuchen, die schwerwiegendsten Schwachstellen zu finden und zu beheben. Das kostet deutlich mehr Zeit und Geld, als sie früher zu beseitigen.
Die meisten Studien zu diesem Thema sind sich einig, dass es sechs- bis zehnmal soviel kosten kann, Schwachstellen erst spät im Software-Lebenszyklus zu beheben. Jedenfalls sehr viel mehr als zu Beginn oder während des Schreibens oder Assemblierens der Software. Wir sprechen hier von exponentiell wachsendem Aufwand. Das Risiko, dass ein Unternehmen in zeitlichen Verzug gerät oder ein Wettbewerber bei der Produkteinführung die Nase vorn hat, ist hier noch gar nicht berücksichtigt.
„Shift Left“ heißt im Grunde, dass Sie nicht bis zum Ende des SDLC warten sollten, um nach Schwachstellen zu suchen. „Shift Everywhere“ bedeutet links, rechts und in der Mitte. Die Grundidee ist, dass man etwas testet, sobald es getestet werden kann. So findet man Bugs sehr viel schneller, kosteneffizienter und man kann sie zügig beheben.
Das Building Security In Maturity Model (BSIMM[1]) gibt einen Überblick zum Stand der Anwendungssicherheit in verschiedenen Branchen. Was sollten Unternehmen tun, wenn sie ihre Software-Sicherheitsinitiativen auf Grundlage von BSIMM verbessern wollen?
Nun, ein entscheidender erster Schritt ist, den Reifegrad der eigenen Software-Sicherheitsinitiative zu ermitteln. BSIMM unterteilt grundsätzlich in drei Grade: in der Entstehung befindlich, reifend und optimierend. Auf dieser letzten Stufe wird Sicherheit zu einem direkten Business Enabler. Es geht dann nicht mehr nur darum, ein Compliance-Kästchen abzuhaken, sondern effektiver, schneller und agiler zu werden. BSIMM zeigt Ihnen, wo genau Sie in diesem Prozess stehen und erlaubt es Ihnen, die eigene Sicherheitsinitiative mit dem Status Quo der Branche zu vergleichen. Das hilft dabei, zu entscheiden, wohin Sie in Sachen Software-Sicherheit weiter gehen wollen.
Der zweite BSIMM-Befund: Wenn Sie noch nicht auf den DevSecOps-Zug aufgesprungen sind, sollten Sie es schleunigst tun. Richtig verstanden und umgesetzt kann Sicherheit mit der Entwicklung Schritt halten, ja sie sogar verbessern. Schon allein, weil sich die Entwicklung nicht verlangsamt. Entwickler müssen nämlich nicht mehr länger weit im SDLC zurück gehen, um nach Schwachstellen zu suchen, die sie zu einem früheren Zeitpunkt vielleicht übersehen haben.
Drittens geht es um Grundlagen der Cloud-Sicherheit, zu denen die Orchestrierung für Container und virtualisierte Umgebungen ebenso zählen wie die Pflege des App-Inventars mithilfe einer Bill of Materials (BOM), also einer Stückliste. Die Vorteile der Cloud wird niemand ernsthaft bestreiten wollen. Sie effektiv zu nutzen, bedeutet aber, dass Sie zumindest einen Teil Ihrer Sicherheitsarchitektur an den Cloud-Anbieter auslagern. Auch die Bereitstellung von Funktionen und andere Software-Sicherheitspraktiken, die traditionell vor Ort oder lokal angesiedelt waren. BSIMM macht das sehr deutlich: „Cloud-Anbieter [sind] zu hundert Prozent für die Bereitstellung von Sicherheitssoftware für Unternehmen verantwortlich, aber die Unternehmen [sind] zu 100 % für die Software-Sicherheit verantwortlich.“ Diesen Punkt sollte man im Auge behalten.
Die Idee, Sicherheitsbeauftragte in Entwicklungsteams einzubinden ist nicht neu – und mittlerweile als „Governance as Code“ automatisiert. Inzwischen stellen Tool Chain-Sensoren fest, ob die Software, die Sie schreiben oder assemblieren, beispielsweise die Richtlinien für die Verwendung von Bibliotheken, Codierungsstandards usw. einhält. Die Idee struktureller Sicherheit ist die, dass Entwickler eine sicherere Software erstellen, wenn sie ihren Code in einer sicheren Struktur schreiben.
Es gibt einen vergleichsweise neuen Begriff, der kürzlich im Bereich der Anwendungssicherheit aufgetaucht ist: DevSecOps. Dabei geht es darum, Sicherheit in DevOps-Praktiken zu integrieren. Worin sehen Sie die wichtigsten Triebfedern für DevSecOps?
Der wichtigste Treiber ist die rasant wachsende Entwicklungsgeschwindigkeit. Der Veröffentlichungszyklus hat sich von Monaten über Wochen zu Tagen und sogar Stunden verkürzt. Der zweite Punkt ist, dass Sicherheit Teil der Qualitätspraxis wird. Auch das eine Erkenntnis von BSIMM. Immer häufiger erkennen Teams den Wert eines Shift Everywhere, sodass sie während des gesamten SDLC, die Sicherheit überprüfen, und nicht erst beim letzten und sehr teuren Schritt unmittelbar vor der Produktion. Die Kombination aus Geschwindigkeit und Sicherheit kann laut den Ergebnissen des BSIMM-Reports aber durchaus zu gemischten Ergebnissen führen. Entwickler sind in der Lage, ihre Aufgaben schneller als bisher zu erledigen. Das ist gut. Für das Management ist das aber unter Umständen zu schnell, um die Auswirkungen auf das Unternehmensrisiko wirklich bewerten zu können.
„Cloud-Anbieter [sind] zu hundert Prozent für die Bereitstellung von Sicherheitssoftware für Unternehmen verantwortlich,
aber die Unternehmen [sind] zu 100 % für die Software-Sicherheit verantwortlich.“
Wie ist es konkret um Open-Source-Schwachstellen und die damit verbundenen Risiken bestellt? Warum ist es für Unternehmen so wichtig, bei Open Source-Komponenten in ihrem Code den Überblick zu behalten?
Wenn es um Open Source Software geht, gliedert sich das Thema in zwei Bereiche: Sicherheit und juristische Aspekte. Open Source Software ist nicht anfälliger als kommerzielle, proprietäre Software, aber sie ist auch nicht sicherer. Sie ist menschengemacht, sie enthält Fehler und Defekte, die, wenn sie nicht gepatcht werden, von Hackern ausgenutzt werden. Die gute Nachricht ist, dass Open Source-Codebasen, von Dutzenden, Hunderten oder Tausenden von Leuten aus der Community untersucht werden. Und die ist ziemlich effektiv, wenn es darum geht Bugs zu finden. Eine Art „Sicherheits-Crowdsourcing“. Der Nachteil ist, dass Patches für Open-Source-Schwachstellen, nicht automatisch, also in einem Push-Modell, an die Benutzer verteilt werden.
Open Source funktioniert nach dem Pull-Modell. Der Benutzer muss Patches aktiv abholen und einspielen. Wenn Sie allerdings nicht wissen, dass Sie eine schwachstellenbehaftete Open- Source-Komponente verwenden, wissen Sie natürlich nicht genug, um sich den entsprechenden Patch herunterzuladen. Die wirklich schlechte Nachricht ist, dass Hacker und andere Angreifer ausgesprochen genau auf Schwachstellenlisten achten, sobald diese veröffentlicht werden.
Anschließend wird man versuchen, Unternehmen zu finden, die eine anfällige Komponente verwenden. Ein berüchtigtes Beispiel ist der Equifax-Hack von 2017. Equifax ist eine der vier großen Wirtschaftsauskunfteien mit Sitz in den USA. Bei diesem Hack wurden Sozialversicherungsnummern und andere personenbezogene Daten von mehr als 147 Millionen Kunden kompromittiert. Wie konnte das passieren? Nun, das Unternehmen hat versäumt, einen Patch für das beliebte Open Source Framework Apache Struts einzuspielen. Einen Patch, der bereits seit einigen Monaten verfügbar war.
Dazu kommt das rechtliche Risiko. Open Source darf zwar frei verwendet und modifiziert werden. Das heißt aber nicht, dass es keine Lizenzbestimmungen oder andere juristische Einschränkungen gibt. Auch für Lizenzkonflikte dieser Art gibt es ein berühmtes Beispiel, auch wenn es mehr als ein Jahrzehnt zurückliegt: Cisco hat den Router-Anbieter Linksys übernommen. Offenbar war beiden Unternehmen nicht bewusst, dass einige der Router, Linksys-Router, Open-Source-Komponenten enthalten, die unter eine Lizenz fallen. Diese Lizenz verpflichtete jeden, der sie in einem Produkt verwendet, dazu, den Quellcode für das Produkt öffentlich zu machen. Letztendlich sah Cisco sich gezwungen, den Quellcode für einige sehr teure Router offenzulegen. Das machte es für die Konkurrenz ziemlich simpel, die Router zu klonen. Nur eben sehr viel billiger. Cisco hat die ganze Sache Hunderte Millionen Dollar gekostet.
Wie lassen sich Open-Source-Schwachstellen besser als in den besagten Beispielen managen?
Sie brauchen eine Reihe von Tools und Diensten, um unvermeidliche Designfehler zu finden und zu beheben. Solche Tools umfassen verschiedene Arten von AppSec-Tests. Während Sie Code schreiben oder assemblieren, führen Sie eine statische Analyse und eine Software Composition Analysis durch, um Schwachstellen sowohl in proprietärem als auch in Open Source-Code zu finden. Für den laufenden Code setzen Sie dynamische und interaktive Tests ein und Konfigurationsüberprüfungen, sobald Sie definierte oder laufende Umgebungen haben. Abschließend helfen Fuzz-Tests, also zufällige Eingaben, festzustellen, wie eine nahezu fertige Anwendung auf fehlerhaften oder zufälligen Code reagiert.
Der aktuelle 2021 OSSRA-Bericht[2]dokumentiert, dass Open-Source-Software inzwischen Teil so gut wie aller heute verwendeten Codebasen ist, und das branchenübergreifend: 100 % der untersuchten Codebasen in Marketing-Tech-Unternehmen nutzen Open-Source-Komponenten, 98 % im Gesundheitswesen, 97 % bei Finanzdienstleistern und Fin-Techs sowie 92% in Einzelhandel und E-Commerce. Gleichzeitig wächst allerdings auch die Angriffsfläche und zwar stetig. Nicht nur, dass eine Vielzahl der verwendeten Open Source-Komponenten Schwachstellen aufweisen. Alarmierende 91 % aller Codebasen weisen Open-Source-Abhängigkeiten auf, die in den letzten zwei Jahren nicht mehr weiterentwickelt worden sind. Das heißt, der Code wurde weder verbessert, noch wurden Sicherheits-Patches zur Verfügung gestellt.
Wie gesagt, im Gegensatz zu kommerzieller Software, wo die Anbieter ihren Kunden die entsprechenden Informationen im Push-Modus zukommen lassen, hängt das Wohl und Wehe von Open Source ganz vom Engagement der Gemeinschaft ab. Wird eine Open-Source-Komponente in ein kommerzielles Angebot eingebettet und fehlt das entsprechende Engagement, beeinträchtigt das die Lebensfähigkeit des gesamten Projekts. Solche aufgegebenen Projekte sind kein neuartiges Phänomen. Aber wenn es auftritt, ist es wesentlich schwieriger, die damit verbundenen Sicherheitsprobleme zu beheben.
Dabei ist die Lösung simpel – Firmen sollten in die Unterstützung genau der Projekte investieren, von denen ihr Erfolg abhängt.
Ermutigend ist trotzdem, dass eine große Mehrheit der Unternehmen, inzwischen Richtlinien für die Nutzung von Open Source eingeführt hat. Mit anderen Worten, welche Komponenten sind erlaubt und welche Lizenzen gelten als akzeptabel. Allerdings verwenden Entwicklungsteams immer noch eine breite Palette von Sicherheitstools, fast ein Dutzend im Schnitt. Das ist zwangsläufig ineffektiv.
###
[1] https://www.synopsys.com/blogs/software-security/bsimm11-mkt-trends/
