Härledda loggkrav ur GDPR

Vilka delar i dataskyddsförordningen (gdpr) kravställer på loggning och vilka delar av gdpr kan anses uppfyllda genom att logga?

Inledning

Vi ska ta er igenom denna del av GDPR eftersom förordningen, liksom direktivet (PUL), inte på något sätt anger HUR kraven i de två lagarna ska uppnås. GDPR och PUL anger bara VAD som förväntas, och inte ens detta är speciellt tydligt. Problemet med en otydlig styrning är att ingen än så länge egentligen vet HUR förordningen ska uppfyllas. Att logga anser nog alla är nödvändigt men frågan är VAD en lämplig nivå av loggning är och HUR den ska implementeras.

Vi ska hjälpa er i dessa frågor genom att dela med oss av vad vi har lärt oss under våra samtal med kunder i kundmöten, förstudier, genomförandeprojekt och föreläsningar i allmänhet.

I jakten på svaret vad GDPR innebär i förhållande till loggning börjar vi med vad Datainspektionen skriver på sin hemsida ”Förberedelser för personuppgiftsansvariga”.

Den personuppgiftsansvariges ansvar och skyldigheter förtydligas och utökas och de registrerades rättigheter förstärks.
Ni kan till exempel behöva införa nya rutiner för att tillmötesgå dataskyddsförordningens utökade krav på öppenhet och de registrerades rättigheter. I större organisationer kan detta få stor påverkan i frågor om budget, IT-system, personal, styrning och kommunikation
Dataskyddsförordningen lägger stor vikt vid den personuppgiftsansvariges skyldighet att kunna visa att förordningen följs, vilket kan medföra krav på ökad dokumentation.
För att kunna leva upp till de nya skyldigheterna enligt förordningen är det viktigt att ni har tillräckliga rutiner på plats för att ni ska kunna upptäcka, rapportera och utreda personuppgiftsincidenter.

Logghantering

I syfte att underlätta för läsaren definierar vi vårt sätt att definiera funktionen logghantering. Den omfattar flera steg. På grund av våra behov av att kunna härleda från lagar, förordningar, omvärldsbevakning, verksamhetskrav m.m. så har vi skapat en egen definition av begreppet.

Definitionen av begreppet logghantering avser samtliga faser i loggpostens livscykel. Dessa utgörs av:

I dag ingår som regel GDPR som en del att hantera under förstudien. Frågor som kretsar kring GDPR är som regel kopplade till vilken information som ska loggas och vilka system som bör ingå i en kommande logglösning.

Logghanteringens begrepp utgör loggpostens hela livscykel. I cykeln kommer varje begrepp kravställas utifrån den enskilde organisationens behov. Det är när man påbörjar denna kravhantering som logglösning börjar möta kraven i GDPR. Att ”logga” utan hjärna löser inga problem. Vad som ska loggas och hur loggningen ska gå till löses enklast genom en top-down modell där kraven identifieras på ett klassiskt sätt.

Bild 3, nedan, visar hur en organisations logghantering ser ut med Secorums modell. Modellen möjliggör en iterativ uppbyggnad av en organisations logganalysförmåga genom att bygga motorvägen innan alla bilar börjar använda den. För att bygga rätt väg krävs att de övergripande kraven är kända. Ur dessa kan vi alltid härleda de specifika. Speciellt de som omfattar vilken information som ska loggas.

Är vi på det klara att vi t.ex. vill kunna fatta långtgående beslut baserat på våra loggar måste allt från generering till analys kravställas utifrån detta. Rätt information måste skapas i loggarna och dessa måste samlas in på ett säkert sätt med bibehållen riktighet och sekretess och så vidare. Härledning är den heliga gral som hela logghanteringsarbetet utgår från.

Generering
Insamling
Bearbetning
Analys
Lagring
Spridning
Radering

Logghanteringsmodellen styrs av dess syfte, mål och vision. Dessa i sin tur är härledda ur lagar, förordningar, interna föreskrifter, verksamhetsbehov, omvärldsbevakning med mera. Utan dessa krav går det inte att fastställa om t.ex. analysen uppnår avsedda mål eller hur varje del i processen ska kravställas. Det går inte ens att veta om rätt information loggas om det saknas en uppfattning m vad analysen ska ge.

Lokal logghantering

Det finns många olika nivåer på HUR en loggfunktion kan byggas. Den enklaste beskrivs nedan i bild 1. Den beskriver dagens situation inom många organisationer där varje loggkälla ansvarar för sin egen loggning och där all logganalys sker av den egna förvaltningen. I dag är det vanligt med att outsourca driften varför OS och loggdata endast är åtkomliga för driftleverantören. I dessa fall beställs loggdata från förvaltningen om egen åtkomst till servrarna saknas.

Fördelar med lokal logghantering:

Det finns inga fördelar

Nackdelarna:

Ej automatiserad, man går till loggkällan vid behov
Skadan redan skedd och loggen kan på sin höjd bekräfta/förneka att en händelse skett
I allmänhet regelstyrd vilket innebär att alla tolkat regeln olika med följden att alla system loggar mer eller mindre olika saker
Automatiserad korrelering finns inte (inga samband mellan loggdata som skapats av olika system)
Loggdata är åtkomligt för alla med rättigheter till loggfilen/databasen eller av root/admint;
Mycket data (kodade värden som kräver uppslag) och lite information
Ingen enhetlig hantering av händelsetyper
Som regel ingen möjlighet att se skillnad mellan vinter- och sommartid

Kräver som regel en tolkning av en tekniker för att förstå
Mottagaren känner sig okunnig då denne inte förstår loggarna varför nya beställningar inte sker
Och mycket mer som gör dessa loggar till en pina att hantera eftersom de aldrig kravställts utifrån ett analysperspektiv.

En lokal logghantering där varje förvaltning ska hantera sina egna loggdata innebär att varje förvaltning måste bygga upp logg- och analysförmågan var för sig. Även om detta skulle gå i teorin så måste varje förvaltning allokera personal för uppföljning och kontroll. Lösningen tenderar att bli allt för ineffektiv och dyr. För att över huvud taget vara möjlig att realisera krävs någon form av logganalysverktyg. I detta fall med en implementation inom varje förvaltning. Detta på en loggmängd som utan logganalysverktyg finns kvar inom loggkällan där den är möjlig att editera (påverka). Kraven på riktighet och sekretess blir svårare att uppnå.

I dag bygger av förklarliga skäl inga ambitionshöjande logglösningar på lokala logglösningar. Ett av de huvudsakliga verksamhetskraven som diskvalificerar lokal loggning är förlusten av korrelering av händelser som kräver åtkomst att loggdata från flera olika loggenererande system.

Central logghantering

Motsatsen till en lokal loggning är att centralisera den. Bild 2 visar hur en centraliserad logglösning kan beskrivas. I denna lösning sker åtkomsten till loggdata på ett och samma ställe, vilket i sig är en förbättring bara det, men en centraliserad logglösning kan implementeras på en rad olika sätt. Av den anledningen är en central logglösning i sig inte svaret på frågan om hur GDPR ska mötas loggmässigt.

En logglösning där loggdata samlas in centralt för central åtkomst och analys.

Att centralisera loggdata möjliggör i steg ett att gå till ett ställe i stället för till flera som med den lokala logganalysen. I sig innebär det inte med någon automatik en bättre logguppföljning. Däremot kan lösningen förbättra tilltron till loggdatas riktighet. Detta om loggdata kan samlas in i realtid.

Om insamlingen sker utan logganalysverktyg sker det med de överföringsprotokoll som finns tillgängliga på de servrar som bär applikationerna. Dessa saknar förmåga att garantera alla krav på insamling som vi hävdar krävs för en genomtänkt analys och en logghantering som följer GDPR.

Spontant hävdar vissa att detta påstående är fel. Detta eftersom det finns protokoll som scp, sftp m.fl. som klarar av detta, men dessa saknar andra viktiga egenskaper som tar hänsyn till filrotation, cachning, återsändning efter ett avbrott, skydd mot redundanta loggar, bandbreddskontroll m.m.

Det finns tekniska begränsningar i existerande protokoll och det krävs som regel en logik i form av lokalt installerad programvara för att hantera loggdata på det sätt som en fungerande analys kräver.

Utan logganalysverktyg är en centraliserad logglösning i sin enkelhet en databas eller ett filsystem där det går att söka efter händelser som redan skett. Vi har samma förvirring som i en lokal hantering eftersom loggdata fortfarande är ostrukturerat och möjligheten att bedöma om all loggdata är tillgänglig eller tillförlitlig saknas.

Att samla in och lagra loggdata centralt är däremot första steget på en förbättrad logghantering och utgör grunden oavsett kommande val av teknik.

Hur logghantering möter GDPR

I detta kapitel identifierar vi de artiklar i lagstiftningen som direkt eller indirekt påverkar området logghantering eller det som allmänt kallas för loggning. I samband med varje artikel för vi en diskussion med källan där vi härleder slutsatsen utifrån tolkning och vår egen kompetens.

Eftersom lagstiftningen inte talar om HUR loggningen ska implementeras kommer olika tolkningar att göras hur detta ska uppnås. Detta är Secorums vägledning, en vägledning som bygger på många års erfarenhet, men där GDPR är lika ny för oss som för er. Vi tar därför tacksamt emot synpunkter på våra resonemang och slutsatser. Skriv dem gärna på vår blogg.

Krav artikel 24

Med beaktande av behandlingens art, omfattning, sammanhang och ändamål samt riskerna, av varierande sannolikhetsgrad och allvar, för fysiska personers rättigheter och friheter ska den personuppgiftsansvarige genomföra lämpliga tekniska och organisatoriska åtgärder för att säkerställa och kunna visa att behandlingen utförs i enlighet med denna förordning. Dessa åtgärder ska ses över och uppdateras vid behov.

Diskussion

Det första steget i jakten på att besvara vilka krav GDPR ställer på loggning utgörs av att GDPR lägger hela vikten vid att den personuppgiftsansvarige ska kunna visa att förordningen följs. Denna del beskrivs i artikel 24 under rubriken ”Den personuppgiftsansvariges skyldighet”. För att uppfylla kravet måste det finnas något att visa upp. Underlaget för detta kommer att vara beskrivande dokumentation och processer. Detta inkluderar loggning som när den är implementerad i praktiken kan visas och bedömas vid en granskning.

För att komma vidare i resonemanget behöver vi veta mer specifikt VAD det är förordningen kräver. Av den diskussion som följer har vi valt att redovisa hela eller bara delar av förordningens artiklar. Dataskyddsförordningen som helhet går att hämta här.

Krav artikel fem

Artikel 5 ”Principer för behandling av personuppgifter” ange bland annat följande:

1. Vid behandling av personuppgifter ska följande gälla:

Uppgifterna ska behandlas på ett lagligt, korrekt och öppet sätt i förhållande till den registrerade (laglighet, korrekthet och öppenhet).
De ska samlas in för särskilda, uttryckligt angivna och berättigade ändamål och inte senare behandlas på ett sätt som är oförenligt med dessa ändamål. Ytterligare behandling för arkivändamål av allmänt intresse, vetenskapliga eller historiska forskningsändamål eller statistiska ändamål i enlighet med artikel 89.1 ska inte anses vara oförenlig med de ursprungliga ändamålen (ändamålsbegränsning).
De ska vara adekvata, relevanta och inte för omfattande i förhållande till de ändamål för vilka de behandlas (uppgiftsminimering).
De ska vara korrekta och om nödvändigt uppdaterade. Alla rimliga åtgärder måste vidtas för att säkerställa att personuppgifter som är felaktiga i förhållande till de ändamål för vilka de behandlas raderas eller rättas utan dröjsmål (korrekthet).
De får inte förvaras i en form som möjliggör identifiering av den registrerade under en längre tid än vad som är nödvändigt för de ändamål för vilka personuppgifterna behandlas. Personuppgifter får lagras under längre perioder i den mån som personuppgifterna enbart behandlas för arkivändamål av allmänt intresse, vetenskapliga eller historiska forskningsändamål eller statistiska ändamål i enlighet med artikel 89.1, under förutsättning att de lämpliga tekniska och organisatoriska åtgärder som krävs enligt denna förordning genomförs för att säkerställa den registrerades rättigheter och friheter (lagringsminimering).
De får inte förvaras i en form som möjliggör identifiering av den registrerade under en längre tid än vad som är nödvändigt för de ändamål för vilka personuppgifterna behandlas. Personuppgifter får lagras under längre perioder i den mån som personuppgifterna enbart behandlas för arkivändamål av allmänt intresse, vetenskapliga eller historiska forskningsändamål eller statistiska ändamål i enlighet med artikel 89.1, under förutsättning att de lämpliga tekniska och organisatoriska åtgärder som krävs enligt denna förordning genomförs för att säkerställa den registrerades rättigheter och friheter (lagringsminimering).

Den personuppgiftsansvarige ska ansvara för och kunna visa att punkt 1 efterlevs (ansvarsskyldighet).

Diskussion kring artikel fem

Av artikel fem kan vi läsa att förordningen kräver att personuppgifterna ska hanteras lagligt och korrekt samt att behandlingen ska ske på ett sätt som säkerställer att uppgifterna skyddas mot obehörig och otillåten behandling och förlust m.m. För detta ska man använda skyddsfunktioner som beskrivs som lämpliga tekniska och organisatoriska åtgärder som skyddar uppgifternas riktighet och sekretess. Artikeln anger inget om HUR personuppgifterna och dess metadata ska skyddas. Den anger bara ATT dessa ska skyddas. Nivån är däremot tydlig. Uppgifterna SKA behandlas på ett lagligt sätt och uppgifterna SKA skyddas mot obehörig och otillåten behandling.

Vilka val finns då till buds för att möta detta krav? Det är uppenbart att åtkomstskydd i form av autentisering och auktorisation tillsammans med behörighetsstyrning är grundläggande skyddsfunktioner när det gäller skyddet mot obehörig åtkomst, men inte heller här anges HUR och till vilken nivå som förväntas.

Om vi håller oss till hur spårbarhet eller loggning hjälper oss i bedömningen HUR artikel fem ska mötas så är det vissa saker som kan mötas med just loggning. Det är hur vi skyddar uppgifterna mot otillåtna behandlingar och hur vi kan hävda att behandlingen skett eller sker på ett lagligt och korrekt sätt. Punkten f) summeras med orden ”integritet och konfidentialitet”, även kallade för riktighet och sekretess. Sekretessen bryts för varje läsa händelse, vilket är en del i varje behörighet. Riktigheten påverkas likaså av varje förändring om dessa inte är korrekta. För att uppnå kravet att skydda informationens sekretess och riktighet måste det inbegripa även de användare som har teknisk behörighet till informationen.

Eftersom vi inte kan hindra användare med rättigheter i objekten att skapa, läsa, förändra, söka eller radera informationen så måste vi, för att uppnå kraven i förordningen, utbilda, styra och följa upp dessa åtkomster så att vi kan förbjuda och upptäcka sådant som inte är tillåtet. Det vill säga visa att detta går att upptäcka och därmed visa om så skett eller ej. Detta är svårt, eller rättare sagt omöjligt, att uppnå utan en väl fungerande loggning. Att inte logga användarnas åtkomst till information innebär att det inte går att visa att hanteringen av dessa går eller har gått rätt till.

Vad som är rätt eller fel vid åtkomst av användare med tekniska behörigheter påverkas av syftet bakom behandling av uppgifterna. En tillåten åtkomst från en anvä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.

Slutsats

Artikel 24 anger att det är den personuppgiftsansvariges skyldighet att visa att behandlingarna utförts i enlighet med förordningens alla krav. Detta är svårt att uppnå utan att loggning eller logghantering är ett av de tekniska hjälpmedel som måste användas för att uppnå förordningens krav. För att visa att förordningen följs vad gällande skydd mot t.ex. obehörig eller otillåten behandling måste vi kunna visa vad som hänt, både gällande behöriga och obehöriga användare.

För att uppnå en tillräcklig nivå av loggning måste enligt oss varje led i logghanteringsprocessen kravställas utifrån både tillgänglighets- sekretess- och riktighetsperspektiv. Vi återkommer längre fram om varför tillgänglighetsaspekten är viktig.

Hur logghanteringen implementeras

För att kunna visa att förordningen följs (artikel 24) och att loggningen är en dela av lösningen krävs någon form att kontinuitet och att loggfunktionen har vissa kvalitativa egenskaper. En logglösning måste därför kravställas utifrån en viss nivå av tilltro. Detta är inte ett vagt uttalande utan något som framgår av artikel 32 som reglerar säkerheten i samband med själva behandlingen.

Krav artikel 32

Artikel 32 ”Säkerhet i samband med behandlingen” Med beaktande av den senaste utvecklingen, genomförandekostnaderna och behandlingens art, omfattning, sammanhang och ändamål samt riskerna, av varierande sannolikhetsgrad och allvar, för fysiska personers rättigheter och friheter ska den personuppgiftsansvarige och personuppgiftsbiträdet vidta lämpliga tekniska och organisatoriska åtgärder för att säkerställa en säkerhetsnivå som är lämplig i förhållande till risken, inbegripet, när det är lämpligt

pseudonymisering och kryptering av personuppgifter
förmågan att fortlöpande säkerställa konfidentialitet, integritet, tillgänglighet och motståndskraft hos behandlingssystemen och -tjänsterna
förmågan att återställa tillgängligheten och tillgången till personuppgifter i rimlig tid vid en fysisk eller teknisk incident,
ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos de tekniska och organisatoriska åtgärder som ska säkerställa behandlingens säkerhet

Vid bedömningen av lämplig säkerhetsnivå ska särskild hänsyn tas till de risker som behandling medför, i synnerhet från oavsiktlig eller olaglig förstöring, förlust eller ändring eller till obehörigt röjande av eller obehörig åtkomst till de personuppgifter som överförts, lagrats eller på annat sätt behandlats.

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.

Rapportering

Rapporteringsplikt

Nästa fråga som behandlas är vilken beredskap organisationen ska ha för att upptäcka oegentligheter som med tiden kommer att ske. Den som inte söker kommer inget att finna. Detta är ett mantra som gällt för logghantering fram till idag. Vi har mött myndigheter som velat stänga av logganalysfunktionen eftersom så många oegentligheter upptäcks. Myndighetsledningar har ansett att detta är för mycket ”badwill” för organisationen.

Krav artikel 33

1. Vid en personuppgiftsincident ska den personuppgiftsansvarige utan onödigt dröjsmål och, om så är möjligt, inte senare än 72 timmar efter att ha fått vetskap om den, anmäla personuppgiftsincidenten till den tillsynsmyndighet som är behörig i enlighet med artikel 55, såvida det inte är osannolikt att personuppgiftsincidenten medför en risk för fysiska personers rättigheter och friheter. Om anmälan till tillsynsmyndigheten inte görs inom 72 timmar ska den åtföljas av en motivering till förseningen.

2. Personuppgiftsbiträdet ska underrätta den personuppgiftsansvarige utan onödigt dröjsmål efter att ha fått vetskap om en personuppgiftsincident.

3. Den anmälan som avses i punkt 1 ska åtminstone:

beskriva personuppgiftsincidentens art, inbegripet, om så är möjligt, de kategorier av och det ungefärliga antalet registrerade som berörs samt de kategorier av och det ungefärliga antalet personuppgiftsposter som berörs
förmedla namnet på och kontaktuppgifterna för dataskyddsombudet eller andra kontaktpunkter där mer information kan erhållas
beskriva de sannolika konsekvenserna av personuppgiftsincidenten, och
beskriva de åtgärder som den personuppgiftsansvarige har vidtagit eller föreslagit för att åtgärda personuppgiftsincidenten, inbegripet, när så är lämpligt, åtgärder för att mildra dess potentiella negativa effekter.

4. Om och i den utsträckning det inte är möjligt att tillhandahålla informationen samtidigt, får informationen tillhandahållas i omgångar utan onödigt ytterligare dröjsmål.

5. Den personuppgiftsansvarige ska dokumentera alla personuppgiftsincidenter, inbegripet omständigheterna kring personuppgiftsincidenten, dess effekter och de korrigerande åtgärder som vidtagits. Dokumentationen ska göra det möjligt för tillsynsmyndigheten att kontrollera efterlevnaden av denna artikel.

Diskussion skring artikel 33

Definitionen av en personuppgiftsincident är:

”en säkerhetsincident som leder till oavsiktlig eller olaglig förstöring, förlust eller ändring eller till obehörigt röjande av eller obehörig åtkomst till de personuppgifter som överförts, lagrats eller på annat sätt behandlats”

Artikel 33 anger att alla personuppgiftsincidenter ska anmälas till tillsynsmyndigheten, och i vissa fall till ägaren av personuppgifterna. Det intressanta med denna paragraf är att tiden börjar räknas efter det att den personuppgiftsansvarige fått vetskap om incidenten. Det finns därmed en risk i att detta kommer att utnyttjas, likaså definitionen av en inträffad händelse.

Att komma ihåg är att artikel 5 kravställer på att personuppgifter ska hanteras lagligt och korrekt och att det ska behandlas på ett sätt att det finns säkerhetsfunktioner som säkerställer att dessa skyddas mot obehörig åtkomst med mera. Detta innebär att en incident som upptäcks på annat sätt än av säkerhetsfunktionerna, som ska skydda informationen, innebär att dessa skyddsfunktioner eventuellt inte varit tillräckliga. Om vi även för in artikel 32 i diskussionen, den som anger att säkerhetsfunktionerna ska fungera och att dessa arbetar med bibehållen motståndskraft, bör vi hamna i ett läge där det inte lägre går att dölja sig bakom en logghantering utan analys. Att logga utan att analysera bör därför inte längre vara möjligt.

Slutsats

Att tro att man klarar sig undan genom att inte söka efter personuppgiftsincidenter är ett vågat beslut. Detta på grund av att kommande straffavgifter kommer att baseras på om och vilka tekniska och organisatoriska åtgärder som genomförts i enlighet med artiklarna 25 (inbyggt dataskydd) och 32 (Säkerhet i samband med behandlingen”. Att inte sökt trots förmåga och att varken skapa förmåga eller söka bör rimligtvis innebära en hårdare smäll än för en organisation som försökt men av förståeligare skäl misslyckats.

Nivåer av central logghantering

Hur logghanteringsförmågan kan byggas upp

Vi möter frågan hur en central logglösning kan implementeras. Alla är inte beredda att bygga allt på en gång. Detta är tekniskt inga problem och inom området logghantering pratar vi om två nivåer i utbyggandet av en väl fungerande logghantering. Dessa är:

Log Management (LM)
Security Information and Event Management (SIEM)

Det saknas givna beskrivningar på vad som ingår i vad, men både Gartner och Wikipedia har sina definitioner som man kan läsa om vägledning behövs. Själva definierar vi begreppen på följande sätt:

Logg management

Funktion för en säker insamling, lagring och grundläggande analys i form av ad hoc eller schemalagda sökningar i historiska loggdata.

Siem

Log Management plus ett intelligent analyslager som möjliggör realtidsanalys, korrelering, dashboards och rapporter som baseras på händelser som upptäcks i snar realtid.

Interativ uppbyggnad

De flesta produkter på marknaden tillåter att du bygger upp din logghanteringsförmåga i två steg. Detta genom att börja med en säker insamling, lagring och grundläggande analys och genom att addera realtidsanalys och korrelering i steg två.

Genom denna tvådelade implementation kan elefanten styckas i mindre delar. Viktigt att komma ihåg är att denna uppdelning återspeglas i identifierade syften, mål och vision. Om målet är en SIEM funktion på sikt eller om SIEM är en del av visionen så måste dessa likväl hanteras kravmässigt i den kravspecifikation som ska ligga till grund för ett kommande avrop eller upphandling. Om så ej sker riskerar man att köpa en produkt som inte är skalbar och som inte möjliggör att nå mål på sikt eller vision.

Förordningen har ett mycket gott syfte, men kan bli svår för organisationer att förhålla sig till, speciellt om det existerar en kultur där personuppgifter idag används utanför de strikt reglerade användingsområden som förordningen kräver, exempelvis för att utföra tester av applikationer. Överträdelser av GDPR kan medföra sanktioneringsavgifter på 20 000 000 EUR eller 4% av den totala globala årsomsättningen under föregående år (beroende på vilket värde som är högst) är det för många organisationer av stor vikt att inte bryta mot förordningen.

Ett kontor i rörelse med kollegor som går

Vad kan en organisation göra för att åtgärda felaktig användning av personuppgifter? Vi har satt ihop en liten film som kan demonstrera detta:

Secorum är inte experter på hela GDPR, vi är inte heller experter på hur GDPR ska tolkas, men vi är experter på psudonymisering och hur man kan använda produktionsdata i tvättad form som testdata – det kan vi hjälpa er organisation med. Secorum erbjuder ett paket för att hjälpa en organisation att hitta och psudonymisera personuppgifter.

Klicka här om ni vill läsa vilka delar i Dataskyddsförordningen (GDPR) kravställer på loggning och vilka delar av GDPR kan anses uppfyllda genom att logga.