Cybersecurity gaat vaak over het voorkomen van incidenten. MFA inschakelen, apparaten beveiligen, netwerken segmenteren en verdachte activiteiten detecteren zijn allemaal belangrijke maatregelen.
Maar geen enkele beveiligingsmaatregel kan garanderen dat er nooit een incident plaatsvindt.
Daarom moet een theater, schouwburg of cultuurhuis ook antwoord hebben op een andere vraag: wat doen we als het ondanks alle maatregelen toch misgaat?
Dat vraagt om meer dan een technisch herstelplan. Bij een cyberincident moeten in korte tijd keuzes worden gemaakt over bedrijfsvoering, communicatie, herstel en verantwoordelijkheden. Zeker bij een theater kan het tijdstip daarbij bepalend zijn.
Een storing om dinsdagochtend 10:00 heeft een andere impact dan een incident om 19:30 terwijl honderden bezoekers binnenkomen.
Begin met één vraag: welke systemen moeten als eerste worden hersteld?
Niet ieder ICT-systeem heeft voor een theater dezelfde prioriteit.
Wanneer een systeem uitvalt, is de eerste vraag daarom niet automatisch hoe de technische oorzaak zo snel mogelijk wordt opgelost. Eerst moet duidelijk zijn wat de gevolgen zijn voor de organisatie.
Voor een theater kunnen bijvoorbeeld deze systemen direct belangrijk zijn voor de avond:
- theatertechniek;
- ticketing en toegangscontrole;
- internet en netwerk;
- kassa- en pinsystemen;
- systemen die direct noodzakelijk zijn voor de productie of bezoekersstroom.
Microsoft 365 en telefonie zijn eveneens belangrijke systemen, maar een storing daarvan hoeft niet altijd direct te betekenen dat een voorstelling niet kan doorgaan.
Die prioritering helpt tijdens een incident om keuzes te maken. Welke systemen moeten als eerste worden hersteld?
Daarmee verschuift de aanpak van uitsluitend technisch herstel naar bedrijfscontinuïteit.
Vijf onderdelen van een praktisch incidentplan
1. Leg vooraf vast wie beslissingen neemt
Tijdens een ernstig cyberincident moet duidelijk zijn wie het mandaat heeft om beslissingen te nemen.
De IT-partner kan de technische situatie onderzoeken, scenario’s uitwerken en adviseren over de mogelijke impact. Maar beslissingen over de organisatie horen bij de organisatie zelf.
Denk bijvoorbeeld aan:
- gaat een voorstelling of evenement door;
- moet een locatie tijdelijk sluiten;
- wat wordt gecommuniceerd naar medewerkers en bezoekers;
- moet een incident worden gemeld bij de Autoriteit Persoonsgegevens;
- wanneer wordt een verzekeraar ingeschakeld;
- welke bedrijfsrisico’s zijn acceptabel tijdens het herstel.
Idealiter is daarom aan beide kanten één persoon met voldoende mandaat aangewezen.
Vanuit het theater is dat iemand vanuit directie of management die bedrijfsbesluiten kan nemen. Vanuit de IT-partner is er iemand die de technische incidentrespons coördineert.
Is er interne ICT aanwezig, dan heeft die eveneens een belangrijke rol. De interne ICT-medewerker kan de eerste melding beoordelen en fungeren als ogen en handen in het gebouw.
De verdeling blijft daarbij helder: de directie beslist, de IT-partner coördineert en voert technisch uit.
2. Maak een kort incidentdraaiboek
Een incidentplan hoeft geen document van tientallen pagina’s te zijn.
Een kort draaiboek dat tijdens een incident daadwerkelijk wordt gebruikt is waardevoller dan uitgebreid beleid dat niemand op het juiste moment kan vinden.
Leg daarin minimaal vast:
- de interne en externe contactpersonen;
- wie beslissingsbevoegd is;
- de escalatieroute;
- welke systemen bedrijfskritisch zijn;
- wat tijdens het eerste uur per incidentscenario moet gebeuren;
- waar back-ups en herstelprocedures zijn vastgelegd;
- welke externe leveranciers eventueel nodig zijn;
- communicatiesjablonen voor belangrijke scenario’s.
Bewaar dit draaiboek niet uitsluitend in dezelfde Microsoft 365-omgeving die tijdens een incident mogelijk onbereikbaar of gecompromitteerd is.
Het team moet de noodzakelijke contactgegevens en eerste stappen ook kunnen vinden wanneer de normale digitale werkomgeving tijdelijk niet beschikbaar is.
3. Beschrijf de eerste acties per incidentscenario
Niet ieder cyberincident vraagt om dezelfde reactie. Daarom helpt het om vooraf voor een aantal waarschijnlijke scenario’s de eerste technische stappen vast te leggen.
Bij een overgenomen gebruikersaccount kan het bijvoorbeeld nodig zijn om actieve sessies in te trekken, het wachtwoord en MFA opnieuw in te stellen en inboxregels en applicatietoestemmingen te controleren.
Bij een bredere compromittering van Microsoft 365 kan de aanpak verder gaan. Denk aan het gebruiken van een vooraf ingericht noodaccount, het vervangen of opnieuw beveiligen van beheerdersaccounts, het intrekken van actieve sessies, het aanscherpen van Conditional Access en het onderzoeken van auditlogs.
Bij ransomware ligt de eerste prioriteit juist op het beperken van verdere verspreiding. Netwerkdelen kunnen moeten worden geïsoleerd en verdachte endpoints in quarantaine geplaatst. Daarna moet worden vastgesteld of beschikbare back-ups betrouwbaar en onaangetast zijn.
Deze scenario’s laten zien waarom alleen preventieve beveiliging niet voldoende is. Een organisatie moet ook weten wat er gebeurt nadat een beveiligingsmaatregel een incident signaleert.
Meer over de preventieve kant daarvan lees je in hoe je Microsoft 365 beveiligt binnen een culturele organisatie.
4. Bepaal vooraf de workaround voor kritieke systemen
Bij een storing van een bedrijfskritisch systeem is de technische oorzaak belangrijk, maar niet altijd de eerste prioriteit.
Eerst de workaround, daarna de oorzaak.
Als ticketing of toegangscontrole vlak voor een voorstelling uitvalt, moet bijvoorbeeld eerst duidelijk zijn hoe bezoekers naar binnen kunnen. Als een kassa- of pinsysteem niet beschikbaar is, moet duidelijk zijn of en hoe de horeca tijdelijk verder kan werken.
Dat betekent dat je per kritisch systeem vooraf twee vragen moet beantwoorden:
- hoe lang kunnen we zonder dit systeem functioneren;
- hoe werken we tijdelijk verder als het systeem niet beschikbaar is?
Daarbij moet ook duidelijk zijn welke leveranciers onderdeel zijn van de keten. Een ticketingomgeving kan bijvoorbeeld afhankelijk zijn van ticketingsoftware, website, hosting, netwerkverbindingen en verschillende koppelingen.
Juist daarom is het belangrijk dat duidelijk is wie tijdens een storing de regie voert wanneer meerdere partijen betrokken zijn.
Een goed ingericht en gemonitord netwerk speelt hierin eveneens een belangrijke rol. Lees daarover meer in waarom professioneel netwerkbeheer belangrijk is voor theaters en culturele organisaties.
5. Test of herstel daadwerkelijk mogelijk is
Een back-up hebben en kunnen herstellen zijn twee verschillende dingen.
Een back-up zonder hersteltest is een aanname.
Voor belangrijke gegevens en systemen moeten back-ups daarom niet alleen automatisch worden gemaakt, maar ook beschermd worden tegen wijziging of verwijdering vanuit de productieomgeving.
Bij ransomware is dat essentieel. Wanneer een aanvaller naast de productieomgeving ook de beschikbare back-ups kan versleutelen of verwijderen, verdwijnt een belangrijk deel van de herstelmogelijkheid.
Daarnaast moet herstel periodiek worden getest.
Een praktisch uitgangspunt is om ieder kwartaal een hersteltest uit te voeren voor belangrijke systemen en data. Daarbij controleer je niet alleen of een back-upbestand bestaat, maar of gegevens daadwerkelijk bruikbaar kunnen worden teruggezet.
Dat geldt ook voor gegevens in Microsoft 365. Cloudsoftware gebruiken betekent niet automatisch dat de organisatie voor ieder scenario over de gewenste back-up- en herstelmogelijkheden beschikt.
Yitte neemt back-up, herstel en continuïteit daarom ook mee als onderdeel van een bredere ICT-structuur. Op de pagina over cloud & hosting lees je meer over professioneel beheerde back-ups en herstel.
Maak van cyberincidenten geen puur IT-probleem
Een ernstig cyberincident raakt uiteindelijk meer dan techniek.
De directie moet mogelijk besluiten nemen over bedrijfsvoering. Communicatie moet medewerkers, bezoekers of andere betrokkenen informeren. Een privacy-incident kan om juridische beoordeling en mogelijk een melding vragen. Een cyberverzekeraar kan voorwaarden stellen aan de manier waarop een incident wordt afgehandeld.
Daarom moet incidentrespons niet uitsluitend bij de IT-afdeling of IT-partner worden neergelegd.
Een praktische rolverdeling kan er als volgt uitzien:
- Directie of management: neemt bedrijfsbesluiten en beslist over communicatie, sluiting, externe meldingen en andere organisatorische gevolgen;
- Interne ICT: verzorgt de eerste melding, lokale ondersteuning en fungeert als ogen en handen in het gebouw;
- IT-partner: verzorgt de technische incidentleiding, onderzoekt de impact, adviseert over scenario’s en coördineert de technische herstelwerkzaamheden;
- Andere specialisten: worden afhankelijk van het incident betrokken, bijvoorbeeld een privacydeskundige, verzekeraar of gespecialiseerde leverancier.
Deze rollen moeten vóór een incident duidelijk zijn. Tijdens een incident is het verkeerde moment om voor het eerst te bespreken wie eigenlijk verantwoordelijk is.
Vergeet Microsoft 365-noodtoegang niet
Wanneer Microsoft 365 zelf onderdeel is van het incident, moet worden voorkomen dat alle beheerders tegelijkertijd worden buitengesloten.
Daarvoor kunnen vooraf specifieke noodaccounts worden ingericht, vaak aangeduid als break-glass accounts.
Deze accounts zijn niet bedoeld voor dagelijks beheer. Ze zijn bedoeld voor uitzonderlijke situaties waarin reguliere beheerders door een storing, foutieve configuratie of beveiligingsincident geen toegang meer hebben.
Het bestaan van zo’n account alleen is niet voldoende. Ook moet duidelijk zijn wie het mag gebruiken, hoe de toegang wordt beveiligd en hoe gebruik wordt gecontroleerd.
Noodtoegang is daarmee onderdeel van dezelfde voorbereiding als het incidentdraaiboek: regel de uitweg voordat je hem nodig hebt.
Oefen het incidentplan minimaal één keer per jaar
Een draaiboek dat nooit wordt getest kan tijdens een echt incident onverwachte gaten bevatten.
Daarom is het verstandig om minimaal één keer per jaar een incidentscenario te oefenen.
Dat hoeft niet direct een grote technische oefening te zijn. Een zogenoemde tabletop-oefening kan al veel inzicht geven.
Leg bijvoorbeeld het volgende scenario op tafel:
Het is vrijdag 18:45. Over 45 minuten begint een uitverkochte voorstelling. Meerdere systemen vertonen problemen en er zijn aanwijzingen voor ransomware. Wat doen we?
Door het scenario stap voor stap te bespreken, wordt snel duidelijk of de voorbereiding klopt.
- Wie wordt als eerste gebeld?
- Wie heeft mandaat om beslissingen te nemen?
- Welke systemen worden geïsoleerd?
- Kan ticketing blijven functioneren?
- Hoe controleren we de toegangscontrole?
- Welke workaround is beschikbaar?
- Waar staat het incidentdraaiboek?
- Hoe bereiken we medewerkers als Microsoft 365 niet beschikbaar is?
- Welke leveranciers moeten worden ingeschakeld?
- Wie communiceert met bezoekers als de voorstelling wordt geraakt?
De antwoorden laten zien welke afspraken ontbreken voordat een echt incident ontstaat.
Praktijkvoorbeeld: ransomware vlak voor een voorstelling
Stel dat een schouwburg op vrijdagmiddag verdachte activiteit ontdekt op meerdere werkplekken. Kort daarna worden bestanden onbereikbaar en ontstaat het vermoeden van ransomware. Over twee uur begint een voorstelling.
De eerste reactie is niet om willekeurig systemen opnieuw op te starten of direct bestanden vanuit een back-up terug te zetten.
De IT-partner coördineert de technische respons. Verdachte endpoints worden in quarantaine geplaatst en waar nodig worden netwerkdelen geïsoleerd om verdere verspreiding te beperken.
Tegelijk kijkt de organisatie naar de bedrijfscontinuïteit. Functioneren theatertechniek, ticketing, toegangscontrole, internet, kassa en pin nog? Kan de voorstelling veilig doorgaan en zijn er workarounds beschikbaar als één van deze systemen uitvalt?
De aangewezen persoon vanuit de directie krijgt van de IT-partner inzicht in de technische situatie en mogelijke scenario’s. De directie beslist vervolgens over de bedrijfsvoering en communicatie.
Voordat herstel plaatsvindt, wordt gecontroleerd of de beschikbare back-ups betrouwbaar en onaangetast zijn. Systemen worden niet zomaar teruggezet op infrastructuur waarvan nog niet vaststaat dat deze schoon is.
Na het incident wordt niet alleen gekeken naar de technische oorzaak. Ook wordt geëvalueerd of het draaiboek werkte, of de juiste mensen bereikbaar waren en of de workarounds voldoende waren.
Juist doordat verantwoordelijkheden en prioriteiten vooraf zijn bepaald, hoeft tijdens het incident niet meer te worden uitgevonden wie wat moet doen.
Een praktisch voorbereidingsplan in zeven stappen
Een theater hoeft niet te wachten op een incident om hiermee te beginnen. De voorbereiding kan in zeven concrete stappen worden opgebouwd.
- Stap 1: bepaal welke systemen de voorstelling en bezoekerservaring direct kunnen stilleggen;
- Stap 2: bepaal welke systemen belangrijk zijn voor de bedrijfsvoering op de langere termijn;
- Stap 3: wijs vanuit directie en IT duidelijke verantwoordelijken met voldoende mandaat aan;
- Stap 4: beschrijf voor de belangrijkste incidentscenario’s de acties tijdens het eerste uur;
- Stap 5: leg workarounds vast voor bedrijfskritische systemen en afhankelijkheden;
- Stap 6: test ieder kwartaal het herstel van belangrijke back-ups en data;
- Stap 7: oefen minimaal jaarlijks een realistisch incidentscenario met de betrokken personen.
Cyberweerbaarheid ontstaat daarmee niet uit één beveiligingsproduct. Het ontstaat uit een combinatie van preventie, detectie, duidelijke verantwoordelijkheden en aantoonbaar herstel.
Dat sluit aan bij de bredere beveiligingsstructuur die Yitte beschrijft bij digitale weerbaarheid.
Conclusie
Een theater voorbereiden op een cyberincident begint niet bij een draaiboek van tientallen pagina’s. Het begint bij weten welke systemen kritisch zijn, wie beslissingen mag nemen en hoe de organisatie tijdelijk verder kan wanneer een systeem niet beschikbaar is.
Maak daarom vooraf onderscheid tussen wat vanavond raakt en wat volgende week raakt. Leg per belangrijk scenario de eerste acties vast, zorg voor noodtoegang, wijs verantwoordelijken aan en bewaar het incidentdraaiboek ook buiten de normale Microsoft 365-omgeving.
En test wat je hebt ingericht. Een back-up waarvan nooit is aangetoond dat deze kan worden hersteld, geeft geen zekerheid over herstel wanneer het daadwerkelijk nodig is.
Met kwartaalgewijze hersteltests en minimaal één jaarlijkse incidentoefening wordt cyberincidentrespons geen plan op papier, maar een proces waarvan de organisatie weet dat het werkt.
Over Yitte
Yitte helpt theaters, schouwburgen, cultuurhuizen en podia om hun ICT-omgeving niet alleen veilig, maar ook beheersbaar en herstelbaar in te richten. Van Microsoft 365, werkplekken en netwerk tot monitoring, back-up en digitale weerbaarheid. Daarbij kijken we niet alleen naar het voorkomen van incidenten, maar ook naar verantwoordelijkheden, continuïteit en wat er moet gebeuren wanneer een kritisch systeem daadwerkelijk uitvalt.