Tien tips voor privacyvriendelijke securitylogs
Vaak zullen sysadmins voor security-doeleinden loggen. Je zult dan al gauw te maken krijgen met privacyregels, want die logs kunnen privacy-gevoelig zijn. Hoe kan je het risico op privacy-problemen zo veel mogelijk voorkomen? Hier zijn tien tips.
1. Log pas als dat nodig is. Log gegevens niet ‘voor de zekerheid’, maar alleen als dat noodzakelijk is om, bijvoorbeeld, fraude te voorkomen of om de veiligheid van je netwerk te waarborgen.
2. Informeer je gebruikers. Maak duidelijk aan gebruikers wat je precies doet, bijvoorbeeld via je privacy policy. Leg het zo helder mogelijk uit.
3. Omschrijf duidelijk voor welk doel je gegevens logt. Het is belangrijk dat je duidelijk de doeleinden omschrijft waarvoor je gegevens opslaat, ook om de volgende reden.
4. Gebruik de gegevens niet voor andere doelen. Als je logt voor security-doeleinden, kan je die logs vervolgens niet gebruiken voor, bijvoorbeeld, marketingdoeleinden.
5. Log op het laagste niveau. Beperk je tot het hoogst noodzakelijke. Log bij netwerkverkeer niet de IP-adressen, als je kan volstaan met de poorten. Log niet het hele IP-adres, als je kan volstaan met twee octets.
6. Log slechts een deel. Soms is het voldoende om slechts een percentage te loggen: bij netwerkverkeer bijvoorbeeld 1 op de 10.000 pakketjes.
7. Bewaar gegevens zo kort mogelijk. Onderzoek kritisch hoe lang je de logs nodig hebt, en verwijder ze na die termijn. Je kan bijvoorbeeld onderzoeken hoe vaak het in het afgelopen jaar nodig was om langer dan drie maanden in de logs terug te zoeken.
8. Beperk de toegang tot de gegevens. Ook als je zo min mogelijk logt, dan nog moet je de toegang tot die gegevens beperken. Alleen die personen die niet zonder toegang kunnen, moeten toegang krijgen.
9. Beveilig je gegevens goed. Als je bijvoorbeeld niet continu toegang tot je logs nodig hebt kan het verstandig zijn om ze versleuteld op te slaan. Het risico dat de gegevens op straat komen te liggen beperk je daarmee.
10. Evalueer je beleid periodiek. Wat nu noodzakelijk is om te loggen, was dat een tijd geleden misschien niet. Het is daarom verstandig om af en toe, bijvoorbeeld een keer per half jaar, te kijken of je beleid aan herziening toe is.
Bij twijfel is het goed om nader advies in te winnen – een fout is gauw gemaakt en kan stevige gevolgen hebben voor de reputatie van je bedrijf (denk aan KPN die DPI toepaste op haar netwerkverkeer).
Ot van Daalen is advocaat en oprichter van advocatenkantoor Digital Defence dat is gespecialiseerd in security- en privacyrecht. Daarvoor was hij oprichter en directeur van de digitale burgerrechtenbeweging Bits of Freedom. Hij werkt ook als onderzoeker privacy- en securityrecht bij het Instituut voor Informatierecht aan de Universiteit van Amsterdam.
Waarom niet gewoon 1 regel: laat slechts 2 gescreende mensen toegang geven tot de logs die alleen ontsloten mogen worden na expliciete opdracht van het MT. oid.
Waarom niet gewoon 1 regel: laat slechts 2 gescreende mensen toegang geven tot de logs die alleen ontsloten mogen worden na expliciete opdracht van het MT. oid.
Ik vind het wel een mooie voorzet in ieder geval, lekker duidelijk en helder. Het enige dat mij echt opviel is de foto, Ot kijkt wel erg content, misschien net iets té voor een advocaat ;) (No offense!)
Waarom niet gewoon 1 regel: laat slechts 2 gescreende mensen toegang geven tot de logs die alleen ontsloten mogen worden na expliciete opdracht van het MT. oid.
Vertel dat maar eens aan de beheerders van de mailservers die een issue met de mail van een bepaalde gebruiker moeten onderzoeken. Eerst dus maar die twee mensen bij elkaar zien te krijgen (ja, die hebben soms ook vakantie). Misschien zijn ze er wel, maar zijn ze bezig met het doornemen van de logging van de nameserver. Of was dat gister en zijn ze vandaag bezig met de logging van AD. En morgen staat eigenlijk een onderzoek van de VPN logs op de planning.
Met enkele honderden servers en tientallen verschillende diensten die allemaal loggen, heb je per omgeving twee mensen nodig. Laat dat nu net het aantal zijn dat goed op de hoogte is van de configuratie van de omgeving. Want ook van die beheerders moet er soms eentje op vakantie.
Beheerders moeten logbestanden kunnen analyseren als er een probleem is en niet als een van de twee gescreende medewerkers tijd hebben. Toegang tot logbestanden moet gelogd worden en de beheerders moeten kunnen verklaren waarom ze toegang hebben genomen.
Als je dat niet doet, gaan ze eigen logbestanden, buiten zicht van de FG of SM aanleggen. Leer mij sysadmins kennen.....
Peter
Dat wil overigens niet zeggen dat de adviezen van Ot van Daalen geen hout snijden, het betekent wel dat je een grote verantwoordelijkheid op je neemt als je zo gedetailleerd logt, en het is noodzakelijk om je bewust te zijn van die verantwoordelijkheid en wat die impliceert. Ik herinner me bij die webapplicatie hoe de commerciële mensen likkebaardden toen ze lucht kregen van het bestaan van die gegevens, terwijl die toch absoluut niet voor het soort doelen dat zij voor ogen hadden waren vastgelegd. Die mensen missen in mijn ogen de discretie die nodig is om goed met privacy van anderen om te kunnen gaan. Mij overviel dat destijds. De adviezen van Ot van Daalen kunnen helpen daarop voorbereid te zijn.
Als je bij mij alleen dit soort inkoppertjes vertelt wordt je echt niet aangenomen.....
Ik denk dat men over het algemeen het hier mee eens is.
Het is net alsof je zegt "laten we hier een beveiligscamera ophangen, maar alle hoofden in beeld voorzien we (geautomatiseerd en onomkeerbaar) van een zwart balkje". Handig als je weet dat er een inbreker in beeld is, maar niet meer kunt achterhalen wie het is...
Voor niet-securitylogs zijn het overigens prima tips.
Beveiligingstechnisch zijn dit onbruikbare tips, omdat wanneer je niet volledig logt c.q. je logs moedwillig aanpast, deze later wellicht nooit meer gebruikt kunnen worden voor opsporing/detectie van frauduleuze handelingen. Dit kan je beveiliging verzwakken op een dusdanige manier dat er van beveiliging geen sprake meer is.
Privacytechnisch gaan deze maatregelen eigenlijk weer niet ver genoeg, want of je bij wijze van spreke nu één pakketje hebt of 10.000, als er net in dat ene pakketje iets heel gevoelig staat heeft je (privacy)maatregel niet geholpen. Nog los van het feit dat je (wellicht met wat extra moeite) alsnog logs bij elkaar kunt verzamelen die het 'hele verhaal' vertellen.
Het is gewoon simpel: Wil je iets beveiligen, dan ontkom je er niet aan dat je privacy tot op zekere hoogte schend. Wil je iets privacy-vriendelijk maken, dan ontkom je er niet aan dat je veel beveiligingsmiddelen- en maatregelen aan de kant moet schuiven. Een andere (tussen)oplossing is er simpelweg niet.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
