DORA verordnet Resilienz: Stabilität oder neue Risiken?

Im Januar wird DORA verbindlich. Soweit so klar. Bei DORA geht es meist um formale Anforderungen und daher stellt sich die Frage, welche technischen Herausforderungen die Umsetzung in der Praxis mit sich bringt. Aber wie verhindert man hier neue Risiken?

von Dr. Nikolai Bauer, Senior IT-Analyst bei iSYS Software, und Dorian Degen, Head of Financial Services bei iSYS Software

Gestärkte Betriebsstabilität

Artikel 7 der Verordnung fordert, dass IKT-Systeme Protokolle und Tools verwenden, die stets auf dem neuesten Stand gehalten werden, was natürlich bereits jetzt zu empfehlen ist. Ein Technologieupdate ist allerdings häufig mit Risiken verbunden, besonders, wenn innerhalb der genutzten Systeme oder Technologien ein größerer Release-Wechsel stattfindet.

Ein konkretes Beispiel wäre das Update eines Linux-Systems wie Debian. Hier endete dieses Jahr der Support für das Release 10, so dass ein Umstieg auf die Version 11 oder 12 notwendig wird. Damit werden aber auch Aktualisierungen von beispielsweise PHP auf Version 8 oder von Java auf mindestens JDK 17 notwendig, welche in den meisten Fällen auch Anpassungen am Programmcode nach sich ziehen. So führt zum Beispiel die neue Verwendung der geschweiften Klammern für den Zugriff auf Arrays und Strings seit PHP 7.4 zwangsläufig zu Anpassungen über die gesamte Anwendung hinweg.

Re­gel­mä­ßi­ge und au­to­ma­ti­sier­te Ak­tua­li­sie­run­gen der ein­ge­setz­ten Tech­no­lo­gi­en und Sys­te­me lö­sen das Pro­blem al­so nur temporär.”

Daher ist es wichtig, den Markt bzw. die Community, in der die eingesetzten Komponenten weiterentwickelt werden, kontinuierlich bzgl. zukünftiger Releases und die hier zu erwartenden Änderungen zu überwachen und neue Versionen rechtzeitig in geeigneten Testumgebungen zu verifizieren. Idealerweise kombiniert man dies mit einer schrittweisen Modernisierung der Architektur des Systems. Eine Modularisierung und somit Aufteilung des Gesamtsystems in eigenständige Komponenten, so wie sie charakteristisch für alle modernen Architekturansätze ist, reduziert das Risiko, das sich beim Austausch bestimmter Technologien oder des Basissystems ergibt, nochmals deutlich.

Anwendungsentwicklung

Im Gegensatz zu den BAIT/VAIT liegt der Fokus in DORA im Bereich der Entwicklung von Anwendungen nun weniger auf der Dokumentation, sondern mehr auf der sicheren Implementierung. RTS RMF fordert in Artikel 16 (3), dass Verfahren existieren müssen, die Schwachstellen und Anomalien im Quellcode identifizieren und diese auch aktiv adressieren.

Die zuverlässige Erkennung von Schwachstellen und Anomalien in einem Softwareprogramm ist eine bekannte Herausforderung, daher ist die Vorgabe durch DORA an dieser Stelle nur konsequent.”

Die Identifikation solcher Schwachstellen ist in modernen IT-Projekten gängige Praxis. Es gibt am Markt eine Vielzahl bewährter Werkzeuge wie beispielsweise SonarQube, Checkmarx oder Veracode, die Programmcode auf Schwachstellen, konkrete Fehler oder Sicherheitslücken hin untersuchen. Verbunden mit entsprechenden DevOps-Prozessen werden solche Prüfungen dann in Build-Pipelines fest integriert, so dass sichergestellt ist, dass kein ungeprüfter Code auf Test-, Abnahme- oder Produktionsumgebungen gelangt.

Eine Software Bill of Materials (SBOM) ist in diesem Zusammenhang ein wertvolles Instrument, da sie sämtliche genutzten Komponenten und deren Abhängigkeiten erfasst und diese Informationen auch über die Lieferketten hinweg transparent macht.”

Auch das in der agilen Softwareentwicklung häufig genutzte Pair Programming ist ein probates Mittel, um Schwachstellen durch ein 4-Augen-Prinzip frühzeitig zu entdecken.

Eine interessante Frage ist hier, wie man erkannte Schwachstellen adressiert, wenn man sie in Systemen identifiziert, die bereits produktiv genutzt und aktuell nicht direkt weiterentwickelt werden. Hier muss neben dem technischen Risiko der identifizierten Schwachstelle selbst auch das Risiko bewertet werden, welches die Anpassung des bestehenden Codes einer eventuell schon älteren Komponente mit sich bringt. Dazu müssen alle betroffenen Komponenten inklusive sämtlicher Abhängigkeiten zunächst identifiziert und dann einer individuellen Risikoanalyse unterzogen werden.

DORA-Testing

In Kapitel IV DORA wird gefordert, dass die operationale Resilienz durch Tests regelmäßig überprüft wird.

Neben den sehr umfangreichen Thread-Lead-Penetration-Tests (TLPT), die an dieser Stelle nicht weiter betrachtet werden, da sie nur für ausgewählte Finanzunternehmen gelten, sind Basistests für alle Unternehmen relevant.”

In Artikel 25 werden hier szenariobasierte Tests, Leistungs- und Penetrationstests gefordert. Hier ist sicherzustellen, dass solche Tests und die hier simulierten Störungen nicht genau die unerwünschten Nebenwirkungen in Produktionsumgebungen haben, die man vermeiden will.

Hat man Umgebungen zur Verfügung, die mit der Produktionsumgebung weitgehend identisch sind, kann man solche Tests dort natürlich simulieren, allerdings ist die Bereitstellung einer wirklich identischen Umgebung in der Regel auch mit vielen Herausforderungen verbunden.”

So kann z.B. die realitätsnahe Simulation eines Katastrophenfalls durch provozierte Cluster-Failover unter Einbeziehung physikalisch getrennter Rechenzentrumsstandorte und sämtlicher Netzwerkparameter inklusive Firewalls nur im Produktivbetrieb und außerhalb der Geschäftszeiten in dedizierten Wartungsfenstern erfolgen. Andernfalls müssten bei der Bewertung der Ergebnisse deutliche Abstriche hinsichtlich ihrer Belastbarkeit gemacht werden.

Geänderte Anforderungen an den Ausstieg

Entsprechend der Mitteilung der BaFin steigen die Anforderungen an Ausstiegsstrategien für IKT-Dienstleistungen kritischer und wichtiger Funktionen deutlich.”

Man muss aus technischer Sicht also die Frage beantworten können, ob eine Software oder Softwarekomponenten bei einem anderen Dienstleister betrieben werden könnten und wie ein Wechsel hier in der Praxis organisiert werden kann.

In einem klassischen Szenario betreibt das Unternehmen ein individuell entwickeltes System selbst in der Infrastruktur eines externen Dienstleisters.”

In diesem Fall ist eine Exit-Strategie zu einem alternativen Dienstleister in der Regel ohne größere Probleme zu bewerkstelligen, sofern es sich bei den Basissystemen um jeweils aktuelle Versionen handelt, die breit verfügbar sind.

Komplizierter wird das Thema Ausstieg, wenn bereits individuelle Dienste einer der etablierten Cloud-Anbieter intensiver genutzt werden, zum Beispiel Speicherdienste wie S3 in AWS oder Blob Container in Azure. Um hier die Abhängigkeit zu einem der Provider reduzieren zu können, muss man sich mit dem Thema Multi-Cloud-Computing beschäftigen und die dort etablieren Konzepte berücksichtigen. Die meisten Funktionalitäten werden im Grunde überall angeboten, unterscheiden sich aber häufig in Details. Beschreibt man die Infrastruktur konsequent mit Werkzeugen aus dem Bereich Infrastructure as Code, wie zum Beispiel Teraform, schafft man eine gute Basis, um eine Migration in eine neue Cloud-Infrastruktur bei Bedarf effizient umsetzen zu können.

Betrifft die externe Dienstleistung nicht nur den Betrieb, sondern auch die Wartung und Entwicklung unternehmenskritischer IT-Systeme, bringt ein Ausstieg nochmals ganz andere Herausforderungen mit sich. Ein Dienstleister, der an der Entwicklung der relevanten IT-Systeme beteiligt ist oder diese sogar federführend übernimmt, hat in der Regel die notwendige Technologiekompetenz sowie ein tieferes Verständnis der fachlichen Anforderung und Spezifikationen aufgebaut, die nicht ohne weiteres auf einen neuen Dienstleister übertragen werden können.

Ein ausreichendes internes Wissen über Architektur und Code ist hier also unverzichtbar.”

Der Einsatz moderner KI-Werkzeuge wie zum Beispiel Large Language Modelle liefern hier aktuell sehr vielversprechende Ergebnisse, wenn es darum geht, größere Systeme besser analysieren und verstehen zu können.

Auf diese Weise gewonnene Erkenntnisse können auch für die Modernisierung der IT-Architektur in Richtung modularer Ansätze wie etwa Microservices genutzt werden. Durch die hier definierte klare und konsequente Trennung in fachlich und technisch unabhängige Module ist eine Übergabe einzelner Komponenten an einen oder sogar mehrere neue Dienstleister leichter zu steuern und mit wesentlich weniger Risko für das Gesamtsystem verbunden.

Bleibt die Frage, wie die Abhängigkeit zu einem Dienstleister bzw. die Frage eines Ausstiegs bei Standardlösungen wie zum Beispiel Office 365 im Rahmen von DORA gelöst werden kann.

Erkennung und Behandlung von Schwachstellen

Für die Erkennung von Anomalien sowie die Klassifizierung und Berichterstattung von Vorfällen ist die Behandlung von Logfiles interessant, für die in RTS RMF in Artikel 12 weitreichende Anforderungen gestellt werden.”

So sind Logs vor Manipulation, Löschen und unberechtigtem Zugriff zu schützen. Der Zugriff an sich wird in bestehenden Systemen in der Regel durch die notwendigen Administrationsrechte auf Systemebene geschützt. Hier muss man bestehende Systeme hinsichtlich einer längerfristigen und sicheren Archivierung der Logdateien prüfen. Um eine Manipulation der Logs ausschließen zu können, sind zum Beispiel Hashing- oder Verschlüsselungsverfahren einzusetzen, was aber ebenfalls zu größeren und vor allem zentralen Anpassungen bestehender Systeme führen kann.

Die Cloud-Infrastrukturen der großen Provider haben naturgemäß sehr umfassende Lösungen im Bereich des Monitorings und der Log-Dateien, die verbunden mit einem entsprechenden IAM-Konzept den hier gestellten Anforderungen leichter gerecht werden, sofern das System in Richtung einer echten Cloud-Architektur migriert werden kann.

Verschlüsselung von Daten auch während der Verarbeitung

In DORA wird die Verschlüsselung von Daten entsprechend ihrer Kritikalität in allen Zuständen (at rest, in transit & in use) vorgeschrieben.”

Da eine Verschlüsselung während der Verarbeitung bisher nicht etabliert ist, ist hier gemäß der Verordnung alternativ auch die Verarbeitung in separierten und besonders geschützten Umgebungen möglich.

Der Schutz von Informationen auch während der Verarbeitung ist ein Sicherheitsparadigma, das als Confidential Computing bezeichnet wird und bisher nur in ausgewählten IT-Infrastrukturen Anwendung findet.”

Für ein Finanzunternehmen, das eine so gesicherte Umgebung aufbauen will, stellt sich dabei die Frage, ob das on-premise oder als Cloud-Dienst umgesetzt werden soll. In einer eigenen Umgebung kommen dann Technologien wie etwa Intels Software Guard Extensions (SGX) zum Tragen, mit denen das entsprechende Trusted Execution Environment (TEE) realisiert werden kann.

In der Cloud hingegen bieten die großen Service Provider hier Lösungen wie Nitro Enclaves von AWS oder Azure Confidential Computing an.

Identitäts- und Rechtemanagement

Auch wenn sich durch DORA inhaltlich nicht allzu viele Änderungen im Vergleich zur BAIT/VAIT im Bereich des Identitäts- und Rechtemanagements ergeben, gibt es doch an einigen Stellen detaillierte Anforderungen. So fordert zum Beispiel, ergänzend zum Kapitel 6.2 der BAIT/VAIT, Artikel 21 des RTS RMF unter anderem, dass generische Accounts weitestgehend limitiert werden.

Es stellt sich die Frage, ob hier die häufig eingesetzten technischen Benutzer, über die sich heute noch sehr viele IT-Systeme zum Beispiel gegenüber Schnittstellen oder Datenbanken authentifizieren, damit zwingend durch modernere, etwa tokenbasierte Ansätze abgelöst werden müssen.”

Solche modernen Authentifizierungsmechanismen sind grundsätzlich zu empfehlen, da sie eine wesentlich höhere Sicherheit als die klassisch statischen Ansätze bieten. Dadurch wird auch vermieden, dass technische Benutzer von Entwicklern oder Administratoren genutzt werden, und so die Zuordnung zu handelnden Personen, die ja auch schon in der BAIT gefordert wurde, nicht gewährleistet werden kann.

Fazit

Die neue europäische Verordnung DORA und die hier begleitenden Umsetzungshinweise der BaFin haben nicht nur organisatorische, sondern auch technische Konsequenzen, die gerade in Infrastrukturen mit IT-Systemen, die schon länger in Betrieb sind, nicht ohne Aufwand und Risiko umzusetzen sind. Wir haben hier anhand einiger Beispiele erläutert, dass die Umsetzung der hier definierten Vorgaben wichtig und für das Ziel resilienter IT-Systeme langfristig unerlässlich sind, man im Einzelnen das Vorgehen aber sehr sorgfältig planen und individuell auf die bestehenden Gegebenheiten der IT-Systeme abstimmen muss.

Zusammenfassend kann man festhalten, dass eine Modernisierung bestehender IT-Systeme in vielen Fällen die effizientere, oft auch die einzige Variante darstellt, um die neuen Anforderungen hinsichtlich resilienter Systeme zuverlässig umsetzen zu können.”

Sie sollte daher fester Bestandteil einer zukunftssicheren IT-Strategie sein.Dr. Nikolai Bauer und Dorian Degen, iSYS Software