Welchen Einfluss hat DORA auf die Cybersicherheit?
Mit dem Digital Operational Resilience Act (DORA) will die EU-Kommission die Cybersicherheit und -Resilienz im Finanzsektor verbessern. DORA soll einen einheitlichen regulatorischen Rahmen schaffen, der die Bewältigung von Cybervorfällen und das Risikomanagement unterstützt. Was sollten Finanzinstitute und ihre Dienstleister jetzt dringend tun?
Bis zum 16. Januar 2025 müssen Finanzinstitute und ihre IT-Dienstleister die Maßnahmen von DORA umsetzen. Dazu zählen strenge Anforderungen an Sicherheitsaudits, Risikomanagementprozesse und das Management von Cyber-Risiken. Im Gegensatz zum ursprünglichen Entwurf sind die Regulatory Technical Standards (RTS) und die Implementing Technical Standards (IST) ebenso umfangreich wie detailliert.
Spezifische Tests der Anwendungssicherheit wie Static Application Security Testing (SAST), Software Composition Analysis (SCA), Dynamic Application Security Testing (DAST) und Interactive Application Security Testing (IAST) sind dabei wesentliche Instrumente, die direkt dazu beitragen, die DORA-Anforderungen zu erfüllen. Diese Tests gewährleisten, dass die in einem Institut eingesetzten oder vom IT-Dienstleister entwickelten Anwendungen möglichst keine Schwachstellen aufweisen.
Achtung: DORA betrifft nicht nur Finanzinstitute
DORA betrifft nicht nur Finanzinstitute, sondern auch kritische IKT-Dienstleister. Dazu zählen Anbieter von Cloud-Diensten, Software-Hersteller, Datenanalysedienste und Rechenzentren, die Dienstleistungen für Finanzinstitute erbringen. Die verpflichtenden Maßnahmen in DORA sind:
- Audits von Anwendungen gemäß DORA im eigenen Unternehmen durchführen
- Überprüfung/Reifegradmessung der bestehenden Prozesse und deren Dokumentation in Bezug auf die Ausgestaltung des Risiko- und Vorfalls- Managements
- Festlegung von Maßnahmen auf Basis des zuvor durchgeführten Audits / der Reifegradmessung
- Einführung und Umsetzung der definierten Maßnahmen
Verständnis von Testverfahren für Anwendungen: SAST, SCA und DAST
Im Rahmen der Einführung von DORA spielen Regulatory Technical Standards (RTS) im IKT-Bereich eine wesentliche Rolle, das gilt auch für Software-Tests. Sie betreffen Banken und Finanzdienstleister, aber auch deren IKT-Dienstleister, welche die Anwendungen entwickeln.
Für eine möglichst umfassende Abdeckung empfiehlt es sich, unterschiedliche Testverfahren zu berücksichtigen, wie das Static Application Security Testing, das Dynamic Application Security Testing und die Software Composition Analysis. Bei SAST wird der Quellcode auf Schwachstellen untersucht. Dazu gehören White-Box-Sicherheitstests sowie Tests von innen nach außen und aus Entwicklerperspektive. SAST identifiziert Schwachstellen und kann Entwicklern bereits beim Schreiben des Codes gezielt Hilfestellung leisten. So lassen sich beispielsweise Datendiebstahl durch SQL-Injection, fehlerhafte Login-Masken und andere Cyber-Angriffe verhindern.
Bei SCA geht es zusätzlich um Lizenzrisiken, wie sie mit Open Source und 3rd-Party-Software verbunden sein können sowie die Bereitstellung einer Software Bill of Materials (SBOM). Dazu später mehr. DAST wiederum betrachtet potenzielle Schwachstellen in laufenden Anwendungen, also solchen, die bereits in Produktion sind. Diese Tests werden aus Sicht der Angreifer und als Black Box Security Testing durchgeführt. DAST hilft, gezielt nach Schwachstellen in einer Anwendung zu suchen, die zum Beispiel über das Internet verfügbar ist. Solche Tests sind ein wesentlicher Faktor, um fertige, bereits laufende Anwendungen umfassend auf Schwachstellen hin zu untersuchen. DAST liefert somit relevante Daten, um die Compliance mit Anforderungen an die kontinuierliche Überwachung und Prüfung von IT-Systemen herzustellen – ein wichtiger Bestandteil von DORA.
Wenn Organisationen, die unter DORA fallen, eigenentwickelte Anwendungen, Open Source und proprietäre Software einsetzen, kommen idealerweise alle drei Testverfahren zum Tragen. Während SAST und SCA schnell durchgeführt werden können, testet DAST die Anwendungen regelmäßig und dauerhaft.
Was sollten Finanzinstitute und ihre Dienstleister jetzt dringend tun?
Bei der Programmierung von Anwendungen sollten Bedrohungen so früh wie möglich erkannt und beseitigt werden. Im Rahmen der von DORA vorgegebenen Maßnahmen gehört dazu das Testen der eingesetzten Anwendungen, unabhängig davon, ob es sich um Eigenentwicklungen, Open Source oder proprietäre Software handelt. SAST ist an dieser Stelle besonders hilfreich, denn die Tests legen auch unsichere Programmierpraktiken wie das Hartcodieren von Secrets, Tokens oder Anmeldedaten offen. Dies unterstützt bei der Einhaltung der DORA-Vorgaben zur systematischen Überprüfung und Behebung von Sicherheitsproblemen während des gesamten Entwicklungsprozesses. Die Entwickler bekommen gemäß der Testergebnisse Empfehlungen dazu, wie sie die Schwachstelle am besten beheben, bevor die Anwendung in die Produktion geht. Dazu zählen umfassende Erläuterungen zur betreffenden Schwachstelle, wie diese sich auswirkt und wie die Lücke mit sicherem Code geschlossen werden kann. Dies passiert in gängigen Entwicklungsumgebungen (IDE) in Echtzeit. Dadurch lernen Entwickler gleichzeitig, sicheren Code zu programmieren (Security First).
Gerade der Build-Prozess von Anwendungen ist in jüngster Zeit immer häufiger zum Sicherheitsrisiko geworden. SCA-Tests berücksichtigen bei ihrer Überprüfung zusätzliche Pakete, die in eine Anwendung integriert werden, zum Beispiel Open-Source-Pakete. SCA-Tests werden hier eingesetzt, um parallel zu SAST-Tests für 3rd-Party-Anwendungen oder -Pakete Sicherheit zu gewährleisten. Häufig integrieren Entwickler externe Open Source in ihre eigenen Anwendungen – hier hat sich der Anteil von Open Source gegenüber proprietärem Code nahezu umgedreht. Durch die Implementierung in eigenentwickelten Code werden die Open-Source-Pakete Teil der Anwendung. Neben potenziellen Schwachstellen innerhalb von 3rd-Party-Komponenten treten nicht selten Lizenzkonflikte und Abhängigkeiten auf, die es zu berücksichtigen gilt.
SCA-Tests schaffen Transparenz über die Verwendung dieser Komponenten und tragen so direkt dazu bei, DORA-Regeln einzuhalten. SCA erlaubt eine genaue Prüfung und Überwachung der verwendeten Bibliotheken und Frameworks, um bekannte Schwachstellen zu identifizieren und entsprechende Maßnahmen zu ergreifen.
DORA wiederum hält Unternehmen dazu an, alle Risiken, die sich aus der Software-Lieferkette ergeben, zu identifizieren und zu managen. In vielen Fällen sind dazu sowohl SCA als auch SAST notwendig. Zentral ist es, eine Software Bill of Materials, eine SBOM, zu erstellen, damit klar ist, aus welchen Komponenten eine fertige Software besteht. Die Kombination der Testmethoden unterstützt die DORA-Compliance, indem sie eine umfassende Prüfung und Absicherung der digitalen Prozesse im Finanzsektor ermöglicht und derart die geforderte operationelle Resilienz fördert.
Interactive Application Security Testing
Das Interactive Application Security Testing (IAST) ist eine Testmethode, die sowohl statische als auch dynamische Aspekte kombiniert, indem sie Tests in einer laufenden Anwendung durchführt und Feedback in Echtzeit liefert. Auch das ein Baustein innerhalb der DORA-Compliance, denn so besteht die Möglichkeit, Anwendungen in Echtzeit zu überwachen und zu testen, während sie von realen Benutzern verwendet werden. IAST liefert kontinuierliche Sicherheitsbewertungen und unterstützt Firmen dabei, die Sicherheit ihrer operativen und informationsbezogenen Prozesse kontinuierlich zu validieren und zu verbessern.
So identifiziert man Sicherheitslücken, die während der Ausführung der Anwendung auftreten. Das sind zum Beispiel solche, die nur unter bestimmten Betriebsbedingungen oder in bestimmten Datenflüssen erkennbar sind. IAST ergänzt die SAST-Tests, die vor allem während der Codeerstellung eingesetzt werden. SAST analysiert den Quellcode einer Anwendung, ohne dass diese ausgeführt wird. Diese Methode ist effektiv bei der frühzeitigen Erkennung von Fehlern, die auf Code-Ebene sichtbar sind. Die Kombination von IAST und SAST erlaubt eine umfassende Sicherheitsabdeckung. Während SAST Schwachstellen früh im Entwicklungszyklus aufdeckt, bietet IAST Einblicke in Laufzeitprobleme und die tatsächlichen Auswirkungen von Schwachstellen unter realen Bedingungen. Die Integration beider Methoden in den Softwareentwicklungsprozess sorgt insgesamt für eine robustere Anwendungssicherheit.
Viele Tools, viele Probleme? Wo das Application Security Posture Management Abhilfe verspricht
Die unterschiedlichen Testmethoden, SAST, IAST, SCA und DAST, erfordern oft viele verschiedene Tools von unterschiedlichen Herstellern. Das führt zwangsläufig zu komplexen Testprozessen. Entwickler und Sicherheitstester sind nicht selten von der Vielzahl an Tools mit unterschiedlichen Schnittstellen überfordert. Hinzu kommen diverse Reports, die jeweils andere Schwerpunkte setzen und Ergebnisse entsprechend aufbereiten. Eine Priorisierung ist nur schwer möglich, erst recht, wenn man bei der Dokumentation und Verknüpfung auf Tabellenkalkulationsprogramme setzt. Sie sind bei der Priorisierung des Schwachstellenmanagements wenig hilfreich. Oft geht schlicht der Überblick verloren.
Veraltete Tools und Methoden verlangsamen zudem die DevOps-Geschwindigkeit, sei es durch einen Bearbeitungsstau innerhalb der Pipeline oder die Überlastung durch eine Vielzahl von Befunden. Im Idealfall sollte eine Lösung Tests ausführen, die Ergebnisse miteinander verknüpfen, Schwachstellen priorisieren, die Behebung nachverfolgen und die Risikotransparenz zentralisieren können.
Hier verspricht das sogenannte Application Security Posture Management (ASPM) Abhilfe, eine zentrale Plattform, auf der die verschiedenen Quellen für das Risikomanagement zusammengeführt werden. ASPM orchestriert die verschiedenen Tests, priorisiert deren Management und integriert sich in die CI/CD-Pipeline. Auf diese Weise lassen sich die Anforderungen und Maßnahmen von DORA umfassend umsetzen, nachverfolgen und transparent verwalten.
Womit sollte man beginnen?
Wie so oft geht es darum, Mitarbeiter, Prozesse und Technologien nach einem definierten Maßstab aufeinander auszurichten, um Softwarerisiken zu minimieren. Der erste Schritt: einen umsetzbaren Plan für die Applikationssicherheit erstellen und einen Konsens hinsichtlich der SSI-Ziele erzielen. Als nächstes sollte man den aktuellen Status ermitteln, den Lebenszyklus der Softwareentwicklung absichern und den gewünschten Zielhorizont bestimmen – einschließlich der zur Verfügung stehenden Budgets. Eine oft unterschätzte Rolle spielt die Schulung der Mitarbeiter hinsichtlich der Grundlagen von Codierungsstandards und der Fähigkeit, sicheren Code zu erstellen. Je nach Anforderungsprofil reicht die Palette von E-Learning über kundenspezifische Trainings oder Champions-Programme, die Schulungen und ein Framework zum internen Aufbau von Champions kombinieren.
Boris Cipot ist Senior Sales Engineer bei Synopsys SIG.