weerapat1003 - stock.adobe.com
Das Schwachstellen-Management mit DevSecOps verbessern
DevSecOps integriert das Thema IT-Security in jeden Schritt bei der Entwicklung von eigener Software. Besonders wichtig ist dabei auch das Management von Schwachstellen.
Selbst manche IT-Profis sind der Meinung, dass es nur wenig oder gar keine Unterschiede zwischen einer Schwachstelle und einem Bug gibt. Aber auch wenn es sich sowohl bei Schwachstellen als auch Bugs um Fehler im Code handelt, die mit größter Wahrscheinlichkeit nicht beabsichtigt sind, gibt es doch einige gewichtige Unterscheidungsmerkmale.
Manche Bugs in Software werden zum Beispiel niemals in produktiven Umgebungen auftreten, weil die verschiedenen Bedingungen für ihre Aktivierung äußerst unwahrscheinlich sind. Schwachstellen sind dagegen eine spezielle Art von Bugs, die von zwei Kerncharakteristiken bestimmt werden:
- Sie können von einer externen Quelle aus gezielt aktiviert werden.
- Sie können ausgenutzt werden, um Daten zu stehlen oder um die Sicherheit einer Anwendung zu kompromittieren.
Es ist dieser Unterschied, mit dem sich DevSecOps und alle Unternehmen, die Software entwickeln, beschäftigen müssen.
Was bedeutet DevSecOps?
DevSecOps ist nicht nur ein Konzept, sondern auch ein Set aus Tools und Methoden, mit denen Unternehmen bereits am Beginn und während einer Entwicklungs-Pipeline dafür sorgen, dass ihre Sicherheitsanforderungen auch tatsächlich eingehalten werden.
DevSecOps stuft dabei die Absicherung der Entwicklung als genauso essenziell wie das Erreichen von bestimmten Zielen oder das Einhalten von Compliance-Vorgaben ein. DevSecOps macht alle Beteiligten für die Sicherheit der Anwendung verantwortlich, egal ob es um die für das Design, die Programmierung, das Testen oder die Bereitstellung zuständigen Personen geht. Dadurch reduziert sich das Risiko, dass sich Sicherheitslücken einschleichen können, die erst dann entdeckt werden, wenn es zu spät ist, um den Schaden noch effektiv zu begrenzen.
Das Ziel von DevSecOps ist also, das gesamte beteiligte Team dazu zu bringen, sich für die Absicherung ihres Produkts und die Eliminierung von Schwachstellen verantwortlich zu fühlen. Manche Unternehmen beauftragen nur eine Einzelperson oder ein kleines Team mit dem Einsatz der DevSecOps-Tools und der Überwachung der erforderlichen Prozesse.
Ihre Rolle sollte dabei aber nur sein, alle erforderlichen Aufgaben zu koordinieren und nicht als einzig Verantwortlicher für das Schwachstellenmanagement zu fungieren. Bei den erfolgreichsten DevSecOps-Umsetzungen stellt immer auch das für die Entwicklung verantwortliche Team die meisten Ressourcen bereit.
Bewährte DevSecOps-Methoden zum Management von Schwachstellen
Aufgrund der verteilten Natur von DevSecOps ist es wichtig, sich an bereits eingeführte und erprobte Verhaltensweisen und Prozesse zu halten. Jeder einzelne Schritt in der Pipeline muss gehärtet werden, um das allgemeine Risiko zu verringern und um zu vermeiden, neue Schwachstellen einzuführen, weil die Best Practices nicht eingehalten wurden.
Dokumentieren Sie alle Maßnahmen und Ereignisse mit einer klaren Abgrenzung der benötigten Rollen. Nutzen Sie dafür speziell für den Software Development Cycle (SDLC) entwickelte Werkzeuge.
Die Sicherheit mit einem modernen Entwicklungszyklus verbessern
Der erste Schritt bei der Umsetzung von DevSecOps ist, den Entwicklungszyklus selbst abzusichern. So entstehen zum Beispiel keine neuen Schwachstellen durch eine mangelhafte Organisation und Kontrolle der Entwicklung und auch nicht durch Fehler beim Testen oder bei der Bereitstellung. Die meisten Firmen sollten moderne Tools und Konzepte bei jedem einzelnen Schritt nutzen. Beispiele für solche Lösungen sind GitOps, Container und Kubernetes. Auf hoch spezialisierte DevSecOps-Tools oder -Prozesse sollten Sie aber noch verzichten, bis der Entwicklungszyklus bereit dafür ist.
Konzentrieren Sie sich auf bewährte Lösungen. Der Grund dafür ist, dass Entwicklungs-Pipelines, Rapid Development und ähnliche Initiativen erdacht wurden, um riskante Lücken zwischen einer Änderung der Software und ihrem produktiven Einsatz zu schließen.
Dadurch sind aber neue Risiken entstanden. So können etwa schlampig umgesetzte Verfahren dazu führen, dass nur minimal getestete oder sogar komplette ungetestete Software eine Pipeline durchläuft. Ohne eine deutliche, mit Tools gestützte Methodik in jedem einzelnen der erforderlichen Schritte ist es deshalb fast unmöglich, sicherzustellen, dass die Teams DevSecOps-Tools und -Prozesse auch wirklich korrekt nutzen.
Tools zum Schwachstellenmanagement gezielt einsetzen
Wenn moderne Entwicklungs-Pipelines selbst alle Schwachstellen eliminieren könnten, gäbe es gar keinen Bedarf für DevSecOps. Der nächste erforderliche Schritt ist daher, zusätzliche auf die Absicherung ausgerichtete Maßnahmen in den Entwicklungszyklus zu integrieren.
Besonders interessant dafür sind vor allem DevSecOps-Tools aus den folgenden Bereichen:
- SDLC-Monitoring, -Versionskontrollen und -Entwicklung. Wenn Sie den richtigen Code nicht in Ihre produktiven Umgebungen bekommen, können Sie die Schwachstellen auch nicht kontrollieren. Beschäftigen Sie sich deswegen mit Entwicklungs-Tools, die Beispielcode, wiederverwendbare Codeschnipsel und Versionsverfolgung bereitstellen.
- API-Management und -Dokumentation. Die erste Kategorie erleichtert das Nutzen von APIs mit höherer Sicherheit, während die zweite dafür sorgt, dass die eingeführten Schutzmaßnahmen bei künftigen Änderungen nicht wieder verloren gehen.
- Testen sowie Auditing der Tests. Diese Art von Werkzeugen prüft die Codequalität, Leistung sowie Funktionen und sucht zudem nach Schwachstellen.
- Release-Management sowie Pre-Release-Validierung. Dabei handelt es sich gewissermaßen um die letzte Verteidigungslinie in einem Unternehmen. Diese Tools verknüpfen DevSecOps-Maßnahmen mit realen Cybergefahren.
Den Code und die verwendeten Libraries regelmäßig auf Schwachstellen testen
Viele Unternehmen, die DevSecOps nutzen, führen Code-Reviews durch – entweder wegen der Einhaltung der Compliance-Vorgaben oder aus anderen Gründen. Für ein erfolgreiches Schwachstellenmanagement sollten Sie die durchgeführten Reviews aber um Analysen der gefundenen Sicherheitslücken erweitern.
Wenn Ihr Unternehmen solche Untersuchungen momentan nicht vorsieht, dann schauen Sie sich nach Code-Review-Tools und -Praktiken um, die zu Ihrer Organisation passen. Bilden Sie Ihre Mitarbeiter in diesem Bereich aus und stellen Sie sicher, dass Code-Reviews standardmäßig durchgeführt werden müssen.
Das Management von Softwarebibliotheken ist gerade in der Entwicklungsphase ein kritisches Element jeder DevSecOps-Umsetzung. Angreifer geben sich oft besonders viel Mühe, um Schwachstellen in Libraries zu finden, da hier jeder funktionierende Exploit ausgenutzt werden kann, um gleich zahllose Systeme anzugreifen. Aus diesem Grund ist es so riskant, Ihren Entwicklern zu erlauben, fremde Bibliotheken ohne Einschränkungen einzubinden.
Ihre Entwickler sollten deshalb zumindest ein Inventar über alle in Ihrer Software genutzten Libraries führen. Außerdem sollten Sie mindestens einen Mitarbeiter damit beauftragen, jede verwendete Bibliothek auf bekannt gewordene Schwachstellen zu kontrollieren und zu überwachen.
Wenn eine weitere Absicherung nötig wird, dann sorgen Sie dafür, dass für das Hinzufügen einer neuen Bibliothek zum Inventar eine ausdrückliche Erlaubnis erteilt werden muss. Ergänzen Sie diese Maßnahme um Tests auf Schwachstellen und prüfen Sie, ob eventuell noch bereits bekannte Sicherheitslücken enthalten sind. Spezielle DevSecOps-Tools zur Analyse der Zusammensetzung einer Software können hier sehr hilfreich sein.
Testen auf Schwachstellen vs. Testen auf Bugs
Testen ist ein wesentlicher Bestandteil von DevOps. DevSecOps ist da keine Ausnahme. Bei DevSecOps ist es aber von größter Bedeutung, zwischen dem Vermeiden von normalen Bugs und Schwachstellen zu unterscheiden.
Traditionelle Softwaretests versuchen das Verhalten der Nutzer nachzuempfinden, indem alle erdenklichen Datenkombinationen getestet werden. Wenn es aber um das Aufspüren von Schwachstellen geht, sollten die Entwickler zusätzlich noch Tests durchführen, bei denen es auch um unerwartete Strukturen und Ereignisse geht. Dazu gehört zum Beispiel fehlerhaft formatierter Input. Auf diese Weise erhöhen Sie die Chance, bislang noch verborgene Schwachstellen zu finden.
Das dynamische Testen von Anwendungen (Dynamical Application Security Testing, DAST) auf ihre Sicherheit bildet dagegen das Verhalten von potenziellen Hackern nach, wenn diese gerade in ein System eindringen wollen. Auf das reine massenhafte Erzeugen von Testnachrichten wird dabei in der Regel verzichtet. In der Konsequenz können aber auch diese Tests ungewöhnliche Angriffsvektoren übersehen.
IAST-Tools (Interactive Application Security Testing) validieren APIs sowie Web-Interfaces und überwachen Interaktionen, um so beispielhafte Verhaltensweisen zu modellieren. Auf diese Weise lassen sich auch Schwachstellen auffinden, die bei Brute-Force-Tests mit zufälligen Daten häufig übersehen werden.
Manche DevSecOps-Teams ziehen es daher vor, diese Tests zuerst durchzuführen und erst danach statische oder dynamische zu starten. Welches die für Sie optimale Strategie ist, hängt von der Komplexität der Interfaces ab. Je komplexer eine API oder ein Interface ist, desto wahrscheinlicher ist es, dass früh im Entwicklungszyklus durchgeführte IAST-Tests die besten Ergebnisse bringen.
Da allgemein genutzte Libraries einer der wichtigsten Gründe für das häufige Auftreten von Schwachstellen sind, muss Quellcode, der vor allem neue Bibliotheken enthält, besonders gründlich geprüft werden. Das ändert aber nichts daran, dass vor allem Firmen in Branchen, die zu den beliebtesten Zielen von Cyberangreifern gehören jeglichen neuen Code sehr umfangreich auf Schwachstellen testen sollten. Insbesondere sind das Unternehmen aus Bereichen wie Finanzen oder Versorger. Aber auch Regierungsbehörden stehen oft im Fokus der Angreifer.
Wie viel und welche spezialisierte Software für DevSecOps tatsächlich benötigt wird, ist eine heiß diskutierte Frage. Kaum jemand wird jedoch die Notwendigkeit bestreiten, DevSecOps-Prozesse einzuführen und Trainings aller am Entwicklungszyklus beteiligten Personen sowie formalisierte Code-Reviews durchzuführen. Außer Frage steht zudem, dass dafür die Rolle eines zentralen DevSecOps-Koordinators geschaffen werden sollte. Sonst ist das moderne Rapid Development eine offene Einladung für Cyberangreifer.
