Den vanskeligste delen av en sikkerhetshendelse skjer vanligvis etter at selve hendelsen er over: når virksomheten må forklare hva som skjedde, når det ble oppdaget, hvilke data som var involvert, hvem som ble påvirket, og hvorfor visse beslutninger ble tatt.
For mange små og mellomstore bedrifter finnes ikke disse loggene i fullstendig form. Detaljer kan være spredt i chatmeldinger, innbokser, supportsaker, skjermbilder og i teammedlemmenes minner. Virksomheter holder hodet over vannet under en hendelse med disse lappede loggene, men de blir et problem når tilsynsmyndigheter, et forsikringsselskap, en kunde eller et styremedlem ber om en klar tidslinje.
Virksomheter i alle størrelser trenger en grundig sikkerhetshendelseslogg. Den bør være en enkelt kilde til sannhet for å registrere hva som skjedde, hvordan hendelsen ble håndtert, og hvilke bevis som støtter beslutningene som ble tatt underveis.
Loggen er verdifull selv når du ikke trenger å rapportere en hendelse. Vi skal forklare hvorfor sikkerhetshendelseslogger er nyttige for virksomheten din, og hvordan du lager dine egne.
Hvorfor sikkerhetshendelseslogger er viktige
Hendelseslogger vs. planer for hendelseshåndtering
Hva en sikkerhetshendelseslogg bør inneholde
En enkel mal for hendelseslogg for små og mellomstore bedrifter
Hvordan registrere varslingsbeslutninger
Hva tilsynsmyndigheter forventer av sikkerhetshendelseslogger
Loggen for tilgang til påloggingsinformasjon
Hvorfor sikkerhetshendelseslogger er viktige
Sikkerhetshendelseslogger skaper ansvarlighet i det øyeblikket en virksomhet mest sannsynlig mister oversikten over detaljer. Under en hendelse skjer handlinger raskt: passord tilbakestilles, kontoer deaktiveres, IT-leverandører kontaktes, kundedata sjekkes, og ledelsen orienteres. Disse trinnene kan være akkurat det virksomheten trenger i øyeblikket, men de blir mye vanskeligere å forklare senere hvis ingen registrerer når hver handling skjedde, hvem som godkjente den, og hvilke bevis som støttet beslutningen.
For virksomheter basert i Europa er dette ikke bare god praksis. I henhold til personvernforordningen (GDPR), både i Storbritannia og EU, må personopplysningsbrudd vurderes, og noen må rapporteres til den aktuelle tilsynsmyndigheten.
I Storbritannia forklarer ICOs rapporter et brudd(nytt vindu)-veiledning at organisasjoner må vurdere den sannsynlige risikoen for folks rettigheter og friheter og varsle ICO når denne risikoen er sannsynlig. Artikkel 33 krever også at behandlingsansvarlige dokumenterer personopplysningsbrudd, inkludert fakta om bruddet, dets virkninger og iverksatte utbedringstiltak. De samme kravene gjelder under EUs GDPR.
For eksempel forventer ikke ICO at alle små og mellomstore bedrifter har systemer på bedriftsnivå, men de forventer passende opptegnelser. Deres rammeverk for bruddhåndtering og overvåking sier at organisasjoner bør ha prosedyrer for å sikre at personopplysningshendelser og -brudd oppdages, håndteres og registreres på riktig måte. Det betyr at en hendelseslogg ikke bare bør opprettes når et alvorlig brudd allerede har skjedd. Den bør være en del av den normale responsprosessen.
Gode opptegnelser støtter også forsikringskrav. Cyberforsikringsselskaper kan be om bevis for når hendelsen ble oppdaget, hvilke inneslutningstrinn som ble tatt, hvilke kontoer som ble påvirket, og om virksomheten fulgte sin prosess for hendelseshåndtering. En godt vedlikeholdt logg kan vise at virksomheten handlet raskt og konsekvent.
Det hjelper også selskapet å lære. Minner og muntlige opptegnelser er ikke pålitelige, men en opptegnelse som viser at hendelsen startet med et gjenbrukt passord, manglende flerfaktorautentisering (MFA), leverandørtilgang eller forsinket avslutning, gir virksomheten noe konkret å fikse og en klarere retning for å styrke sikkerheten over tid.
Hendelseslogger vs. planer for hendelseshåndtering
En sikkerhetshendelseslogg og en plan for hendelseshåndtering er knyttet sammen, men de er ikke det samme dokumentet.
En plan for hendelseshåndtering forklarer hva virksomheten bør gjøre når noe går galt. Den tildeler roller, eskaleringsruter, inneslutningstrinn, kommunikasjonsansvar og gjenopprettingsprosedyrer. Hendelsesloggen registrerer hva som faktisk skjedde. Den er tidslinjen, beviskjeden, beslutningsloggen og oppfølgingsfilen for en spesifikk hendelse.
Den forskjellen er viktig fordi selv en god plan kan mislykkes uten dokumentasjon. En virksomhet kan følge de riktige trinnene, men fortsatt slite med å bevise det senere. Loggen bør gjøre det mulig å svare på praktiske spørsmål: når visste vi det, hvem handlet, hva innesluttet vi, hvilke data var i fare, hva bestemte vi, og hva endret seg etterpå?
| Plan for hendelseshåndtering: hva virksomheten din bør gjøre | Sikkerhetshendelseslogg: hva som faktisk skjedde |
| Hvem leder responsen Hvem kontakter IT, juridiske rådgivere, forsikringsselskap eller tilsynsmyndigheter Hvordan inneslutte, gjenopprette og kommunisere | Når hendelsen ble oppdaget Hvilke systemer og data som ble påvirket Hvilke handlinger som ble utført, av hvem og når |
Hva en sikkerhetshendelseslogg bør inneholde
En nyttig hendelseslogg må være konsekvent nok til at en virksomhet kan rekonstruere hendelsen senere og forklare beslutningene som ble tatt under responsen.
Dato og tidspunkt for oppdagelse
Registrer når virksomheten først ble klar over hendelsen, hvem som oppdaget den, og hvordan den ble oppdaget. Hvis tidspunktet er omtrentlig, merk det som omtrentlig. Oppdagelsestidspunktet er viktig fordi GDPR-rapporteringsfrister og forsikringskrav ofte avhenger av når virksomheten ble klar over problemet.
Hendelsens art
Beskriv hva som skjedde i klartekst. Unngå vage etiketter som «sikkerhetsproblem» eller «mulig brudd» uten kontekst. Loggen bør forklare hvilke systemer som ble påvirket, og om hendelsen involverte påloggingsinformasjon, e-post, filer, kundedata, betalingssystemer, endepunkter eller tredjepartstilgang.
Involverte data
Hvis personopplysninger kan ha blitt påvirket, registrer hva slags data som var involvert: navn, e-postadresser, telefonnumre, adresser, kontodetaljer, finansiell informasjon, ansattopptegnelser, kundekommunikasjon, påloggingsinformasjon eller en hvilken som helst annen relevant kategori. Anslå hvor mange personer som kan være påvirket, og gjør det klart om antallet er bekreftet eller fortsatt under etterforskning.
Sannsynlig årsak
Registrer den kjente eller antatte årsaken, selv om etterforskningen fortsatt pågår. Etter hvert som nye detaljer kommer frem, kan loggen oppdateres fra «årsak ukjent» til «nettfisking-e-post førte til kompromittering av påloggingsinformasjon» eller «tidligere kontraktørkonto forble aktiv». Loggen bør vise hvordan virksomhetens forståelse endret seg over tid.
Umiddelbare inneslutningstiltak
Dokumenter hva som ble gjort for å begrense skaden. Dette kan omfatte tilbakestilling av passord, tilbakekalling av økter, håndheving av MFA, kontosuspensjon, fjerning av innboksregler, enhetsisolering, fjerning av leverandørtilgang, brannmur-endringer eller midlertidig nedstenging av tjenester. Der det er mulig, inkluder eier og tidsstempel for hver handling.
Varslingsbeslutninger
Registrer om virksomheten varslet den relevante tilsynsmyndigheten (ICO i Storbritannia, eller den nasjonale datatilsynsmyndigheten ellers i EU påvirkede enkeltpersoner, kunder, leverandører, forsikringsselskaper, juridiske rådgivere eller rettshåndhevelse. Hvis beslutningen var å ikke varsle, dokumenter begrunnelsen. Den forklaringen er ofte like viktig som selve varselet.
Utbedringstrinn og tidslinje
Inneslutning håndterer den umiddelbare hendelsen. Utbedring reduserer sjansen for at det samme problemet skjer igjen. Registrer oppfølgingshandlinger som å håndheve MFA, fjerne delt påloggingsinformasjon, oppdatere tilgangsretningslinjer, forbedre avslutning, rette en feilkonfigurasjon eller endre hvordan sikkerhetskopier beskyttes.
Lærdommer
Avslutt med hva virksomheten lærte, og hva som vil endres. Dette bør ikke skrives som skyld. Det bør identifisere svakheten, forbedringen som trengs, og hvem som eier oppfølgingen.
En enkel mal for hendelseslogg for små og mellomstore bedrifter
Spesialisert programvare er ikke nødvendig for å dokumentere hendelser. Et regneark, et sikkert internt skjema, et sakssystem eller et delt register kan fungere hvis tilgangen er kontrollert og oppføringene holdes konsekvente.
En effektiv hendelseslogg bør inneholde disse feltene:
- Hendelses-ID: Et unikt referansenummer.
- Dato og tidspunkt for oppdagelse: Når virksomheten ble klar over hendelsen.
- Rapportert av: ansatt, tjenesteleverandør, kunde, leverandør, overvåkingsvarsel eller ekstern part.
- Hendelsestype: nettfisking, skadelig programvare, kompromittering av påloggingsinformasjon, tap av data, uautorisert tilgang, løsepengevirus, leverandørhendelse, tap av enhet, e-post sendt til feil mottaker eller annet.
- Sammendrag: hva som skjedde, skrevet i klart språk.
- Berørte systemer: applikasjoner, kontoer, enheter, databaser, innbokser eller tredjepartstjenester som er involvert.
- Berørte data: om personopplysninger ble berørt, hvilken type og hvor mange personer som kan være berørt.
- Sannsynlig årsak: kjent, mistenkt eller under etterforskning.
- Inndemmende tiltak: hva som ble gjort umiddelbart.
- Varslingsbeslutning: tilsynsmyndighet, enkeltpersoner, kunder, forsikringsselskap eller ingen varsling med begrunnelse.
- Bevislenker: skjermbilder, saker, logger, e-poster, tilgangsregistre, eksportfiler eller leverandørrapporter.
- Utbedringstiltak: trinn som ble tatt etter inndemming.
- Ansvarlig: person som er ansvarlig for oppfølging.
- Status: åpen, overvåking, inndemmet, løst, lukket.
- Erfaringer: hva som bør endres.
Slik registrerer du varslingsbeslutninger
Varslingsbeslutninger fortjener sin egen plass i en sikkerhetshendelseslogg, fordi de ofte gjennomgås etter hendelsen.
Både under britisk og EU-GDPR må organisasjoner vurdere den sannsynlige risikoen for folks rettigheter og friheter når et personopplysningsbrudd inntreffer. Hvis risikoen er sannsynlig, må tilsynsmyndigheten varsles så snart som mulig og, der det er gjennomførbart, innen 72 timer, ICO(nytt vindu) i Storbritannia, den nasjonale datatilsynsmyndigheten i hver EU-medlemsstat. Hvis risikoen er høy, må også berørte enkeltpersoner varsles uten unødig forsinkelse. Tersklene og tidsfristen er de samme på begge sider; det er bare myndigheten som endres.
En god hendelseslogg bør vise at virksomheten gjorde denne vurderingen. Den bør registrere om personopplysninger var involvert, hva slags skade som kunne oppstå, hvilke beskyttelsestiltak som var på plass, og hvorfor virksomheten bestemte seg for å rapportere eller ikke rapportere.
For eksempel kan en hendelse med et eksponert administratorpassord ikke umiddelbart avsløre om personopplysninger var blitt aksessert. Loggen bør gjenspeile denne usikkerheten. Den kan registrere den opprinnelige bekymringen, etterforskningstrinnene, gjennomgangen av kontoaktivitet og den endelige konklusjonen når bevisene er tilgjengelige.
På dette tidspunktet i prosessen fokuserer mange virksomheter på å organisere den tekniske utbedringen og glemmer å registrere begrunnelsen for etterlevelse. Passord tilbakestilles, kontoer sikres og driften fortsetter. Uker senere kan ikke virksomheten forklare hvorfor den konkluderte med at hendelsen ikke var rapporteringspliktig.
Hva tilsynsmyndigheter forventer av dokumentasjon
Tilsynsmyndigheter ser ikke bare på om et brudd ble rapportert. De kan også spørre om hvordan virksomheten:
- identifiserte hendelsen
- vurderte risikoen
- bestemte om varsling var påkrevd
- dokumenterte tiltakene som ble gjort
En god registrering bør gjøre historien om hendelsen tydelig fra begynnelse til slutt. Den bør vise hva som skjedde, hvilke personopplysninger som var involvert, hvilken skade som kunne oppstå, hva virksomheten gjorde for å inndemme problemet, og hvorfor den rapporterte eller ikke rapporterte bruddet.
Detaljnivået bør samsvare med alvorlighetsgraden av hendelsen. En e-post sendt til feil mottaker trenger ikke samme registrering som et løsepengevirusangrep, men det må likevel dokumenteres for å vise at virksomheten vurderte det på riktig måte.
Disse registreringene bør også lagres sikkert. Hendelseslogger kan inneholde sensitive detaljer om berørte enkeltpersoner, eksponerte systemer, ansattes handlinger, skjermbilder, tilgangslogger eller utbedringstrinn. Tilgangen bør begrenses til personene som trenger den, og oppbevaringen bør samsvare med selskapets overordnede retningslinje for dataoppbevaring.
Loggen over tilgang til påloggingsinformasjon
Mange hendelser involverer påloggingsinformasjon: de kan utløses av et gjenbrukt passord, en delt konto, en kompromittert innboks, en eksponert administratorpålogging, en mistenkelig MFA-forespørsel eller en ansatt som ikke ble avsluttet på riktig måte.
Av den grunn kan tilgangsregistre for påloggingsinformasjon bli en direkte inndata til dokumentasjon av cybersikkerhetshendelser. Når en hendelse involverer en delt pålogging eller en sensitiv konto, trenger virksomheten å vite hvem som hadde tilgang, hvordan tilgangen ble delt, om tillatelsene ble endret, og om påloggingsinformasjonen ble rotert etter hendelsen.
En passordapp for bedrifter som Proton Pass for Business hjelper team med å administrere påloggingsinformasjon i krypterte hvelv, generere unike passord, bruke autofyll, dele påloggingsinformasjon sikkert, administrere passnøkler og bruke innebygd tofaktorautentisering. For hendelsesdokumentasjon er den sterkeste verdien sporet av tilgang rundt påloggingsinformasjon: hvem som hadde tilgang til delte hvelv/kontoer, hvordan tilgangen ble administrert og hvem som brukte den, og hva som endret seg etter hendelsen.
En passordapp for IT-team tilfører administratorfunksjoner som retningslinjer, rapportering, logger, rollebasert tilgangskontroll, SCIM-provisjonering og SSO-integrasjon. Disse funksjonene kan hjelpe virksomheter med å vise hvordan tilgang til påloggingsinformasjon kontrolleres, og gi bevis når en hendelse knyttet til påloggingsinformasjon etterforskes.
En passordapp kan ikke erstatte en hendelseslogg, en juridisk vurdering, en prosess for regulatorisk varsling eller en plan for hendelseshåndtering. Men den gir bevis knyttet til påloggingsinformasjon som kan inngå i disse prosessene.
Hold et fullstendig revisjonsspor over tilgang til påloggingsinformasjon med en passordapp for bedrifter.
