Kort sagt: God krisekommunikation efter et cyberangreb er hurtig, ærlig og ensartet. Informér først internt, derefter de berørte og partnere, og sig kun, hvad der er sikkert, klart adskilt fra det, der stadig undersøges. Pligter til underretning, f.eks. efter art. 34 GDPR, skal afstemmes med databeskyttelsesrådgiveren og juridisk rådgivning; denne side er ingen juridisk rådgivning.
Hvorfor kommunikation er en del af hændelseshåndteringen
Et angreb på en webserver er først og fremmest et teknisk problem. Meget hurtigt bliver det dog også et spørgsmål om tillid: Kunder bemærker et utilgængeligt website, partnere modtager påfaldende mails, medarbejdere spørger. Den, der så tier eller svarer modstridende, mister mere tillid, end selve hændelsen koster.
Den aktuelle situation omkring PHP2Shell gør det håndgribeligt. Mange virksomheder har forebyggende taget deres websites offline eller kortvarigt vedligeholdt dem. Det betyder ikke automatisk, at de er blevet hacket. Netop denne forskel bør I kunne forklare klart og roligt udadtil.
Krisekommunikation efter cyberangreb: den rette rækkefølge
En gennemprøvet rækkefølge forhindrer, at vigtige grupper hører det fra pressen eller fra tredjeparter:
- Kriseteam internt: ledelse, teknik, databeskyttelse, eventuelt juridisk rådgivning og forsikringsselskab. Her afgøres, hvad der siges.
- Medarbejdere: kort intern information med anmodning om at videresende henvendelser til den udpegede instans, og henvisninger til forsigtighed ved mistænkelige mails.
- Myndigheder, hvor det er nødvendigt: f.eks. databeskyttelsestilsynet efter art. 33 GDPR, BSI (det tyske forbundsagentur for informationssikkerhed) ved NIS2-pligt, politiet ved anmeldelse. Rækkefølgen afstemmer I med jeres juridiske rådgivning.
- Berørte kunder og partnere: direkte og om muligt før en offentlig erklæring.
- Offentligheden: henvisning på websitet, eventuelt pressemeddelelse.
Efter art. 34 GDPR skal de berørte underrettes uden unødig forsinkelse, når et brud på databeskyttelsen sandsynligvis indebærer en høj risiko for dem. Grundtrækkene forklarer GDPR-anmeldelsespligt: 72 timer.
Hvad der hører med i en meddelelse
En god meddelelse er kort og besvarer de spørgsmål, som de berørte stiller sig. Denne opbygning har vist sig at fungere:
| Afsnit | Indhold |
|---|---|
| Hvad er sket? | Saglig beskrivelse i enkle ord, med tidsrum |
| Hvad ved vi, hvad ved vi ikke? | Sikre fakta adskilt fra igangværende undersøgelse |
| Hvem er berørt? | Grupper af personer eller data, så vidt kendt |
| Hvad har vi gjort? | Akutforanstaltninger, inddragelse af fagfolk og myndigheder |
| Hvad bør I gøre? | Konkrete anbefalinger, f.eks. skifte adgangskode, være på vagt over for phishing |
| Hvordan når I os? | Fast kontaktpunkt til opfølgende spørgsmål |
Meddel, hvornår I informerer igen, og hold dette tilsagn. Også et „ingen nye erkendelser endnu“ på det annoncerede tidspunkt skaber tillid.
Forbered skabeloner til intern information, kundemeddelelse og website-henvisning, før der sker noget. I et alvorligt tilfælde skal så kun fakta indsættes.
Hvad I bedre kan undgå
Nogle formuleringer og adfærdsmønstre skader regelmæssigt:
- Forhastet afblæsning: „Der er ikke udtrukket data“ er kun tilladt, hvis det er dokumenteret. En indspillet patch beviser ikke, at intet er sket før.
- Bagatellisering: Begreber som „lille teknisk mellemfald“ virker uærlige, hvis der senere bliver kendt mere.
- Bebrejdelser: Henvisninger til hostingudbydere, tjenesteudbydere eller producenter hjælper ikke de berørte og kan have retlige følger.
- Tekniske detaljer med nytte for angribere: Konkrete sårbarheder i jeres systemer hører ikke hjemme i offentlige meddelelser.
- Garantier: Udsagn som „fuldstændig sikker“ eller „uhackbar“ kan ikke holdes.
Website, søgemaskiner og phishing-bølge
Efter et angreb på et website kommer der ofte to ledsagefænomener til. For det første kan Google vise en advarsel, hvis der er fundet skadelig kode; hvordan I får den fjernet efter oprydningen, står under Fjern Google-advarslen. For det andet bruger svindlere kendte hændelser til falske mails i den berørte virksomheds navn. Advar aktivt jeres kunder mod det, og nævn, via hvilke veje I faktisk kommunikerer.
Tager I websitet forebyggende offline, er en enkel statisk side med en kort henvisning og en kontaktvej, der ikke afhænger af den berørte server, tilstrækkelig.
Er hændelsen afsluttet, kan det betale sig med en afsluttende meddelelse til alle, I tidligere har informeret: hvad undersøgelsen har vist, hvilke foranstaltninger der er gennemført varigt, og hvem man fortsat kan henvende sig til. Mange virksomheder springer dette trin over, fordi presset aftager. Netop det viser dog, at I har taget hændelsen alvorligt. Evaluér desuden internt, hvad der gik godt i kommunikationen, og hvad der ikke gjorde, og tilpas skabeloner og ansvarsområder i jeres nødplan tilsvarende.
Hvordan hjælper PHP SOS konkret?
- Vi leverer de tekniske fakta forståeligt tilrettelagt og adskiller klart mellem dokumenteret, sandsynligt og ukendt.
- Vi gennemgår udkast til jeres meddelelser for teknisk rigtighed og for detaljer, som kunne hjælpe angribere.
- Vi stiller kortfristet en statisk vedligeholdelsesside til rådighed, som kører uafhængigt af det berørte system.
- Via incident response holder vi teknikken i takt med jeres kommunikation, så tilsagn om informationsstatus kan overholdes.
Ofte stillede spørgsmål
Skal vi gøre et angreb offentligt, mens ikke alt endnu er klart?
Det afhænger af situation, pligter og de berørte. Ofte er en kort, saglig meddelelse med den kendte status bedre end tavshed, fordi kunder og partnere ellers hører det fra andre kilder. Afstem tidspunktet med juridisk rådgivning og forsikringsselskab.
Hvad bør under ingen omstændigheder stå i en kundemeddelelse?
Formodninger, der fremstår som kendsgerninger, bebrejdelser mod tredjeparter, tekniske detaljer, som hjælper angribere, og tilsagn, som I ikke sikkert kan holde. Formuleringer som fuldstændig udelukket bør I kun bruge, hvis de er dokumenteret.
Hvem bør tale udadtil?
En udpeget person, oftest fra ledelsen eller virksomhedskommunikationen, understøttet af teknik og juridisk rådgivning. Alle andre henviser til denne instans. Så forbliver udsagnene ensartede.
Skal vi tage vores website offline og forklare det?
Tager I websitet forebyggende af nettet, hjælper en kort meddelelse, f.eks. på en statisk vedligeholdelsesside. Den behøver ikke være teknisk. At tage noget forebyggende offline betyder ikke automatisk, at et angreb lykkedes.