Für das laufende Jahr haben BaFin und Bundesbank drei nationale Aufsichtsschwerpunkte gesetzt: das wirtschaftliche Umfeld mit geopolitischen Unsicherheiten, IT-Sicherheit und Governance. Eine Sonderprüfung nach § 44 KWG braucht dabei keinen besonderen Anlass. Institute sollten deshalb wissen, wie ihre Softwarelandschaft in einer Prüfung aussieht, bevor die Ankündigung kommt.
Was die ersten DORA-Prüfungen gezeigt haben
Nach Berichten aus der Prüfungspraxis konzentrieren sich die bisherigen Feststellungen auf drei Felder. Im IKT-Risikomanagementrahmen wurden kritische und wichtige Funktionen nicht immer vollständig identifiziert, sodass die Sicherheitsmaßnahmen nicht risikoorientiert abgeleitet waren. Im Bereich Erkennung waren Systeme, die kritische Funktionen stützen, nicht durchgängig an die Sicherheitsüberwachung angebunden. Im Geschäftsfortführungsmanagement fehlten teilweise Business-Impact-Analysen.
Abgekündigte Software taucht in diesen Feldern nicht als eigener Prüfungspunkt auf. Sie wird dort sichtbar, wo Prüfer nach Vollständigkeit und Nachvollziehbarkeit fragen.
Wo EOL-Komponenten in der Prüfung auffallen
Der erste Punkt ist das Asset-Inventar. Wer kritische und wichtige Funktionen sauber auf Anwendungen und deren Komponenten herunterbricht, macht damit auch sichtbar, welche Frameworks und Bibliotheken keine Sicherheitsupdates mehr erhalten. Fehlt diese Tiefe, ist bereits das Inventar unvollständig.
Der zweite Punkt ist das Schwachstellenmanagement. Für jede erkannte Schwachstelle muss ein Behandlungspfad dokumentiert sein. Bei End-of-Life-Komponenten endet dieser Pfad ohne Patch, übrig bleiben Ausnahmen und kompensierende Maßnahmen. Werden diese Ausnahmen über Jahre verlängert, ist die Frage nach dem Zielbild absehbar.
Der dritte Punkt betrifft Dienstleister. Wer Sicherheits-Support für alte Komponenten einkauft, führt einen IKT-Drittdienstleister ein, der ins Informationsregister gehört und dessen Vertrag den Anforderungen genügen muss. Auch das prüft die Aufsicht.
„In Prüfungen scheitert es selten am Verständnis für das Risiko, sondern an der Nachweisbarkeit. Wer nicht zeigen kann, welche Komponenten in kritischen Anwendungen stecken und wer sie patcht, hat eine Feststellung, unabhängig davon, wie gut das System technisch abgesichert ist“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.
Reaktionswege nach einer Feststellung
Feststellungen werden mit Fristen und einem Maßnahmenplan abgearbeitet, die Umsetzung wird nachgehalten. Für EOL-Komponenten heißt das in der Regel: kurzfristig einen Patch-Pfad herstellen, mittelfristig migrieren. Eine Migration innerhalb weniger Monate ist bei tief integrierten Frameworks selten realistisch.
Als kurzfristige Maßnahme kommt Drittsupport infrage. ProLicense vertreibt als Reseller Never-Ending Support (NES) von HeroDevs, der für abgekündigte Open-Source-Versionen weiterhin CVE-Behebungen mit vertraglich zugesagten Reaktionszeiten liefert. Damit lässt sich gegenüber der Aufsicht belegen, wer die Komponente pflegt und in welcher Frist. Die Migration bleibt im Plan, bekommt aber ein realistisches Datum.
„Ein Maßnahmenplan, der nur aus einem Migrationsprojekt besteht, überzeugt niemanden, wenn das Projekt achtzehn Monate dauert. Sinnvoll ist die Kombination: sofort einen Supportvertrag, der die Lücke schließt, und parallel die geplante Ablösung“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.
ProLicense unterstützt Institute bei der Bestandsaufnahme abgekündigter Komponenten, beim Vergleich der Optionen und bei der Vertragsgestaltung, mit dem Ziel minimaler Kosten bei voller Compliance. Das Vorgehen entspricht dem Drittsupport bei Oracle-Software. Anfragen nimmt ProLicense über die Kontaktseite entgegen.
Was die ersten DORA-Prüfungen gezeigt haben
Nach Berichten aus der Prüfungspraxis konzentrieren sich die bisherigen Feststellungen auf drei Felder. Im IKT-Risikomanagementrahmen wurden kritische und wichtige Funktionen nicht immer vollständig identifiziert, sodass die Sicherheitsmaßnahmen nicht risikoorientiert abgeleitet waren. Im Bereich Erkennung waren Systeme, die kritische Funktionen stützen, nicht durchgängig an die Sicherheitsüberwachung angebunden. Im Geschäftsfortführungsmanagement fehlten teilweise Business-Impact-Analysen.
Abgekündigte Software taucht in diesen Feldern nicht als eigener Prüfungspunkt auf. Sie wird dort sichtbar, wo Prüfer nach Vollständigkeit und Nachvollziehbarkeit fragen.
Wo EOL-Komponenten in der Prüfung auffallen
Der erste Punkt ist das Asset-Inventar. Wer kritische und wichtige Funktionen sauber auf Anwendungen und deren Komponenten herunterbricht, macht damit auch sichtbar, welche Frameworks und Bibliotheken keine Sicherheitsupdates mehr erhalten. Fehlt diese Tiefe, ist bereits das Inventar unvollständig.
Der zweite Punkt ist das Schwachstellenmanagement. Für jede erkannte Schwachstelle muss ein Behandlungspfad dokumentiert sein. Bei End-of-Life-Komponenten endet dieser Pfad ohne Patch, übrig bleiben Ausnahmen und kompensierende Maßnahmen. Werden diese Ausnahmen über Jahre verlängert, ist die Frage nach dem Zielbild absehbar.
Der dritte Punkt betrifft Dienstleister. Wer Sicherheits-Support für alte Komponenten einkauft, führt einen IKT-Drittdienstleister ein, der ins Informationsregister gehört und dessen Vertrag den Anforderungen genügen muss. Auch das prüft die Aufsicht.
„In Prüfungen scheitert es selten am Verständnis für das Risiko, sondern an der Nachweisbarkeit. Wer nicht zeigen kann, welche Komponenten in kritischen Anwendungen stecken und wer sie patcht, hat eine Feststellung, unabhängig davon, wie gut das System technisch abgesichert ist“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.
Reaktionswege nach einer Feststellung
Feststellungen werden mit Fristen und einem Maßnahmenplan abgearbeitet, die Umsetzung wird nachgehalten. Für EOL-Komponenten heißt das in der Regel: kurzfristig einen Patch-Pfad herstellen, mittelfristig migrieren. Eine Migration innerhalb weniger Monate ist bei tief integrierten Frameworks selten realistisch.
Als kurzfristige Maßnahme kommt Drittsupport infrage. ProLicense vertreibt als Reseller Never-Ending Support (NES) von HeroDevs, der für abgekündigte Open-Source-Versionen weiterhin CVE-Behebungen mit vertraglich zugesagten Reaktionszeiten liefert. Damit lässt sich gegenüber der Aufsicht belegen, wer die Komponente pflegt und in welcher Frist. Die Migration bleibt im Plan, bekommt aber ein realistisches Datum.
„Ein Maßnahmenplan, der nur aus einem Migrationsprojekt besteht, überzeugt niemanden, wenn das Projekt achtzehn Monate dauert. Sinnvoll ist die Kombination: sofort einen Supportvertrag, der die Lücke schließt, und parallel die geplante Ablösung“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.
ProLicense unterstützt Institute bei der Bestandsaufnahme abgekündigter Komponenten, beim Vergleich der Optionen und bei der Vertragsgestaltung, mit dem Ziel minimaler Kosten bei voller Compliance. Das Vorgehen entspricht dem Drittsupport bei Oracle-Software. Anfragen nimmt ProLicense über die Kontaktseite entgegen.
