De Nederlandse Spoorwegen (NS) zijn onvoldoende voorbereid op een grote ict-storing. Het spoorbedrijf is te veel afhankelijk van externe leveranciers die bij ict-problemen slecht communiceren, er is geen geautomatiseerde back-up en de ict-infrastructuur moet sowieso op de schop. Dat concluderen onderzoekers die in opdracht van NS onderzoek deden naar een grote landelijke treinstoring op 3 april van dit jaar. NS belooft de aanbevelingen over te nemen.
Op 3 april 2022 ging het helemaal mis. Nagenoeg al het treinverkeer kwam tot stilstand door een grote ict-storing. Op die dag ontstond de storing in cruciale ict-systemen van de bijsturing en reisinformatie waardoor NS geen zicht meer had op waar personeel en treinen zich bevonden. Toen daarop ook de bovenleiding brak bij Hoofddorp, raakte de spoorvervoerder het spoor volledig bijster en werd het treinverkeer rond die middag volledig stilgelegd.
NS zegt in een persbericht over de uitkomsten van onderzoek naar de ict-storing: ‘De conclusies zijn stevig, maar ook helder. Zo waren we onvoldoende voorbereid op een it-storing van deze duur en omvang.’ Ook was NS te optimistisch, er werd te lang vanuit gegaan dat de geraakte it-systemen snel weer zouden werken zoals bij eerdere storingen. Hierdoor werd de crisisorganisatie niet snel genoeg opgeschaald.
Op verzoek van NS heeft het Instituut voor Veiligheids- en Crisismanagement (COT) onderzoek gedaan naar het verloop van de storing en de crisisorganisatie van NS. Ook zijn er twee verdiepende onderzoeken gedaan. Railistics heeft gekeken naar de mogelijkheden voor een pendeldienst. Het onderzoeksinstituut van Nokia (Bell Labs) onderzocht de it-systemen.
Bell Labs
Bell Labs concludeert dat de storing is ontstaan in het planningsysteem, waardoor NS geen zicht meer had op waar personeel en treinen zich in het land bevonden. Ook kon er geen actuele reisinformatie op borden worden getoond. Uit de analyse blijkt dat er veel tijd verloren is gegaan met het zoeken naar de storing. De it-systemen van NS konden de storing niet automatisch vaststellen, waardoor geen automatische back-up is gestart.
NS: ‘Het beheer van de it-systemen is in handen van vaste externe partijen die veel onderzoektijd nodig hadden om te constateren wat de oorzaak van de verstoring was. Ook is door deze partijen onvoldoende snel opgeschaald.’
De onderzoekers doen vijf aanbevelingen [zie kader onderaan artikel voor opsomming uit rapport]. Ze adviseren om meer indicatoren voor een storing in te bouwen, it-collega’s bij een storing sneller op te schalen en om scenario’s voor het geval it-systemen uitvallen uit te breiden. Ook is het advies om vaker te oefenen met het scenario waarin een systeem uitvalt en een overschakeling naar een ander systeem nodig is.
Aanbevelingen
- Zorg voor een betrouwbare end-to-end bedrijfskritische servicearchitectuur met geografisch redundante infrastructuur, connectiviteit en applicaties. Zorg daarnaast ook voor goede monitoring op de afzonderlijke componenten in en over de gehele keten, met name gericht op de gegevensstromen en bijbehorende drempels (bandbreedte voor de gegevensstromen gebaseerd op business rules).
- Operationele processen tussen alle servicepartners zijn aanwezig en worden onderhouden, maar op 3 april niet altijd nageleefd. Het wordt aanbevolen om duidelijk rollen en verantwoordelijkheden te definiëren (RACI-model, red.) voor betrokkenen bij de incident-, probleem-, veranderings- en operationele beschikbaarheidsprocessen.
- Menselijke besluitvormingsprocessen en handmatige interacties moeten in het monitoren en beheer van de it-infrastructuur verder worden verminderd. Door toepassing van automatische failover-oplossingen worden vertragingen en fouten voorkomen.
- Test regelmatig de juiste werking van beveiligingsmechanismen, oefenprocedures en systeem-failovers met alle partners in de gehele keten.
- Applicaties moeten worden ontworpen volgens de best practices voor ‘redundantiemechanismen met hoge beschikbaarheid’. Lopende activiteiten om deze best practices te implementeren, waaronder automatische failover, moeten worden versneld. De bevindingen, verbeteringen en aanbevelingen worden geprioriteerd en gedeeld met NS en technologiepartner(s). De implementatie van de belangrijkste bevindingen is aan de gang om het risico op herhaling van het grote incident te minimaliseren. De overige bevindingen worden in nauwe samenwerking tussen alle betrokken partijen gepland.
Bron: Samenvatting Dutch Railways Resilience Audit, Bell Labs
Geen zicht meer op waar personeel en treinen zich bevinden.. ja, dan wordt het lastig.
die aanbevelingen :
1. men weet niet hoe e.e.a. in mekaar steekt (architectuur) en kijkt er ook niet naar om (monitoring)
2. er zijn processen, maar daar houdt men zich niet aan (nageleefd). wie wat moet doen, ook geen idee (raci)
3. bla bla bla storing en nu ? probeer die server eens reboot, ow misschien weet pietje er meer van. waaat? werkt die hier al jaren niet meer ? (menselijke interacties)
4. zullen we het eens uitproberen ? nee ? echt niet ? gelijk heb je, misschien werkt het niet en dan moeten we daar weer tijd in stoppen (testen)
5. dubbel uitvoeren (redundant) en ook echt doen ipv alleen maar plannen (implementeren)
Dat laatste vind ik wel een goeie want recent onderzoek van Gartner laat zien dat plannen veel effectiever worden als je ze ook daadwerkelijk uitvoert.