Proaktive App-Sec-Strategien in unwägbaren Zeiten

Gastbeitrag von Florian Thurmann

Über den Verlauf dieses Jahres hinweg standen Unternehmen bereits vor einigen Herausforderungen. Darunter die Aussicht monatelang Probleme bei der Besetzung von Stellen zu haben und die geschäftlichen Prozesse aufrechtzuerhalten. Gleichzeitig nehmen Cyberangriffe zu. Firmen müssen demzufolge gewährleisten, dass die Software, die sie entwickeln und betreiben, sie vor diesen Angriffen schützt, und dass dedizierte Sicherheitsressourcen vorhanden sind. Viele Unternehmen wollen in mehr Sicherheit investieren, wissen allerdings nicht, wo sie am besten anfangen sollten.

Das ist angesichts der komplexen Aufgabe nicht überraschend. Es gibt aber einige Schritte, mit denen man schon jetzt auf Ressourcenprobleme reagieren und gleichzeitig die Effektivität von AppSec-Programmen grundlegend verbessert. Dazu zählt eine taktische Herangehensweise an die vorhandenen Kapazitäten für notwendige Sicherheitstests, die Kompetenz von Mitarbeiterinnen und Mitarbeitern und ein Blick auf die Risiken innerhalb der Software-Lieferkette. Nachfolgend finden Sie einige Empfehlungen, was Firmen in Sachen vorausschauender App-Sec-Strategien berücksichtigen sollten, insbesondere in unwägbaren Zeiten wie diesen.

Maßstäbe festlegen und die Strategie reifen lassen

Machen Sie sich zunächst ein möglichst umfassendes Bild von den Sicherheitsmaßnahmen innerhalb des Unternehmens. Mit dem Building Security In Maturity Modell (BSIMM) lassen sich die aktuellen Softwaresicherheitsmaßnahmen methodisch bewerten. Das Ergebnis liefert einen objektiven Benchmark, der als Grundlage für eine Verbesserung der Softwaresicherheit dienen sollte.

BSIMM, aktuell in der 11. Auflage, dient sowohl als Fahrplan wie auch als Messlatte, wenn Firmen ihre Software Security Initiatives (kurz SSIs) erstellen oder verbessern wollen. Als Orientierung dient dabei, was andere Firmen tun und was in dieser Hinsicht branchenrelevant ist. Firmen haben beispielsweise manuelle Governance-Aktivitäten erfolgreich durch automatisierte Lösungen ersetzt. Die geschäftliche Triebfeder ist der Ruf nach höherer Geschwindigkeit. Wenn man sich wiederholende Analysen und verfahrenstechnische Anforderungen an Bots, Sensoren und andere Tools, automatisiert, kann man Prozesse besser skalieren. Das wiederum hilft, mit Engpässen und der notorischen knappen Zeit umzugehen. Die Automatisierung hat branchenübergreifend für höhere Geschwindigkeit und mehr Beweglichkeit gesorgt. Das gilt laut den Ergebnissen von BSIMM11 allerdings bei weitem nicht im selben Ausmaß für die Kontrolle und Überwachung von Sicherheitsstandards.

Eine gut durchdachte Strategie zur Risikobegrenzung

Das Aufgabengebiet von Sicherheitsexperten und Softwareentwicklern ist inzwischen sehr komplex geworden. Mit wachsenden Verantwortungsbereichen müssen sie mehr in weniger Zeit erledigen und gleichzeitig die Anwendungssicherheit gewährleisten. Entwicklungsprozesse verändern sich außerdem kontinuierlich, um Durchlaufzeiten zu reduzieren und die Agilität des Unternehmens zu verbessern. Damit das gelingt, müssen eine Vielzahl von Anforderungen erfüllt sein: 

• Transparenz in Echtzeit darüber, welche Software und Dienste ausgeführt werden sowie über die zugehörigen Umgebungen und Konfigurationen
• Einblick in die laufenden Software-Komponenten (z.B. Open-Source-Software, benutzte Cloud-APIs)
• Die automatische Ausführung von mindestens den minimal erforderlichen Tests zur Schwachstellenerkennung mit jeder Version; nachverfolgen der Ergebnisse in einem Bug-Tracking-System
• Speichern betrieblicher Daten für aussagekräftige Sicherheitsanalysen über den gesamten Wertstrom hinweg
• Rückverfolgbarkeit der laufenden Dienste bis zu den Repositories und genau dem Team, das sie erstellt hat
• Es Engineering-Teams ermöglichen, Sicherheitsmängel so früh wie möglich im Lebenszyklus zu beheben
• Aktualisieren von Netzwerk-, Host-, Container- oder Application-Layer-Konfigurationen mittels Orchestrierung
• Automatisches ungültig erklären und die Rotation sensibler Assets (Anmeldeinformationen/Schlüsselmaterial) in einer Bereitstellung
• Automatisches Failover/Rollback bei funktionierenden Assets oder bekanntermaßen gut funktionierenden Konfigurationen/Builds.

Das ist die Realität, in der Unternehmen Software entwickeln und/oder nutzen. Wir beobachten einen wachsenden Trend zur Automatisierung bei der Integration von Tools wie GitLab für die Versionskontrolle, Jenkins bei der Continuous Integration (CI), Jira für die Fehlerverfolgung und Docker für die Container-Integration in Werkzeugketten. Diese Tools schaffen eine zusammenhängende, automatisierte Umgebung. Sie erlaubt es einem Unternehmen, qualitativ hochwertige Innovationen schneller auf den Markt zu bringen und sich auf seine Kernkompetenzen zu konzentrieren.

Die Entwicklungsgeschwindigkeit nimmt weiter zu. Das gilt auch für die Häufigkeit der Bereitstellungen. Diese vielfältigen dynamischen Workflows müssen zwangsläufig um Sicherheitstests ergänzt werden. Integrierte, automatisierte Sicherheitstests werden dabei zunehmend wichtiger.

Der Innovationsdruck darf allerdings nicht dazu führen, dass Unternehmen sich aus ihrer Verantwortung für Sicherheit und Risikobegrenzung zurückziehen. Managed Security Testing liefert die wichtigsten Überlegungen zu Personen, Prozessen und Technologien. Erkenntnisse, die Unternehmen dabei unterstützen, das gewünschte Innovationstempo beizubehalten, ohne bei der Sicherheit Kompromisse einzugehen. Geeignete Managed Security Testing-Lösungen kehren die Beziehung zwischen Mensch und Automatisierung um. Menschen fungieren in einem ansonsten maschinengesteuerten Prozess gewissermaßen als „Mikro-Services“ und nicht wie in der traditionellen Sichtweise, in der Automatisierung einen menschlichen Prozess verstärkt oder ergänzt.

Unternehmen gewinnen dadurch die notwendige Flexibilität zum Testen der Anwendungssicherheit, und handeln gleichzeitig finanziell verantwortlich. Gezahlt wird nur, was man wirklich braucht. Firmen greifen je nach ihrem Bedarf auf Cybersicherheits-Ressourcen zu, etwa bei Engpässen der Testkapazitäten. So lässt sich mehr Transparenz, Flexibilität und Qualität zu vorhersehbaren Kosten schaffen. Gleichzeitig liefert das Verfahren die erforderlichen Daten, um Risiken effizient und effektiv zu beheben.

Eine Open Source-Managementstrategie implementieren

Open Source Software (OSS) ist in wachsendem Ausmaß zu einem wesentlichen Baustein nahezu jeder modernen Softwareanwendung in unterschiedlichen Branchen geworden. Die Nachfrage, Open Source-Codekomponenten und -Bibliotheken zu identifizieren, nachzuverfolgen und zu verwalten hat exponentiell zugenommen. Wer Open Source verantwortungsvoll nutzen will, der muss sich um die Identifikation von Lizenzen ebenso kümmern wie um das Patchen bekannter Schwachstellen und Richtlinien, um das Problem veralteter und nicht mehr unterstützter Open Source-Pakete zu adressieren.  Die Verwendung von Open-Source-Software an sich ist nicht das Problem, zumal die Wiederverwendung zu den Best Practices der Softwareentwicklung zählt. Was Unternehmen hingegen gefährdet, ist die Nutzung nicht gepatchter OSS.

Der 2020 Open Source Security and Risk Analysis (OSSRA) Bericht liefert dazu einiges an Zahlenmaterial. Leider brauchen Unternehmen immer noch viel zu lange, um bekannte Schwachstellen zu beheben. Beispielsweise wurde 2020, sechs Jahre nach der ersten öffentlichen Bekanntgabe, die Heartbleed Sicherheitslücke erstmals in keiner der geprüften kommerziellen Software mehr gefunden (die die Grundlage des OSSRA-Berichts bilden).

Bemerkenswert ist, dass 91 % der untersuchten Codebases Komponenten enthalten, die seit mehr als vier Jahren veraltet sind oder bei denen in den letzten zwei Jahren keinerlei Entwicklungstätigkeit zu verzeichnen war. Die Folge: Diese Komponenten sind einem höheren Risiko von Sicherheitslücken und Exploits ausgesetzt. Das Durchschnittsalter der in den geprüften Codebasen gefundenen Schwachstellen liegt bei etwas weniger als 4 ½ Jahren. Der Prozentsatz an Schwachstellen, die älter als 10 Jahre sind, betrug 19 %, und die älteste gefundene Schwachstelle war stolze 22 Jahre alt. Es liegt auf der Hand, dass wir alle (als Nutzer von Open Source) bei der Abwehr von Cyberangriffen Nachholbedarf haben.

Um dem Ganzen ein wenig mehr Kontext zu geben: 99 % der für den Bericht analysierten Codebasen enthielten Open-Source-Software, 75 % davon wies mindestens eine Schwachstelle und 49 % hochriskante Schwachstellen auf. Um das Sicherheitsrisiko in einer Open-Source-Codebasis zu senken, muss man genau wissen, welche Software verwendet wird und welche Exploits sich auf die Schwachstellen auswirken könnten. Eine populäre Methode, sich diese Transparenz zu verschaffen sind umfassende Stücklisten vom betreffenden Lieferanten. Diese Listen werden auch als „Build List“, „Software-Stückliste“ oder „SBOM“ bezeichnet. Die SBOM sollte allerdings nicht nur alle Open-Source-Komponenten verzeichnen, sondern auch die verwendeten Versionen, den jeweiligen Download-Ort für jedes Projekt und sämtliche Abhängigkeiten, die Bibliotheken, die der Code aufruft, und die Bibliotheken, mit denen diese Abhängigkeiten verknüpft sind.

Moderne Anwendungen enthalten durchweg eine Fülle von Open Source-Komponenten und beschwören damit eine Reihe von möglichen Problemen mit Sicherheit, Lizenzierung oder auch der Codequalität heraus. Irgendwann, wenn eine Open-Source-Komponente älter wird (mit neu entdeckten Schwachstellen in der Codebasis), wird sie mit ziemlicher Sicherheit nicht mehr funktionieren – oder anderweitig eine Codebasis öffnen, die sich wiederum ausnutzen lässt. Um die von älteren Open-Source-Komponenten ausgehenden Risiken zu bewältigen, braucht man entsprechende Richtlinien. Sonst läuft man in eine Reihe möglicher Probleme mit Cyber-Assets, die zu 100 % von Software abhängig sind.

Unternehmen profitieren in vielerlei Hinsicht von klar definierten Prozessen und Richtlinien. Etwa, wenn es darum geht, Open-Source-Komponenten und -Bibliotheken zu verwalten, Qualitäts-, Sicherheits- und Lizenzrisiken bei Open Source zu senken und die Open-Source-Codebasis kontinuierlich auf Schwachstellen, Upgrades und den allgemeinen Zustand hin zu überwachen. Klare Richtlinien bei der Einführung und Dokumentation neuer Open-Source-Komponenten tragen dazu bei, zu kontrollieren, was in die Codebasis einfließt und ob das den Unternehmensrichtlinien entspricht.

Die Verbesserung der Softwaresicherheit ist eine Reise. Wenn es um Software- und Applikationssicherheit geht, gibt es kein letztendliches Ziel. Entscheidend ist es, Assets präzise zu verwalten und zu überwachen sowie Transparenz über die Software-Lieferkette zu haben. Es existiert eine Reihe von Strategien, um ein solches Sicherheitsprogramm und damit den Datenschutz voranzubringen. Diese Strategien funktionieren. Und zwar unabhängig von Unternehmensgröße, Branche, aktuellem Status des Programms oder zur Verfügung stehenden Budgets.

Florian Thurmann, EMEA Technical Director bei Synopsys

Aufmacherbild / Quelle / Lizenz
Photo by Philipp Katzenberger on Unsplash