Swiss Room · Krimi 5 von 8
Das Einfallstor
Software · Code-Sicherheit nach Startup-Übernahme
Zum Szenario · regulatorische Einordnung
Konstruiertes Fallbeispiel auf Basis typischer Projektrisiken. Angenommen wird, dass das betroffene Finanzunternehmen im Anwendungsbereich von Art. 2 DORA steht und NovaByte als ICT-Dienstleister in einer vertraglichen DORA-Kette eingebunden ist. Ein Drittanbieter ist nicht schon dadurch selbst DORA-verpflichtet, dass er Software liefert.
Alle Schadens-, Einspar- und Kundenzahlen sind illustrative Größen des konstruierten Szenarios — keine realen Schadensstatistiken. Sämtliche Unternehmens- und Personennamen sind frei erfunden; Ähnlichkeiten mit realen Unternehmen oder Personen wären rein zufällig und sind nicht beabsichtigt.
Was dieser Krimi zeigt
Warum Legacy-APIs nach Startup-Übernahmen geprüft werden müssen – und APIs keine Schnittstellen, sondern Einfallstore sind. Basierend auf DORA Art. 17 und Art. 28.
Prolog – 3 Tage vor dem Einbruch
Die Lead Developerin Maren zoomte in die Log-Dateien. Kleine Latenzspitzen. Uneinheitliche Requests. Kein Alarm – aber ein Gefühl.
Sie schrieb dem CTO:
„Die alte API macht mir Sorgen. Ich traue dem Merge nicht.“
Der CTO antwortete nach einer Minute:
„Wir haben den Go-Live versprochen. Wir ziehen das durch.“
Es war der Moment, an dem aus einer Warnung ein Kipppunkt wurde.
1 Der unsichtbare Code
Das Berliner Softwarehaus NovaByte hatte gerade ein Startup übernommen. Name: FastLayer. Klein, agil, kreativ – aber technisch wild gewachsen. Die Integration sollte die Produktpalette erweitern.
Architekturpläne sahen sauber aus: Containerisiert. API-gesteuert. Dokumentiert. Angeblich „DORA-ready“.
Doch eine Komponente war ein blinder Fleck: Eine alte REST-API, die FastLayer nie modernisiert hatte. Gehostet bei einem Sub-Drittanbieter, von dem niemand bei NovaByte je gehört hatte. Die Logs zeigten Latenzspitzen. Die Entwickler hielten es für einen Nebeneffekt der Migration. Ein klassischer Fall von Selbsttäuschung.
2 Der Kipppunkt
Einen Tag vor dem Release warnte Maren erneut:
„Der Code ist nicht isoliert. Die API öffnet Ports, die keiner braucht.“
Doch der CTO stand unter Druck. Kunden warteten. Der Markt erwartete. Der Vorstand drängte. Er entschied:
„Wir shippen. Danach patchen wir.“
Gleichzeitig spielte der Sub-Drittanbieter ein automatisches Update ein – ungetestet, ohne Info an NovaByte, ohne Security-Check. Kein direkter Art.-17-Verstoß des Anbieters — Art. 17 richtet sich an das Incident-Management des Finanzunternehmens, nicht als unmittelbares Update-Verbot an den Zulieferer. Verletzt sind hier zuerst die vertraglichen Change- und Informationspflichten, das ICT-Änderungsmanagement und die Third-Party-Anforderungen; Art. 17 ff. DORA greifen, sobald daraus ein Vorfall wird.
Der Compliance Officer markierte den Merge im System als „integrated“. Ohne Code-Review. Ohne Scan. Nur ein Klick. Es war das digitale Äquivalent zu „Wird schon nichts passieren“.
3 Der Crash
24 Stunden später.
Ein Hacker entdeckte die ungeschützte API schneller als irgendein Mensch. Attack-Vektor: trivial. Schadenpotenzial: maximal. Die API erlaubte unautorisierte Datenabfragen. Finanzdaten flossen ab – unbemerkt.
Weder SIEM noch Monitoring schlugen an. Kein funktionierender Alert. Kein Rollback-Pfad. Keine Resilienztests. Die perfekte Dunkelzone.
4 Der Tsunami
Freitag, 21:47 Uhr. Das gesamte System brach ein.
Banken meldeten Datendiebstahl
Kunden konnten nicht mehr auf ihre Konten zugreifen
Partner verweigerten API-Zugriffe
Sub- und Hauptprovider schoben sich gegenseitig die Schuld zu
Der Auditbericht am Montag war vernichtend:
Kein Security-Review der übernommenen Codebasis
Keine Sicherheitsprüfung der API und keine angemessene Steuerung des dahinterstehenden ICT-Drittparteienrisikos (u. a. Art. 28 DORA – Sub-Kette ungeprüft)
Kein Incident Response (Art. 17)
Ungetestete Integrationspfade
Fehlendes Monitoring der Third-Party-API
Der Schaden: 6 Millionen Euro in 168 Stunden. Der CTO trat zurück. Der Compliance Officer ebenso.
5 Die Wende
NovaByte rekonstruierte das System mit chirurgischer Präzision.
| 1 | Code-Ketten prüfen | Alle APIs, alle Endpunkte, alle Sub-Prozesse. Zero-Trust. Jede Übernahme erhält ein Security-Review als Pflichtschritt. |
|---|---|---|
| 2 | Automatisierte Tests | Jeder Merge → automatisierter Security-Scan. Jede Abhängigkeit → inventarisiert, kontextualisiert und risikobasiert bewertet (nicht jede Schwachstelle hat bereits eine CVE, ein CVE-Treffer allein sagt nichts über Ausnutzbarkeit). Kein manueller Bypass. |
| 3 | Warnrunden etablieren | Technical Resilience Meetings. Wöchentliche Red Line Reviews, bei denen Entwickler Bedenken eskalieren dürfen und müssen. |
| 4 | Rollback-Pläne üben | Statt Panik: 30-Minuten-Rollback-Drills. Recovery-Pfade dokumentiert und regelmässig getestet. |
| 5 | Reporting skalieren | Fristensteuerung nach der geltenden DORA-Meldelogik (Kenntnisnahme, Klassifikation, Erst- und Zwischenbericht getrennt überwacht). Transparente Pipeline ohne Schuldzuweisungen zwischen Providern. |
Das Ergebnis: Datenleck in 12 Stunden gestoppt. Im konstruierten Szenario wurde keine regulatorische Geldbuße verhängt. Neuer Sub-Provider-Vertrag – 700.000 € Ersparnis jährlich.
Epilog – Der unsichtbare Bruch
Der grösste Fehler war nicht die fehlerhafte API. Er war der Glaube, dass alter Code „schon noch funktioniert“. Dass eine Übernahme nur eine Vermögensfrage ist, keine Sicherheitsfrage.
DORA zwingt dazu, diese Illusion zu beenden. Jede Integration ist ein neues Risiko. Und jedes ignorierte Risiko ist eine Entscheidung – auch wenn niemand sie so nennt.
Die vorliegende Geschichte ersetzt keine Rechtsberatung.
Wissen prüfen
Möchten Sie Ihr Wissen zu diesem Thema testen? Die folgenden Quiz- bzw. Lernkarten-Sets decken den Stoff dieses Stücks ab — jeweils mit Erklärung nach jeder Antwort bzw. Aufdeck-Logik.