I de første timene av en sikkerhetshendelse kan du ikke danne et fullstendig teknisk bilde av hva som har skjedd. Teamet ditt prøver kanskje fortsatt å forstå hvilken konto som ble kompromittert, hvilke data som ble aksessert, hvor langt angriperen kom, eller om hendelsen fortsatt er aktiv.
Samtidig som du etterforsker, begynner presset på å handle umiddelbart. Ansatte hører fragmenter og trenger å vite hva de skal gjøre. I mellomtiden kan kunder oppdage tjenesteavbrudd, mistenkelig aktivitet eller uvanlige forespørsler om tilbakestilling av passord. Forretningspartnere kan spørre om deres systemer eller data er involvert, og ledelsen må bestemme hvem som snakker, hva som kan bekreftes, og når stillhet blir en risiko i seg selv.
Kommunikasjon under en sikkerhetshendelse er vanskelig fordi en virksomhet må være åpen før den har alle svar, men informert nok til ikke å gjette. Kommunikasjon som sendes for tidlig kan skape forvirring, men hvis den sendes for sent kan den skade tilliten, bremse beskyttende handlinger og reise regulatoriske spørsmål.
Det er usannsynlig at små og mellomstore bedrifter har opprettet eller øvd på planen for hendelsesrespons, og dette kan føre til ekstra kaos. Selv for større bedrifter med en plan kan de tekniske trinnene være dokumentert: begrense hendelsen, tilbakestille tilgang, bevare bevis, gjenopprette systemer. Kommunikasjon kan bli utsatt til senere, helt til hendelsen plutselig eskalerer eller endrer seg.
En del av å forberede seg på en hendelse er å vite hvem som trenger å høre fra deg, hva de trenger å vite, hvem som godkjenner meldingen, og hvordan du kommuniserer fakta tydelig mens etterforskningen fortsatt pågår.
Kommunikasjonsplanlegging hører til i hendelsesrespons
To-sporsstrukturen for responsen din
Start med målgruppen, ikke kunngjøringen
Hva du bør kommunisere internt
Hvordan varsle kunder om et brudd
Når du bør varsle tilsynsmyndigheter
Forbered meldinger før du trenger dem
Hvordan Proton Pass for Business kan hjelpe
Kommunikasjonsplanlegging hører til i hendelsesrespons
Hendelsesrespons blir ofte beskrevet som en teknisk prosess, men en reell hendelse blir raskt tverrfaglig. IT-team kan begrense trusselen, men ledelsen, juridiske, kundestøtte, HR, kommunikasjon og drift trenger alle å vite hva som skjer og hva de har lov til å si.
NCSCs veiledning om effektiv kommunikasjon under en cyberhendelse(nytt vindu) — generell beste praksis som gjelder langt utenfor Storbritannia — understreker dette tydelig: organisasjoner prioriterer ofte teknisk respons og skyver kommunikasjon i bakgrunnen, selv om kommunikasjon former hvordan ansatte, kunder, interessenter og mediene oppfatter organisasjonen under en krise.
Ikke alle hendelser trenger en offentlig uttalelse. Men virksomheten bør vite på forhånd hvem som bestemmer hva som skal kommuniseres, hvem som godkjenner eksterne meldinger, hvem som snakker med kunder, og hvem som håndterer regulatorisk rapportering.
En robust plan for håndtering av databrudd må inkludere et kommunikasjonslag. Dette bør inneholde praktiske detaljer:
- Kontaktlister
- Utkastmaler
- Godkjenningsruter
- Juridisk gjennomgang
- Talepunkter for kundestøtte
- Ansvarsområder for varsling av tilsynsmyndigheter
- Oversikt over hva som ble sendt, når og til hvem.
To-sporsstrukturen for responsen din
Hendelsesrespons trenger to spor: teknisk respons og kommunikasjonsrespons. De går parallelt, og hendelseslederen/responseieren kobler dem sammen.
| Venstre spor: Teknisk respons | Høyre spor: Kommunikasjonsrespons |
| Begrens hendelsen | Oppdater det interne teamet |
| Sikre berørte kontoer | Varsle berørte kunder eller partnere |
| Bevar bevis | Vurder varsling til tilsynsmyndigheter |
| Gjenopprett systemer | Hold meldinger konsistente når fakta endrer seg |
Dette lar deg strukturere responsen din og sikre at samarbeidet fortsetter når teammedlemmer påtar seg ulike oppgaver.
Start med målgruppen, ikke kunngjøringen
Kommunikasjon under en sikkerhetshendelse mislykkes når én melding prøver å tjene alle. Ansatte, kunder, partnere og tilsynsmyndigheter trenger ulike detaljnivåer fordi de har ulike beslutninger å ta.
Ditt interne team trenger klarhet først
De trenger ikke hver detalj — spesielt mens etterforskningen pågår — men de trenger klarhet i hva som er bekreftet, hva de skal gjøre nå, og hvem som leder responsen. Det betyr å vite hvilke systemer eller kontoer som skal unngås, hvilke handlinger som skal utføres umiddelbart, og hvilke spørsmål som fortsatt er åpne.
Ansatte trenger også å vite hva de ikke skal gjøre. For eksempel:
- Ikke diskuter hendelsen offentlig
- Ikke tilbakestill påloggingsinformasjon utenfor den godkjente prosessen
- Ikke kontakt kunder med improviserte forklaringer
- Ikke videresend mistenkelige meldinger uten veiledning.
Kunder og partnere trenger å vite hvordan de blir berørt
De vil vite om dataene, tilgangen, betalingene, tjenesten eller driften deres er berørt. Et godt kundevarsel bør forklare:
- Hva som er kjent
- hvilken type data kan være involvert
- hva virksomheten gjør
- hva kundene bør gjøre nå, om noe
- hvor de kan få oppdateringer
Tonelaget bør være enkelt og direkte. En kunde trenger heller ikke detaljer, de trenger bare nok informasjon til å beskytte seg selv.
Tilsynsmyndigheter trenger en faktabasert oversikt
Et GDPR-bruddvarsel til den relevante tilsynsmyndigheten (ICO(nytt vindu) i Storbritannia, den nasjonale datatilsynsmyndigheten i hver EU-medlemsstat) er ikke en markedsføringsmelding eller en beroligende melding til kunden. I stedet må det være en faktabasert oversikt over hva som skjedde, hvem som er berørt, og hva du gjør med det. Vi dekker nøyaktig hva som skal inkluderes i avsnittet om å varsle tilsynsmyndigheter nedenfor.
Hva som skal kommuniseres internt
Dine ansatte er en del av responsen, selv når de ikke er i hendelsesteamet. Et forvirret team kan ved uhell skape mer støy, dele unøyaktig informasjon eller bremse inneslutningen. På den annen side kan et godt informert team bidra til å beskytte kontoer, lede kunder til riktig kanal og unngå at spekulasjoner vokser.
En intern kunngjøring om sikkerhetshendelse bør dekke:
- en tøm oppsummering av hva som er bekreftet så langt, på klarspråk
- hvilke systemer, kontoer, team eller data kan være potensielt berørt
- hva virksomheten gjør nå
- hva ansatte bør gjøre umiddelbart
- hvem som har lov til å kommunisere eksternt
- hvor oppdateringer vil bli lagt ut
- hvordan rapportere relatert mistenkelig aktivitet
Det er aspekter som ikke bør inkluderes: angrepsvektorer, årsaksanalyse og spesifikke sårbarheter deles vanligvis ikke internt mens en hendelse er aktiv, og ofte heller ikke i etterkant, siden disse detaljene kan hjelpe andre angripere, skape juridisk eksponering eller avdekke hull som ennå ikke er lukket.
Den første interne meldingen trenger ikke å svare på alle spørsmål, den må skape orden. For eksempel kan ansatte måtte tilbakestille passord kun gjennom en godkjent prosess, unngå å bruke et spesifikt system, bevare mistenkelige e-poster eller slutte å bruke delt påloggingsinformasjon til responsteamet er ferdig med gjennomgangen.
Å vurdere dine eksisterende tilgangskontroller opp mot beste praksis for passordadministrasjon er også viktig. Under en hendelse kan utdatert eller uformell deling av påloggingsinformasjon gjøre det vanskeligere å forstå hva som ble eksponert.
Protons guider til databruddbeskyttelse og databruddforebygging for bedrifter forklarer hvordan lagdelte kontroller reduserer eksponering før et brudd oppstår. Sikker påloggingsadministrasjon er et av disse lagene fordi det hjelper virksomheten med å vite hvilke kontoer som finnes, hvem som har tilgang til dem, og hva som må endres raskt.
Hvordan varsle kunder om et brudd
Et databruddvarsel til kunder er vanskeligere fordi det har omdømmemessig og juridisk vekt. Folk kan være bekymret for identitetstyveri, kontoovertakelse, økonomisk svindel eller eksponering av private opplysninger. De kan også være frustrert over at selskapet ikke forhindret hendelsen.
En god kundemelding bør være ærlig uten å være alarmistisk. Den bør unngå teknisk sjargong, men være tøm. Kunder trenger å forstå hvilke data som var involvert, hvilken risiko det skaper, og hva de bør gjøre videre.
En nyttig struktur er:
- hva som skjedde, på et detaljnivå som passer for kunder
- når virksomheten ble klar over det
- hvilken informasjon eller hvilke tjenester som kan være berørt
- hvilke tiltak virksomheten har iverksatt
- hva kundene bør gjøre nå
- hvordan virksomheten vil gi oppdateringer
- hvem kundene kan kontakte med spørsmål
Hvor etterforskningen fortsatt er aktiv, bør dette opplyses om. Nøyaktighet og åpenhet bidrar til å gjenopprette tillit. Å være åpen om påvirkning krever ikke at man avslører tekniske detaljer som ville hjelpe noen med å gjenta angrepet.
For alvorlige hendelser kan kunder trenge praktiske instruksjoner: endre passord, aktivere MFA, se opp for nettfiskingse-poster, kontakte banken sin, og ignorere meldinger som hevder å være fra selskapet med mindre de kommer gjennom en offisiell kanal. Varselet bør gjøre disse trinnene enkle å forstå.
Når og hvordan varsle reguleringsmyndigheter
Ikke enhver sikkerhetshendelse trenger å rapporteres til tilsynsmyndighetene. Et rapporteringspliktig brudd under britisk og EU-GDPR avhenger av om et personopplysningsbrudd sannsynligvis vil resultere i en risiko for folks rettigheter og friheter.
ICOs veiledning for personopplysningsbrudd(nytt vindu) gjenspeiler et krav som er felles for både britisk og EU-GDPR: organisasjoner må rapportere et varslingspliktig brudd uten unødig forsinkelse og senest 72 timer etter at de ble klar over det. En sen rapport krever grunner for forsinkelsen.
Det 72-timers vinduet kan skape press, spesielt når etterforskningen fortsatt er ufullstendig. GDPR anerkjenner at organisasjoner kanskje ikke har alle detaljer innen de første 72 timene, så informasjon kan gis i faser, så lenge ytterligere oppdateringer gis uten unødig forsinkelse.
Et varsel til den relevante tilsynsmyndigheten (ICO i Storbritannia, eller den nasjonale datatilsynsmyndigheten i EU) bør vanligvis inkludere:
- personopplysningsbruddets art
- kategoriene og omtrentlig antall berørte personer
- kategoriene og omtrentlig antall berørte personopplysningsposter
- navn og kontaktdetaljer til personvernombudet (DPO) eller et annet kontaktpunkt
- sannsynlige konsekvenser av bruddet
- tiltakene som er tatt eller foreslått for å adressere det
ICO har også en sentral side for å rapportere et brudd(nytt vindu) og rute organisasjoner til riktig rapporteringsprosess.
For berørte personer er terskelen annerledes. Hvor et personopplysningsbrudd sannsynligvis vil resultere i høy risiko for folks rettigheter og friheter, må de informeres uten unødig forsinkelse. Dette er en situasjon der juridiske team, personvern-team og ledelsesteam bør involveres tidlig, selv i en liten bedrift.
Forbered meldinger før du trenger dem
Det verste tidspunktet å utforme en kommunikasjonsprosess på er under en hendelse. Det er ikke nyttig å komme med uttalelser eller veiledning som må oppdateres og endres.
Det er derfor det er nyttig å forberede strukturen til meldingene dine før du trenger dem. Ikke den endelige ordlyden, fordi hver hendelse vil være forskjellig, men strukturen: hvem som må godkjenne meldingen, hvilke detaljer som må inkluderes, hvor oppdateringer vil bli registrert, og hvem som er ansvarlig for hver målgruppe.
Et enkelt kommunikasjonssett er nok til å gjøre den første timen mindre kaotisk. Det kan inneholde:
- En mal for intern hendelsesvarsling
- En mal for kundevarsel
- En mal for oppdatering til partnere eller leverandører
- Talepunkter for kundestøtte
- Sjekkliste for varsling til tilsynsmyndighet
- Liste over godkjente talspersoner
- Eskaleringskontakter for juridisk, IT, personvern, ledelse og kommunikasjon
- Et sted å registrere alle oppdateringer og beslutninger
Forberedelse gir et team et trygt utgangspunkt når både hastighet og nøyaktighet er viktig. En forberedt mal gir mer oppmerksomhet til fakta i hendelsen: hva som skjedde, hvem som er berørt, hva som allerede er gjort og hva folk må gjøre videre.
Hvordan Proton Pass for Business kan hjelpe
Kommunikasjon ved sikkerhetshendelser avhenger av fakta. Jo tydeligere en virksomhet administrerer tilgang før en hendelse, desto lettere er det å forklare hva som skjedde, hva som kan være berørt og hva som er endret.
En passordapp for bedrifter som Proton Pass for Business hjelper team med å redusere eksponering knyttet til påloggingsinformasjon. Ansatte kan generere sterke passord, lagre dem i krypterte passordhvelv, bruke autofyll, dele påloggingsinformasjon sikkert, administrere passnøkler og bruke innebygd tofaktorautentisering. Administratorer kan bruke passordretningslinjer, gjennomgå aktivitetslogger, administrere tilgang med rollebaserte kontroller og støtte provisjonering gjennom SCIM- og SSO-integrasjoner.
Under en hendelse kan disse funksjonene hjelpe virksomheter med å handle med større trygghet. Hvis en ansattkonto blir kompromittert, kan administratorer gjennomgå tilgang, identifisere delt påloggingsinformasjon som kan trenge rotasjon, håndheve sterkere autentisering og redusere avhengigheten av passord som er kopiert via chat eller regneark.
Vær klar til å reagere før et brudd skjer, med en passordapp for bedrifter.
