Pre-Incident Planning: 5 Things to Document in an Incident Response Plan
Planning vóór een incident:
Want als het gebeurt, heeft u geen tijd om dit nog op te zoeken.
De meeste richtlijnen voor IT-beveiligingsvoorbereiding richten zich op wat u moet doen nadat een aanval is begonnen. De geïnfecteerde apparaten isoleren. Uw incident response-partner inschakelen. De juridische afdeling informeren. Allemaal goed advies, maar alleen nuttig als u al weet wie u moet bellen, waar uw back-ups zich bevinden en welke systemen cruciaal zijn voor het voortbestaan van uw organisatie.
Het probleem is dat de eerste uren van een ransomware-incident chaotisch zijn. Beslissingen die eigenlijk slechts minuten zouden moeten kosten, duren veel langer wanneer de benodigde informatie verspreid is over e-mailthreads, in het collectieve geheugen van de organisatie of in systemen die inmiddels mogelijk niet meer toegankelijk zijn. Dat is geen technologisch falen. Het is een documentatiefalen — en het is volledig te voorkomen.
Wat volgt is geen incident response-plan. Het is iets kleiners en direct toepasbaars: vijf cruciale categorieën informatie die uw team moet documenteren en toegankelijk maken vóórdat zich een incident voordoet. Het opstellen van deze lijst kost weinig tijd. Het niet beschikbaar hebben ervan wanneer u het nodig hebt, kost uiteindelijk veel meer tijd dan het ooit bespaart.
Wanneer zich een beveiligingsincident voordoet, is de eerste reactie meestal om de telefoon te pakken. Het probleem is dat veel teams niet altijd weten wie ze moeten bellen.
Uw escalatiedocumentatie moet de contactgegevens bevatten van uw incident response-team, de primaire contactpersonen en uw DFIR-partner. Neem ook het inschakelproces op, de contactgegevens van uw juridisch adviseur (met ervaring in gegevensbescherming) en de schadecontactgegevens van uw cyberverzekeraar, inclusief uw polisnummer.
De escalatiedocumentatie moet de belangrijkste contactpersonen en polisgegevens bevatten die nodig zijn bij een incident. Concreet moet dit omvatten:
Incident response-team en verantwoordelijken
Contactgegevens van uw interne incident response-team en de verantwoordelijke contactpersonen
DFIR-partner
Contactgegevens van uw partner voor Digital Forensics and Incident Response (DFIR), inclusief het inschakelproces.
Juridisch adviseur
Contactgegevens van uw externe juridisch adviseur, waarbij u ervoor zorgt dat deze ervaring heeft met gegevensbescherming.
Cyberverzekering
De schadecontactpersoon van uw cyberverzekeraar en uw polisnummer.
Dat laatste punt ontbreekt het vaakst. Cyberverzekeringen bevatten doorgaans specifieke meldtermijnen, en het missen daarvan kan uw claim juist op het moment dat u zich geen complicaties kunt veroorloven onnodig bemoeilijken. Het vooraf kennen van uw schadecontact en polisnummer is een noodzaak.
Nog een laatste opmerking over cyberverzekeringen: bewaar uw polis veilig en gescheiden van uw primaire systemen. Dreigingsactoren die vóór het starten van de versleuteling al tijd in uw netwerk hebben doorgebracht, kunnen toegang hebben tot daar opgeslagen documenten. Uw polisgegevens mogen zich niet bevinden op een plek waar zij deze kunnen vinden.
Wanneer alles snel gaat, wilt u niet op zoek moeten naar een telefoonnummer.
Dreigingsactoren richten zich als eerste op back-ups. Dat is geen speculatie. Het is een consistent patroon dat DriveSavers heeft waargenomen bij veel ransomware-incidenten. Voordat productiesystemen worden versleuteld, identificeren en compromitteren aanvallers vaak de back-upinfrastructuur om het meest directe herstelpad van het slachtoffer uit te schakelen. Tegen de tijd dat de versleuteling start, kunnen de back-ups al verdwenen zijn.
Dit moet bepalend zijn voor hoe u naar back-updocumentatie kijkt. Het is niet voldoende om te weten dat er back-ups bestaan. Uw team moet de integriteit van back-ups onder incidentomstandigheden snel kunnen beoordelen. Dat betekent dat de architectuur voldoende gedocumenteerd moet zijn om die beoordeling mogelijk te maken voordat iemand onder druk staat.
Documenteer waar back-ups zich bevinden (on-site, off-site en in de cloud), hoe back-uptaken worden uitgevoerd en volgens welk schema, evenals de stapsgewijze herstelprocedures.
Ga ervan uit dat uw back-ups mogelijk gecompromitteerd zijn totdat u het tegendeel kunt verifiëren.
Bij een beveiligingsincident zult u niet alles tegelijk kunnen herstellen. Beslissingen over wat als eerste wordt teruggezet, worden snel en onder druk genomen, door mensen die mogelijk op weinig slaap draaien. Die beslissingen verlopen aanzienlijk beter wanneer ze vooraf en zonder druk zijn genomen.
Uw lijst met kritieke gegevens moet de systemen identificeren zonder welke het bedrijf niet kan functioneren, de datasets die nodig zijn voor de dagelijkse bedrijfsvoering en een duidelijke prioriteitsvolgorde voor herstel: essentieel versus wenselijk.
Wees eerlijk over waar het bedrijf werkelijk van afhankelijk is en wat slechts belangrijk is. Die eerlijkheid is veel moeilijker te vinden midden in een actief incident. Geef prioriteit aan de absoluut te herstellen datasets voordat u zich richt op de minder kritieke. Niet alles kan als eerste terugkomen, en dat vooraf weten is een aanzienlijk operationeel voordeel.
Bij een beveiligingsincident draait herstel niet alleen om het terugzetten van gegevens — maar om het eerst herstellen van de juiste gegevens.
Bij een beveiligingsincident draait herstel niet alleen om het terugzetten van gegevens — maar om het eerst herstellen van de juiste gegevens.
In de meeste omgevingen van betekenisvolle omvang strekt de back-upinfrastructuur zich uit over meerdere locaties. De verantwoordelijkheidsdocumentatie moet vastleggen wie eigenaar is van elke back-upomgeving, welke toegangsgegevens gelden voor back-ups, snapshots en replica’s, en waar secundaire systemen en extra kopieën zich kunnen bevinden.
Houd er rekening mee dat dezelfde gegevens vaak in meerdere vormen bestaan: als primaire back-up, als snapshot, als replica of als gearchiveerde kopie op tape of in een secundaire cloudomgeving. In situaties waarin primaire back-ups zijn gecompromitteerd, kan het weten waar u nog meer moet zoeken een aanzienlijk verschil maken.
Een grondige eigendomskaart is in de praktijk een kaart van uw hersteloppervlak. Hoe vollediger deze vóór een incident is, hoe meer opties u tijdens een incident heeft.
Dezelfde gegevens bestaan vaak in meerdere vormen. Weten waar u moet zoeken vergroot de herstelopties.
Een succesvol operationeel herstel na een cyberaanval is sterk afhankelijk van de leveranciers die de producten en diensten leveren waarop uw infrastructuur draait. Daarom is het essentieel om hun escalatieroutes en ondersteuningskanalen te documenteren voordat zich een incident voordoet.
De leverancierscontactlijst moet de leveranciers bevatten die nodig zijn om de kernactiviteiten te herstellen, hun ondersteuningskanalen en escalatieroutes, evenals een data recovery-partner voor situaties waarin back-ups en decryptietools hebben gefaald.
Dat derde punt is precies wat de meeste organisaties volledig achterwege laten. Het falen van back-ups en decryptietools zijn geen zeldzame uitzonderingen. Het zijn realistische uitkomsten van een goed uitgevoerde cyberaanval. Een professionele data recovery-partner vooraf identificeren en documenteren betekent dat u leveranciers niet hoeft te beoordelen op het slechtst denkbare moment voor uw organisatie. Het betekent ook dat uw incidentrespons-team een parallel hersteltraject kan volgen in plaats van te wachten op één enkel oplossingspunt.
Door deze relaties vooraf te documenteren, zorgt u ervoor dat uw team bij de start van het herstel een plan uitvoert — en niet eerst naar een plan hoeft te zoeken.
English (United States) 
English (Australia) 
French (France) 
English (UK) 
French (Canada) 
English (Canada) 
Spanish (Mexico) 
German 
Dutch 
Italian 
Finnish 
Polish 
Norwegian 
Swedish 
Danish 
Spanish (Spain) 
Chinese 
Japanese 
German (Austria)