It-sikkerhedstekst ST8

Transkript

1 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015

2 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data En "log" er en registrering af hændelser, der er indtruffet på et tidligere tidspunkt, fx: brugernes handlinger i et it-system, ændringer i en database, opdateringer af software, nedbrud og fejl i itsystemer. Den proces, som danner loggen, kaldes "logning" eller "at logge". Logning kan udføres af mennesker og af it-systemer. Denne tekst har fokus på den type logning, som udføres af it-systemer (ikke manuelt af mennesker), og hvor den resulterende log skal kunne tjene som værktøj ved efterforskning i forbindelse med mulig uberettiget anvendelse af data. Dette er det primære formål med den type logning, som kræves i sikkerhedsbekendtgørelsens 19: 19, stk. 1: Der skal foretages maskinel registrering (logning) af alle anvendelser af personoplysninger. Registreringen skal mindst indeholde oplysning om tidspunkt, bruger, type af anvendelse og angivelse af den person, de anvendte oplysninger vedrørte, eller det anvendte søgekriterium. Loggen skal opbevares i 6 måneder, hvorefter den skal slettes. Myndigheder med et særligt behov kan opbevare loggen i op til 5 år. At der er etableret logning, er ikke i sig selv en garanti for, at man altid har en log, der i praksis kan anvendes ved en efterforskning. Der kan fx være et problem med loggens troværdighed, eller det kan være svært at tolke loggen. Denne tekst handler om, hvad man med fordel kan overveje med henblik på at sikre en log, som i praksis kan anvendes ved efterforskning af autoriserede brugeres anvendelser af data. Tolkning af log I nogle it-systemer er loggen ikke selvforklarende, og loggen viser ikke direkte, hvilke data brugeren har anvendt. En log kan fx angive hændelser i it-systemet. Nogle af disse hændelser kan være handlinger (eller resultatet af handlinger) udført af en specifik bruger. Hvis man til en efterforskning har behov for at vide, hvilke data brugeren har anvendt, vil det kræve en nærmere tolkning af loggens indhold. Figur 1 illustrer et eksempel på en efterforskning, hvor man søger efter en specifik brugers anvendelser af data. Eksemplet viser, hvorledes den praktiske tolkning af en log kan kræve, at der udføres en række trin. 1

3 I første trin udtrækkes loggen. I andet trin udskilles de hændelser, som er resultatet af den specifikke brugers handlinger. I tredje trin ændres loggen til et letlæseligt format, fx så den fremstår i tabelform i stedet for en lang uafbrudt tekst. I fjerde trin omsættes brugerens handlinger til en beskrivelse af, hvilke data brugeren har anvendt gennem sine handlinger, samt hvilken type anvendelse der er tale om. Hvis en tolkning er udført forkert, kan resultatet være uegnet til brug ved en efterforskning. Derfor er det relevant at sikre sig viden om, hvordan man i praksis skal bære sig ad med at tolke loggen korrekt. Den dataansvarlige bør sikre sig, at viden om hvordan en specifik log skal tolkes, er tilgængelig, når logningen etableres. Hvis den manglende viden først opdages den dag, loggen skal anvendes ved en efterforskning, kan det måske vise sig svært eller umuligt at tilvejebringe den nødvendige viden hurtigt nok. For at undgå afhængighed af enkeltpersoner bør der foreligge en skriftlig dokumentation af, hvordan loggen tolkes. Forståelse for det samlede system Hvis en log skal kunne tjene som værktøj ved efterforskning, skal loggen være fyldestgørende, således at den indeholder tilstrækkelig information til, at man efterfølgende kan tolke sig frem til alle brugeres anvendelser af data. Det kan være kompliceret at sikre en fyldestgørende logning, og i den sammenhæng kan forståelsen for det samlede system være afgørende. Forståelsen for det samlede system kan også være relevant i forhold til at sikre en beskrivelse af, hvordan loggen skal tolkes. Figur 2 illustrerer et simpelt ESDH-system 1 bestående af: En ESDH-applikation som tilgås via en browser og, hvor der er mulighed for at foretage logning (log 1). En ESDH-database hvor alle data er lagret og, hvor der er mulighed for at foretage logning (log 2). 1 System til Elektronisk Sags- og Dokumenthåndtering. 2

4 Figur 2 En bruger foretager login på ESDH-applikationen via en browser. Brugeren laver en søgning, hvor søgekriteriet passer til 32 s i databasen. ESDH-applikationen henter emner (indholdet af ens emnefelt) på de 32 s fra databasen. Brugeren får kun vist emner fra de første 10 s, fordi der ikke er plads til mere på skærmen. For at se de næste 10 emner skal brugeren klikke på en knap, men det undlader brugeren at gøre, fordi han/hun finder den søgte blandt de første 10 viste emner. Brugeren klikker på nr. 5 og får vist hele indholdet af denne i et nyt browservindue. Brugerens handlinger medfører i dette eksempel, at både databasen og applikationen foretager en behandling af oplysninger på alle 32 s (32 emner og indholdet af én ). Det er applikationen, som styrer login, og hvad brugeren får vist på skærmen. Dermed har applikationens log (log 1) mulighed for at angive, hvem brugeren er, hvilke emner brugeren har fået vist, hvilken der blev åbnet, og hvornår en blev åbnet. Forudsætningen er, at log 1 er sat op til at logge alle disse informationer sammen med et klokkeslæt fra et tilstrækkeligt præcist ur. Databasens log (log 2) har mulighed for at angive den samlede databehandling initieret af brugerens handlinger, nemlig 32 titler og indholdet af én . Log 2 kan ikke angive, hvilke emner brugeren har fået vist, fordi det styres af applikationen. Log 2 kan ikke angive, hvem brugeren var, fordi login styres af applikationen. Af hensyn til at spare tid for brugeren, kan ESDH-systemet være konstrueret således, at indholdet af de første 10 s bliver hentet over i applikationen sammen med søgeresultatet, så indholdet kan blive vist hurtigere for brugeren, når der klikkes på en . I den situation vil kun applikationens log kunne angive, hvilken/hvilke af de 10 s der rent faktisk blev åbnet og vist for brugeren, og på hvilket tidspunkt. ESDH-systemet kan også være konstrueret således, at der sker en udveksling af informationer mellem applikationen og databasen, og dette gør det muligt for log 2 at angive det samme som log 1. Dette simple scenarie viser, at skal man sikre sig en log, der kan benyttes ved efterforskning af brugeres anvendelser af data, kan det være nødvendigt at afdække det konkrete it-systems sammensætning og begrænsninger. Scenariet viser også, at en korrekt tolkning af logs kræver forståelse for, hvad den enkelte log viser, og hvad loggen ikke viser. I mere komplekse scenarier kan faldgruberne være langt mindre gennemskuelige. 3

5 Personhenførbar logning Hvis en log benyttes ved en efterforskning til at finde frem til den fysiske person, som har anvendt data, sker det under formodningen om, at en logget information, typisk en bruger-id, kan henføres til én fysisk person. Det er derfor relevant at sikre troværdighed i denne henføring til én fysisk person. Hvis flere brugere kan benytte samme login, og deres handlinger derved logges under samme bruger-id, vil den loggede bruger-id ikke tydeligt indikere, hvem der var brugeren bag den enkelte handling. I denne situation er det uklart, hvilken værdi loggen har ved en efterforskning af brugeres anvendelser af data. Loggede bruger-id'er kan henføres til én - og kun én - fysisk person, hvis der udelukkende anvendes personligt login på it-systemet. Derfor er det relevant at gennemgå de itsikkerhedsmæssige aspekter, som bidrager til sikring af, at et login altid er personligt. Det drejer sig især om følgende: Hvordan personligt login etableres. 2 Hvordan bruger-id'er administreres. Hvordan adgangsgivende faktorer (fx adgangskoder) administreres. Forøgelse af loggens troværdighed Ud over sikring af at logningen er personhenførbar, er det relevant at vurdere, hvordan man generelt kan øge troværdigheden af oplysningerne i loggen. Troværdigheden af de loggede oplysninger er selvsagt vigtig, hvis en efterforskning ved brug af logs kan lede til sanktioner mod en person. Isoleret set kan indholdet af en log sjældent anskues som bevis på, at de loggede hændelser er indtruffet. Ligeledes er der sjældent belæg for at hævde, at en bestemt hændelse ikke er indtruffet, udelukkende fordi den ikke fremgår af loggen. Den følgende liste indeholder eksempler på, hvad man kan overveje ved en vurdering af loggens troværdighed. Listen er ikke udtømmende: Hvordan er loggen sikret mod manipulering/sletning af indholdet, der hvor loggen opbevares eller transmitteres? Hvordan er loggen beskyttet mod uautoriseret adgang? Er autoriseret adgang til loggen (fx for driftspersonel) begrænset mest muligt, eventuelt begrænset til læseadgang? Kan der laves funktionsadskillelse, således at enkeltpersoner er forhindret i at tilgå de logs, hvor deres egne handlinger logges? Hvem har mulighed for at stoppe/starte loggen eller ændre på, hvad der logges? Handlinger kan skjules gennem selektivt logning, fx ved at handlinger, foretaget under login med en bestemt bruger-id, ikke logges. Hvordan kan det sikres, at der altid logges? Hvad er behovet for automatisk alarmering ved manglende logning? Hvordan kan der sikres en tilstrækkelig præcis tidsangivelse for de loggede handlinger? I den forbindelse kan det være af afgørende betydning, hvad loggen skal kunne 2 Disse aspekter er nærmere forklaret i følgende tekster: ST5 Identificering af en fysisk person med henblik på udstedelse af faktorer til et personligt login, ST6 Registrering af en fysisk person med henblik på udstedelse af faktorer til et personligt login, ST7 Overdragelse af faktorer ved udstedelse af et personligt login til en identificeret fysisk person. 4

6 sammenstilles med (under en efterforskning), fx om loggens tidsangivelse skal kunne sammenstilles med tidsangivelser i andre logs. Hvor længe skal data i loggen opbevares Hvis en log skal anvendes ved efterforskning, er det en forudsætning, at de relevante data i loggen opbevares længe nok. Modsat kan der være lovkrav (blandt andet i førnævnte 19 i sikkerhedsbekendtgørelsen) som begrænser, hvor længe loggen må opbevares. Det er derfor relevant at undersøge, hvordan man sikrer en rettidig sletning af data i loggen. Hvis der sker automatisk sletning af data i loggen, og dette fx er styret af, hvor meget plads der maksimalt er afsat til loggen, kan det bevirke, at data slettes for hurtigt eller for sent. Visse it-systemer kan danne og opbevare logs flere steder og eventuelt i flere formater, fx i flere databaser og filer. Hvis man kun benytter én eller nogle af disse logs, er der risiko for manglende opmærksomhed og dermed manglende oprydning i forhold til alle logs. Derfor bør man sikre sig det fornødne indblik i it-systemet til at vide, hvor logs dannes og opbevares. Der kan være systemer, som ikke er indrettet til at kunne slette dele af loggen automatisk, fx automatisk sletning af data som er logget før en bestemt dato. Dette kan være en udfordring i forhold til rettidig sletning. Det kan vise sig, at systemet enten skal ændres, eller at rettidig sletning i loggen bliver en ressourcekrævende, manuel proces. Derfor bør man få afklaret og afprøvet, hvordan rettidig sletning af data kan foretages i praksis, uden at alle data i loggen slettes. Test af logning En test kan afsløre, at en etableret logning ikke virker som forventet, at loggen i praksis ikke kan tolkes korrekt, eller at loggen ikke kan anvendes med meget kort varsel. Dette kan være kritiske elementer, når en log skal anvendes ved efterforskning. Man kan eksempelvis teste på denne måde: 1. It-systemet udsættes for flere brugeres samtidige handlinger. 2. Handlingerne noteres inklusiv en beskrivelse af, hvilke data den enkelte bruger derved anvender. 3. Efterfølgende udtrækkes loggen og tolkes af en person, som er helt afhængig af en nedskrevet beskrivelse af, hvordan loggen skal tolkes. Med andre ord, så ved denne person ikke, hvordan loggen fungerer, og personen ved ikke, hvilke handlinger brugerne har foretaget, eller hvilke data brugerne derved har anvendt. 4. Det tolkede resultat skal angive, hvilke data som har været anvendt, af hvem, hvornår og hvordan. Dette resultat sammenlignes med den faktiske anvendelse af data, for at se om der er overensstemmelse (fx at der hverken er flere eller færre anvendelser af data). En undersøgelse af logning bør også afdække andre relevante aspekter, fx om loggens data slettes rettidigt, alarmering ved manglende logning, hvem der kan manipulere med loggen, muligheden for at sammenstille logs korrekt, med videre. 5

7 Logning kan ikke erstatte basale it-sikkerhedsforanstaltninger Selv om en konkret logning sker med henblik på håndtering af it-sikkerhedsmæssige risici, som fx uberettiget anvendelse af data, er det ikke ensbetydende med, at logningen kan erstatte andre basale it-sikkerhedsforanstaltninger. Logs viser kun hændelser, der er indtruffet på et tidligere tidspunkt. En hændelse, som forårsager tab af datas fortrolighed, integritet, tilgængelighed eller uafviselighed, kan først logges, når hændelsen er indtruffet og tabet er sket. Logning kan derfor ikke stå alene, når det kommer til beskyttelse af data. Personer, som har autoriseret adgang til data, vil kunne misbruge disse data øjeblikkeligt. Loggen kan måske efterfølgende vise, at der er sket et misbrug, hvis flere forudsætninger er opfyldt som beskrevet i denne tekst. Loggen kan ikke anvendes til at forhindre et misbrug foretaget af autoriserede personer. Altså kan logning ikke anvendes som alternativ til basale itsikkerhedsforanstaltninger, fx begrænsning af brugernes adgange og rettidig nedlæggelse af brugernes adgange. Hvis en ondsindet person stopper logningen, er det afgørende, om man kan opdage dette hurtigt nok. Det kan kræve andre it-sikkerhedsforanstaltninger end logning, fx en manuel overvågning eller alarmer. dt@datatilsynet.dk (+45)