Threat Modeling: Mit DORA zur Pflichtübung

Schwerpunkt: Security-by-Design & Zero Trust

Jörg Botsch, Partner bei PwC Deutschland im Bereich Cyber Security, thematisiert die Notwendigkeit von Threat Modeling im Rahmen von DORA. Die Vorschriften erfordern, dass Änderungen an Bankensoftware nicht ungeprüft implementiert werden. — Jörg Botsch, Partner bei PwC Deutschland im Bereich Cyber Security PwC Deutschland

Security by Design unter DORA – da wird Threat Modeling eher zur Pflichtübung als nur eine Kür: Änderungen an Bankensoftware ungeprüft ausrollen? Seit DORA (Art. 9, RTS Art. 10) ein Compliance-Verstoß. Threat Modeling liefert die geforderten Nachweise – Bedrohungsmodell, Security-Requirements, Testfälle. Neu und brisant: Frontier-AI-Modelle wie Claude Mythos beschleunigen den Schwachstellenzyklus und zwingen zu kürzeren Deploy-Intervallen.“

von Jörg Botsch, Partner bei PwC Deutschland & Robert Eberhard, Senior Manager bei PwC Deutschland, beide im Bereich Cyber Security

Mit dem Digital Operational Resilience Act (DORA) werden die regulatorischen Anforderungen an die Softwareentwicklung im Finanzsektor deutlich konkretisiert. Was bislang häufig als Best Practice galt, ist jetzt Bestandteil der Regulatorik: Änderungen an Anwendungen müssen risikobasiert bewertet, kontrolliert umgesetzt und nachvollziehbar dokumentiert werden.

Robert Eberhard, Senior Manager bei PwC Deutschland im Bereich Cyber Security, präsentiert sich in formeller Kleidung. Die Darstellung unterstreicht die Bedeutung von Threat Modeling im Kontext der DORA-Verordnung zur Verbesserung der Sicherheitsstandards. — Robert Eberhard, Senior Manager bei PwC Deutschland im Bereich Cyber Security PwC Deutschland

DORA stellt in Art. 9 der Verordnung und Art. 10 des dazugehörigen Regulatory Technical Standards (RTS) konkrete Anforderungen an Schutz, Prävention und Schwachstellenerkennung – Vorgaben, die sich unmittelbar auf die Anwendungsentwicklung auswirken. So müssen Änderungen an Software auf einem „Risikobewertungsansatz“ basieren und „auf kontrollierte Weise“ erfasst, getestet, bewertet, genehmigt, implementiert und überprüft werden.

Der RTS konkretisiert weiter: Richtlinien für Beschaffung, Entwicklung und Wartung müssen Sicherheitskonzepte enthalten und Maßnahmen gegen vorsätzliche Manipulation während Entwicklung und Einführung vorsehen.“

Ein Secure Software Development Lifecycle (Secure SDLC) bietet einen praktikablen Rahmen, um diese Anforderungen systematisch umzusetzen und gegenüber Aufsicht sowie Abschlussprüfern nachzuweisen.

Kernanforderungen aus DORA

Die Kernerwartungen lassen sich auf drei Säulen verdichten:

Erstens muss jede Änderung an Software, Hardware oder Firmware auf einem Risikobewertungsansatz basieren und kontrolliert durchlaufen werden. Zudem ist u.a. bei jeder wesentlichen Änderung der Infrastruktur eine dedizierte Risikobewertung durchzuführen.
Zweitens sind Mechanismen zur umgehenden Erkennung anomaler Aktivitäten und potenzieller Schwachstellen einzurichten. Der RTS verlangt dazu wöchentliche automatisierte Schwachstellen-Scans für IKT-Assets, die kritische Funktionen unterstützen.
Drittens sind alle IKT-Assets einschließlich ihrer Verbindungen und Interdependenzen zu inventarisieren. Auf Softwareebene bedeutet das: Transparenz über eingebundene Drittkomponenten – der RTS fordert explizit die Nachverfolgung von Bibliotheken Dritter einschließlich Open-Source-Bibliotheken.
Die Verordnung formuliert diese Pflichten technologieneutral. Wie ein Institut sie genau umsetzt, bleibt ihm selbst überlassen. Bei einer Prüfung durch die Aufsicht legt diese den jeweiligen „Stand der Technik“ als Orientierung an, gleiches sollten Unternehmen tun.

Das Bild illustriert die Prinzipien von "Security by Design" unter DORA. Es hebt die Bedeutung von Threat Modeling zur Identifizierung und Priorisierung von Risiken hervor, um Sicherheitsanforderungen effektiv abzuleiten und zu integrieren. — PwC

Threat Modeling als Risikobewertungsansatz

Autor Jörg Botsch, PwC Deutschland

Jörg Botsch ist Partner bei PwC Deutschland (Website) im Bereich Cyber Security mit Schwerpunkt auf den Themen IT-Zuverlässigkeit und IT-Resilienz und verfügt über mehr als 20 Jahre Erfahrung im IT-Umfeld. Vor seinem Eintritt bei PwC sammelte er unternehmerische Erfahrungen als Gründer und geschäftsführender Gesellschafter eines Start-ups im Bereich der Sharing Economy.

Threat Modeling, also die strukturierte Analyse möglicher Bedrohungen in der Designphase, übersetzt den von DORA geforderten Risikobewertungsansatz unmittelbar in die Praxis. Es liefert als wesentliche Ergebnisse: Bedrohungsmodell, abgeleitete Sicherheitsanforderungen, Testfälle. Damit adressiert es die Nachweispflicht für „bewertet“ und auch die Vorgaben für „getestet“. Der RTS stützt diesen Ansatz: IKT-Risikobewertung muss Schwachstellen und Bedrohungen ermitteln sowie deren Auswirkungen und Eintrittswahrscheinlichkeit messen.“Gängige Methodenmodelle zur Bedrohungsanalyse, wie beispielsweise STRIDE, lassen sich in Prozesse integrieren.

In der CI/CD-Pipeline geht es End-to-End weiter: Die auf dem Bedrohungsmodell basierenden Sicherheitsanforderungen fließen in die Entwicklungsphase ein. Beim Commit greifen Static Application Security Testing (SAST) und Software Composition Analysis (SCA). Der RTS ergänzt insbesondere statische und dynamische Testmethoden für Quellcode als explizite Erwartung.

Im Build wird dann auch die SBOM (Software Bill of Materials) generiert, der eine besondere Bedeutung zukommt. Sie schafft Transparenz über eingesetzte Bibliotheken und Drittkomponenten und bildet damit eine wichtige Grundlage für das von DORA geforderte Drittparteien- und Schwachstellenmanagement. Im Prüfungsfall ermöglicht sie den Nachweis, welche Komponenten in einer Anwendung verwendet werden und ob bekannte Sicherheitslücken betroffen sind. Vor dem Release steht ein Quality Gate – die RTS verlangt Tests und Genehmigung vor Einführung in die Produktionsumgebung, wobei Entwicklungs- und Testumgebungen strikt getrennt sein müssen. Im Betrieb führt dann das kontinuierliche Monitoring gegen CVE-Datenbanken die Schwachstellenanalyse fort.

Autor Robert Eberhard, PwC Deutschland

Robert Eberhard, Senior Manager bei PwC Deutschland, präsentiert sich in einem formellen Anzug mit Krawatte. Sein gepflegtes Erscheinungsbild und die Brille unterstreichen seine Professionalität im Bereich Cyber Security. Autor Robert Eberhard, PwC Deutschland.

Robert Eberhard begleitet als Senior Manager bei PwC Deutschland (Website) im Bereich Cyber Security seit mehr als 13 Jahren Prüfungs- und Beratungsprojekte an der Schnittstelle von IT-Sicherheit, IT-Risikomanagement und Regulatorik. Seine Expertise wird fachlich gestützt durch ein Masterstudium der Wirtschaftsinformatik (M.Sc.), die Zertifizierungen IT-Systemauditor (CISA) und IT-Risikomanager (CRISC) der ISACA und die technische Fortbildung als Cloud Solutions Architect (AWS) und -Security Engineer (Microsoft).

„Frontier AI“-Modelle, bekanntester Vertreter hier vor allem „Claude Mythos“, stellen eine neu aufgekommene und brisante Bedrohungslage dar. Diese ist sowohl in der Bedrohungsanalyse vor allem aber im Rahmen der Schwachstellenanalyse zu berücksichtigen. Verfügbare Frontier AI-Modelle sollten daher aktiv in den Sicherheitstestzyklus mit einbezogen werden. Zudem muss erreicht werden, dass die Deploy-Zyklen so verkürzt werden, dass die durch Frontier AI-Modelle häufiger und schneller auftretenden Schwachstellen schnell genug behoben werden können.

Was die Aufsicht erwartet

Security-Tests vor Produktivgang, Umgebungstrennung und dokumentierte Freigabeprozesse waren bereits vor DORA gelebter Prüfungsstandard. Was sich verändert hat, ist der regulatorische Unterbau: DORA liefert ein EU-weit einheitliches Rahmenwerk, das diese Erwartungen verbindlich verankert. Besonders hinsichtlich Frontier AI hat die Aufsicht, in Form der Europäische Zentralbank, mit ihrem Brief an die Vorstände der signifikanten Institute auch bereits eine klare Erwartungshaltung kommuniziert.

Die Aufsicht wird zwar selten nach einem „Secure SDLC“ fragen. Sie wird jedoch Nachweise für Risikobewertungen, Sicherheitstests, Freigaben und Transparenz über eingesetzte Drittkomponenten erwarten. Ein etablierter Secure SDLC bündelt genau diese Nachweise in einem konsistenten Prozess. Damit wird er nicht nur zum Instrument für sichere Softwareentwicklung, sondern auch zu einem Baustein der regulatorischen Compliance gemäß DORA. Jörg Botsch & Robert Eberhard, PwC Deutschland/dk