Sikkerhetslogger skal gjøre det mulig å undersøke hendelser som truer informasjon og tjenester. Start med spørsmål virksomheten trenger svar på: Hvem endret en tilgang? Ble en kundeliste eksportert? Hvorfor stoppet sikkerhetskopieringen? Det er disse spørsmålene som bør styre hvilke hendelser som registreres. En stor mengde loggdata gir ikke automatisk bedre oppdagelse eller bedre dokumentasjon.
Logger kan inneholde personopplysninger selv om de først og fremst beskriver tekniske hendelser. Brukernavn, IP-adresser, enhetsidentifikatorer og tidspunkt kan knyttes til ansatte eller kunder. Behandlingen må derfor ha et avklart formål, passende grunnlag og kontrollert tilgang. Artikkel 5 og 32 i GDPR gir rammen. NSMs grunnprinsipper beskriver oppdagelse som en del av sikkerhetsarbeidet; de fastsetter ikke én universell oppbevaringstid for alle norske logger.
Lag en katalog over loggkildene
Registrer system, hendelsestype, teknisk eier, faglig formål og hvor loggen lagres. Skill applikasjonslogger fra innloggingslogger, administratorhendelser, nettverksdata og sikkerhetskopirapporter. En hendelse kan finnes flere steder, men med forskjellige tidsstempler og identifikatorer.
For en nettbutikks ordreprosess bør katalogen skille tekniske hendelser fra kundedata som trengs til levering, retur og regnskapsoppfølging. Katalogen skal gjøre det mulig å finne en kilde og forstå hva den faktisk beviser.
Bruk systemoversikten for å finne skytjenester, integrasjoner og lokale komponenter. Spør fagavdelingene om systemer de administrerer selv. En sentral sikkerhetsplattform dekker ikke nødvendigvis løsninger kjøpt utenfor vanlig IT-prosess. Noter også kilder som ikke kan levere nødvendige hendelser; fravær av logg må ikke forveksles med fravær av aktivitet.
Velg hendelser etter undersøkelsesbehov
Start med hendelser som påvirker tilganger, opplysninger eller drift: innlogginger, endrede rettigheter, opprettede integrasjonsnøkler, større eksporter og sletting av viktige objekter. For hver kategori beskrives et konkret bruksområde. Et mislykket innloggingsforsøk alene har en annen betydning enn mange forsøk etterfulgt av en vellykket innlogging fra en ukjent enhet.
Vurder hvilke felter som er nødvendige. Tidspunkt, hendelsestype, resultat og en stabil aktørreferanse kan være tilstrekkelig. Hele meldingsinnholdet, fødselsnummer eller passord hører normalt ikke hjemme i feilloggen. Oppdag slike felt før sentral innsamling starter, fordi en unødvendig opplysning ellers kan spre seg til søkeindekser, varsler og eksportfiler.
Arbeidsark for én loggkilde
| Felt | Eksempel på beslutning som må dokumenteres |
|---|---|
| System | Navn og miljø, inkludert produksjon eller test |
| Formål | Undersøke endringer i administrative rettigheter |
| Hendelser | Tildeling, endring og fjerning av rettigheter |
| Opplysninger | Aktørreferanse, berørt konto, tidspunkt og resultat |
| Tilgang | Navngitte driftsroller og særskilt hendelsestilgang |
| Oppbevaring | Begrunnet periode med startpunkt og slettemetode |
| Kontroll | Kontrollhendelse som viser at innsamling fungerer |
| Begrensning | Hendelser leverandøren ikke tilbyr i tjenesten |
Eksemplet viser oppsettet, ikke en obligatorisk norsk standard. Tilpass kategoriene til systemets faktiske funksjoner. Hvis leverandøren beskriver «audit logging», må dere undersøke hvilke handlinger som inngår, om funksjonen er aktivert og om opplysningene er tilgjengelige lenge nok til det dokumenterte behovet.
Beskytt loggene mot urettmessig endring
En administrator som kan endre både systemet og alle spor etter endringen, skaper en svakhet i undersøkelsesgrunnlaget. Vurder separat lagring, begrensede sletterettigheter og oppfølging av endringer i selve loggoppsettet. Løsningen må passe risikoen og tilgjengelige ressurser. Det viktigste er at dere kjenner hvem som kan påvirke bevisene.
Kontroller tidssynkronisering og hvordan tidssoner presenteres. Hendelser fra ulike tjenester kan ellers komme i feil rekkefølge. Bevar nødvendig originalinformasjon når data normaliseres til et felles format. Hvis et felt forkortes eller oversettes, bør det være mulig å forstå forskjellen ved en senere undersøkelse. En pen tidslinje er utilstrekkelig dersom den bygger på uforenlige tidsstempler.
Gi tilgang etter oppgaven
Skill rutinemessig oppfølging fra undersøkelser som krever mer omfattende tilgang. Drift kan trenge å se om en jobb feilet uten å lese hele innholdet i en brukers handlinger. Ved en konkret hendelse kan et avgrenset utvalg gjøres tilgjengelig for en autorisert person. Registrer hvorfor tilgangen ble gitt, hvilket omfang den hadde og når den opphørte.
Vurder IP-adresser som personopplysninger i stedet for å anta at tekniske identifikatorer er ufarlige. Informer berørte grupper om relevant logging på en forståelig måte. Hvis virksomheten vil bruke sikkerhetslogger til et annet formål, eksempelvis kontroll av arbeidstid, må dette vurderes særskilt. Den opprinnelige sikkerhetsbegrunnelsen gir ikke automatisk adgang til slik gjenbruk.
Fastsett oppbevaring med en begrunnelse
Vurder hvor sent en hendelse realistisk kan bli oppdaget, hvilke undersøkelser som er nødvendige og hvor inngripende opplysningene er. Skill mellom aktive søkbare logger, begrensede arkivkopier og materiale som er sikret for en konkret sak. Ikke kopier en leverandørs standardperiode inn i egen policy uten å vurdere behov og begrensninger.
Knytt avgjørelsen til lagringsbegrensning. Hvis en hendelse krever at et utvalg beholdes lenger, dokumenteres dette med omfang, formål og videre oppfølging. Et pågående undersøkelsesbehov begrunner ikke nødvendigvis at alle logger fra hele virksomheten beholdes. Kontroller også at søkeindekser og eksportmapper omfattes av sletterutinen.
Lag varsler som noen kan håndtere
Et varsel trenger en eier, en vurderingsregel og en tilgjengelig reaksjon. Angi hvilke opplysninger mottakeren får, hva som undersøkes først og når saken skal eskaleres. Begynn med få scenarier som virksomheten kan følge opp. Mange alarmer uten kapasitet til vurdering skaper en kø som kan skjule alvorlige hendelser.
Dokumenter kjente feilkilder. En stor eksport kan være et godkjent månedsoppgjør, men den kan også være misbruk. Et varsel bør derfor kobles til relevant kontekst, uten at unødvendige personopplysninger deles bredt. Mottakeren må kunne begrunne hvorfor hendelsen ble lukket eller sendt videre. En automatisk statusendring er ikke det samme som en faglig vurdering.
Hypotetisk eksempel: uventet eksport av kundedata
En tenkt virksomhet får et varsel om en eksport utenfor vanlig arbeidsmønster. Den ansvarlige sammenholder eksporthendelsen med innlogging og endring av rettigheter. Det viser seg at en integrasjonskonto nylig har fått en bredere rolle. Undersøkelsen avgrenser hvilke opplysninger som var tilgjengelige og hvilke som faktisk ble hentet ut.
Teamet sikrer et nødvendig utvalg av loggene, begrenser kontoen og dokumenterer tidslinjen. Deretter vurderes om hendelsen er et brudd på personopplysningssikkerheten og om melding er nødvendig. Dette følger virksomhetens rutine for avviksbehandling. At en eksport er uvanlig, avgjør ikke alene om det foreligger et meldepliktig brudd.
Verifiser at loggingen virker etter endringer
Gjennomfør en kontrollert, ufarlig hendelse med tillatelse fra systemeier. Bekreft at den vises med riktig aktør, tid og resultat, at en autorisert person finner den, og at uvedkommende ikke får tilgang. Følg også dataene frem til sletting der dette kan gjøres på et egnet kontrollutvalg. Dokumenter hva kontrollen omfattet.
Gjenta relevante kontroller når en tjeneste bytter versjon, en integrasjon endres eller tilgangsmodellen justeres. En kilde som tidligere leverte hendelser, kan slutte å gjøre det uten at selve applikasjonen feiler. Et enkelt kontrollvarsel om manglende data kan derfor være like viktig som avansert analyse av det som kommer inn.
Forankre rutinen og følg kostnadene
Knytt loggrutinen til informasjonssikkerhetspolicyen, slik at ansvar og unntak behandles konsekvent. Beregn både lagringskostnad og tiden som går til å undersøke varsler. Større datamengde kan gi mer arbeid uten at de viktigste spørsmålene blir lettere å besvare. Prioriter dokumentert nytte fremfor antall innsamlede hendelser.
Ved neste gjennomgang bør dere kunne vise hvilke spørsmål loggene hjalp med å besvare, hvilke mangler som ble funnet og hvilke datakategorier som ble fjernet. Det gir et konkret grunnlag for å endre innsamling og oppbevaring. Målet er en loggflyt som støtter undersøkelser og samtidig begrenser eksponering av personopplysninger.
Avklar eksport til eksterne undersøkere
Hvis en ekstern rådgiver skal analysere hendelsen, må dere velge et nødvendig utvalg og avklare vedkommendes rolle. Eksporter bare feltene som trengs for oppdraget, bruk en godkjent overføringskanal og angi hvem som kan motta materialet. Dokumenter hva som ble sendt, uten å lage en ny ukontrollert kopi av hele logginnholdet. Avtal hvordan arbeidskopier og analyser håndteres når oppdraget avsluttes. En konsulentrapport kan inneholde de samme personopplysningene som råloggene og må omfattes av tilgangs- og oppbevaringsvurderingen.