Der Digital Operational Resilience Act (DORA) verlangt von Finanzunternehmen, DORA-konforme Quellcode-Review-Praktiken in einen sicheren DORA-SDLC zu integrieren, um Risiken durch Anwendungsschwachstellen und bösartigen Code zu mindern.

Bedeutung von “wo durchführbar” (where feasible)

Artikel 25 des DORA legt fest, dass Softwaretestprogramme Quellcode-Reviews “wo durchführbar” beinhalten müssen. Diese Einschränkung gilt, wenn der Quellcode dem Finanzunternehmen tatsächlich zur Verfügung steht. Folglich ist das Code-Review für intern entwickelte Software und für maßgeschneiderte Entwicklungen durch Dritte obligatorisch, während es bei “Off-the-shelf”-Paketen ausgeschlossen werden kann, wenn der Code nicht bereitgestellt wird.

Code-Review, SAST, DAST und manuelle Überprüfung

Finanzunternehmen müssen einen strengen Ansatz für DORA-Softwaretests gemäß der Delegierten Verordnung (EU) 2024/1774 verfolgen:

• Static Application Security Testing (SAST): Statische Analyse des Quellcodes zur Erkennung von Logik- und Sicherheitslücken ohne Programmausführung.
• Dynamic Application Security Testing (DAST): Dynamische Tests bei laufender Software, um Fehler zu identifizieren, die erst während der Ausführung auftreten.
• Sicherheitstests für exponierte Systeme: Für Anwendungen und Systeme, die über das Internet zugänglich sind, sind vor der Inbetriebnahme tiefgreifende Sicherheitsüberprüfungen erforderlich.

Kundenspezifische Anwendungen und kritische Funktionen

Das Niveau und die Intensität der Tests müssen in einem angemessenen Verhältnis zur Kritikalität der von den IKT-Assets unterstützten Geschäftsfunktionen stehen. Für Anwendungen, die kritische oder wichtige Funktionen unterstützen, sieht DORA vor:

• Überprüfung durch Tests, ob neue Systeme für den vorgesehenen Betrieb geeignet sind.
• Analyse der Qualität der intern entwickelten Software, um Fehler zu vermeiden, die zu Betriebsstörungen führen könnten.
• Implementierung von Kontrollen zum Schutz der Integrität des Quellcodes, um unbefugte Manipulationen während der Entwicklung und Bereitstellung zu verhindern.

Integration in den Entwicklungszyklus (Secure SDLC)

• Trennung der Umgebungen: Entwicklungs- und Testumgebungen müssen strikt von der Produktionsumgebung getrennt sein.
• Verwaltung von Testdaten: Die Verwendung echter Daten in Nicht-Produktionsumgebungen ist untersagt, es sei denn, sie sind anonymisiert, pseudonymisiert oder randomisiert, unter Wahrung von Integrität und Vertraulichkeit.
• Projekt-Governance: IKT-Projekte, die sich auf kritische Funktionen auswirken, müssen regelmäßig der Geschäftsleitung gemeldet werden.

Nachweise für Audits und Remediation-Management

• Identifizierung von Anomalien: Jede erkannte Schwachstelle oder Anomalie muss analysiert werden.
• Aktionsplan: Es ist zwingend erforderlich, einen Aktionsplan zur Behebung der Mängel zu erstellen, in dem Verantwortlichkeiten und Zeitpläne definiert sind.
• Überwachung: Die Umsetzung der Korrekturmaßnahmen muss kontinuierlich überwacht werden, um sicherzustellen, dass das Restrisiko innerhalb der festgelegten Grenzen bleibt.

FAQ

• Ist ein Code-Review obligatorisch?
• Ja, es ist für alle intern entwickelte oder kundenspezifische Software erforderlich. Bei Software von Drittanbietern ist es “wo durchführbar” obligatorisch, d. h. wenn der Anbieter den Quellcode zur Verfügung stellt.
• Reicht SAST aus?
• Nein. Es ist erforderlich, dass Code-Reviews sowohl SAST als auch DAST umfassen, um eine umfassende Bewertung der Anwendungssicherheit zu gewährleisten.
• Wie werden Prioritäten festgelegt?
• Die Prioritäten müssen einem risikobasierten Ansatz folgen, wobei Systeme, die kritische oder wichtige Funktionen unterstützen sowie solche, die externen Netzwerken oder dem Internet ausgesetzt sind, Vorrang haben.

Bauen Sie resiliente Software: Fordern Sie eine Bewertung Ihres sicheren SDLC und Ihres Anwendungstestprogramms an, um Ihre Entwicklungsprozesse an die technischen Anforderungen des DORA anzupassen.