INFORMATIONS- OG INDIVIDSIKKERHED (IOI) VEJLEDNING OM RISIKOHÅNDTERING (SIKKERHEDSKONTROLLER) Version 1.0

Transkript

1 INFORMATIONS OG

2 snummer Dato Afsnit der er ændret Gældende version BEMÆRK! Denne vejledning er udarbejdet med KOMBIT A/S for øje. Den kan derfor IKKE adopteres i sin nuværende form. Vejledningen er derfor ALENE tænkt som en inspiration til, hvordan GDPRarbejdet kan brydes ned i mindre og mere forretningsnære størrelser. KOMBIT fraskriver sig derfor også ethvert ansvar, såfremt andre aktører anvender KOMBITs vejledninger/værktøjer i sin helhed eller brudstykker heraf i deres arbejde med EU s databeskyttelsesforordning. INFORMATIONS OG Side 2/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

3 Indholdsfortegnelse 1 INTRODUKTION OG FORMÅL Opbygning VEJLEDNING Terminologi Håndtering af kontroller i kravspecifikation Opfølgning på kontroller BRUG AF SKEMA FOR KONTROLLER Eksempel... 8 INFORMATIONS OG Side 3/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

4 1 INTRODUKTION OG FORMÅL Dette dokument er udarbejdet i regi af IOIprojektet i KOMBIT, som har til formål at sikre overholdelse af EU s Databeskyttelsesforordning (GDPR). Dokumentet indeholder en vejledning og et skema til projekterne, der kan støtte fastlæggelse og dokumentation af de tekniske og organisatoriske tiltag, der skal gennemføres for at opnå en passende itsikkerhed og databeskyttelse med andre ord risikohåndteringen, som i det følgende udmøntes i form af sikkerhedskontroller. Ved at udfylde og supplere skemaet, der følger med denne vejledning, etablerer projekterne dokumentation for de sikkerhedshedsmæssige kontroller. Kontrollerne besluttes på baggrund af den risikovurdering, som projekterne allerede har gennemført og dokumenteret, som en del af arbejdet med GDPRcompliance. Sammenhængen mellem de forskellige GDPRrelaterede opgaver er illustreret i nedenstående figur: Det er målsætningen, at projekterne gennem dette arbejde omsætter risikovurderingen til konkrete tiltag, som kan implementeres enten teknisk eller organisatorisk. Dette understøtter bl.a. kravene i Databeskyttelsesforordningens artikel 32 om behandlingssikkerhed, hvor det bl.a. fremgår, at den dataansvarlige og databehandleren skal træffe passende tekniske og organisatoriske foranstaltninger for at sikre et sikkerhedsniveau, der passer til de risici, som er identificeret i en risikovurdering. INFORMATIONS OG Side 4/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

5 I vurderingen af, hvilke tekniske og organisatoriske foranstaltninger, der skal etableres i forhold til den konkrete løsning, skal der tages hensyn til en række forhold; herunder det aktuelle tekniske niveau, implementeringsomkostningerne, den pa gældende behandlings karakter, omfang, sammenhæng og forma l samt risiciene af varierende sandsynlighed og alvor for fysiske personers rettigheder. Inden skemaet for risikohåndtering (sikkerhedskontroller) kan udfyldes, er der en række forudsætninger, som skal være opfyldt: a) Der skal være gennemført en kortlægning af Dataprocesser, Datatyper og Datastrømme med tilhørende datakategorier, behandlingshjemler, hvem der er dataansvarlig og databehandler osv. Der findes en særskilt vejledning og skabelon til dette på ShareIT 1. b) Der skal være gennemført en vurdering af forpligtelser i relation til registreredes rettigheder. Vejledning og skema for dette findes ligeledes på ShareIT. c) Der skal være gennemført en sikkerhedsmæssig risikovurdering, som har kortlagt relevante trusler, sårbarheder, konsekvenser og risici. Vejledning og værktøj til dette publiceres ligeledes på ShareIT. De indledende trin sikrer, at tekniske og organisatoriske kontroller fastlægges på baggrund af en omhyggelig og konkret risikovurdering og ikke ud fra vaner eller isolerede tekniske overvejelser. Med afsæt i de forretningsmæssige behov, bliver risikohåndteringen (sikkerhedskontroller) afstemt med risikoniveauet (som er kortlagt i risikovurderingen). Sikkerhedskontroller kan i mange tilfælde være cost drivere, og ressourceforbruget for den konkrete risikohåndtering bør derfor nøje afstemmes med risikoniveauet, som kortlægges og dokumenteres i projekternes arbejde med risikovurderingen. 1.1 Opbygning Dokumentet består dels af denne vejledningsdel og dels af et skema (Excel ark), der udfyldes og efterfølgende vil udgøre projektets dokumentation for GDPRcompliance: Vejledningen rummer en introduktion til området og giver nogle konkrete eksempler på, hvordan guiden kan anvendes. Skemaet udgøres af et Excel ark, der udfyldes af projekterne som dokumentation for de overvejelser, der er gennemført, og de valg, der er truffet. 1 INFORMATIONS OG Side 5/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

6 2 VEJLEDNING Herunder findes vejledning til udvælgelse og dokumentation af konkrete sikkerhedsforanstaltninger, som kan benyttes i KOMBITs projekter. Vejledningen er tænkt som en konkret støtte og inspiration, men det skal dog slås fast, at ingen prædefinerede skemaer med standardtrusler og hændelser kan dække alle situationer, og vejledningen skal derfor ses som inspiration og må altid suppleres af projektspecifikke overvejelser herunder kontroller, som ikke er med i skemaet. 2.1 Terminologi En sikkerhedskontrol er en foranstaltning, der skal forhindre, opdage eller minimere skadeforvoldende hændelser (tab af fortrolighed, integritet eller tilgængelighed) som følge af udnyttelse af sårbarheder i itsystemer. Der skelnes ofte mellem forskellige typer af kontroller 2 : Forebyggende kontroller (fx sikkerhedstræning, firewalls, antivirus osv.) Opdagende kontroller (fx overvågning, antivirus, intrusion detection osv.) Korrigerende kontroller (fx patchning) Kompenserende kontroller (fx backup site) En anden måde at karakterisere kontroller på er, hvordan de realiseres: Tekniske kontroller (typisk bygget ind i systemer som fx adgangskontrol, kryptering, firewalls osv.) Organisatoriske eller administrative kontroller (handlinger som mennesker udfører, der realiseres gennem politikker, procedurer, guidelines, træning osv.) Sammenhængen med risikovurderingen etableres ved, at kontroller kan mitigere identificerede, potentielle risici ved at nedsætte sandsynligheden for, at en sårbarhed kan udnyttes (likelyhood), eller ved at reducere konsekvenserne ved udnyttelse af en sårbarhed (impact). 2.2 Håndtering af kontroller i kravspecifikation Specifikationen af mange kontroller, vil ofte naturligt høre til i et sikkerhedsbilag til kravspecifikationen for et udbud (samt for visse kontroller i driftsbilaget). I den forbindelse skal opmærksomheden henledes på, at KOMBIT har udarbejdet et standardiseret sikkerhedsbilag 3 med generelle sikkerhedskrav. Det er obligatorisk, at projekterne tager udgangspunkt i dette bilag, når sikkerhedskrav beskrives INFORMATIONS OG Side 6/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

7 Ved at tage udgangspunkt i KOMBIT's standardbilag for drift og sikkerhed slipper projekterne for at opfinde 'den dybe tallerken' hver gang. I stedet bygges der oven på en allerede etableret baseline af best practice. For at sikre en hensigtsmæssig udnyttelse af ressourcerne anbefales derfor en tilgang, hvor man kan fokusere på de omstændigheder og karakteristika, som er særlige for det konkrete projekt / itsystem, når yderligere kontroller tilvælges, frem for at bruge kræfter på forhold, som er generelle for alle projekter. AULA projektet er fx kendetegnet ved, at behandle data om en meget stor gruppe børn. Deraf følger en lang række udfordringer i relation til samtykke og forudsætninger om brugernes itkundskaber, samt ved en stor forekomst af brugergenerede data (fx beskeder), som ikke nødvendigvis på forhånd kan klassificeres i forhold til følsomhed. Andre projekter vil være karakteriseret ved andre forhold, der skal tages særligt højde for. Det projektspecifikke fokus kan eksempelvis opnås ved at udvælge de vigtigste risici (identificeret under risikovurderingen fx dem der kommer ud med en risikoscore på 9 eller højere) og koncentrere kontrolindsatsen omkring disse risici og ved at have et særligt fokus på beskyttelse af personhenførbare data. Skemaet, som hører til denne vejledning, er da også udformet, så hovedfokus er lagt på kontroller, der typisk overvejes og tilpasses i det enkelte projekt, mens standardkontroller, som er med i KOMBITs standardbilag, har mindre fokus. 2.3 Opfølgning på kontroller En risikovurdering og de tilhørende valg af sikkerhedskontroller vil altid være en pointintime vurdering. Dokumenterne bør derfor periodisk genbesøges og opdateres (fx 2 gange om året eller i forbindelse med større ændringer) for hele tiden at have dokumentation som er i overensstemmelse med virkeligheden. Herudover skal der løbende følges op på, om planlagte / specificerede kontroller rent faktisk er implementeret og fungerer i kørende itsystemer, så man ikke har en falsk tryghed. Denne opfølgning kan eksempelvis ske gennem itrevision, audits, sikkerhedstest samt ved løbende at evaluere sikkerhedshændelser (fx baseret på overvågningen) samt modtagne efterretninger om det generelle trusselsbillede. IOIprojektet udarbejder en særskilt vejledning med forslag til en strukteret tilgang til opfølgning, der sikrer den nødvendige skriftlighed af hensyn til compliance arbejdet. INFORMATIONS OG Side 7/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

8 3 BRUG AF SKEMA FOR KONTROLLER Der er udarbejdet et skema / Excel ark, som projekterne skal udfylde inden udbud og ajourføre løbende igennem itløsningens levetid. Skemaet er udformet med en række spørgsmål inden for forskellige områder. Hvert spørgsmål i Excel arket besvares med følgende informationer: Begrundelse for om/hvordan området er relevant for projektet. Ambitionsniveau for kontroller Ikke alle kontroller er lige vigtige for alle projekter, så her er der mulighed for at indikere, hvor højt de tilhørende kontroller prioriteres på baggrund af risikovurderingen. I skemaet for risikovurdering vil risikoscoren kunne bruges som indikation for prioriteten for risici med høj risikoscore vil der således være behov for supplerende, stærke kontroller, som kan nedsætte risikoniveau et til et acceptabelt niveau. ID på risikoelementer i risikovurderingen Skal skabe strukturel sammenhæng mellem identificerede risici og de kontroller, der adresserer dem. Bemærk, at der i værktøjet pt. ikke findes sådanne IDfelter, men at det er tanken, at disse indføres i en senere version. ID på krav i kravspecifikationen Skal skabe sammenhæng mellem planlagte kontroller og de krav, der stilles i udbudsmaterialet (samt links til eventuelle instrukser til databehandler og underdatabehandler(e) som indgår i databehandleraftaler). Da skemaet ikke på forhånd kan tage højde for alle risici, som kan blive identificeret af KOMBITs projekter, er det vigtigt, at der konkret tages stilling til behovet for projektspecifikke tilføjelser. 3.1 Eksempel Nedenfor er beskrevet et fiktivt eksempel, som viser hvordan Excel arket er tænkt anvendt. Tabellen nedenfor viser indholdet af én enkelt linje i arket. Område D. Beskyttelse af data D3: Autentificeres anvendere af web services og brugerflader på en sikker måde? Fx ved krav om stærk autentifikation (certifikater, 2faktor eller security token) ved adgang følsomme oplysninger. Redegørelse Systemets brugerflader kræver et SAML token fra ContextHandler og afviser login s hvor værdien af AssuranceLevel attributten er mindre end 3. INFORMATIONS OG Side 8/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr

9 Systemets systemgrænseflader kræver et SAML token fra Security Token Service og afviser login s hvor værdien AssuranceLevel attributten er mindre end 3. Dermed er autentifikationen uddelegeret til støttesystemerne, og systemet skal blot validere det modtagne token. Ved konsekvent at benytte støttesystemerne til autentifikation, opnås en høj grad af sikkerhed, de støttesystemerne er designet, udviklet og testet til dette formål. Ambitionsniveau for kontroller ID på elementer i egen risikovurdering ID på krav i egen kravspecifikation Høj da utilstrækkelig brugerautentifikation kan føre til store konsekvenser, herunder tab af fortrolighed for følsomme personoplysninger. AULARISKID23 (utilstrækkelig brugerautentifikation) Krav 0317 og INFORMATIONS OG Side 9/9 KOMBIT A/S, Halfdansgade 8, 2300 København S, CVRnr