Krav artikel 32
Artikelns rubrik ” Säkerhet i samband med behandlingen” indikerar starkt att kraven avser att skyddsfunktionerna som valts är aktiva när behandlingen sker. Funktionen i en logghanteringslösnig ska med andra ord fungera när behandlingen sker.
När en organisation centraliserar sin logghantering utgör det nya logganalyssystemet en del av säkerheten inom varje behandlingsystem och tjänst. Detta på grund av att analysen övertagits av en central funktion i stället för att utföras lokalt. De kvalitativa kraven på en fortlöpande funktion riktas därför lika mycket på den centrala logganalysfunktionen som på de lokala systemen som genererar loggdata.
Egentligen har vi inte diskvalificerat lokal logghantering som ett sätt att möte kraven i GDPR. Vad vi säger är att det är en ohållbar lösning om organisationen i sig inte är väldigt liten. Var gränsen går ger vi oss inte in på, men det krävs inte många system innan en centraliserad lösning vinner ekonomiskt och kvalitetsmässigt.
Oanvändare som har en teknisk behörighet till informationen blir otillåten om syftet med åtkomsten är otillåten. Ett exempel är en handläggare som handlägger sina anhöriga inom en organisation där detta uttryckligen är förbjudet. Den tekniska behörigheten ger honom åtkomst till informationen, men likväl gör användaren fel.
Krav artikel 32
Av artikel 32 framgår att förmågan hos en avsedd säkerhetsfunktion fortlöpande ska klara av att säkerställa skyddet hos den information som hanteras. För ett logghanteringssystem innebär detta att själva logghanteringsfunktionen ska ha en viss kvalité och fungera när behandlingen sker.
Funktionen ska därför regelbundet testas och undersökas så att skyddsfunktionen är varaktig över tid. Tillgänglighetskrav i form av mottagningsförmåga och analys är därför större än vad många tror. Det är sannolikt inte OK att låta analysfunktionen ligga nere en vecka om den centrala logganalysfunktionen övertagit analysansvaret från de loggenererande systemen. Däremot skulle en lokal logganalys kunna vara en reservrutin om så sker, vilket förutsätter att loggdata ligger kvar hos källsystemen en tid efter överföringen.
Av ovan resonemang, och inte minst av artikel 32, drar vi slutsatsen att det inte räcker med att skapa loggdata och lagra dessa lokalt eller centralt i en hög. Förmågan att fortlöpande garantera att funktioner som innebär att informationen är korrekt till sitt innehåll (riktighet) och att hanteringen sker utan sekretessförlust och på ett korrekt sätt m.m. innebär behov av en pågående kontroll. Det bör rimligtvis inte räcka med att lagra loggdata i en hög och gå till högen och ställa en fråga när behovet påkallats av en extern anledning. Det förefaller rimligt att krav som ”Loggdata ska kunna användas för att upptäcka och minimera eller eliminera pågående informationsförlust eller informationsläckage” är nära förknippade med förordningens andemening.
Med Undantag av mycket små organisationer så utgör en central logganalysfunktion det mest effektiva. En central analysfunktion som bygger på loggdata som samlats in från de olika loggenererande IT-systemen innebär inte bara en möjlighet att korrelera. Den innebär även att bemannings- och kunskap minimeras till bara en förvaltning. Förmågan att korrelera innebär därutöver att upptäcka händelser som tidigare inte varit möjligt då analysen var begränsad till det specifika IT-systemet. Korrelering innebär en möjlighet att finna beroenden mellan händelser som inträffat i olika loggenererande system.
Vad vi kommer fram till som ett minimum är en centraliserad logghantering som möjliggör en automatisk eller schemalagd analys som är återkommande. Exakt var gränsen går för återkommande är svårt att ange, men om en organisation ändå investerar i en systemlösning som möjliggör en automatiserad analys kan den lika väl vara i snar realtid.