Dora-Kompatibilität von Java-Umgebungen Java lernt Dora kennen

Ein Gastbeitrag von Simon Ritter* 4 min Lesedauer

Anbieter zum Thema

Seit dem 17. Januar 2025 gilt die EU-Verordnung über digitale operationale Resilienz im Finanzsektor (Dora) verbindlich für betroffene Finanzdienstleister. Das heißt aber nicht, dass alle alles erledigt haben. Um die Anforderungen der neuen Regularie zu erfüllen, sollten Unternehmen auch ihre Java-Umgebungen überprüfen. Denn hier schlummern zahlreiche Compliance-Risiken.

Auch Java-Umgebungen gehören für Dora gesichert. (Bild:  Midjourney / KI-generiert)
Auch Java-Umgebungen gehören für Dora gesichert.
(Bild: Midjourney / KI-generiert)

Mit dem Digital Operational Resilience Act will die EU den Finanzsektor resilienter gegen Cyber-Vorfälle und ICT-Risiken machen. Die Regularie ist eigentlich bereits seit dem 16. Januar 2023 in Kraft und gilt ab dem 17. Januar 2025 verbindlich in den EU-Ländern.

Obwohl sich Dora in erster Linie auf Unternehmen mit Sitz in der EU konzentriert, wirkt es sich auch über die Grenzen der Europäischen Union hinaus aus, nsbesondere auf Finanzunternehmen die Geschäftsbeziehungen mit der Region unterhalten. Innerhalb der EU sind fast alle Unternehmen aus dem Finanzsektor, darunter Banken, Zahlungsdienstleister, Investmentfirmen und Versicherungsgesellschaften sowie ICT-Dienstleister, die mit diesen Unternehmen zusammenarbeiten, betroffen.

Doch bei der Umsetzung hinken viele Finanzinstitute noch immer hinterher. Laut einer McKinsey-Studie glauben weniger als ein Drittel der Befragten (31 Prozent), dass sie bis Januar 2025 alle Dora-Anforderungen erfüllen können. Genauso viele zweifeln an ihrer Fähigkeit, die Frist einzuhalten. Das könnte teuer werden, denn bei Verstößen drohen Bußgelder in Millionenhöhe (bis zu zwei Prozent des Jahresumsatzes), administrative Konsequenzen, Lizenzentzug und mögliche Reputationsschäden.

Welche Rolle spielt Java für die DORA-Compliance?

Viele Unternehmen sind sich noch immer unsicher, welche Maßnahmen sie ergreifen müssen, um Dora-Compliance zu etablieren. Wie die McKinsey-Studie zeigt, liegen die tatsächlichen Implementierungskosten ohnehin fünf- bis zehnmal höher als die von den meisten Finanzinstituten ursprünglich vorgesehenen Budgets von 5 bis 15 Millionen Euro.

Ein Bereich, der oft unterschätzt wird, ist die Java-Umgebung. Dora bezieht sich auf ICT-Assets, die als „Software- oder Hardware-Assets in den Netz- und Informationssystemen eines Finanzinstituts“ definiert sind. Da Java die bevorzugte Programmiersprache im Finanzsektor ist und 51 Prozent des Software-Codes in dieser Branche ausmacht, spielt Java Security eine wichtige Rolle für die Compliance.

Dass hier höchste Aufmerksamkeit gefragt ist, zeigt der aktuelle „State of DevSecOps-Report“ . Demzufolge haben 90 Prozent der untersuchten Java-Dienste mindestens eine schwere bis kritische Schwachstelle, und 55 Prozent lassen sich mit bekannten Exploits angreifen.

Wo lauern die größten Risiken?

Besonders anfällig für Cyber-Angriffe sind nicht im Support inbegriffenen Versionen von „Open JDK“, da diese keine routinemäßigen Sicherheits-Updates oder Patches erhalten. Dadurch steigt die Gefahr, dass Schwachstellen offen bleiben.

Ganz ähnlich verhält es sich, wenn Unternehmen veraltete Versionen von „Oracle JDK“ einsetzen. So bietet Oracle zum Beispiel keinen Support mehr für JDK 6 oder 7. Erschwerend kommt hinzu, dass Unternehmen häufig viele verschiedene Java-Versionen nutzen, so eine Azul-Studie.

Das macht das Sicherheits-Management der Systemlandschaft noch komplexer. Außerdem können veraltete Java-Versionen auch das Testing beeinträchtigen. Denn wenn Testumgebungen die Produktionsumgebung nicht mehr akkurat abbilden, vermitteln sie ein falsches Bild der tatsächlichen Anwendungsleistung und -funktionalität. Dadurch steigt das Risiko, dass wichtige Sicherheitslücken übersehen werden.

Wie gefährlich das sein kann, zeigt die „Log4Shell“-Schwachstelle, die Ende 2021 in der Log4j-Bibliothek entdeckt wurde. Log4Shell gilt bis heute als eine der kritischsten Zero-Day-Schwachstellen aller Zeiten. Aufgrund der weiten Verbreitung der Bibliothek waren fast 80 Prozent der Unternehmen weltweit betroffen. Noch immer kämpfen Security-Teams damit, die Sicherheitslücke zu schließen, weil sie schlichtweg nicht wissen, wo sich die Log4j-Bibliothek überall versteckt und welche Abhängigkeiten bestehen.

Die Dora-Anforderungen für Java-Umgebungen

Was sollten Finanzdienstleister tun, um ihre Java-Umgebungen sicherer zu machen? Die Dora-Regularie schreibt Maßnahmen in fünf Bereichen vor: ICT-Risiko-Management, Meldung von ICT-bezogenen Sicherheitsvorfällen, Testen der digitalen operationalen Resilienz, Drittanbieter-Risiko-Management und Austausch von Informationen zu Cyber-Bedrohungen. In Bezug auf Java-Umgebungen bedeutet das Folgendes:

  • 1. Finanzdienstleister müssen ein ICT-Risiko-Management-Framework entwickeln und implementieren. Da nicht-unterstützte Java-Distributionen erhebliche Risiken bergen, sollten Unternehmen lieber auf eine kommerzielle Version mit Support setzen, die stabile, getestete Builds liefert und regelmäßig Sicherheits-Updates über verschiedene Versionen und Betriebssysteme hinweg bereitstellt.
  • 2. Dora fordert einen Prozess, um ICT-bezogene Sicherheitsvorfälle zu überwachen, zu protokollieren, zu klassifizieren und zeitnah zu melden. Wird ein Vorfall als schwerwiegend eingestuft, gilt eine Meldepflicht. Finanzdienstleister brauchen daher eine Lösung, um ihre Java-Umgebungen kontinuierlich zu überwachen und Sicherheitslücken schnell zu erkennen.
    Dabei ist es wichtig, dass Inventarisierung und Vulnerability Scanning nicht nur in der Build-, sondern auch in der Run-Phase erfolgen. Nur so können Sicherheitslücken im produktiven Java-Ökosystem erfasst werden, die sich durch die Hintertür eingeschlichen haben. Außerdem sollte der Schwachstellen-Scanner direkt in die JVM (Java Virtual Machine) integriert sein, damit er keine versteckten Komponenten übersieht.
  • 3. Dora verpflichtet Finanzdienstleister, regelmäßig zu testen, ob ihre ICT-Systeme resilient und sicher funktionieren. Dazu gehört auch, das Java-Ökosystem sorgfältig auf Herz und Nieren zu prüfen. Indem Unternehmen eine aktuelle, durch Support unterstützte Java-Version einsetzen, können sie moderne Testumgebungen bereitstellen, die verlässliche Ergebnisse liefern.
  • 4. 4Zu den großen Herausforderungen von Dora zählt das Management von Drittanbieter-Risiken. Finanzunternehmen müssen Sicherheit in ihrer gesamten ICT-Lieferkette gewährleisten. Um Risiken zu minimieren, sollten sie nur mit Partnern zusammenarbeiten, die geprüfte und Java-Distributionen mit Support einsetzen und strenge Security-Standards einhalten.
  • 5. Finanzdienstleister sind laut Dora dazu angehalten, den Informationsaustausch über Cyberbedrohungen zu erleichtern. Auch dafür ist es wichtig, eine aktuelle, Java-Support-Version einzusetzen. So verpassen Unternehmen keine Patches und Sicherheits-Updates und bleiben über die neuesten Schwachstellen informiert. Relevante Bedrohungsinformationen können sie zeitnah teilen, um die kollektive Cyber-Sicherheit zu stärken.

*Der Autor
Simon Ritter ist Deputy CTO bei Azul und seit 1984 in der IT-Branche tätig. In den 90er Jahren begann er bei Sun Microsystems mit Java zu arbeiten und war im Laufe seiner Karriere sowohl in der Java-Beratung als auch der Java-Entwicklung tätig. Nach seinem Wechsel zu Oracle im Zuge der Übernahme von Sun leitete er das Java-'Evangelism'-Team für die Java-Kernplattform.
Ritter wurde zweimal mit dem „Java Rockstar“-Status auf der Veranstaltung „Javaone“ ausgezeichnet und ist ein „Java Champion“. Er vertritt Azul in der Java SE Expert Group, , der OpenJDK Vulnerability Group und dem Adoptium Steering Committee .

Bildquelle: Azul

(ID:50514028)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung