NIS2-Umsetzung: Lehren aus dem Angriff auf europäische Flughäfen

Der Cyberangriff auf Collins Aerospace im September 2025 legte durch den Ausfall eines zentralen IT-Dienstleisters den Betrieb an mehreren europäischen Großflughäfen lahm. Während große Drehkreuze im Chaos versanken, demonstrierte der Flughafen Münster/Osnabrück (FMO) durch proaktive Maßnahmen und technologische Autarkie eine beeindruckende Resilienz. Diese Analyse beleuchtet den Vorfall im Lichte der kommenden deutschen NIS2-Gesetzgebung und zeigt auf, wie die darin verankerten Pflichten zur Risikobewertung und Managementhaftung künftig solche Systemausfälle verhindern sollen.

Einleitung

Im September 2025 wurde die europäische Luftfahrtindustrie Zeuge eines Cyberangriffs, der die systemische Verwundbarkeit moderner, vernetzter Infrastrukturen aufzeigte. Ziel war nicht ein einzelner Flughafen, sondern der IT-Dienstleister Collins Aerospace, dessen Ausfall eine Kaskade von Betriebsstörungen an wichtigen Verkehrsknotenpunkten auslöste - während die Passagier bei anderen Flughäfen vom Vorfall nichts mitbekommen haben. Dieser Vorfall kann daher als Fallstudie für die Auswirkungen der bevorstehenden Umsetzung der NIS2-Richtlinie in deutsches Recht dienen. Der vorliegende Beitrag analysiert das Geschehen, indem er zunächst die unterschiedlichen Auswirkungen und Reaktionen an betroffenen Flughäfen darstellt. Anschließend wird eine Bewertung anhand der konkreten Regelungen des geplanten deutschen NIS2-Umsetzungsgesetzes (NIS2UmsuCG-E) und seines Kernstücks, des BSI-Gesetz-Entwurfs (BSIG-E), vorgenommen, um aufzuzeigen, wie die neuen regulatorischen Anforderungen den Ausgang eines solchen Vorfalls maßgeblich beeinflusst hätten.

Der Vorfall: Ein Stresstest für die operative Resilienz im Luftverkehr

Am 19. und 20. September 2025 führte eine als Ransomware-Attacke bestätigte Kompromittierung der Check-in-Software „MUSE“ des Anbieters Collins Aerospace zu weitreichenden Betriebsstörungen. MUSE steht für „Multi-User System Environment“ und ist eine sogenannte „Common Use“-Plattform. Solche Systeme, standardisiert als Common Use Passenger Processing Systems (CUPPS), ermöglichen es mehreren Fluggesellschaften, dieselbe physische Infrastruktur an einem Flughafen zu nutzen, wie z. B. Check-in-Schalter, Abfluggates und Self-Service-Kioske. Anstatt dass jede Airline eigene, dedizierte Schalter unterhält, können die Ressourcen dynamisch je nach Bedarf zugewiesen werden. Die Anwendung kann auf den Servern des Flughafens laufen oder in der Cloud. Während letztere Lösung die Skalierung erleichtert, kann sie - wie möglicherweise hier - zu einer grundlegenden Schwachstelle werden.

Die Auswirkungen an den betroffenen Flughäfen unterschieden sich jedenfalls signifikant und zeichneten ein klares Bild von den verschiedenen Graden der Vorbereitung und technologischen Abhängigkeit.

An den internationalen Drehkreuzen Berlin (BER), Brüssel (BRU) und London Heathrow (LHR) führte der Ausfall des zentralisierten externen Systems zu einem nahezu vollständigen Zusammenbruch der Passagierabfertigung. Die Betreiber waren gezwungen, auf manuelle Prozesse mit Papierlisten umzusteigen, was dem Passagieraufkommen nicht gewachsen war. Die Folge waren massive Verspätungen – am Folgesonntag waren in Heathrow 90 % der Flüge betroffen – und eine hohe Zahl an Flugstreichungen. Die präventive Reduzierung der Flugkapazitäten in Brüssel um 50 % für den Folgetag deutet auf das Fehlen eines funktionsfähigen und erprobten Notfallkonzepts hin.

Im Gegensatz dazu stand die Situation am Flughafen Münster/Osnabrück (FMO) und an den weiteren Flughäfen in Nordrhein-Westfalen (NRW). Nach Bemerken der Störung traf die IT-Leitung des FMO die Entscheidung, die eigenen Systeme proaktiv von der externen Plattform zu trennen. Der Check-in-Betrieb wurde nahtlos auf autarke, interne Serversysteme umgeschaltet, sodass der Flugbetrieb ohne nennenswerte Einschränkungen für die Passagiere fortgesetzt werden konnte. Dieses Vorgehen war kein Zufall, sondern das Ergebnis einer strategischen Ausrichtung auf technologische Unabhängigkeit, die durch den Betrieb eines eigenen, KRITIS-fähigen Rechenzentrums untermauert wird.

Bewertung anhand des NIS2-Umsetzungsgesetzes: Regulatorische Anforderungen als Blaupause für Resilienz

Hätte das deutsche NIS2UmsuCG zum Zeitpunkt des Angriffs bereits gegolten, wären die Betreiber als “besonders wichtige Einrichtungen“ zu Maßnahmen verpflichtet gewesen, die ein Szenario wie an den großen Drehkreuzen verhindert hätten. Der Fall Münster/Osnabrück dient hierbei als positives Fallbeispiel, das die Prinzipien der neuen Regulierung bereits in der Praxis umsetzt.

1. Risikomanagement und Sicherheit der Lieferkette: Gemäß § 30 Abs. 2 Nr. 4 des BSI-Gesetz-Entwurfs (BSIG-E) müssen Betreiber die Sicherheit ihrer Lieferketten gewährleisten. Dies hätte eine verpflichtende Risikoanalyse der Abhängigkeit von Collins Aerospace erfordert. Die Identifizierung des MUSE-Systems als kritischer „Single Point of Failure“ (SPOF) wäre zwingend gewesen. Ein Betreiber hätte nachweisen müssen, welche Maßnahmen zur Risikominderung ergriffen wurden – etwa durch vertraglich vereinbarte Sicherheitsstandards oder, wie im Fall des FMO, durch die Vorhaltung eines redundanten, autarken Systems. Das blinde Vertrauen auf die Verfügbarkeit eines einzelnen externen Anbieters wäre nach der neuen Rechtslage eine klare Pflichtverletzung.
2. Krisenmanagement und Aufrechterhaltung des Betriebs: Die Anforderung nach § 30 Abs. 2 Nr. 3 BSIG-E verlangt explizit Konzepte zur „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. Das Vorgehen an den großen Flughäfen, das auf einer reaktiven Improvisation mit unzureichenden manuellen Prozessen beruhte, steht im klaren Widerspruch zu dieser Vorschrift. Das Beispiel des FMO hingegen demonstriert ein idealtypisches Krisenmanagement: Die schnelle Trennung vom kompromittierten System und -vermutlich - die Aktivierung eines vorbereiteten, funktionsfähigen Backup-Systems sind genau das, was der Gesetzgeber mit diesem Paragrafen bezweckt.
3. Verantwortung und Haftung der Geschäftsleitung: Der entscheidende Hebel des neuen Gesetzes ist § 38 BSIG-E, der die Geschäftsleitung persönlich in die Pflicht nimmt. Sie ist nicht nur für die Billigung, sondern auch für die aktive Überwachung der Risikomanagementmaßnahmen verantwortlich und haftet bei Pflichtverletzungen persönlich. Diese Regelung hätte sichergestellt, dass die strategische Entscheidung über die Abhängigkeit von externen Dienstleistern auf höchster Ebene getroffen und das damit verbundene Risiko angemessen bewertet und gemindert worden wäre. Eine auf reiner Kosteneffizienz basierende Entscheidung ohne adäquates Risikomanagement wäre unter dieser Regelung kaum haltbar.