AlienCat - stock.adobe.com
Threat Modeling und DevOps: ein echtes Traumpaar
Proaktives Threat Modeling passt ideal zu der iterativen Arbeitsweise mit DevOps und den zugehörigen Prinzipien für Zusammenarbeit, Automatisierung und kontinuierliches Feedback.
Anwendungsentwickler müssen bei ihrer Arbeit potenzielle Bedrohungen von Anfang an mitdenken. Threat Modeling – auf deutsch Bedrohungsmodellierung – ist ein strukturierter Prozess, der es IT-Teams ermöglicht, sich potenzielle Bedrohungen für ihre Anwendungen vorzustellen und Schwachstellen zu lokalisieren.
Cloud Service Provider gehören zu den wichtigsten Verfechtern von Threat Modeling. AWS (Amazon Web Services) verbreitet Threat Modeling als Teil seines Well-Architected-Framework. Microsoft Azure bietet das Microsoft Threat Modeling Tool im Rahmen des Microsoft Security Development Lifecycle an. Auch Google Cloud Platform stellt Schwachstellen- und Bedrohungsdaten als Feature des Security Command Centers bereit. Daneben gibt es eigenständige Threat Modeling Tools für DevOps-Organisationen, darunter Kenna.VM, OWSP-Threat-Dragon und ThreatModeler.
Das Threat Modeling Manifesto fasst die Vorteile der Bedrohungsmodellierung in einfachen Worten zusammen und rät dazu, vier wichtige Fragen für jedes DevOps-Projekt zu beantworten:
- Woran arbeiten wir?
- Was kann schief gehen?
- Was werden wir dagegen tun?
- Haben wir gute Arbeit geleistet?
Dies sind Fragen, die Sie sich in jeder Phase des DevOps-Lebenszyklus – Entwicklung, Integration, Tests, Bereitstellung und Überwachung – stellen sollten, da Anwendungen mit der Zeit immer komplexer werden. Die Kombination von DevOps und Threat Modeling ist aufgrund des datenreichen, geschlossenen und iterativen Entwicklungs-Frameworks, das DevOps bietet, geschäftlich und strategisch sinnvoll.
Wenn Sie dies in Ihrem Unternehmen umsetzen, gibt es einige bewährte Verfahren, an denen Sie sich orientieren können und die Ihnen dabei helfen, Herausforderungen vorherzusehen.
Best Practices für DevOps und Threat Modeling
Hier sind einige Best Practices, die Ihnen helfen, Threat Modeling in die DevOps-Praktiken Ihrer IT-Organisation aufzunehmen.
1. Überlegen Sie, was schiefgehen kann
Überlegen Sie gemeinsam mit dem Entwicklungsteam, wo im Projekt etwas schief gehen könnte, und ermitteln Sie, welche Maßnahmen das verhindern. Das STRIDE-Framework – Spoofing, Tampering (Manipulation), Repudiation (Leugnung), Information Disclosure (Datenpannen), Denial of Service und Elevation of Privileges (Rechteausweitung) – listet die wichtigsten Bedrohungen auf, die Sie beim Threat Modeling beachten müssen.
2. Bewerten Sie von Anfang an Geschäftsrisiken
Die Umstellung auf ein DevOps-Organisationsmodell beseitigte die Silos von Entwicklern und Systemadministratoren. Wenn Sie Threat Modeling in DevOps integrieren, müssen Sie das Geschäftsrisiko zu Beginn des Projekts bewerten.
Auf diese Weise wird Threat Modeling zur ersten Hürde, die DevOps-Teams vor dem Start des Projekts nehmen, genauso wie Sicherheit und Tests als Kontrollpunkte in der gesamten CI/CD-Pipeline fungieren. Beziehen Sie verschiedene Interessenvertreter frühzeitig und häufig in den DevOps-Prozess ein. Dokumentieren Sie die Geschäftsrisiken in einer Weise, die bei den Technologieteams Anklang findet. Und pflegen Sie offene Kanäle für die Zusammenarbeit zwischen Technologen und Geschäftsteams.
3. Implementieren Sie DevSecOps
Threat Modeling ist ein einfacher Einstiegspunkt, wenn Sie die Evolution von einem DevOps-Modells zu DevSecOps anstreben. Berücksichtigen Sie Threat Modeling in der langfristigen Strategie und im Budget, um Teams frühzeitig zu schulen und geeignete Tools einzuführen.
4. Wählen Sie ein Pilotprojekt aus
Beginnen Sie den Einstieg Ihrer IT-Organisation in das Threat Modeling auf die gleiche Weise, wie Sie ihre DevOps-Reise begonnen haben: Wählen Sie ein kleines Projekt, das wahrscheinlich besonders von Threat Modeling profitieren wird. Nehmen Sie dafür beispielsweise ein Produkt, das erhöhte Sicherheits- und Compliance-Standards erfüllen muss – und idealerweise von einem sehr sicherheitsbewussten Team entwickelt und gepflegt wird.
5. Lassen Sie Ihr Unternehmen noch mehr zusammenwachsen
Einer der Gründe für das Einführen von DevOps ist, dass Unternehmen die Lücke zwischen Entwicklungs- und Betriebsteams schließen, Kommunikationswege straffen und Bereitstellungszyklen verkürzen wollen. Threat Modelling lässt Ihre Mitarbeiter noch enger zusammenrücken.
Bieten Sie allen Beteiligten – insbesondere den nicht-technischen Mitarbeitern – Einblick in das Projekt und geben Sie ihnen eine Plattform, um Fragen oder Bedenken zu äußern. Gesunder Pessimismus und auch unrealistische Befürchtungen sind in diesen Gesprächsräumen willkommen – solange dabei am Ende ein praktikabler Plan zustande kommt.
6. Automatisieren Sie das Threat Modeling
Suchen Sie, wie bei allen anderen Elementen einer DevOps-Initiative, nach jeder Möglichkeit, die Arbeit zu automatisieren, solange der Aufwand dafürsteht – sowohl in finanzieller als auch in personeller Hinsicht. Schon ohne DevOps wird es schwierig, auf dem Arbeitsmarkt Sicherheitsexperten aufzutreiben.
Suchen Sie nach einem Threat-Modeling-Werkzeug, das sich in die DevOps-Toolchain Ihrer IT-Organisation integrieren lässt und einen grundlegenden Satz von Bedrohungsdefinitionen sowie Dokumentation und Schulungen für IT-Teams enthält.
Die größten Herausforderungen beim Einführen von Threat Modeling
Das Hinzufügen von Thred Modeling zu DevOps-Prozessen und -Toolchains kann einige Herausforderungen mit sich bringen.
1. Die Entwickler sperren sich dagegen
Threat Modeling bedeutet wesentliche Änderung an den Entwickler-Workflows, mit denen Ihr Team möglicherweise nicht einverstanden ist. Einige Entwickler wehren sich dagegen, Threat-Modeling-Prozesse zu übernehmen, weil sie das für die Aufgabe von Sicherheitsexperten halten und das nicht zu ihrer Stellenbeschreibung gehört. Zu den Faktoren, die diesen Effekt verstärken, gehört:
- mangelndes Bewusstsein oder schlechte Erfahrungen bei vorangegangenen Projekten;
- Bedenken hinsichtlich der Reibung mit dem DevOps-Prozess; und
- Budget-Streitigkeiten und interne Konflikte, wie zum Beispiel schlechte Beziehungen zwischen Entwicklern und dem Sicherheitsteam.
Bemühen Sie sich besonders, Entwickler von Anfang an sowohl in die Planungs- als auch in die Strategiediskussionen miteinzubeziehen. Suchen Sie dann nach Möglichkeiten, intern Fachwissen zu Threat Modeling zu teilen und zwar mit der gleichen Strategien, die sich bei der DevOps-Transformation Ihrer IT-Organisation bewährt haben, wie zum Beispiel Schulungen und Pilotprojekte.
2. Sie können sich nicht für einen Ansatz entscheiden
Ansätze und Prozesse für Threat Modeling sind sehr unterschiedlich. Eine Philosophie besagt, dass Sie Bedrohungen zu Beginn des Projekts prognostizieren müssen. Ein anderer sagt, dass der ideale Zeitpunkt ungefähr nach der Hälfte der Arbeit liegt. Andererseits bekommen Sie am Ende des Projekts eine besonders realistische Einschätzung.
Sprechen Sie mit Experten und lesen Sie Berichte von Branchen-Vorreitern, um Ihre Strategie auf eine Form des Threat Modeling einzugrenzen, die Ihren Projekten und Branchenkunden am besten entspricht.
3. Die Bedrohungslage ist zu komplex
Für manche Unternehmen ist es schwierig, selbst Bedrohungen zu identifizieren und sie so zu analysieren, dass sich klare Handlungsanweisungen ableiten lassen.
Um diese Herausforderung zu meistern, sind Schulungen, Best Practices und im Laufe der Zeit gesammelte Erfahrung von zentraler Bedeutung. Widmen Sie dem Projektmanagement genug Aufmerksamkeit, um diesen Übergang zu bewältigen und sicherzustellen, dass die gewonnenen Erkenntnisse auch umgesetzt werden.
