Een datalek…! Wat nu?
door Strict op do 15 sep 2016
Begin september heeft de Autoriteit Persoonsgegevens (AP) via BNR bekendgemaakt dat zij 3400 meldingen van een datalek hebben ontvangen. Dat zijn zo’n 425 meldingen per maand. Dit aantal valt erg mee omdat naar schatting van de AP zo’n 135.000 organisaties omgaan met persoonsgegevens. Een verklaring voor dit geringe aantal meldingen kan zijn dat organisaties niet weten dat ze te maken hebben met een datalek. Of weten zij dat er een datalek bestaat, maar besluiten het niet te melden bij de AP. De meldplicht is geïntroduceerd zodat ‘bedrijven er vooral open over zijn’, aldus de Autoriteit Persoonsgegevens. Als een datalek niet wordt gemeld bij de AP is dit strafbaar. Het niet voldoen aan de meldplicht vereisten kan een boete betekenen variërend tussen €120.000 en €500.000 per overtreding. De AP kan daar bovenop, per overtreding, boetes opleggen tot maximaal €820.000 van (de rechtspersoon van) de overtreder. Voor organisaties die niet weten of zij te maken hebben met een datalek of niet weten hoe zij moeten handelen: hier geven we de stappen met een aantal adviezen van incidentbehandeling voor een datalek.
Een datalek is een beveiligingsincident waarbij sprake moet zijn van een inbreuk op de beschikbaarheid, integriteit en vertrouwelijkheid en onderscheidt zich van alle andere beveiligingsincidenten door nog één extra kenmerk: er zijn persoonsgegevens bij betrokken. Is er geen persoonsgegeven bij betrokken, dan kan er sprake zijn van een informatiebeveiligings- of een cyberincident, maar het is geen datalek. Om een datalek te identificeren moeten een paar kenmerken worden beoordeeld, zoals: zijn er persoonsgegevens verloren gegaan en bestaat er geen complete of actuele reservekopie? Of heeft er een onrechtmatige verwerking van persoonsgegevens plaatsgevonden, zoals aantasting van de persoonsgegevens, onbevoegde kennisneming of wijziging, verstrekking van persoonsgegevens?
Maar wat nu als een datalek of een vermoedelijk datalek je overkomt, ben je er dan klaar voor om dit te behandelen? Is er al overwogen hoe je te werk gaat en hoe je moet reageren naar de Autoriteit Persoonsgegevens? Simpele vragen die geen eenvoudig antwoord hebben, zeker niet als de omvang van de organisatie groot is. Je wilt geen fouten maken en zeker geen boete betalen, dus wat nu?
Een incidenten behandelingsproces of procedure biedt hulp. Hierin kun je de activiteiten bepalen die van belang zijn om de juiste stappen te nemen. Strict gebruikt hiervoor de ‘6 fasen van incident behandeling van SANS’ (SANS staat voor SysAdmin, Audit, Network and Security). Deze 6 fasen bieden uitkomst bij een (vermoedelijk) datalek en helpen te bepalen wat efficiënt en effectief is binnen de processen van de organisatie.
Hieronder tref je een beknopte weergave van deze 6 fasen van incident behandeling:
- Voorbereiden
Deze fase staat voor: “een goede voorbereiding is het halve werk”. In deze fase zorg je dat alle activiteiten die nodig zijn om een datalek te behandelen vooraf gecommuniceerd en beschreven zijn. Enkele punten die hierbij belangrijk zijn: het inrichten van een centraal meldpunt, het communiceren met een SCIRT (Security Computer Incident Response Team) en het inrichten van een crisisruimte. Het is belangrijk na te denken over de inrichting van een SCIRT voor een datalek. Als het je overkomt dan roep je dit team bij elkaar om door te kunnen gaan naar de volgende fase.
- Identificeren
In deze fase wordt bepaald of er sprake is van een (vermoedelijk) datalek. Na vaststelling van de melding door het centrale meldpunt moet een verificatie worden gestart om te bevestigen of de melding inderdaad een datalek betreft. Deze handeling wordt meestal door een CISO (Chief Information Security Officer) en/of een Privacy Officer verricht en bij bevestiging moet er groen licht gegeven worden om de datalekprocedure te starten. De start gebeurt meestal met de bepaling van een Modus Operandi (de werkwijze) waarbij er bevestigd wordt of er sprake is van een datalek en of er een impact is naar betrokkenen. Communiceer dit naar stakeholders (zoals de informatie eigenaar) zodat zij op de hoogte zijn van dit incident.
- Afbakenen
Nadat bekend is dat er sprake is van een datalek, moet de omvang van dit lek goed worden gedefinieerd. De CSIRT, CISO en/of de Privacy Officer zal een onderzoek starten en de resultaten communiceren naar de stakeholders en aan de AP. Deze melding aan de AP moet gebeuren binnen 72 uur nadat het datalek is ontdekt. Heb je de omvang en de scope nog niet goed kunnen bepalen, geen nood, je kunt altijd de melding die je bij de AP hebt gemaakt aanpassen. De melding die je maakt wordt vertrouwelijk behandeld bij de AP en is nodig om duidelijk inzicht te geven over dit datalek. Het is belangrijk om te bepalen welke rol de organisatie heeft vervuld bij dit datalek. Is er bijvoorbeeld een leverancier bij betrokken. Niet alleen de melding is belangrijk, maar ook welke maatregelen je inricht om eenzelfde datalek te voorkomen. Verzorg, indien nodig, een duidelijke communicatie naar de betrokkenen want daar hebben zij recht op. Zorg dat je elke update van de AP melding in een privacy incident register plaatst. Dit is belangrijk, want alle stappen die je uitvoert om dit datalek goed op te lossen moeten hierin opgeslagen te worden. Ook alle communicatie met de betrokkenen moeten hierin worden opgeslagen. Een AP zou kunnen vragen hoe je het datalek hebt opgelost en daarbij biedt dit register een uitkomst.
Verwijderen
Het doel van de verwijderingsfase is het wegnemen of verminderen (remediation) van de factor(en) die hebben geresulteerd in een datalek. In de fase ‘afbakenen’ hebben we precies bepaald waar het datalek is ontstaan en nu is het belangrijk om oorzaken aan te pakken en maatregelen in te richten ter voorkoming van herhaling. Het team van (IT)specialisten speelt hierbij een belangrijke rol, zij moeten beoordelen of alle kenmerken van dit lek verdwenen zijn. Dit is makkelijker gezegd dan gedaan. Een USB met persoonsgegevens verliezen betekent nieuwe maatregelen implementeren. Maar een of meerdere kenmerken van malware wegwerken wordt al lastiger om dit goed op te lossen. Is de malware of andere oorzaak verwijderd dan kan de herstelfase worden uitgevoerd.
- Herstellen
Het doel van deze fase is herstel naar een normale operatie. Deze fase zorgt ervoor dat de getroffen informatiesystemen of diensten worden hersteld onder de voorwaarden die de organisatie stelt. Dit kan betekenen dat procedures of processen aangepast moeten worden of dat er contracten met leveranciers opnieuw beoordeeld moeten worden. Bij bijvoorbeeld malware die verstoringen veroorzaakt in een database kan besloten worden om een restore van een database te verrichten. Dit is geen makkelijk besluit, want: is de restore al ooit gevalideerd, kan de database zonder gevolgen worden teruggeplaatst? Vragen die niet eenvoudig zijn te beantwoorden, de oplossing zit in het testen van deze restore voordat besloten wordt tot welke actie wordt overgegaan.
Is na het herstel de oorzaak nog steeds aanwezig, dan moet het team besluiten om terug te gaan naar fase 3: afbakenen, daar opnieuw alle stappen doorlopen om zo uiteindelijk weer tot de fase herstel te komen.
- Opvolgen
Na de fase herstel is het erg belangrijk om met elkaar de leermomenten vast te leggen. Daarnaast moet de verantwoordelijke een verslag opstellen waarin uitgelegd wordt welke maatregelen er zijn opgenomen om het datalek goed te beheersen of hoe dit is opgelost. Als er een SCIRT is samengesteld dan is het belangrijk om de ‘lessons learned’ met elkaar te bespreken. Het doel van dit verslag is om de efficiëntie en effectiviteit te verhogen voor een volgende behandeling van een datalek.
Zoals u hebt gelezen zijn er veel stappen nodig om een datalek goed te behandelen. We hebben in dit blog globaal de stappen beschreven, maar kunnen in detail met uw organisatie deze stappen bespreken en uitwerking realiseren. Als er dan een datalek ontstaat kunt u slagvaardig te werk gaan. Dit reduceert het risico dat er fouten worden gemaakt en de schade kan sneller worden hersteld. Uiteindelijk is het doel de persoonsgegevens voldoende te beschermen en snel en effectief herstel van de dienstverlening te bevorderen!
- Technologie (133)
- Nieuws (70)
- 5G (66)
- Continuïteit (64)
- Security & Privacy (57)
- Agility (35)
- Podcast (34)
- Wendbaarheid (31)
- Klantcase (18)
- Webinar (18)
- Blog (15)
- Innovatie (13)
- Mission Critical (13)
- Healthcare (12)
- Overheid (12)
- AI (11)
- Cloud (9)
- Medewerker interview (8)
- Smart City (7)
- Video (7)
- OOV (5)
- Vervoer (5)
- Projectmanagement (3)
- Duurzaamheid (2)
- december 2024 (2)
- november 2024 (9)
- oktober 2024 (9)
- september 2024 (10)
- augustus 2024 (6)
- juli 2024 (9)
- juni 2024 (6)
- mei 2024 (3)
- april 2024 (9)
- maart 2024 (11)
- februari 2024 (4)
- december 2023 (2)
- november 2023 (4)
- oktober 2023 (3)
- september 2023 (3)
- juli 2023 (4)
- juni 2023 (3)
- mei 2023 (6)
- april 2023 (2)
- maart 2023 (5)
- februari 2023 (1)
- januari 2023 (1)
- december 2022 (1)
- november 2022 (2)
- oktober 2022 (3)
- september 2022 (3)
- augustus 2022 (3)
- juli 2022 (8)
- juni 2022 (6)
- mei 2022 (4)
- april 2022 (5)
- maart 2022 (4)
- februari 2022 (5)
- januari 2022 (2)
- november 2021 (2)
- oktober 2021 (1)
- september 2021 (3)
- augustus 2021 (2)
- juli 2021 (1)
- juni 2021 (1)
- mei 2021 (1)
- april 2021 (3)
- maart 2021 (1)
- februari 2021 (1)
- november 2020 (1)
- augustus 2020 (1)
- juli 2020 (2)
- mei 2020 (2)
- april 2020 (4)
- maart 2020 (5)
- februari 2020 (3)
- januari 2020 (5)
- december 2019 (2)
- november 2019 (3)
- oktober 2019 (5)
- september 2019 (1)
- augustus 2019 (3)
- juli 2019 (2)
- juni 2019 (3)
- mei 2019 (2)
- april 2019 (4)
- maart 2019 (8)
- februari 2019 (6)
- januari 2019 (3)
- december 2018 (4)
- november 2018 (2)
- oktober 2018 (10)
- september 2018 (5)
- augustus 2018 (6)
- juli 2018 (2)
- juni 2018 (7)
- mei 2018 (3)
- maart 2018 (3)
- februari 2018 (3)
- januari 2018 (3)
- december 2017 (6)
- november 2017 (5)
- oktober 2017 (5)
- september 2017 (5)
- juli 2017 (1)
- juni 2017 (4)
- mei 2017 (1)
- februari 2017 (1)
- januari 2017 (1)
- december 2016 (1)
- oktober 2016 (2)
- september 2016 (2)
- augustus 2016 (6)
- juli 2016 (1)
- juni 2016 (3)
- mei 2016 (2)
- april 2016 (3)
- maart 2016 (3)
- januari 2016 (1)
- december 2015 (1)
- november 2015 (2)
- oktober 2015 (1)
- september 2015 (2)
- augustus 2015 (1)
- juli 2015 (1)
- juni 2015 (2)
- mei 2015 (2)
- maart 2015 (2)
- februari 2015 (2)
- juni 2014 (1)