DORA und End-of-Life-Software: Was nachzuweisen ist

Was DORA zu Schwachstellen und Patches verlangt

Artikel 9 DORA verpflichtet Finanzunternehmen zu Maßnahmen, die IKT-Systeme gegen Angriffe und Ausfälle schützen. Konkretisiert wird das im technischen Regulierungsstandard, der Delegierten Verordnung (EU) 2024/1774. Deren Artikel 10 verlangt dokumentierte Verfahren für das Schwachstellen- und das Patch-Management, einschließlich automatisierter Schwachstellen-Scans, einer Priorisierung nach Kritikalität und der Frage, wie IKT-Drittdienstleister mit Schwachstellen in ihren Leistungen umgehen.

Hinzu kommt Artikel 8 DORA. Danach sind Altsysteme zu identifizieren und die daraus entstehenden Risiken regelmäßig zu bewerten. Abgekündigte Open-Source-Komponenten fallen genau in diese Kategorie.

Wo abgekündigte Komponenten das Verfahren sprengen

Das vorgeschriebene Verfahren endet bei End-of-Life-Software an einer Stelle, die sich nicht wegdokumentieren lässt. Der Scanner meldet eine Schwachstelle, die Bewertung ergibt einen kritischen Befund, und für die Behebung steht kein Patch bereit, weil der Maintainer keine Updates mehr liefert. Übrig bleiben Ausnahmelisten und kompensierende Maßnahmen.

Bei Anwendungen, die kritische oder wichtige Funktionen stützen, wird daraus schnell eine Prüfungsfeststellung. Die Aufsicht fragt dann nicht nach der Dokumentation der Lücke, sondern nach dem Weg, der sie schließt.

„DORA verbietet keine alte Software. Die Verordnung verlangt aber, dass jede erkannte Schwachstelle einen Behandlungspfad hat. Wer für eine Komponente dauerhaft keinen Patch bekommt und trotzdem kritische Prozesse darauf betreibt, muss erklären, wie er dieses Risiko konkret beherrscht“, sagt Rechtsanwalt Sören Reimers, Geschäftsführer der ProLicense.

Drei Wege und ihre regulatorischen Folgen

Die Migration auf eine unterstützte Version schließt die Lücke dauerhaft, bindet aber Budget und Zeit. Eigenpatching ist zulässig, muss jedoch dieselbe Nachweistiefe erreichen wie ein Herstellerpatch, inklusive Tests, Freigaben und Dokumentation. Der dritte Weg ist Drittsupport: ProLicense vertreibt als Reseller Never-Ending Support (NES) von HeroDevs, der für abgekündigte Open-Source-Versionen weiterhin CVE-Behebungen mit SLA liefert. Damit steht für die Komponente wieder ein Patch-Pfad zur Verfügung.

Ein Punkt gehört dabei offen benannt: Wer Drittsupport einkauft, nimmt einen IKT-Drittdienstleister unter Vertrag. Dessen Leistung gehört ins Informationsregister, und die vertraglichen Anforderungen von DORA an Dienstleister gelten auch hier. Das ist Aufwand, aber ein kalkulierbarer.

„In Prüfungen zählt am Ende, ob ein Unternehmen für jede Komponente sagen kann, wer sie patcht und in welcher Frist. Diese Frage lässt sich beantworten, entweder durch Migration oder durch einen Supportvertrag. Was nicht trägt, ist eine Ausnahmeliste, die jedes Jahr länger wird“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

ProLicense unterstützt bei der Bestandsaufnahme abgekündigter Komponenten und beim Vergleich der Optionen, mit dem Ziel minimaler Kosten bei voller Compliance. Das Prinzip kennt die Beratung aus dem Oracle-Drittsupport. Anfragen nimmt ProLicense über die Kontaktseite entgegen.