Een kritiek lek. Wie trekt aan de handrem?

Een melding over een ernstige kwetsbaarheid zet IT-afdelingen direct op scherp. Welke systemen worden geraakt? Wat moet worden bijgewerkt? Moeten er diensten offline? De technische vragen komen snel op tafel. Maar wie neemt de besluiten als de gevolgen verder reiken dan IT?

Op 21 oktober waarschuwde het NCSC voor twee kritieke kwetsbaarheden in PHP, een programmeertaal die veel websites en webapplicaties gebruiken. Het NCSC haalde uit voorzorg zijn eigen website tijdelijk offline en adviseerde organisaties om per getroffen systeem een risicoafweging te maken.

Dat er bij zo’n waarschuwing snel wordt geschakeld, is goed. Kwetsbaarheden in veelgebruikte software zijn een terugkerend gegeven. Ze vragen om alertheid, onderhoud en mensen die weten wat ze doen. Tegelijk roept deze situatie voor mij een bredere vraag op: hoe goed hebben we de besluitvorming georganiseerd die op zo’n melding volgt?

Wie besluit dat een systeem offline gaat?

Een systeem uitschakelen klinkt overzichtelijk. Totdat medewerkers het nodig hebben om hun werk te doen. Zeker in de zorg kan een veiligheidsmaatregel direct gevolgen hebben voor de dagelijkse dienstverlening.

Wie weegt die gevolgen tegen elkaar af? Wie mag besluiten om een systeem uit te schakelen? En wie bepaalt onder welke voorwaarden het weer beschikbaar komt?

Een technisch specialist kan aangeven hoe ernstig een kwetsbaarheid is en welke maatregelen mogelijk zijn. Voor een besluit is ook kennis nodig van de werkprocessen, de afhankelijkheden en de gevolgen voor cliënten en medewerkers. Daar moeten de juiste mensen bij betrokken zijn, met een duidelijk mandaat.

Ook de druk van buiten speelt mee. Als andere organisaties hun websites offline halen, ontstaat al snel de vraag waarom jouw organisatie dat nog niet heeft gedaan. Die vraag is begrijpelijk. Maar de afweging moet passen bij je eigen systemen en risico’s. Je moet kunnen uitleggen waarom je ingrijpt, of waarom je een dienst onder bepaalde voorwaarden beschikbaar houdt.

Een systeem uitschakelen klinkt overzichtelijk. Totdat medewerkers het nodig hebben om hun werk te doen.

Oefen het gesprek voordat het nodig is

Dit is precies het soort vraagstuk dat je in een tabletop-oefening wilt bespreken. Je doorloopt samen een crisisscenario, zonder dat er daadwerkelijk systemen uitvallen.

Stel: er verschijnt een waarschuwing over een kritieke kwetsbaarheid. Een leverancier onderzoekt nog of jullie omgeving geraakt wordt. De directie wil weten of de dienstverlening door kan. Medewerkers lezen ondertussen berichten over organisaties die uit voorzorg offline gaan.

Wat doe je met de informatie die je op dat moment hebt? Hoe lang wacht je op zekerheid? Wie moet bereikbaar zijn? En wanneer schaal je op?

Tijdens zo’n oefening merk je waar afspraken ontbreken. Misschien blijkt dat iedereen ervan uitgaat dat iemand anders de leverancier belt. Of dat wel duidelijk is wie een systeem kan uitschakelen, maar niet wie daar toestemming voor geeft. Daar kun je vooraf iets aan doen. Tijdens een incident kost dezelfde onduidelijkheid kostbare tijd.

Weet je eigenlijk wat je hebt staan?

Een kritieke kwetsbaarheid dwingt je ook tot een heel basale inventarisatie: waar gebruiken we deze software?

Het antwoord zit niet altijd alleen bij de IT-afdeling. Denk aan een oude campagnesite, een portaal van een leverancier of een toepassing die ooit door een afdeling zelf is aangeschaft. Wie beheert die omgeving? Wie houdt de software bij? En is het systeem nog nodig?

Schaduw-IT maakt die vragen lastiger. Je kunt moeilijk snel handelen op een systeem waarvan niemand weet dat het nog bestaat.

Cyberhygiëne begint daarom ook bij overzicht en eigenaarschap. Weten welke toepassingen je gebruikt, wie ervoor verantwoordelijk is en welke afspraken gelden voor onderhoud. En afscheid nemen van systemen die hun functie hebben verloren. Iedere vergeten toepassing kan tijdens een incident alsnog aandacht en capaciteit opeisen.

Wanneer leggen we ander werk stil?

Wat mij bij dit soort situaties opvalt, is dat andere IT-projecten en reguliere werkzaamheden vaak lijken door te lopen. Terwijl een deel van de organisatie druk bezig is om de dreiging te beoordelen en maatregelen te nemen.

Dat roept bij mij een open vraag op: wanneer trekken we écht aan de handrem?

Wanneer stellen we een migratie uit? Wanneer stoppen we tijdelijk met wijzigingen? Wanneer besluiten we dat beschikbare mensen eerst nodig zijn voor inventarisatie, herstel of extra controles?

Daar is geen algemeen antwoord op. Ander werk stilleggen kan helpen om capaciteit vrij te maken en overzicht te houden. Het kan ook nieuwe problemen veroorzaken of noodzakelijk werk vertragen. Juist daarom verdient het een bewuste afweging. Gewoon doorgaan is óók een besluit, al voelt het soms niet zo.

Die afweging hoort wat mij betreft thuis in het crisis- en continuïteitsplan. Welke werkzaamheden moeten doorgaan? Wat kan wachten? En wie hakt daarover de knoop door?

De voorbereiding moet verder gaan dan IT

Een ernstige kwetsbaarheid vraagt om technisch vakmanschap. Maar de organisatie moet de mensen die dat werk doen ook in staat stellen om snel en zorgvuldig te handelen.

Dat vraagt om overzicht, bereikbare verantwoordelijken, geoefende besluitvorming en werkbare alternatieven als een systeem tijdelijk niet beschikbaar is.

Voor mij is dat de belangrijkste aanleiding om dit incident te bespreken. Hoe verliep de samenwerking? Waar ontstond twijfel? Welke besluiten bleven liggen? En welke afspraken willen we vóór de volgende melding hebben gemaakt?

De volgende kwetsbaarheid laat zich moeilijk voorspellen. Wie dan aan de handrem mag trekken, kun je vandaag al afspreken.