Bij het vaststellen van bewaartermijnen voor applicaties en databases ligt de nadruk vaak op de inhoudelijke gegevens. Logginggegevens zijn echter ook persoonsgegevens, deze leggen immers acties van gebruikers vast. Veel organisaties zijn zich niet van bewust van de aard of het bestaan van deze gegevens. De borging van privacy en de bewaartermijn zijn dan in het geding. In dit artikel belicht ik een aantal aandachtspunten vanuit privacyperspectief, waaronder de bewaartermijn van loggegevens.
In computersystemen worden gebeurtenissen die belangrijk zijn voor de beveiliging of voor de analyse van verstoringen in een logbestand vastgelegd. Voor zo’n gebeurtenis worden onder andere de volgende gegevens vastgelegd: datum en tijd van de gebeurtenis, gebruikersnaam en type gebeurtenis. Bij een gebeurtenis die wordt vastgelegd in een logbestand moet je denken aan het al of niet succesvol inloggen in een applicatie, door het systeem gegenereerde foutmeldingen of het vastleggen van een actie van een gebruiker, bijvoorbeeld het inzien van een medisch dossier.
De Autoriteit Persoonsgegevens (AP) beschouwt logging als een belangrijke manier om te controleren of gebruikers hun boekje te buiten gaan bij het raadplegen van persoonsgegevens. We gebruiken hier het voorbeeld van het HagaZiekenhuis, maar een en ander geldt voor alle organisaties waar gevoelige persoonsgegevens worden verwerkt, zoals banken, webwinkels, gemeenten, onderwijs- en zorginstellingen.
In de motivatie van de AP van de boete voor het HagaZiekenhuis in 2019 speelde logging een belangrijke rol. Uit praktische overwegingen hadden veel medewerkers toegang tot de gegevens van patiënten. Het Elektronisch Patiëntendossier voorzag in het loggen van de toegang tot medische dossiers. In april 2018 meldde een klokkenluider dat medische gegevens van een bekende Nederlander in de wandelgangen van het ziekenhuis rondzongen. Met behulp van de loggegevens kon worden vastgesteld welke medewerkers inzage hadden gehad in het dossier en in welke gevallen dit ongeoorloofd was.
De AP verwacht van organisaties niet alleen dat de toegang tot gegevens wordt gelogd, maar ook dat de loggegevens regelmatig worden geanalyseerd, zodat misstanden snel aan het licht komen en niet pas na de melding van een klokkenluider. Een steekproef van jaarlijks zes patiëntendossiers, zoals in het HagaZiekenhuis, is daarbij niet genoeg. Een ‘intelligente’ analyse is nodig, waarbij wordt geselecteerd op situaties die afwijken van het gewenste gebruik van het systeem. Daarbij kan bijvoorbeeld worden gekeken naar dossiers die door meer medewerkers dan gebruikelijk worden geraadpleegd. Het incident in het HagaZiekenhuis had op die manier mogelijk ook zonder klokkenluider vastgesteld kunnen worden.
Niet in alle gevallen zal een signalering een onterechte toegang betreffen, maar ook het bespreken van opvallende situaties met medewerkers draagt bij aan het bewustzijn.
Loggegevens zijn ook persoonsgegevens. Ook de mensen van wie de acties worden gelogd hebben recht op privacy. Daarom is het belangrijk ervoor te zorgen dat ook loggegevens niet zomaar ingezien kunnen worden. Dat kan door de toegang tot de loggegevens te beperken tot die personen die de gegevens moeten analyseren. Daarnaast kan voor de analyse van de loggegevens gebruikgemaakt worden van geautomatiseerde rapportages die alleen de voor de controle noodzakelijke informatie laten zien. Deze rapportages bevatten dan geen of minder tot personen herleidbare informatie of alleen bij opvallende situaties. Verder is het van belang om loggegevens niet langer te bewaren dan nodig. In het vervolg van dit artikel ga ik daar verder op in.
Bij de informatiebeveiliging worden loggegevens gebruikt om (pogingen tot) inbreuken in informatiesystemen vast te stellen en ook om achteraf te kunnen analyseren wat er is gebeurd. Bij het onderzoek naar de geslaagde ransomware-aanval op de Universiteit Maastricht eind 2019 waren loggegevens een belangrijke bron van informatie. Het gaat dan ook om technische gebeurtenissen die niet direct het gevolg zijn van handelingen door gebruikers.
Persoonsgegevens mogen niet langer worden bewaard dan nodig is voor het doel. Dat geldt ook voor loggegevens. Dat staat op gespannen voet met het belang van informatiebeveiliging, waar men de loggegevens het liefst zolang mogelijk zou bewaren. En dat terwijl informatiebeveiliging ook een belangrijke waarborg is voor privacy.
Ik licht dit nader toe. Vanuit privacyperspectief zouden de gegevens na de periodieke, bijvoorbeeld maandelijkse, analyse kunnen worden gewist. Vanuit het perspectief van informatiebeveiliging is het van belang om de loggegevens zolang mogelijk te bewaren. Dat bleek bij de ransomware-aanval op de Universiteit Maastricht. Achteraf bleek dat de hackers al enkele maanden actief waren op het netwerk van de Universiteit Maastricht. Dat kon alleen worden vastgesteld omdat er loggegevens waren bewaard. Volgens een onderzoeksrapport van IBM duurt het gemiddeld 206 dagen, oftewel bijna zeven maanden, voordat een datalek wordt bemerkt. En dat gaat alleen nog maar over datalekken die zijn ontdekt en het is een gemiddelde. Bij een Amerikaanse zorgverzekeraar duurde het negen jaar voor het datalek werd ontdekt. Tegen die achtergrond is een bewaartermijn van tien jaar voor loggegevens ook plausibel.
In de praktijk wordt vaak niet nagedacht over de bewaartermijn van loggegevens. In het verleden was gebruik van opslagcapaciteit een reden om de loggegevens regelmatig te wissen, maar tegenwoordig is opslag goedkoop en onzichtbaar (want in de cloud).
De AP geeft niet aan hoelang loggegevens bewaard mogen worden. Elke organisatie zal zelf een afweging moeten maken. Welke aanknopingspunten hebben we voor een gebalanceerde bewaartermijn voor loggegevens? Ik noem er enkele:
Volgens Artikel 33 lid 5 van het Vrijstellingsbesluit WBP (inmiddels niet meer geldig) moet de opslag van loggegevens gemeld worden wanneer ze langer worden bewaard dan zes maanden.
Volgens het Basel II-akkoord, dat geldt voor banken, moeten loggegevens drie tot zeven jaar worden bewaard.
De Baseline Informatiebeveiliging Overheid (BIO) noemt alleen een termijn van drie jaar bij een incident. De voorganger van de BIO voor de gemeenten, de BIG, gaat uit van minimaal drie maanden.
De Informatiebeveiligingsdienst (IBD) voor gemeenten maakt de bewaartermijn voor logging afhankelijk van de vertrouwelijkheidsclassificatie van het desbetreffende systeem, van een halfjaar voor bedrijfsvertrouwelijke informatie tot zeven jaar voor geheime informatie.
De minister van VWS heeft per ministerieel besluit vastgesteld dat loggegevens van zorgdossiers ten minste vijf jaar moeten worden bewaard.
De standaardinstelling voor het bewaren van logfiles is een jaar voor Office 365.
De standaardinstelling voor het bewaren van logfiles is zes maanden voor de GSuite- kantoorautomatiseringsomgeving van Google en een tot dertien maanden voor de IaaS cloud-diensten, afhankelijk van het type logfile.
Deze aanknopingspunten laten zien dat het zinvol kan zijn om niet slechts één bewaarperiode vast te stellen, maar deze afhankelijk te maken van het soort loggegevens. In het algemeen is een half jaar als minimum te zien. Als we loggegevens langer willen bewaren dan de detectietijd van de meeste datalekken, zitten we op een jaar. Dat is een termijn die we in de praktijk ook veel tegenkomen. Voor langere bewaartermijnen is een meer uitvoerige onderbouwing nodig, met een zorgvuldige afweging tussen noodzaak van beveiliging en de privacy van gebruikers. Bij die afweging zullen de gevoeligheid van de gegevens en de noodzaak van forensisch onderzoek op langere termijn een rol spelen. Daarnaast moet de langdurige opslag van loggegevens in verhouding staan tot de inspanningen die worden gedaan om een datalek zo snel mogelijk te detecteren. Dat kan door middel van de analyse van logging: niet alleen maandelijks, maar ook dagelijks of realtime. Daarvoor zijn speciale Security Operation Centers (SOC’s), die de systemen 24 uur per dag en 365 dagen per jaar bewaken en ingrijpen als dat nodig is.
In dit artikel ligt het accent op het dilemma bewaartermijnen. Deze zijn een onderdeel van het loggingbeleid. Vanuit privacyperspectief zijn daarvoor nog de volgende aandachtspunten van belang:
Hoe is de logging ingesteld: welke gebeurtenissen en welke informatie worden gelogd? Hierbij is het van belang om op hoofdlijnen per type gebeurtenis vast te stellen waarom logging nodig is en hoe dit wordt geëvalueerd. Het registreren van gebruikersactiviteiten zonder evaluatie daarvan zal in de regel niet proportioneel zijn.
Hoe wordt de logging privacyvriendelijk geëvalueerd? Voor de periodieke logging is het niet gewenst dat het gedrag van individuele medewerkers wordt geanalyseerd of dat een loganalist door de logging gaat grasduinen op zoek naar afwijkend gedrag. Privacyvriendelijker is het om rapportages te maken die ongewenst gedrag filteren, zodat alleen de namen van medewerkers met dit gedrag naar voren komen. Met hen kan vervolgens het gesprek worden aangegaan.
Wanneer er een vermoeden is van bijvoorbeeld fraude, kan het wel gerechtvaardigd zijn om de activiteiten van een individuele gebruiker te analyseren. Daarvoor zijn dan wel de nodige waarborgen noodzakelijk.
Het gehele loggingbeleid, inclusief de bovengenoemde punten, vormt een regeling met betrekking tot de verwerking van persoonsgegevens van medewerkers. Dat betekent dat de OR daarover instemmingsrecht heeft volgens artikel 27 k,l van de Wet op de ondernemingsraden.
Samengevat is het belangrijk te onderzoeken waar logging-gegevens worden geregistreerd, hoe de logging is ingesteld, wat er met de logginggegevens wordt gedaan en hoe lang ze worden bewaard. Maak vervolgens bewuste keuzes en leg die vast in beleid, afgestemd met de OR.
Logging is een complex onderwerp, omdat techniek en privacywet- en regelgeving hier samenkomen. Het is dan ook van belang om bij het ontwikkelen en implementeren van loggingbeleid de juiste expertise aan tafel te hebben.
