Cyberangriff auf ARINC SelfServ vMUSE: Europaweite Check-in-Stoerungen und Lehren fuer die Cyberresilienz

CyberSecureFox 🦊

Ein Sicherheitsvorfall beim IT-Dienstleister Collins Aerospace hat am Freitag, dem 19. September 2025, weite Teile der europäischen Bodensysteme für die Passagierabfertigung beeinträchtigt. Betroffen war das ARINC SelfServ vMUSE, eine zentrale Check-in- und Kioskplattform. In mehreren Flughäfen – darunter Berlin, Brüssel und London – kam es zu massiven Verzögerungen, teils mit Umstellung auf manuelle Notfallprozesse.

Auswirkungen auf den Flugbetrieb: Verzoegerungen und Annullierungen in Europa

Am Flughafen Brüssel wurden die Airlines aufgefordert, mangels «neuer sicherer Systemversion» am Montag rund 140 Flüge zu annullieren. Bereits am Wochenende fielen 25 Flüge (Samstag) und 50 Flüge (Sonntag) aus. Am Flughafen London-Heathrow waren laut Flightradar24 am Sonntag 90% von 350 Flügen um mindestens 15 Minuten verspätet; 6 Flüge wurden gestrichen, die durchschnittliche Verspätung lag bei 34 Minuten. Am Samstag kamen weitere 13 Annullierungen hinzu.

Die Europäische Kommission betonte, dass Flugsicherheit und Air-Traffic-Management nicht betroffen waren. Der Vorfall beschränkte sich auf die IT-gestützte Bodenabfertigung (Check-in, Gepäckaufgabe, Boarding-Pass-Druck).

Warum vMUSE ein Single Point of Failure werden kann

vMUSE ist eine virtualisierte CUTE/CUPPS-Plattform, die mehreren Airlines die gemeinsame Nutzung von Check-in-Schaltern und Selbstbedienungskiosken ermöglicht. Dieses Multi-Tenant-Modell erhöht zwar die Effizienz, konzentriert aber Risiko: Eine Störung im Plattformlayer wirkt sich simultan auf viele Nutzer aus. Ohne strikte Segmentierung und aktive Redundanz (aktiv/aktiv) kann es zu Kaskadeneffekten kommen – von Schlangenbildung bis hin zu flächendeckenden Ausfällen.

Moegliche Angriffsvektoren und TTPs

Die Attribution ist aktuell unbekannt. Infrage kommen typische Muster: ein Supply-Chain-Angriff auf den Anbieter, die Kompromittierung von Zugangsdaten mit nachgelagerter Code-Injektion oder ein Ransomware-Ereignis, das kritische Komponenten verschlüsselt. Ähnliche Störungen in der Luftfahrt-IT sind dokumentiert; Studien von ENISA (Threat Landscape) und NIST (SP 800-161r1) zeigen, dass gemeinsam genutzte Plattformen ohne starke Isolation besonders anfällig für breit streuende Auswirkungen sind.

Betriebliche Resilienz: Was funktionierte, wo Engpaesse lagen

Die Umstellung auf manuelle Check-in-Prozesse gehört zum Standard-BCP in Flughäfen und hält den Betrieb minimal aufrecht. Gleichzeitig sinkt die Durchsatzleistung drastisch, und Fehlerquoten steigen. Sichtbare Schwachstellen: unzureichend isolierte Kernservices, fehlende sofort verfügbare Ersatzkapazitäten an den Terminals sowie begrenzte Möglichkeiten zum Schnell-Rollback auf «goldene Images» und signierte, geprüfte Build-Stände.

Technische und organisatorische Gegenmassnahmen

Third-Party-Risiko souverän managen: Verpflichtende Sicherheitsanforderungen in Verträgen (MFA, PAM, Härtungs- und Patchprozesse), RTO/RPO vereinbaren und regelmäßig testen, Red-Team- und tabletop-Übungen durchführen. Referenzen: NIS2-Anforderungen, ENISA-Guidelines, NIST SP 800-161r1.

Zero Trust und Mikrosegmentierung: Netzwerkzonen für Kioske/Schalter strikt trennen, East-West-Traffic minimieren, Application Allowlisting durchsetzen, Updates kryptographisch signieren und Integrität prüfen. Immutable Backups und saubere Referenzimages verkürzen Wiederanlaufzeiten signifikant (vgl. NIST SP 800-34).

Resiliente Architektur und Betrieb: Aktiv/aktiv-Design für Check-in-Backends, fail-closed mit definierten Degradationsmodi, «Kiosk-Offline-Profile» für temporären Betrieb, sowie geübte Kommunikations- und Passagierinformationsprozesse zur Entlastung der Terminals.

Der Vorfall unterstreicht, dass zentrale Plattformen in der Passagierabfertigung zum Flaschenhals einer ganzen Transportökosystemkette werden können. Betreiber sollten ihre Kernarchitekturen beschleunigt modernisieren: konsequente Segmentierung, überprüfte Lieferkettenkontrollen und echte Redundanz. Wer von reaktiver Störungsbehebung zu proaktivem Risikomanagement wechselt, senkt die Wahrscheinlichkeit massiver Verzögerungen und Annullierungen beim nächsten Angriff auf die Supply Chain. Flughäfen und Airlines sind gut beraten, ihre Notfallpläne unter realistischen Bedingungen zu testen, SLAs mit messbaren RTO/RPO zu verankern und Sicherheitsupdates nur nach Signatur- und Integritätsprüfung auszurollen.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.