GDPR i praktiken - del 2
Detta är den andra delen i artikelserien som handlar om vilka utmaningar vi ställs inför när vi ska hantera personuppgifter. I denna del kommer säkerhet och skyddande av personuppgifter att behandlas. Den första delen handlade om vad som är viktigt att tänka på vid skapande av system som är compliant med GDPR.
Skydd av personuppgifter enligt GDPR
Det talas ofta om vilken data som får sparas enligt GDPR, men lagen ställer även stränga krav på hur personuppgifter skyddas, så att de inte förstörs eller stjäls. Det är därför svårt för ett företag av storlek att hävda att de inte haft möjlighet att genomföra de åtgärder som nämns i denna artikel. Man kan inte heller hävda okunskap om man råkar ut för en incident. Det är även viktigt att förstå att om vi outsourcar personuppgifterna till tredje part så avsäger vi oss inte ansvaret, vilket gör att man måste kontrollera att de uppfyller sitt uppdrag. Att låta en tredje part hantera data kan i sig vara en säkerhetsrisk.
Denna artikel är inte en lista på åtgärder som måste hanteras för att följa GDPR. Den innehåller övergripande information och exempel på tekniska och organisatoriska säkerhetsåtgärder som tillsammans behövs för att skydda personuppgifter. Skyddsåtgärder skall inte ses som något som görs i efterhand och som bockas av på en lista, utan måste vara integrerat i utvecklingsprocessen och integration av system. De måste ses som en helhet då de tillsammans med säkerhetstänk utgör ett skyddsnät. GDPR ställer inga orimliga krav på säkerhet och hur konfidentiella uppgifter bör skyddas då dessa ändå bör hanteras av organisationen för att se till att den dagliga verksamheten ej riskeras.
När en person begär att få ett registerutdrag är det viktigt att det hanteras på ett säkert sätt. Det har visat sig allt för enkelt att ringa eller maila utan att behöva styrka sin identitet på ett säkert sätt. Även denna process måste det finnas en processbeskrivning för, så att uppgifterna inte skall hamna i fel händer. Denna artikel belyser på ett bra sätt hur enkelt det kan vara att få ut uppgifter utan att styrka sin identitet. Man kan därför dra nytta av de kartläggningar och åtgärder GDPR tvingar oss att utföra då vi bör hantera säkerheten oavsett lagar och förordningar. Skillnaden jämfört med tidigare är att numera är okunskap och slarv även straffbart.
GDPR som drivkraft för förbättrad cybersäkerhet
I artikeln GDPR i praktiken - del 1 skrev jag att man kan se GDPR som ett lackmuspapper som ger svar på om vi gjort ”rätt”. Se därför arbetet med att skapa en säker IT-miljö som en investering och inte en kostnad som tvingats fram. Enligt en färsk undersökning gjord av IBM Security and Ponemon Institute så tar det i Skandinavien i snitt 299 dagar från incident inträffar tills den upptäcks och löses. Undersökningen ser ett klart samband mellan hur lång tid det tar att upptäcka intrånget och kostnaden för den. Den genomsnittliga kostnaden för företag per intrång är 22 miljoner kronor vilket främst baseras på att kunderna förlorar förtroendet. Det är tydligt att det kan bli väldigt dyrt om säkerheten i företaget är bristfällig. Många företag är dessutom dåliga på att upptäcka incidenter, vilket i sig kan ses som både olagligt och förenat med betydande affärsrisker. Enligt samma undersökning kommer en fjärdedel av alla företag drabbas av intrång inom de närmaste 2 åren vilket manar till eftertanke.
Enlighet en undersökning som konsultfirman RSM lät utföra så börjar GDPR att få en positiv inverkan på cybersäkerheten inom EU. Nästan tre fjärdedelar (73%) av företagen hävdar att GDPR har uppmuntrat dem att förbättra hanteringen av kunddata och 62% säger att det har fått dem att öka sina investeringar i cybersäkerhet. Det återstår dock mycket att göra, men 21 % av företagen erkänner att de fortfarande inte har någon strategi för cybersäkerhet på plats.
Skyddsåtgärder
IT kommissionen finns inte längre, men det material de skapade går fortfarande att nå och ”HANTERING AV IT-INCIDENTER - vem gör vad och hur?” är ett bra dokument att utgå ifrån när man planerar skyddsåtgärder.
Där delas skyddsåtgärder upp i fyra huvudområden:
Proaktiva (förebyggande), t.ex. i form av införande av behörighetskontrollsystem eller incidentrapporteringssystem.
- Aktiva (operativa), t.ex. i form accesskontroll i realtid eller säkerhetsloggning
- Reaktiva (detektiva och korrigerande), t.ex. i form av intrångsdetektering eller incidentrespons i realtid
- Postaktiva (återställande), t.ex. i form av återstartsystem och återhämtningsprocedurer
I dokumentet finns även utmärkta exempel på hur man skall gå tillväga vid ett dataintrång.
Här följer ett axplock av vad man bör tänka på när man som organisation hanterar data.
Behörighetskontroll/Rättigheter
Det är viktigt att tänka på att personer som skall ha tillgång till data kan, såväl medvetet som omedvetet, bryta mot GDPR. De kan göra det för egen vinnings skull, för att de är tvingade, för att de styrs av processer som inte är GDPR-anpassade eller av brist på kompetens. De kan även omedvetet ha läckt inloggningsuppgifter eller ha en trojan i sitt system. Därför bör man inte ha rättigheter till mer än vad man behöver för sitt arbete. Att ge personer rättigheter baserat på deras titel istället för deras roll, behov eller kompetens, har visat sig vara mycket riskabelt. Det är mycket vanligt att man för vissa system delar inloggningsuppgifter, vilket i sig inte är förbjudet, men är klart olämpligt då det försvårar intrångsdetektering.
Segmentering
Segmentering gör det enklare att skydda de känsligaste delarna av en organisations nätverk. Om någon person eller trojan/virus lyckats ta sig in i ett nätverk så når de inte alla datorer/servrar. Det kan ge organisationen tid på sig att hantera intrånget och minimera följdverkningarna. Segmentering kan liknas vid ett företag med kontorslandskap uppdelat på olika avdelningar. Inom kontorslandskapet kan alla kommunicera fritt. Allt som kommunicerar mellan dessa avdelningar passerar en brandvägg där grundregeln vanligtvis är det motsatta mot inom avdelningen (nätverkssegmentet), dvs allt som inte är tillåtet (öppnat) är förbjudet (blockerat). I brandväggen kan man exempelvis välja att bara tillåta vissa språk (protokoll/portar) och vilka (servrar/klienter) personer man får kommunicera med. Man kan dela upp (segmentera) företaget på en mängd olika sätt, tex baserat på avdelning, hur känsliga uppgifter personalen hanterar, typ av serverhall osv.
Kryptering
Okrypterad datakommunikation är mycket enkelt att avlyssna, vilket innebär att alla känsliga uppgifter bör krypteras även inom nätverket. Tänk på att oviktiga data tillsammans med andra lika oviktiga kan avslöja mycket känsliga uppgifter. Mängden data gör det därför väldigt svårt att avgöra om den tillsammans med annan data är känslig eller ej. Det är därför säkrast att ha som policy att all kommunikation skall krypteras. Det är även viktigt att inloggningsuppgifter alltid är krypterade och inte skickas i klartext, vilket gäller såväl mellan system/servrar som när klientdatorer är uppkopplade mot system. Filer och hårdvara kan stjälas, vilket innebär att såväl hårddiskar som data bör vara krypterade. Annars kan man plocka ur hårddisken och enkelt läsa den utan att ha tillgång till inloggningsuppgifter.
Antivirus
Antivirusprogram tror jag att de flesta vet hur de fungerar så dessa tänker jag inte gå in på djupare på. Men man måste vara medveten om att de måste hållas uppgraderade och att grundinställningarna inte alltid räcker på ett företag.
IDS (Intrångsdetektering / Intrusion Detection System)
IDS används för att på olika sätt detektera intrångsförsök. Om någon trots allt gör ett intrång så måste vi kunna upptäcka det och inom 72 timmar rapportera det till personer som uppgifterna gäller och, om det är allvarligt, till Datainspektionen. Mer om vad som klassas som intrång och hur man skall hantera det kan du läsa hos Datainspektionen. Att sätta rättigheter baserat på vad man behöver tillgång till kan ibland försvåra arbetet på ett oacceptabelt sätt, vilket är fallet för bl.a. polisen och sjukvården. De hanterar denna utmaning genom att ge tillgång till nästan alla uppgifter till samtliga anställda och istället bevaka hur de används och av vem.
Det finns många saker jag inte tagit upp i denna artikel, så betrakta därför denna artikel som en övergripande beskrivning över hur komplext det kan vara att skydda data. Därför bör inte säkerhet hanteras på slutet, utan beaktas i alla installationer, inköp, utbildningar etc. Det går helt enkelt inte att lösa säkerhetsutmaningarna på slutet genom att låsa in allt i säkerhetslösning och samtidigt kräva att systemen skall vara enkla och flexibla. Det blir lite som att låsa in alla dokument i ett kassaskåp. Det är säkert, men blir väldigt svårt att arbeta med.
I den tredje och sista artikeln kommer jag att ta upp utvecklingsmiljöer och testdatabaser. Trots att lagen snart är ett år gammal ställer GDPR till stort huvudbry, och då i synnerhet i utvecklingsmiljön. Jag berättar vad man bör tänka på när man skapar testdatabaser och vilka övriga utmaningar vi ställs inför.
GDPR i praktiken - mer läsning
Detta är del 2 i ämnet, men här hittar du även den tidigare artikeln som handlar om hantering av data/arkitektur och del 3 och sista avsnittet som handlar om utvecklings- och testmiljöer.
