Het moeilijkste deel van een beveiligingsincident vindt meestal plaats nadat het incident zelf voorbij is: wanneer het bedrijf moet uitleggen wat er is gebeurd, wanneer het werd ontdekt, welke gegevens erbij betrokken waren, wie er getroffen was en waarom bepaalde beslissingen zijn genomen.
Bij veel mkb-bedrijven bestaan deze gegevens niet in een volledige vorm. Gegevens kunnen verspreid zijn over chatberichten, inboxen, helpdesktickets, schermafbeeldingen en de herinneringen van teamleden. Bedrijven blijven tijdens een incident overeind met deze gefragmenteerde gegevens, maar ze worden een probleem wanneer een toezichthoudende autoriteit, een verzekeraar, een klant of een bestuurslid om een duidelijke tijdlijn vraagt.
Bedrijven van elke omvang hebben een grondig logboek voor beveiligingsincidenten nodig. Het moet één bron van waarheid zijn om vast te leggen wat er is gebeurd, hoe het incident is behandeld en welk bewijs de beslissingen ondersteunt die gaandeweg zijn genomen.
Het logboek is waardevol, zelfs wanneer u een incident niet hoeft te melden. In dit artikel wordt uitgelegd waarom logboeken voor beveiligingsincidenten nuttig zijn voor uw bedrijf en hoe u uw eigen logboek kunt maken.
Waarom logboeken voor beveiligingsincidenten belangrijk zijn
Incidentlogboeken versus incidentresponsplannen
Wat een logboek voor beveiligingsincidenten moet bevatten
Een eenvoudig sjabloon voor een incidentlogboek voor mkb-bedrijven
Hoe u meldingsbeslissingen vastlegt
Wat toezichthoudende autoriteiten verwachten van logboeken voor beveiligingsincidenten
Het logboek voor toegang met inloggegevens
Waarom logboeken voor beveiligingsincidenten belangrijk zijn
Logboeken voor beveiligingsincidenten zorgen voor verantwoording op het moment dat een bedrijf het meest waarschijnlijk het overzicht over gegevens verliest. Tijdens een incident gaan acties snel: wachtwoorden worden gereset, accounts worden uitgeschakeld, IT-leveranciers worden gecontacteerd, klantgegevens worden gecontroleerd en het management wordt bijgepraat. Die stappen zijn op dat moment misschien precies wat het bedrijf nodig heeft, maar ze zijn later veel moeilijker uit te leggen als niemand vastlegt wanneer elke actie plaatsvond, wie deze heeft goedgekeurd en welk bewijs de beslissing ondersteunde.
Voor bedrijven die in Europa zijn gevestigd, is dit niet alleen een goede praktijk. Op grond van de General Data Protection Regulation (GDPR), zowel in het Verenigd Koninkrijk als in de EU, moeten inbreuken op persoonsgegevens worden beoordeeld en sommige moeten worden gemeld bij de betreffende toezichthoudende autoriteit.
In het Verenigd Koninkrijk legt de richtlijn van de ICO over het melden van een datalek(nieuw venster) uit dat organisaties het waarschijnlijke risico voor de rechten en vrijheden van mensen moeten beoordelen en de ICO moeten informeren wanneer dat risico waarschijnlijk is. Artikel 33 vereist ook dat verwerkingsverantwoordelijken inbreuken op persoonsgegevens documenteren, inclusief de feiten van de inbreuk, de gevolgen ervan en de genomen herstelmaatregelen. Dezelfde vereisten gelden onder de EU-GDPR.
De ICO verwacht bijvoorbeeld niet dat elk mkb-bedrijf systemen op ondernemingsniveau heeft, maar wel passende registraties. Het kader voor respons op datalekken en monitoring van de ICO stelt dat organisaties procedures moeten hebben om ervoor te zorgen dat incidenten met persoonsgegevens en datalekken worden gedetecteerd, beheerd en op passende wijze geregistreerd. Dat betekent dat een incidentlogboek niet alleen mag worden aangemaakt wanneer er al een ernstig datalek heeft plaatsgevonden. Het moet deel uitmaken van het normale responsproces.
Een goede administratie ondersteunt ook verzekeringsclaims. Cyberverzekeraars kunnen vragen om bewijs van wanneer het incident werd ontdekt, welke maatregelen zijn genomen om het incident in te dammen, welke accounts zijn getroffen en of het bedrijf zijn incidentresponsproces heeft gevolgd. Een goed bijgehouden logboek kan aantonen dat het bedrijf snel en consistent heeft gehandeld.
Het helpt het bedrijf ook om te leren. Herinneringen en mondelinge verslagen zijn niet betrouwbaar, maar een registratie waaruit blijkt dat het incident begon met een hergebruikt wachtwoord, ontbrekende multi-factorauthenticatie (MFA), toegang van leveranciers of een vertraagde offboarding geeft het bedrijf iets concreets om te verhelpen en een duidelijkere richting om de beveiliging op termijn te versterken.
Incidentlogboeken versus incidentresponsplannen
Een logboek voor beveiligingsincidenten en een incidentresponsplan zijn met elkaar verbonden, maar het zijn niet hetzelfde document.
Een incidentresponsplan legt uit wat het bedrijf moet doen wanneer er iets misgaat. Het wijst rollen, escalatieroutes, indammingsmaatregelen, communicatieverantwoordelijkheden en herstelprocedures toe. Het incidentlogboek registreert wat er daadwerkelijk is gebeurd. Het is de tijdlijn, het bewijsspoor, het beslissingsregister en het opvolgingsdossier voor een specifieke gebeurtenis.
Dat onderscheid is belangrijk, want zelfs een goed plan kan mislukken zonder documentatie. Een bedrijf kan de juiste stappen volgen, maar het later nog steeds moeilijk vinden om dat te bewijzen. Het logboek moet het mogelijk maken om praktische vragen te beantwoorden: wanneer werd het bekend, wie handelde, wat werd ingedamd, welke gegevens liepen risico, wat werd besloten en wat veranderde daarna?
| Incidentresponsplan: wat uw bedrijf moet doen | Logboek voor beveiligingsincidenten: wat er daadwerkelijk is gebeurd |
| Wie leidt de respons Wie neemt contact op met IT, juridische zaken, de verzekeraar of toezichthouders Hoe u het incident indamt, herstelt en communiceert | Wanneer het incident werd ontdekt Welke systemen en gegevens getroffen waren Welke acties werden ondernomen, door wie en wanneer |
Wat een logboek voor beveiligingsincidenten moet bevatten
Een bruikbaar incidentlogboek moet consistent genoeg zijn zodat een bedrijf de gebeurtenis later kan reconstrueren en de beslissingen die tijdens de respons zijn genomen kan uitleggen.
Datum en tijd van ontdekking
Leg vast wanneer het bedrijf voor het eerst op de hoogte raakte van het incident, wie het opmerkte en hoe het werd ontdekt. Als de tijd bij benadering is, markeer deze dan als bij benadering. Het moment van ontdekking is belangrijk omdat meldtermijnen volgens de GDPR en verzekeringsvereisten vaak afhangen van wanneer het bedrijf op de hoogte raakte van het probleem.
Aard van het incident
Beschrijf wat er is gebeurd in gewone taal. Vermijd vage labels zoals “beveiligingsprobleem” of “mogelijk datalek” zonder context. Het logboek moet uitleggen welke systemen getroffen waren en of het incident te maken had met inloggegevens, e-mail, bestanden, klantgegevens, betaalsystemen, endpoints of toegang van derden.
Betrokken gegevens
Als persoonsgegevens getroffen kunnen zijn, leg dan vast om welk soort gegevens het ging: namen, e-mailadressen, telefoonnummers, adressen, accountgegevens, financiële informatie, personeelsdossiers, klantcommunicatie, inloggegevens of een andere relevante categorie. Schat in hoeveel personen getroffen kunnen zijn en maak duidelijk of het aantal bevestigd is of nog wordt onderzocht.
Waarschijnlijke oorzaak
Leg de bekende of vermoede oorzaak vast, zelfs als het onderzoek nog loopt. Naarmate er nieuwe gegevens opduiken, kan het logboek worden bijgewerkt van “oorzaak onbekend” naar “phishing-e-mail leidde tot compromittering van inloggegevens” of “account van voormalige contractant bleef actief”. Het logboek moet laten zien hoe het begrip van het bedrijf in de loop van de tijd veranderde.
Onmiddellijke indammingsmaatregelen
Documenteer wat is gedaan om de schade te beperken. Dit kan bestaan uit het resetten van wachtwoorden, het intrekken van sessies, het afdwingen van MFA, het opschorten van accounts, het verwijderen van postvakregels, het isoleren van apparaten, het intrekken van toegang van leveranciers, firewallwijzigingen of tijdelijke uitschakeling van diensten. Vermeld waar mogelijk de verantwoordelijke en het tijdstip voor elke actie.
Meldingsbeslissingen
Leg vast of het bedrijf de relevante toezichthoudende autoriteit (de ICO in het Verenigd Koninkrijk of de nationale gegevensbeschermingsautoriteit elders in de EU), getroffen personen, klanten, leveranciers, verzekeraars, juridische adviseurs of opsporingsinstanties heeft geïnformeerd. Als is besloten om niet te melden, documenteer dan de redenatie. Die uitleg is vaak net zo belangrijk als de melding zelf.
Herstelmaatregelen en tijdlijn
Indamming pakt het onmiddellijke incident aan. Herstelmaatregelen verkleinen de kans dat hetzelfde probleem zich opnieuw voordoet. Leg vervolgacties vast, zoals het afdwingen van MFA, het verwijderen van gedeelde inloggegevens, het bijwerken van toegangsbeleid, het verbeteren van offboarding, het corrigeren van een verkeerde configuratie of het wijzigen van de manier waarop back-ups worden beschermd.
Geleerde lessen
Sluit af met wat het bedrijf heeft geleerd en wat er gaat veranderen. Dit moet niet als verwijt worden geschreven. Het moet de zwakte, de benodigde verbetering en wie verantwoordelijk is voor de opvolging benoemen.
Een eenvoudig sjabloon voor een incidentlogboek voor mkb-bedrijven
Gespecialiseerde software is niet nodig om incidenten te documenteren. Een spreadsheet, een beveiligd intern formulier, een ticketsysteem of een gedeeld register kan werken als de toegang wordt beheerd en de vermeldingen consistent worden bijgehouden.
Een effectief incidentlogboek moet de volgende velden bevatten:
- Incident-ID: Een uniek referentienummer.
- Datum en tijd van ontdekking: Wanneer het bedrijf op de hoogte kwam van het incident.
- Gemeld door: Medewerker, leverancier, klant, verkoper, monitoringsmelding of externe partij.
- Incidenttype: Phishing, malware, in gevaar brengen van inloggegevens, gegevensverlies, ongeoorloofde toegang, ransomware, leveranciersincident, apparaatverlies, verkeerd verzonden e-mail of anders.
- Samenvatting: Wat er is gebeurd, in begrijpelijke taal.
- Getroffen systemen: Betrokken toepassingen, accounts, apparaten, databases, inboxen of diensten van derden.
- Betrokken gegevens: Of persoonsgegevens zijn getroffen, welk type en hoeveel personen mogelijk getroffen zijn.
- Waarschijnlijke oorzaak: Bekend, vermoed of in onderzoek.
- Beperkende maatregelen: Wat onmiddellijk is gedaan.
- Besluit over melding: Toezichthoudende autoriteit, betrokkenen, klanten, verzekeraar of geen melding met redengeving.
- Bewijskoppelingen: Schermafbeeldingen, tickets, logboeken, e-mails, toegangsregistraties, geëxporteerde bestanden of leveranciersrapporten.
- Herstelmaatregelen: Stappen die na beperking zijn genomen.
- Eigenaar: Persoon die verantwoordelijk is voor de opvolging.
- Status: Open, gemonitord, beperkt, opgelost, gesloten.
- Geleerde lessen: Wat moet veranderen.
Hoe u beslissingen over meldingen vastlegt
Beslissingen over meldingen verdienen een eigen plek in een logboek voor beveiligingsincidenten, omdat ze vaak na het incident worden herzien.
Onder zowel de Britse als de EU-GDPR moeten organisaties het waarschijnlijke risico voor de rechten en vrijheden van mensen beoordelen wanneer een schending van persoonsgegevens plaatsvindt. Als het risico waarschijnlijk is, moet de toezichthoudende autoriteit zo snel mogelijk en, indien haalbaar, binnen 72 uur worden gemeld: de ICO(nieuw venster) in het Verenigd Koninkrijk, de nationale gegevensbeschermingsautoriteit in elke EU-lidstaat. Als het risico hoog is, moeten getroffen personen ook onverwijld worden gemeld. De drempelwaarden en de termijn zijn aan beide zijden hetzelfde; alleen de autoriteit verandert.
Een goed incidentlogboek moet laten zien dat het bedrijf deze beoordeling heeft uitgevoerd. Het moet vastleggen of er persoonsgegevens bij betrokken waren, welk soort schade kon ontstaan, welke beschermingen aanwezig waren en waarom het bedrijf besloot wel of niet te melden.
Een incident waarbij een blootgesteld beheerderswachtwoord betrokken is, hoeft bijvoorbeeld niet onmiddellijk duidelijk te maken of er toegang is geweest tot persoonsgegevens. Het logboek moet die onzekerheid weerspiegelen. Het kan de eerste zorg vastleggen, de onderzoeksstappen, de beoordeling van accountactiviteit en de uiteindelijke conclusie zodra bewijs beschikbaar is.
Op dit punt in het proces richten veel bedrijven zich op het organiseren van de technische oplossing en vergeten ze de nalevingsredenering vast te leggen. Wachtwoorden worden gereset, accounts worden beveiligd en de bedrijfsvoering gaat door. Weken later kan het bedrijf niet uitleggen waarom het besloot dat het incident niet meldingsplichtig was.
Wat toezichthoudende autoriteiten verwachten van vastleggingen
Toezichthoudende autoriteiten kijken niet alleen of een schending is gemeld. Ze kunnen ook vragen hoe het bedrijf:
- het incident heeft geïdentificeerd
- het risico heeft beoordeeld
- heeft besloten of melding vereist was
- de genomen maatregelen heeft gedocumenteerd
Een goede vastlegging moet het verhaal van het incident van begin tot eind duidelijk maken. Deze moet laten zien wat er is gebeurd, welke persoonsgegevens betrokken waren, welke schade kon ontstaan, wat het bedrijf heeft gedaan om het probleem te beperken en waarom het de schending wel of niet heeft gemeld.
Het detailniveau moet overeenkomen met de ernst van het incident. Een verkeerd verzonden e-mail heeft niet dezelfde vastlegging nodig als een ransomwareaanval, maar moet nog steeds worden gedocumenteerd om aan te tonen dat het bedrijf het incident goed heeft beoordeeld.
Deze vastleggingen moeten ook veilig worden opgeslagen. Incidentlogboeken kunnen gevoelige gegevens bevatten over getroffen personen, blootgestelde systemen, handelingen van medewerkers, schermafbeeldingen, toegangslogboeken of herstelmaatregelen. Toegang moet beperkt blijven tot de mensen die deze nodig hebben, en de retentie moet aansluiten bij het bredere gegevensretentiebeleid van het bedrijf.
Het logboek voor toegang tot inloggegevens
Veel incidenten hebben te maken met inloggegevens: ze kunnen worden veroorzaakt door een hergebruikt wachtwoord, een gedeeld account, een in gevaar gebrachte inbox, een blootgestelde beheerderslogin, een verdachte MFA-prompt of een medewerker die niet goed uit dienst is gegaan.
Daarom kunnen toegangsregistraties voor inloggegevens een directe invoer vormen voor de documentatie van cyberbeveiligingsincidenten. Wanneer een incident een gedeelde login of een gevoelig account betreft, moet het bedrijf weten wie toegang had, hoe de toegang werd gedeeld, of machtigingen zijn gewijzigd en of de inloggegevens na het incident zijn geroteerd.
Een zakelijke wachtwoordbeheerder zoals Proton Pass for Business helpt teams om inloggegevens te beheren in versleutelde kluizen, unieke wachtwoorden te genereren, automatisch aanvullen te gebruiken, inloggegevens veilig te delen, passkeys te beheren en ingebouwde tweestapsverificatie te gebruiken. Voor incidentdocumentatie is de grootste waarde het toegangsspoor rond inloggegevens: wie toegang had tot gedeelde kluizen/accounts, hoe toegang werd beheerd en wie deze gebruikte, en wat er na het incident is veranderd.
Een wachtwoordbeheerder voor IT-teams voegt beheerfuncties toe, zoals beleid, rapportage, logboeken, op functies gebaseerd toegangsbeheer, SCIM-provisioning en SSO-integratie. Deze functies kunnen bedrijven helpen om aan te tonen hoe toegang tot inloggegevens wordt beheerd en bewijs te leveren wanneer een incident met inloggegevens wordt onderzocht.
Een wachtwoordbeheerder kan een incidentlogboek, juridische beoordeling, wettelijk meldproces of incidentresponsplan niet vervangen. Maar het levert bewijs over inloggegevens dat in die processen kan worden gebruikt.
Houd een compleet auditspoor bij van toegang tot inloggegevens met een zakelijke wachtwoordbeheerder.
