Den sværeste del af en sikkerhedshændelse opstår normalt, efter selve hændelsen er overstået: når virksomheden skal forklare, hvad der skete, hvornår det blev opdaget, hvilke data der var involveret, hvem der blev påvirket, og hvorfor visse beslutninger blev truffet.
For mange SMV’er findes disse registreringer ikke i en komplet form. Detaljer kan være spredt ud over chatbeskeder, indbakker, helpdesk-tickets, skærmfotos og i teammedlemmers erindringer. Virksomheder klarer sig gennem en hændelse med disse lappede registreringer, men de bliver et problem, når en tilsynsmyndighed, et forsikringsselskab, en kunde eller et bestyrelsesmedlem beder om en klar tidslinje.
Virksomheder i alle størrelser har brug for en grundig sikkerhedshændelseslog. Den bør være en enkelt kilde til sandhed til at registrere, hvad der skete, hvordan hændelsen blev håndteret, og hvilke beviser der understøtter de beslutninger, der blev truffet undervejs.
Registreringen er værdifuld, selv når du ikke behøver at rapportere en hændelse. Vi forklarer, hvorfor sikkerhedshændelseslogge er nyttige for din virksomhed, og hvordan du opretter dine egne.
Hvorfor sikkerhedshændelseslogge er vigtige
Hændelseslogge vs. hændelsesresponsplaner
Hvad en sikkerhedshændelseslog bør indeholde
En enkel skabelon til hændelseslog for SMV’er
Sådan registrerer du underretningsbeslutninger
Hvad tilsynsmyndigheder forventer af sikkerhedshændelseslogge
Loggen over adgang med legitimationsoplysninger
Hvorfor sikkerhedshændelseslogge er vigtige
Sikkerhedshændelseslogge skaber ansvarlighed på det tidspunkt, hvor en virksomhed har størst risiko for at miste overblikket over detaljer. Under en hændelse sker handlinger hurtigt: adgangskoder nulstilles, konti deaktiveres, IT-leverandører kontaktes, kundedata kontrolleres, og ledelsen orienteres. Disse trin kan være præcis, hvad virksomheden har brug for i øjeblikket, men de bliver meget sværere at forklare senere, hvis ingen registrerer, hvornår hver handling skete, hvem der godkendte den, og hvilke beviser der understøttede beslutningen.
For virksomheder med base i Europa er dette ikke bare god praksis. I henhold til General Data Protection Regulation (GDPR), både i Storbritannien og EU, skal brud på personoplysninger vurderes, og nogle skal indberettes til den relevante tilsynsmyndighed.
I Storbritannien forklarer ICO’s indberet et brud(nyt vindue)-vejledning, at organisationer skal vurdere den sandsynlige risiko for folks rettigheder og friheder og underrette ICO, når denne risiko er sandsynlig. Artikel 33 kræver også, at dataansvarlige dokumenterer brud på personoplysninger, herunder faktuelle forhold omkring bruddet, dets konsekvenser og de afhjælpende foranstaltninger, der er truffet. De samme krav gælder i henhold til EU’s GDPR.
For eksempel forventer ICO ikke, at enhver SMV har systemer i enterprise-klasse, men den forventer passende registreringer. Dens rammeværk for brudhåndtering og overvågning siger, at organisationer bør have procedurer til at sikre, at hændelser og brud på personoplysninger opdages, håndteres og registreres korrekt. Det betyder, at en hændelseslog ikke kun bør oprettes, når et alvorligt brud allerede er sket. Den bør være en del af den normale responsproces.
Gode registreringer understøtter også forsikringskrav. Cyberforsikringsselskaber kan bede om beviser for, hvornår hændelsen blev opdaget, hvilke inddæmningstrin der blev taget, hvilke konti der var berørt, og om virksomheden fulgte sin hændelsesresponsproces. En velholdt log kan vise, at virksomheden handlede hurtigt og konsekvent.
Det hjælper også virksomheden med at lære. Erindringer og mundtlige optegnelser er ikke pålidelige, men en registrering, der viser, at hændelsen begyndte med en genbrugt adgangskode, manglende multifaktorgodkendelse (MFA), leverandøradgang eller forsinket offboarding, giver virksomheden noget konkret at rette op på og en klarere retning for at styrke sikkerheden over tid.
Hændelseslogge vs. hændelsesresponsplaner
En sikkerhedshændelseslog og en hændelsesresponsplan er forbundet, men de er ikke det samme dokument.
En hændelsesresponsplan forklarer, hvad virksomheden bør gøre, når noget går galt. Den tildeler roller, eskaleringsveje, inddæmningstrin, kommunikationsansvar og gendannelsesprocedurer. Hændelsesloggen registrerer, hvad der faktisk skete. Det er tidslinjen, sporet af beviser, beslutningsregistreringen og opfølgningsfilen for en specifik begivenhed.
Den forskel er vigtig, fordi selv en god plan kan fejle uden dokumentation. En virksomhed kan følge de rigtige trin, men stadig have svært ved at bevise det senere. Loggen bør gøre det muligt at besvare praktiske spørgsmål: hvornår vidste vi det, hvem handlede, hvad inddæmmede vi, hvilke data var i fare, hvad besluttede vi, og hvad ændrede sig bagefter?
| Hændelsesresponsplan: Hvad din virksomhed bør gøre | Sikkerhedshændelseslog: Hvad der faktisk skete |
| Hvem leder responsen Hvem kontakter IT, juridisk, forsikringsselskab eller tilsynsmyndigheder Hvordan man inddæmmer, gendanner og kommunikerer | Hvornår hændelsen blev opdaget Hvilke systemer og data blev berørt Hvilke handlinger blev taget, af hvem og hvornår |
Hvad en sikkerhedshændelseslog bør indeholde
En brugbar hændelseslog skal være konsistent nok til, at en virksomhed kan rekonstruere begivenheden senere og forklare de beslutninger, der blev truffet under responsen.
Dato og tidspunkt for opdagelse
Registrer, hvornår virksomheden første gang blev opmærksom på hændelsen, hvem der bemærkede den, og hvordan den blev opdaget. Hvis tidspunktet er omtrentligt, skal det markeres som omtrentligt. Opdagelsestidspunktet er vigtigt, fordi GDPR’s indberetningsfrister og forsikringskrav ofte afhænger af, hvornår virksomheden blev opmærksom på problemet.
Hændelsens art
Beskriv, hvad der skete, i et klart sprog. Undgå vage betegnelser som ”sikkerhedsproblem” eller ”muligt databrud” uden kontekst. Loggen bør forklare, hvilke systemer der blev berørt, og om hændelsen involverede legitimationsoplysninger, e-mail, filer, kundedata, betalingssystemer, endepunkter eller tredjepartsadgang.
Involverede data
Hvis personoplysninger kan være blevet berørt, skal du registrere, hvilken type data der var involveret: navne, e-mailadresser, telefonnumre, adresser, kontodetaljer, finansielle oplysninger, medarbejderregistreringer, kundekommunikation, loginoplysninger eller enhver anden relevant kategori. Anslå, hvor mange personer der kan være berørt, og gør det klart, om antallet er bekræftet eller stadig er under undersøgelse.
Sandsynlig årsag
Registrer den kendte eller formodede årsag, selv om undersøgelsen stadig er i gang. Efterhånden som nye detaljer dukker op, kan loggen opdateres fra ”årsag ukendt” til ”phishing-e-mail førte til kompromittering af legitimationsoplysninger” eller ”tidligere entreprenørkonto forblev aktiv”. Loggen bør vise, hvordan virksomhedens forståelse ændrede sig over tid.
Øjeblikkelige inddæmningshandlinger
Dokumentér, hvad der blev gjort for at begrænse skaden. Dette kan omfatte nulstilling af adgangskoder, tilbagekaldelse af sessioner, håndhævelse af MFA, kontosuspension, fjernelse af postkasseregler, enhedsisolering, fjernelse af leverandøradgang, ændringer i firewall eller midlertidig nedlukning af tjenester. Medtag om muligt ejeren og tidsstemplet for hver handling.
Underretningsbeslutninger
Registrer, om virksomheden underrettede den relevante tilsynsmyndighed (ICO i Storbritannien eller den nationale databeskyttelsesmyndighed i resten af EU), berørte personer, kunder, leverandører, forsikringsselskaber, juridiske rådgivere eller retshåndhævende myndigheder. Hvis beslutningen var ikke at underrette, skal begrundelsen dokumenteres. Den forklaring er ofte lige så vigtig som selve underretningen.
Afhjælpningstrin og tidslinje
Inddæmning håndterer den umiddelbare hændelse. Afhjælpning reducerer risikoen for, at det samme problem opstår igen. Registrer opfølgende handlinger såsom at håndhæve MFA, fjerne delte legitimationsoplysninger, opdatere adgangspolitikker, forbedre offboarding, rette en fejlkonfiguration eller ændre, hvordan sikkerhedskopier beskyttes.
Erfaringer
Afslut med, hvad virksomheden lærte, og hvad der vil ændre sig. Dette bør ikke skrives som en bebrejdelse. Det bør identificere svagheden, den nødvendige forbedring, og hvem der ejer opfølgningen.
En enkel skabelon til hændelseslog for SMV’er
Specialiseret software er ikke nødvendig for at dokumentere hændelser. Et regneark, en sikker intern formular, et ticketsystem eller et delt register kan fungere, hvis adgangen er kontrolleret, og registreringerne holdes konsistente.
En effektiv hændelseslog bør indeholde disse felter:
- Hændelses-ID: Et unikt referencenummer.
- Dato og tidspunkt for opdagelse: Hvornår virksomheden blev opmærksom på hændelsen.
- Rapporteret af: Medarbejder, leverandør, kunde, underleverandør, overvågningsalarm eller ekstern part
- Hændelsestype: Phishing, malware, kompromittering af legitimationsoplysninger, datatab, uautoriseret adgang, ransomware, leverandørhændelse, tab af enhed, fejlsendt e-mail eller andet
- Resumé: Hvad der skete, skrevet i et letforståeligt sprog
- Berørte systemer: Involverede applikationer, konti, enheder, databaser, indbakker eller tredjepartstjenester
- Involverede data: Om personoplysninger blev berørt, hvilken type, og hvor mange personer der kan være påvirket
- Sandsynlig årsag: Kendt, mistænkt eller under undersøgelse
- Inddæmningshandlinger: Hvad der blev gjort med det samme
- Notifikationsbeslutning: Tilsynsmyndighed, enkeltpersoner, kunder, forsikringsselskab eller ingen notifikation med begrundelse
- Bevislinks: Skærmfotos, sager, logs, e-mails, adgangsregistre, eksportfiler eller leverandørrapporter
- Afhjælpningshandlinger: Trin taget efter inddæmning
- Ansvarlig: Person ansvarlig for opfølgning
- Status: Åben, overvågning, inddæmmet, løst, lukket
- Erfaringer: Hvad der bør ændres
Sådan registrerer du notifikationsbeslutninger
Notifikationsbeslutninger bør have deres egen plads i en sikkerhedshændelseslog, fordi de ofte gennemgås efter hændelsen.
I henhold til både britisk og EU’s GDPR skal organisationer vurdere den sandsynlige risiko for folks rettigheder og friheder, når et databrud med personoplysninger opstår. Hvis risikoen er sandsynlig, skal tilsynsmyndigheden underrettes hurtigst muligt og, hvor det er muligt, inden for 72 timer, ICO(nyt vindue) i Storbritannien, den nationale databeskyttelsesmyndighed i hver EU-medlemsstat. Hvis risikoen er høj, skal berørte personer også underrettes uden unødig forsinkelse. Tærsklerne og uret er de samme på begge sider; Kun myndigheden ændrer sig.
En god hændelseslog bør vise, at virksomheden foretog denne vurdering. Den bør registrere, om personoplysninger var involveret, hvilken form for skade der kunne opstå, hvilke beskyttelsesforanstaltninger der var på plads, og hvorfor virksomheden besluttede at indberette eller ikke indberette.
For eksempel kan en hændelse med en eksponeret admin-adgangskode ikke umiddelbart afsløre, om der blev opnået adgang til personoplysninger. Loggen bør afspejle denne usikkerhed. Den kan registrere den indledende bekymring, undersøgelsestrinene, gennemgangen af kontoaktivitet og den endelige konklusion, når beviserne er tilgængelige.
På dette tidspunkt i processen fokuserer mange virksomheder på at organisere den tekniske løsning og glemmer at registrere overensstemmelsesbegrundelsen. Adgangskoder nulstilles, konti sikres, og driften fortsætter. Uger senere kan virksomheden ikke forklare, hvorfor den besluttede, at hændelsen ikke var indberetningspligtig.
Hvad tilsynsmyndigheder forventer af registreringer
Tilsynsmyndigheder ser ikke kun på, om et databrud blev indberettet. De kan også spørge, hvordan virksomheden:
- Identificerede hændelsen
- Vurderede risikoen
- Besluttede, om notifikation var påkrævet
- Dokumenterede de udførte handlinger
En god registrering bør gøre historien om hændelsen klar fra start til slut. Den bør vise, hvad der skete, hvilke personoplysninger der var involveret, hvilken skade der kunne opstå, hvad virksomheden gjorde for at inddæmme problemet, og hvorfor den indberettede eller ikke indberettede databruddet.
Detaljeringsgraden bør matche alvoren af hændelsen. En fejlsendt e-mail har ikke brug for den samme registrering som et ransomwareangreb, men den skal stadig dokumenteres for at vise, at virksomheden vurderede den korrekt.
Disse registreringer bør også opbevares sikkert. Hændelseslogge kan indeholde følsomme detaljer om berørte personer, eksponerede systemer, medarbejderhandlinger, skærmfotos, adgangslogge eller afhjælpningstrin. Adgang bør begrænses til de personer, der har behov for det, og opbevaringen bør være i overensstemmelse med virksomhedens overordnede politik for dataopbevaring.
Adgangsloggen for legitimationsoplysninger
Mange hændelser involverer legitimationsoplysninger: de kan udløses af en genbrugt adgangskode, delt konto, kompromitteret indbakke, eksponeret admin-login, mistænkelig MFA-meddelelse eller en medarbejder, der ikke blev afmeldt korrekt.
Af den grund kan adgangsregistreringer for legitimationsoplysninger blive et direkte input til dokumentation af cybersikkerhedshændelser. Når en hændelse involverer et delt login eller en følsom konto, har virksomheden brug for at vide, hvem der havde adgang, hvordan adgangen blev delt, om tilladelser ændrede sig, og om legitimationsoplysningen blev roteret efter hændelsen.
En adgangskodeadministrator til virksomheder som Proton Pass for Business hjælper teams med at administrere legitimationsoplysninger i krypterede bokse, generere unikke adgangskoder, bruge autofyld, dele legitimationsoplysninger sikkert, administrere adgangsnøgler og bruge indbygget tofaktorgodkendelse. For dokumentation af hændelser er den stærkeste værdi adgangssporet for legitimationsoplysninger: hvem havde adgang til delte bokse/konti, hvordan adgangen blev administreret, og hvem der brugte den, og hvad der ændrede sig efter hændelsen.
En adgangskodeadministrator til IT-teams tilføjer admin-funktioner som politikker, rapportering, logs, rollebaseret adgangskontrol, SCIM-provisionering og SSO-integration. Disse funktioner kan hjælpe virksomheder med at vise, hvordan adgang til legitimationsoplysninger styres, og give beviser, når en hændelse relateret til legitimationsoplysninger undersøges.
En adgangskodeadministrator kan ikke erstatte en hændelseslog, juridisk vurdering, regulatorisk notifikationsproces eller beredskabsplan for hændelser. Men den leverer beviser for legitimationsoplysninger, der kan indgå i disse processer.
Hold et komplet revisionsspor over adgang til legitimationsoplysninger med en adgangskodeadministrator til virksomheder.
