Brussels Airport heeft ook op zondag last van cyberaanval op inchecksystemen

Brussels Airport heeft ook zondag nog last van de cyberaanval die eerder dit weekend begon. Net als op zaterdag worden zondag nog verschillende vluchten geschrapt. De luchthaven raadt reizigers aan op de website te kijken voor actuele vluchtinformatie.

De Belgische luchthaven schrijft op zijn website dat het ook op zondag last heeft van verstoringen die zijn veroorzaakt door een cyberaanval waarover nog weinig bekend is. Op zaterdagochtend werd een leverancier van incheck- en boardingssystemen getroffen door een cyberaanval. Het gaat om het Amerikaanse Collins Aerospace, dat software maakt die wordt gebruikt bij incheckbalies en boardinggates.

Door die cyberaanval zijn er op meerdere Europese luchthavens verstoringen in vluchten. Dat is onder andere het geval op het Berlijnse Brandenburg-vliegveld en het Londense Heathrow, maar ook op Brussels Airport. Op zaterdag werden er daarom vluchten geannuleerd of vertraagd. De NOS schrijft dat Brussels Airport op zondag aan luchtvaartmaatschappijen heeft gevraagd de helft van alle vluchten te schrappen.

Het is nog steeds niet duidelijk wie er achter de aanval zit. De leverancier zegt zelf alleen dat het gaat om 'een cybergerelateerde verstoring', maar gaat daar verder niet op in. Ook op zijn website schrijft de leverancier niets over de aanval.

Door Tijs Hofmans

Nieuwscoördinator

21-09-2025 • 09:26

80

Reacties (80)

Sorteer op:

Weergave:

Typisch geval waar er allemaal dienstverleners en software samenwerken zonder fallback oplossingen...het gaat goed tot het mis gaat. Ben eens benieuwd of ze hier uit leren...


EDIT ik ga mijn reactie wat meer duiden:

Voor zover ik weet is er 1 bedrijf gehacked / platgelegd, Collins Aerospace...en alles loopt in het honderd. Ik verwacht van een oplossing dat als worst case scenario in treed (internet werkt niet, Crowdstrike issues, whatever), dat er een protocol / scenario / alternatief klaarligt dat er voor zorgt dat er geen enkele vlucht geannuleerd moet worden. Hier en daar vertragingen lijkt me onvermijdelijk...maar zoals het nu in het honderd loopt en er tientallen vluchten niet kunnen vliegen.

Dit kost tientallen zoniet honderden miljoenen euros...en ik vraag me af wie dat gaat betalen...

Kan je met alles rekening houden? Neen. Maar zoals het nu is dat moet toch echt beter kunnen.

[Reactie gewijzigd door Clemens123 op 21 september 2025 11:08]

Hoe zou jij dit inrichten, dan wel veranderen? En hoeveel bedragen de kosten van de impact van het risico, hoeveel bedragen de mitigatiekosten, en wat is dan se residual risk na mitigatie?
Zonder het systeem heel goed te kennen: wat ik vooral zou veranderen is dat je een deel van cloud omgeving ook lokaal kunt gebruiken zonder cloud, dat zou heel veel papierwerk vermijden. Ja erl zal manueel werk zijn om vluchtdata goed te zetten ipv het uit de cloud te halen / manueel te importeren. Maar dan kun je je tenminste digitaal behelpen en nog steeds gebruikt maken van de digitale voordelen (boarding passes worden nu met pen en papier geschreven)
Zonder het systeem heel goed te kennen
Ja, dat is extreem duidelijk ja.
wat ik vooral zou veranderen is dat je een deel van cloud omgeving ook lokaal kunt gebruiken zonder cloud, dat zou heel veel papierwerk vermijden. Ja erl zal manueel werk zijn om vluchtdata goed te zetten ipv het uit de cloud te halen / manueel te importeren.
Vluchtdata is het probleem niet. Eurocontrol en zijn vluchtplannen zijn nog gewoon operationeel, anders had heel Europa een probleem gehad.
Maar dan kun je je tenminste digitaal behelpen en nog steeds gebruikt maken van de digitale voordelen (boarding passes worden nu met pen en papier geschreven)
Ik denk dat je dit veel te simpel voorstelt. Dit is geen simpele laptop die je bij de Coolblue bestelt. Dit zijn werkstations met fysieke koppelingen naar de MRZ-reader, weegschaal, barcode-printer en alles wat erbij hoort. Het wegvallen van de MRZ-reader alleen zorgt al voor enorme rijen (ben daar zelf ooit slachtoffer van geweest). Tenzij je op magische wijze ineens een volledige standby terminal uit een hoge hoed weet te toveren, met totaal andere werkplekken, is het einde verhaal en is papier en pen de enige optie.

En zelfs al had je die extra terminal klaar staan, dan is mijn ervaring (ik heb aan de openstelling van Heathrow T5 gewerkt), dan gaat het niet werken. Mensen zijn hun nieuwe werkplek niet gewend, en dus daalt de efficiency. Laat dat nu net het grote knelpunt zijn om die tienduizenden passagiers door het proces heen te krijgen.

[Reactie gewijzigd door J_van_Ekris op 21 september 2025 16:16]

Dit zijn werkstations met fysieke koppelingen naar de MRZ-reader, weegschaal, barcode-printer en alles wat erbij hoort
Maar waarom designen ze dat zo?
Barcode scanners, weegschaal, barcode printers etc. hebben toch helemaal geen workstations nodig die elders het werk voor je doen? Dat kan perfect lokaal en losgekoppeld worden van de cloud.

Ik ksnap dat veel data wel ergens gecentraliseerd zit die wel van elders komt...maar om personen een seat toe te kennen, bagage in te checken, labels te printen etc. dat lijkt me inderdaad allemaal vele te complex in me kaar te zitten ,en je ziet wat er van komt.

Als die systemen zouden werken met een middleware die lokaal draait en die kan swtichen van cloud naar local operation, dan ben je veel onafhankelijker...

Maar is ook opzet van veel bedrijven: maak het complex en zorg dat alle workstations van de dienstverlener zijn...en zo zorg er voor dat je moeilijk van een systeem kan afstappen...zo blijven ze klant van je.

Je kan zeggen wat je wil, maar anno 2025 een fallback systeem hebben met pen en papier is imho gewoon belachelijk.

[Reactie gewijzigd door Clemens123 op 21 september 2025 17:22]

Maar waarom designen ze dat zo?
Barcode scanners, weegschaal, barcode printers etc. hebben toch helemaal geen workstations nodig die elders het werk voor je doen?
Het ZIJN de lokale systemen die zijn uitgevallen....
Het kwartje is gevallen. Bedankt voor de uitleg.

Dus als ik het goed versta zal het kwestie worden dan deze systemen lokaal te vervangen / opniew operationeel te maken.

Misschien dan wel kwestie van die workstations te verdubbelen: alles dubbel installeren op 2 aparte netwerken...uitsluiten dan hacken van fallback / normaal mogelijk is. En indien nodig dan maar switchen.

Eens afwactehn of er nog meer details naar buiten komen wat de hack inhield.

[Reactie gewijzigd door Clemens123 op 21 september 2025 17:27]

Dus als ik het goed versta zal het kwestie worden dan deze systemen lokaal te vervangen / opniew operationeel te maken.
Ligt aan de voorgeschreven aanpak. Als je geluk hebt is het een update draaien en dan ben je klaar. Als je pech hebt moet je aannemen dat de huidige infra gehackt is, en moet je eerst alles ontmantelen voordat je iets op kunt bouwen. Dit zijn normaal klussen die goed voorbereid worden en dan nog dagen tot weken duren. Dit is geen fijn klusje, en opschalen gaat niet.
Misschien dan wel kwestie van die workstations te verdubbelen: alles dubbel installeren op 2 aparte netwerken...
Want met twee workstations ben je veilig? Afgezien van de enorme complexiteit van een werkplek met twee servers en één set compkexe randapparatuur. Van wat ik begrijp is dit een supply-chain-attack, en dan helpt dubbel uitvoeren voor geen centimeter. Het verdubbelt alleen de ellende.
Als je die netwerken fysiek scheidt moet dat mogelijk zijn...ik vraag geen dubbel systeem om alles hetzelfde te laten verlopen en waarvan alles in sync gehouden wordt...wel een die toelaat de aanwezige hardware te gebruiken met een noodscenario, en dus wel nog efficienter te kunnen werken dan pen en papier.

Dat kan dan ook ter overbrugging gebruikt worden tot het ander systeem weerr op orde gebracht is.

Ik ga stoppen met reageren ik werk genoeg op je zenuwen...

En zover ik versta is mijn visie op de feiten hier zeer verkeerd, wat best mogelijk is :)

Nogmaals bedankt voor de info!

[Reactie gewijzigd door Clemens123 op 21 september 2025 18:40]

En hoe zie jij dat die verwachting wordt ingelost?

Het check-in systeem is zo gebouwd zodat elke balie gebruikt kan worden door elke luchtvaartmaatschapij. Het is dus perfect mogelijk om een rij incheck balies uit dienst te nemen en die passagies op een andere rij in te checken. Dit zorgt ook voor flexibiliteit en maakt het daarnaast ook mogelijk om bepaalde rijen incheck balies te voorzien voor maatschapijen die niet eens dagelijks op de luchthaven vliegen. maar misschien maar 1 of 2 vluchten per week hebben. Dat maakt de kosten daar lager.

En als dat platform er uit ligt, wat wil je dan dat ze doen? Hoe ga jij een backup voorzien die altijd werkt zonder capaciteitsverlies?

Je noemt zelft het crowdstrike scenario. Stel je nu voor dat een Luchthaven Crowdstrike op zijn systemen gebruikt (en ja, die zijn er geweest bij dat incident). Binnen enkele uren liggen alle computers eruit. Hoe ga jij een backup plan implementeren voor zoiets waarbij de passagiers niet getroffen worden?

Juist, dat kan niet!

Je hebt nu 1 incident in heel wat jaren. Dat is enkele dagen pijn. En jij noemt dat onaanvaardbaar?

Mag ik even vragen: wat ga jij doen als je dadelijk in je wagen stapt en die wagen wil niet starten? Heb je er een tweede naast staan, gewoon voor het geval dat de eerste het niet doet? En wat als die tweede net op dat moment hetzelfde probleem heeft door een software bug? Hoeveel wagens ga jij kopen zodat jij zeker bent altijd een wagen klaar te hebben staan?
Ik heb 2 wagens, beiden zonder verbinding met internet, en 2 verschillende merken.
Op welke fallback doel je? Hoe weet je dat ze die niet hebben?

Theorie: Ze hadden een identieke passieve "fallback omgeving" inclusief procedures (Wat dat dan ook mag zijn in dit geval).

Theorie situatie: Bij het actief maken van de "fallback omgeving" bleek deze exact hetzelfde "probleem" te hebben.

Disclaimer: Ik heb geen kennis en inzicht in de werking van dit systeem en de leverancier.
Ik weet dat de fallback die ze hebben op niets trekt: 1 systeem van 1 bedrijf (Collin Aerpospace) valt uit...en alles loopt in het honderd. Alles moet met hand en papier gedaan worden.

Als fallback situatie hetzelfde probleem heeft dan is de fallback niet onafhankelijk genoeg van het origineel systeem.
En de papieren versie is dus zo een fallback oplossing, net wat jij wenst te zien.
Neen dat wens ik niet te zien. Tientallen vluchten gecancelled en gigantische vertragingen.

Boarding passes met pen en papier invullen...sorry maar ik vind dat niet normaal anno 2025

Zorg voor een digitaal fallback systeem, waarbij je dingen manueel moet importeren en jezelf kan loskoppelen van de cloud indien nodig...en alles zou veel efficienter kunnen verlopen.
Opnieuw, zoals ik in mijn andere reactie reeds neergeschreven heb, je kan niet voor elke storing een digitale fallback voorzien. Dat is praktisch niet haalbaar en kostentechnisch ook niet. Brussels Airport heeft vandaag ongeveer 20% van de vluchten geschrapt.

Je schrijft direct dingen zoals "loskoppelen van de cloud" zonder te begrijpen hoe deze systemen moeten samenwerken met andere systemen, zonder even na te denken over hoe geinformatiseerd heel onze wereld net is om zo efficient en vlot te kunnen werken onder normale omstandighaden. En dan ga jij zeggen dat loskoppelen efficienter gaat zijn.

Neen, we zien nu net wat het betekend om alles los te koppelen, wanneer niets meer communiceert met elkaar, en dat werkt dus net niet. Dus waarom ga jij dan denken dat er veel betere oplossingen moeten bestaan.

Dit zijn keuzes die gemaakt worden. Risico afwegingen en kosten/baten analyses. Ja, je kan een heel redundante luchthaven bouwen als het moet, dat gaat je gewoon even enkele honderden miljoenen kosten aan investering en daarna tientallen miljoenen per jaar aan onderhoud zodat je zeker opgewassen bent tegen elk probleem. Maar is dat het waard voor een storing die zich 1x in heel wat jaren voordoet en enkele dagen voor probleme zorgt?

Ik moet deze week ook nog vliegen vanuit Brussel en ik vind het blijkbaar minder erg dan jij, die volgens mij niet met deze chaos geconfronteerd wordt maar simpelweg als keyboard warrior aan het schrijven is hoe slecht het wel niet is.
Sorry dat ik het erg vind dat er tientallen miljoenen euros aan schade onstaat ten gevolge van een enkele hack/ddos whaterver it is...

En nogmaals: boarding passes printen, bagage inchecken etc. ik snap dat dat allemaal systemen zijn die aan mekaar hangen...maar dat het alternatief van het uitvallen van het standaard systeem papier pen en papier is anno 2025, dat er tientallen vluchten in heel Europa uitvallen omdat er systemen van voor zover ik weet 1 bedrijf gehacked zijn...dat vind ik niet normaal.

Is het knap hoe die systemen normaal allemaal werken en hoe effeicient alles normaal verloopt? Ja.
Is het allemaal verschrikkelijk? Nee er zijn ergere dingen dat klopt.
Doet het personeel fantastisch werk de laatste dagen om toch zoveel mogelijk vluchten te laten vliegen? Ongetwijfeld en chapeau voor die mensen die zich redden met de middelen die er zijn.

Maar noem me geen keyboard warrior omdat ik van mening ben dat er overduidelijk een sterke afhankelijkheid is met 1 bedrijf en alles toch in mekaar lijkt te vallen als dat ene 1 bedrijf/netwerk gehacked wordt. Kan dit gebeuren? Ongetwijfeld. Niemand is immuun van cyberaanvallen...maar daar dient nu eenmal, ook door aanbiedres van deze systemen, rekening mee gehouden worden. En ik ken de de noodscenarios niet in die gevallen...maar wat ik nu lees en zie geeft me schrik dat dit de komende jaren alleen mog maar erger wordt met meer vendor lock ins, meer cloud, etc.

[Reactie gewijzigd door Clemens123 op 21 september 2025 18:35]

Dat klinkt dan als een back-end probleem. Dit soort omgevingen hebben alleen ‘live data’ alle data is ‘nu en alleen nu’ relevant. (De incheck-info van gisteren zit in een ander systeem tenslotte. Zodra het poppetje met z’n bagage de lucht in is, kan het naar een ander systeem.)

Dat maakt relevante back-ups lastiger, zeker omdat het vliegveld ook iedere seconde door gaat. Ze kunnen het niet zomaar even stilzetten en terugzetten en mensen vragen opnieuw in te checken omdat er een paar registraties verloren zijn gegaan.

Hier zijn uiteraard methoden voor, maar je bouwt zoiets als dit om er altijd te zijn (3-4-dubbel redundant, met dubbele frontend-hardware op gescheiden netwerken, blablabla, maar onder aan de streep gebruikt alles dezelfde live databron.)

Al met al. Lastig en gedoe…
Dat klinkt dan als een back-end probleem. Dit soort omgevingen hebben alleen ‘live data’ alle data is ‘nu en alleen nu’ relevant. (De incheck-info van gisteren zit in een ander systeem tenslotte. Zodra het poppetje met z’n bagage de lucht in is, kan het naar een ander systeem.)
De backend systemen werken nog. Zoals in de discussie van gisteren aangegeven werd: het zijn niet de passenger-handling backends die platgegaan zijn, die zijn nog up and running. Het zijn de fysieke terminals, de werkplekken die platgegaan zijn, de frontends zeg maar.
Denk je serieus dat een modern vliegveld zonder fallback-systemen werkt? 🤨

Volgens mij weten we nog altijd weinig over de details, dus er is helemaal niets te zeggen over hoe en wat.
Ik stel alleen maar vast dat er tientallen vluchten geschrapt worden, dat heel veel met pen en papier moet gebeuren zonder logische reden. Koppel de cloud af met een goed digitaal fallback systeem waar je manueel de vluchten etc. importeert...dan zou er ook veel moeten mogelijk zijn, zonder dat je terug wordt geworpen in de vorige eeuw en boarding passes met pen en papier moet maken.

Kijk ik ken hte systeem niet goed en zeg niet dat het eenvoudig is...maar dit moet gewoon beter kunnen en het kan niet zijn dat als 1 extern bedrijf een issue heeft dat je je niet beter kan behelpen.
Alles is een risico afweging, kans x impact. Op basis van risico’s richt je je processen in. Collins is een major speler in de markt en heeft echt wel zijn zaken op orde.

My 2 cents: We weten nog geen details. Als het een geavanceerde/targeted aanval is, is dat echt lastig te mitigeren. Anderzijds vind ik het ook opvallend dat er geen andere luchthavens significant geraakt zijn, terwijl er genoeg luchthavens op Collins cMUSE draaien. Dat zou dus impliceren dat er stiekem meer aan de hand is in Brussel, bijv. tekortkomingen in de disaster recovery procedures.

De toekomst zal het leren…
Ik stel alleen maar vast dat er tientallen vluchten geschrapt worden, dat heel veel met pen en papier moet gebeuren zonder logische reden.
Ik heb zelf wel eens een vlucht gemist omdat de MRZ-lezers van Oslo dienst weigerden. En dan is een rij die normaal 5 minuten is, ineens eentje van 1,5 tot 3 uur. Je hebt te maken met krankzinnig veel korte handelingen voor veel passengiers. Overal bij elke passagiershandeling een minuutje erbij, en je eindigt al in totale chaos. Fallback is niet makkelijk in dit soort situaties.
Koppel de cloud af met een goed digitaal fallback systeem waar je manueel de vluchten etc. importeert...dan zou er ook veel moeten mogelijk zijn, zonder dat je terug wordt geworpen in de vorige eeuw en boarding passes met pen en papier moet maken.
Met de enorme load aan transacties, waar vliegtuigstoelen niet dubbel toegewezen mogen worden etc.. is dat extreem lastig. En de cloudsystemen zijn het probleem niet, Amadeus en Navitaire zijn gewoon bereikbaar en werken (anders hadden Amsterdam en Parijs volledig plat gelegen). Het zit hem juist in de lokale eindpunten...

[Reactie gewijzigd door J_van_Ekris op 22 september 2025 13:29]

Typisch geval van: de beste stuurlui staan aan wal
Ik ben het hier denk ik mee eens. Fallbacks zijn vaak even belangrijk of misschien wel belangrijker.
Als ik het goed begrijp uit de andere thread gaat het hier om de fysieke werkplekken die gehackt zijn. Dan heb je het over honderden terminals met paspoortscanners, barcode printers en weegschalen aangesloten. Niet iets wat je even redundant in de kast legt. Vrijwel geen enkele organisatie heeft al zijn werkplekken volledig redundant off-line beschikbaar: je gaat uit van een technisch falen en dan is bij problemen je capaciteit verminderd.

Een hack aanval die al je werkplekken buiten bedrijf stelt is enorm lastig te mitigeren. Backups (standby werkplekken) hebben immers exact hetzelfde probleem.
Zojuist geland op Brussel. 1 grote bende ook bij de douane en koffer afhandeling. Ik vraag mij oprecht af of het alleen incheck is, of hierdoor het hele proces. Dit heb ik nog nooit gezien.

Nog even een aanvulling: het kan natuurlijk zoiets zijn dat feitelijk het incheck proces verstoord, maar dat je daardoor personeel gaat schuiven en dus ook alle andere processen vertraagd.

[Reactie gewijzigd door the Runningman op 21 september 2025 09:41]

Ik vlieg ook altijd via Brussel normaal maar voor één keertje Parijs gekozen vanwege de prijs en directe vlucht, Godzijdank geen problemen daar :)
Ik vermoed doordat de checkin nu op papier gebeurd dit ook gevolgen heeft voor de douane. Deze zal nu info die het misschien anders automatishc doorkrijgt nu ook op papier doorkrijgen en zo moeten checken.
Ik was gisteren op Brussel airport. Bracht een vriendin weg en die vroeg of ik wilde wachten tot ze was ingecheked. We waren er bijna 4 uur van te voren. Ze zou vliegen naar Bangkok, via Doha met Qatar airways. Na 3.5 uren in de rij voor de balie te hebben gestaan, werd er tegen de laatste circa 70 passagiers, inclusief haar, verteld dat ze niet meer mee konden en de balies zouden sluiten. Vliegtuig was vertraagd met 1 uur en 50 minuten maar ze namen niemand meer mee. Krijg je een blaadje met whatsapp nummer, en zou Qatar airways contact opnemen. Nog een diner bon van 8 euro (kun je een koffie en koekje van kopen maar niet meer). Ze heeft het niet afgewacht, en zelf geregeld dat ze vandaag vanuit Schiphol kon vliegen. Toevallig net nog gevideobelt met haar vanuit vliegtuig naar Doha. Techniek staat voor niets deze dagen maar wel op Brussel airport waar het inderdaad een grote bende was.
In het artikel van vandaag van de NOS wordt ook bevestigd dat inderdaad de bagage-afhandeling ook hierdoor geraakt wordt. En dat kan er mee te maken hebben dat er een flink aantal jaren geleden een regel is ingevoerd dat een koffer altijd gelinkt moet zijn aan een passagier die ingestapt is. Dus wanneer een passagier niet instapt, kan het gebeuren dat de koffer weer uit het vliegtuig moet. Dit is ingevoerd na bomaanslagen met koffers op vliegtuigen waarbij de passagier niet in het vliegtuig zat/was ingestapt/uitgestapt.

Hierdoor is het boardingsysteem gekoppeld aan het koffersysteem. En bij problemen met het boardingsysteem krijg je dus door de link automatisch problemen met het koffersysteem.
Ik heb ooit gewerkt voor een kleine ferry maatschappij.
Zelf hier hadden we een fall back systeem via voor gemaakte Excel sheets i.p.v. manifest systeem in Oracle.
En ook 3de fall back systeem via voor afgeprinte lijsten en formulieren.
Zelfs een simpele bediende had dit al voorzien.

Nog eens een bewijs dat cloud services van derden een risico is waar je totaal afhangt van kunde of onkunde van anderen en waar je data niet in eigen handen hebt.
Ik heb ooit gewerkt voor een kleine ferry maatschappij.
Dus omdat het bij een kleine ferry maatschappij werkt, moet het schalen tot op het nivo van een complete luchthaven met tienduizenden passagiers per dag????

De omvang van dit soort processen vereist een stuk automatisering. Terugval in efficiency leidt tot enorme chaos, bijna per definitie. Ik weet niet of je de ellende van Schiphol van een paar jaar terug nog herinnerd? Dat kwam omdat security onvoldoende efficient de boel afhandelde. Mensen stonden buiten in de rij...
Dus omdat het bij een kleine ferry maatschappij werkt, moet het schalen tot op het nivo van een complete luchthaven
Het argument is dat de luchthaven niet laat zien zich hier op behoorlijk voorbereid te hebben. Niet dat het hoe dan ook maar volledig moet werken.

Complexiteit kan een reden zijn dat men de huidige werkwijze heeft, maar dan nog blijkt uit niets dat dit het geval is. Terwijl het niet voor het eerst zal zijn als bedrijven liever risico nemen dan behoorlijk rekening te houden met risico's. Dat is ook waarom de eisen aan bedrijven steeds strenger worden wat betreft (oa geautomatiseerd) omgaan met persoonlijke gegevens en dienstverlening. Complexiteit is niet zomaar een excuus.
Je kan niet zomaar omschakelen. Luchthavens en luchtvaartmaatschapijen laten net zien dat ze wel verder kunnen ondanks dat deze systemen niet beschikbaar zijn, maar je ziet net dat dit met enorm veel vertraging gaat. Passagiers moet je gaan opzoeken in lijsten die beschikbaar zijn gesteld, meer handmatige controle, de boarding pass moet met de hand ingevuld worden. Daar is ook weer coordinatie voor nodig zodat je niet twee keer dezelfde stoel opschrijft. Handbagage labels moeten met de hand gemaakt en geschreven worden. Dat wil ook zeggen dat de bagage laders niet zomaar snel even kunnen scannen, maar ook weer alles met de hand moeten opschrijven.

Dit vertraagd alles enorm. En daar kan je niet omheen.

Ik zou net zeggen dat we dus zien dat hier wel degelijk procedures voor zijn. Dat luchthavens hier wel op voorbereid zijn. Maar dat ze simpelweg de capaciteit niet hebben om evenveel vluchten af te handellen in een situatie als deze. En dat is maar normaal ook.
Dat omschakelen inspanning kost is algemeen bekend bij bedrijfsvoering. Maar dat gaat net zo goed op als men te weinig tot niets aan behoorlijke voorbereiding heeft gedaan. Het op pen en papier terugvallen is een mogelijkheid. Maar of dat voldoende is valt sterk te betwijfelen. Dan hoort namelijk te blijken dat dit proportioneel is als men gewoonlijk de grens legt bij een hoogwaardige dienstverlening. En niet alleen dat blijkt niet, er is hoe dan ook onduidelijkheid wat men vooraf als redelijke grenzen heeft genomen om zowel de passagiers dienst te verlenen en behoorlijk met hun persoonlijke gegevens om te gaan. Dit soort geautomatiseerde systemen zijn niet slechts een hulpmiddel maar eerder een ondergrens voor de kwaliteit. En daar geen duidelijke gelijkwaardige oplossing voor hebben lijkt meer op het verlagen van de kwaliteit om meer winst te maken ten koste van de klanten en hun gegevens.
Dat omschakelen inspanning kost is algemeen bekend bij bedrijfsvoering. Maar dat gaat net zo goed op als men te weinig tot niets aan behoorlijke voorbereiding heeft gedaan. Het op pen en papier terugvallen is een mogelijkheid.
Dat is wat men nu letterlijk doet. Dat is het noodscenario...
Maar of dat voldoende is valt sterk te betwijfelen. Dan hoort namelijk te blijken dat dit proportioneel is als men gewoonlijk de grens legt bij een hoogwaardige dienstverlening.
Het enige serieuze alternatief buiten pen en papier is het volledig redundant uitvoeren van al die werkplekken (want dat is wat Collins CMUSe is namelijk). Dan heb je wel een volledig redundante terminal nodig om die te huizen. Met andere woorden, je bouwt een tweede vliegveld met andere technologie "voor het geval dat". Dat is wel een extreem dure mitigerende maatregel die geen enkele board goedkeurt.

Je kunt natuurlijk roepen dat je niet op een enkele leverancier moet vertrouwen. Maar het verdubbelen van de leveranciers verdubbeld ook je attack-surface, en in praktijk eindig je alsnog in totale chaos als de helft van je check-in balies niet functioneert. Erg lastig te mitigeren risico...

[Reactie gewijzigd door J_van_Ekris op 21 september 2025 18:22]

En zelfs alles redundant is ook niet zo eenvoudig, want die 2 systemen moeten nog altijd voldoende informatie met elkaar kunnen uitwisselen ook.
Waaruit concludeer jij dat er geen uitgebreide risk assessment is gedaan?
Ik stel op geen enkele manier dat er geen uitgebreide risk assessment is gedaan. Waaruit meen je dat op te maken?
moesten ze alle vluchten schrappen dan had je een punt, ze hebben echter manuele lijsten en de meeste vluchten gaan nog door. De uitvoering ervan vergt gewoon meer mankracht en duurt langer waardoor de luchthaven niet meer dezelfde capaciteit heeft als het manueel moet.
Aangezien er geen grens is dat een bedrijf te weinig heeft gedaan als alle vluchten geschrapt zijn is dat dus ook niet zomaar de grens om te stellen dat er anders genoeg is gedaan.

Het feit dat er achteraf iets blijkt te worden is duidelijk, daar is terecht ook eerder op gewezen. Maar stellen dat het moeite kost valt net zo goed onder een argument dat het compex is: het toont niet aan dat men het risico vooraf voldoende serieus heeft genomen.

Op geen enkele manier sluit ik overigens uit dat men wel degelijk enige heeft gehouden met dit soort risico's als gevolg van bijvoorbeeld randomware, of afhankelijkheid. Maar het punt is dat het nergens duidelijk uit blijkt en ook niet dat het behoorlijk is.
je hebt een punt. nadien zal de schade wel meetbaar zijn in cash geld dat is misgelopen, de kost daarvan zou wss een compleet redundant onafhankelijk tweede systeem van een andere leverancier uit te rollen
Hoe groter de operatie...hoe groter de finananciele risicos. Dan is dit nog belangrijker dat je voorzien bent op worst case scenarios, waar je moet kunnen garanderen dat je vliegtuigen kunnen vliegen.

Ik wil niet weten wat dit verhaal kost enb wie er voor op draait.
@J_van_Ekris Je ???? komen een beetje heftig over, in ieder geval op mij - ik geef die feedback toch maar even. :)

Ik begrijp dat je niet 1-2-3- voor je ziet hoe dat zou schalen - zoiets zal/zou van belangrijke details afhankelijk zijn. Maar 2000 jaar geleden werd het Romeinse keizerrijk toch ook echt administratief bestuurd, en met een significant verveleder latency in de communicatie dan nu als we e.e.a. met papier zouden doen.
Dat wil natuurlijk niet zeggen dat een oraganisatie daaar klaar voor is, want die zijn ontworpen en geoptimaliseerd op werkende IT-infrastructuren.

Wat @Ra_gdd aangeeft is dat zij hun bedrijfsvoering daadwerkelijk hebben voorbereid op de eventualiteit van het moeten terugvallen op middelen/bedrijfsvoering die niet hun voorkeur had maar die wel moet werken - als het niet kan zoals het moet, dan moet het maar zoals het kan.

Mijn interpretatie: Het verschil tussen de situatie die @J_van_Ekris aanhaalt met de situatie waar @Ra_gdd ervaring mee heeft, is dat in het laatste geval er anders is voorbereid op de eventualiteit van de gebeurtenis van de uitval van de mogelijkheid om de (primaire) processen zo uit te voeren als men wenst en waar men zich administratief en procesmatig op voorbereid heeft.

In het bedrijfsleven zijn dit doorgaans consequenties van gekozen korte-termijns oplossingen versus lange-termijns oplossingen. Wil je het komende jaar lagere IT-kosten hebben? Wil je over 10 jaar het hoofd kunnen bieden aan systeemverstoringen teerwijl dat nu geld kost en ten koste gaat van je concurrentiepositie? Of is dat het probleem van je opvolger?
Mijn interpretatie: Het verschil tussen de situatie die @J_van_Ekris aanhaalt met de situatie waar @Ra_gdd ervaring mee heeft, is dat in het laatste geval er anders is voorbereid op de eventualiteit van de gebeurtenis van de uitval van de mogelijkheid om de (primaire) processen zo uit te voeren als men wenst en waar men zich administratief en procesmatig op voorbereid heeft.
Het is makkelijk roepen dat het beter kan, zonder details te kennen. Het punt is, zoals ik ook al op een ander punt in deze discussie aangeef: een luchthaven handelt zo'n krankzinnig volume aan mensen af, als er ergens verlies aan efficiency is, dan stokt het hele proces, oversl. Zie ook de link over het beperkte capaciteitstekort bij security wat bij Schiphol desastreus uitpakte.

Dit is een incident waar je backup terminals exact hetzelfde probleem hebben (in vaktermen een CCF). De ultimate fallback is papier, maar zoals anderen in deze discussie al goed beschreven: je efficiency keldert dus je eindigt in de huidige situatie.

Ik ken de luchtvaart industrie redelijk van binnen uit, en geloof me: men beknibbelt echt niet op noodplannen. Niemand wil een woedende menigte van enkele tienduizenden uitgehongerde en boze passagiers huisvesten. Dat scenario wordt echt wel beschouwd. Maar in dit soort situaties kun je ook niet meer dan men nu doet. Niet alles is oplosbaar, zelfs niet met de beste voorbereiding.
Dank je voor deze mooie aanvulling. En ja, uiteraard stokt het systeem als in de systeemdynamiek de "servers" (niet per se computer servers dus) trager of niet meer werken, of met afgenomen nauwkeurigheid. Het blijft een interessante wereld.
Dat was m'n punt dat een "amateur" bedrijf waar ik werkte wel backup plannen had.
Ook hadden backup formulieren en bestanden namen zodat iedereen de juiste standaard document gebruikte.
We hadden zelfs een gedeeltelijke kwaliteit manager hiervoor.

Gisteren kwam PR-dame luchthaven op het nieuws.
Hun grote backup in geval van nood is pen en papier.
Gelukkig was het geen tabletten in klei en hamer met beitels.
Wat is je back upplan als systemen plat liggen? Hoe pak je het aan voor 10000 mensen per dag?
Ze hebben ook fallbacks. De incheckbalies zijn beginnen werken met pen en papier (met waarschijnlijk uitgeprinte passagier manifesten). Alleen stopt het niet bij deze stap, dit wilt zeggen dat elke stap verder in het proces ook manueel moet gebeuren. Hoe ga je bagagelabels afprinten als uw systeem niet werkt? Ga je daar een handgeschreven kaartje aan hangen? Heel de bagageflow gebeurt automatisch ... Om nog maar te zwijgen als je een overstap moet maken, hoe gaat uw bagage daar automatisch op de volgende vlucht geraken als je een handgeschreven kaartje hebt ...

Ook de grenscontrole zal op die moment volledig handmatig moeten gebeuren wat wilt zeggen dat ze extra werkvolk moeten optrommelen (zeer leuk in het weekend) en dat er zelfs dan nog grote vertragingen ontstaan omdat ze de lijsten manueel moeten controleren, hetzelfde zal ook weer gelden voor het boarden.

Ja, er zijn fallback systemen, maar dan mag je er zeker van zijn dat alles x keer trager zal lopen zijn wat voor lange wachttijden zal zorgen en waarbij je niet zeker kunt zijn dat alles correct verloopt.
lokaal draaiende en zelf onderhouden services zijn bijna per definitie minder betrouwbaar dan een cloud service. Dus ja, je hebt het niet zelf in de hand maar het gaat een stuk minder vaak fout.

Het nadeel van cloud services is dat veel bedrijven afhankelijk zijn. Dus als een service omvalt, dan ligt gelijk een halve sector eruit.

Dit overigens naast het feit dat de maximaal geoptimaliseerde luchtvaart totaal niet te vergelijken is met de relatief inefficiënt georganiseerde werkprocessen bij een klein ferrybedrijf.
Dit gaat waarachijnlijk alleen maar toenemen. Ik ben benieuwd wanneer er standaard offline backup oplossingen komen waardoor bv 75% of meer van de vluchten toch door kan gaan bij zo’n storing.
Zelfs als backups beschikbaar zijn is dat geen garantie voor snelle recovery. Het totaalplaatje moet kloppen. Er zijn genoeg organisaties die gehackt worden, maar bv nog nooit een restore van Active Directory hebben getest. Nou, daar gaan je eerste 3 dagen al. Leuk dat je backups hebt van al je systemen en die binnen 4 uur up and running kunt hebben, zonder je AD kun je niks.

en zo zijn er bij iedere organisatie nog veel meer dependencies die niet getest worden met de ‘compliance back up and restore’-testen.
Je kunt een goede uitwijktest slechts uitvoeren als ALLES plat mag om de test uit te voeren. En dan nog zul je niet 100% kunnen testen omdat er ook gegevens uitwisseling zal zijn met externe partijen.

Wellicht dat er een mogelijkheid is om systemen elke nacht te laden van een niet wijzigbaar image. Dat deden wij voorheen ook met de Citrix werkplek omgeving. Maar dat kan niet met de achterliggende systemen. De achterliggende systemen moeten voldoende gehardend zijn en er moet afdoende microsegmentatie zijn toegepast. Of dat hier gedaan was weet ik niet, maar zonder dit soort oplossingen is het bijna niet te voorkomen.

Continuïteit is niet eenvoudig in te richten. Het is echter wel essentieel voor dit soort omgevingen. En je moet met erg veel scenario’s rekening houden.
Het nadeel van de beveiliger: jij moet iedere hackpoging kunnen afslaan, zij hoeven er maar 1tje te laten slagen…
waardoor bv 75% of meer van de vluchten toch door kan gaan bij zo’n storing.
Dat is enorm lastig in een luchthaven. Die resterende 25% gaat zoveel ellende opleveren dat de boel alsnog in totale chaos eindigt. Een luchthaven is enorm strak gecoordineerd en elke milimeter ruimte is benut. Dingen moeten blijven bewegen om de luchthaven operationeel te houden. Als er mensen, baggage en vliegtuigen te lang blijven staan loopt het onherroepelijk zo vast als een huis omdat je ruimte en personeel tekort komt. Die 25% gaat de rest gewoon in de weg staan.

[Reactie gewijzigd door J_van_Ekris op 21 september 2025 10:12]

Dat gaat in de praktijk niet lukken. Je hebt namelijk met meer te maken dan alleen het vliegveld. Die vliegtuigen gaan ook ergens naartoe en die moeten die data dan ook verwerken. Er is ook nog een factor met bagage die geregistreerd en gevolgd moet worden, zowel op het vliegveld als de volgende.

Je zou dit met enkele vluchten maken nog voor elkaar kunnen krijgen, maar niet met 75%. Doordat alles is gedigitaliseerd, is het mogelijk om zo veel, zo goedkoop te doen.

De oplossing voor dit algemene probleem ligt eerder op nog betere beveiliging en redundantie. En de methodes zijn niets algemeens over te zeggen. Voor iedere aanvalsvorm zijn andere methoden nodig. (DDOS, phishing, ransomware, virussen, fysieke verstoringen, menselijke fouten, enz, enz, hebben allemaal andere afweermethoden nodig.)
Wel eens het geautomatiseerde systeem van een "dozenschuiver" magazijn gezien. Nou is dat natuurlijk geen vliegveld maar ze hebben wel iets gemeenschappelijks: het grote aantal mutaties per minuut.

Een backup oplossing bleek niet te werken bij de "dozenschuiver". Immers, als er 3 minuten verstreken waren er duizenden artikelen niet meer op de plek waar de computer dacht dat ze zouden zijn. De enige oplossing was alles te "bevriezen" tot het systeem weer werkte. Dat "bevriezen" kan niet op een vliegveld.

Het alternatief was dat een klein legertje medewerkers alle dozen in elke schap, elk karretje en elke lift- arm karretjes moesten scannen om de locatie weer actueel te maken in het systeem.

Het magazijn van de dozenschuiver had ook in- en uitgaande goederenstromen. Vrachtwagens kwamen en gingen. Dus het probleem verspreidde zich als een olievlek.

Dit soort hyper efficiënte systemen zijn nodig, anders moet je 10 keer zoveel personeel laten rondlopen. Het maakt het wel heel kwetsbaar bij een totale systeemstoring.
Dit soort storingen zijn vaker nodig. Dat zal er voor zorgen dat ook in dit soort systemen een redundancy ontworpen wordt zodat de processen bij verbroken verbindingen lokaal toch de minimale dienst levert.

Ja, alles kan en mag allemaal in de wolken worden gebouwd. Wel zo handig voor de communicatie. Maar als de bewolking optrekt en de communicatie niet werkt dan zou je toch basis functionaliteit willen behouden. Zodra de communicatie weer werkt zullen de systemen weer kunnen synchroniseren en door werken.
Het zou elke dag moeten gebeuren, want ik merk dat de budgetten van security telkens lager en lager moeten.
Dit soort storingen zijn vaker nodig. Dat zal er voor zorgen dat ook in dit soort systemen een redundancy ontworpen wordt zodat de processen bij verbroken verbindingen lokaal toch de minimale dienst levert.
Als ik het goed begrijp zijn het juist de lokale eindpunten die uitgevallen zijn, niet de cloudoplossingen.

[Reactie gewijzigd door J_van_Ekris op 22 september 2025 13:31]

Ik blijf nooit zo goed snappen waarom dit soort kritieke systemen blijkbaar aan het internet hangen. Dat je wat randzaken beschikbaar stelt via een inlog-iets op het internet, prima. Maar de cruciale dienstverlening zou een besloten dienst moeten zijn in mijn optiek, volledig losgekoppeld van het internet. Bedrijven zoals British Telecom (BT) bieden wereldwijd dit soort diensten aan. En ja, dat is (veel) duurder dan via het internet, maar voorkomt dat de kern van je dienstverlening met een DDOS ter ziele kan gaan. Dat is nu echt verkeerde zuinigheid.
Ik blijf nooit zo goed snappen waarom dit soort kritieke systemen blijkbaar aan het internet hangen.
Omdat het overgrote deel van de passagiers on-line incheckt....
Dat zijn dus de "randzaken" die ik meld. Prima, daar ontkom je inderdaad niet aan. Maar als die randzaken worden platgelegd met een DDOS, zou de "core" niet plat mogen gaan. Zie het als een ui met meerdere ringen. Passagiers die inchecken zitten in de buitenste ring, maar de core applicaties zitten veel dieper. Sloopt iemand de buitenste ring, dan zou alles daaronder door moeten kunnen draaien.
Maar als die randzaken worden platgelegd met een DDOS, zou de "core" niet plat mogen gaan. Zie het als een ui met meerdere ringen. Passagiers die inchecken zitten in de buitenste ring, maar de core applicaties zitten veel dieper. Sloopt iemand de buitenste ring, dan zou alles daaronder door moeten kunnen draaien.
Hier zitten wat onjuiste aannames in:
  • je neemt een DDOS aan, maar dat staat volgens mij nergens.
  • de core systemen voor passenger handling draaien gewoon nog. Er zijn wereldwijd drie spelers, en als die plat gaan had je veel meer cancellations gezien
Er staat "Cyberaanval". Wat het dan ook is, DDOS of wat anders is minder relevant, wel dat er van buitenaf dus "iets" gebeurt of gebeurd is. Mijn punt blijft dan ook staan, ergens is er iets kapot wat uiterst relevant is voor in ieder geval Brussel, wat nooit een connectie met de buitenwereld had mogen hebben.
De Incheckdata wordt toch gecommuniceerd met meerdere systemen in en buiten de luchthaven? Ik heb wel eens gehoord, dat voor intercontinentale vluchten (ook als deze niet naar de VS gaan) de incheck gegevens van alle passagiers moeten worden gecommuniceerd met servers in de VS voordat de vlucht kan vertrekken.
Met "buitenwereld" bedoel ik het internet, dat had wat duidelijker gekund inderdaad maar was in de context wel zo te lezen. Als deze informatie over een besloten netwerk verzonden wordt (zie mijn reacties hierboven) kan er van buiten niemand bij en kan dat deel nooit plat gaan bij een Cyberaanval.
Als deze informatie over een besloten netwerk verzonden wordt (zie mijn reacties hierboven) kan er van buiten niemand bij en kan dat deel nooit plat gaan bij een Cyberaanval.
Dat dachten ze in Natanz ook. Één medewerker die bij een ontwikkelteam bij Collins op een verkeerde link klikt. Dat is wat er nodig is om dit te veroorzaken. En ja, ook die medewerkers hebben internet nodig omdat ze patches moeten downloaden voor de spullen die ze leveren...

[Reactie gewijzigd door J_van_Ekris op 21 september 2025 18:36]

Waarom denk je dat zoiets een besloten netwerk heet? Natanz is wel een heel andere orde van grootte om erbij te halen, daar is net iets meer moeite ingestoken dan een "cyberaanval" ...
Het inchecken is geen kritiek systeem.
Als vliegtuigen niet kunnen opstijgen is dat vervelend, maar niet gevaarlijk.

Systemen voor het landen en begeleiden van vliegtuigen zijn kritiek.
Ik denk dat de baas van de luchthaven Brussel daar anders over denkt. Alleen lees je "Kritiek" hier verkeerd. Niet in de zin dat er vliegtuigen uit de lucht vallen, maar dat de dienstverlening zeer ernstige schade oploopt. Net zoals pinnen bij de Appie in die zin niet kritiek is - er gaat niemand dood of zo - maar is wel een kritieke dienst voor ze. Een dag niet pinnen kost ze vele miljoenen omzet per dag. Reken maar dat ze dat als "kritiek" ervaren.
Je hebt twee soorten effecten bij gevaar:
  1. Mensen zijn in gevaar
  2. Financieen zijn in gevaar
Voor de eerste zijn allerlei richtlijnen zoals de machine richtlijn. De tweede is vrij.
Ben blij dat ik binnenkort via schiphol ga. Wel zuur voor de mensen die hinder ondervinden op Brussel Airport.
En Heathrow en Berlin Airport...
Ik weet niet waar zaterdagochtend vandaan komt. Ik heb zelf gevlogen op vrijdagavond iets na 17.00 vanaf Brussel en toen waren alle vluchten al flink vertraagd door het handmatig boarden, checken en afvinken van de passagiers bij alle gates via portofoon/mobiel met de crew in het toestel.
Gebruikt Schiphol dan dus een ander systeem?


Om te kunnen reageren moet je ingelogd zijn