Kort sagt: God kriskommunikation efter ett cyberangrepp är snabb, ärlig och enhetlig. Informera först internt, därefter berörda och partner, och säg bara det som är säkerställt, tydligt skilt från det som fortfarande undersöks. Skyldigheter att underrätta, till exempel enligt art. 34 GDPR, ska samrådas med dataskyddsombud och juridisk rådgivning; den här sidan är ingen juridisk rådgivning.
Varför kommunikation är en del av incidenthanteringen
Ett angrepp mot en webbserver är först ett tekniskt problem. Mycket snabbt blir det också en förtroendefråga: kunder märker en webbplats som inte går att nå, partner får avvikande mejl, medarbetare ställer frågor. Den som då tiger eller svarar motstridigt förlorar mer förtroende än av själva incidenten.
Det aktuella läget kring PHP2Shell gör det konkret. Många företag har förebyggande tagit sina webbplatser offline eller underhållit dem med kort varsel. Det betyder inte automatiskt att de har blivit hackade. Just den skillnaden bör ni kunna förklara tydligt och lugnt utåt.
Kriskommunikation efter cyberangrepp: rätt ordningsföljd
En beprövad ordningsföljd förhindrar att viktiga grupper får veta det via pressen eller från tredje part:
- Krisgrupp internt: ledning, teknik, dataskydd, i förekommande fall juridisk rådgivning och försäkringsgivare. Här beslutas vad som sägs.
- Medarbetare: kort intern information med uppmaning att vidarebefordra förfrågningar till den utsedda kontaktpunkten och med anvisningar om försiktighet med misstänkta mejl.
- Myndigheter där det behövs: till exempel dataskyddstillsynen enligt art. 33 GDPR, BSI (den tyska förbundsmyndigheten för informationssäkerhet) vid NIS2-plikt, polisen vid anmälan. Ordningsföljden samråder ni med er juridiska rådgivning.
- Berörda kunder och partner: direkt och om möjligt före ett offentligt uttalande.
- Allmänheten: information på webbplatsen, i förekommande fall ett pressmeddelande.
Enligt art. 34 GDPR ska berörda underrättas utan onödigt dröjsmål om en personuppgiftsincident sannolikt medför en hög risk för dem. Grunderna förklaras under GDPR-anmälningsplikt: 72 timmar.
Vad som hör hemma i ett meddelande
Ett bra meddelande är kort och besvarar de frågor som de berörda ställer sig. Den här indelningen har visat sig fungera:
| Avsnitt | Innehåll |
|---|---|
| Vad har hänt? | Saklig beskrivning med enkla ord, med tidsperiod |
| Vad vet vi, vad vet vi inte? | Säkerställda fakta skilda från pågående undersökning |
| Vilka berörs? | Grupper av personer eller uppgifter, i den mån de är kända |
| Vad har vi gjort? | Omedelbara åtgärder, inkoppling av experter och myndigheter |
| Vad bör ni göra? | Konkreta rekommendationer, till exempel byta lösenord, vara uppmärksam på nätfiske |
| Hur når ni oss? | Fast kontaktpunkt för frågor |
Meddela när ni informerar igen och håll det löftet. Även ett ”inga nya insikter ännu” vid den utlovade tidpunkten skapar förtroende.
Förbered mallar för intern information, kundmeddelande och webbplatsmeddelande innan något händer. I skarpt läge behöver då bara fakta föras in.
Det ni bör undvika
Vissa formuleringar och beteenden skadar regelbundet:
- Förhastad avvisning av risken: ”Inga uppgifter har tagits” får sägas bara om det är belagt. En installerad patch bevisar inte att ingenting hände tidigare.
- Förminskning: begrepp som ”en liten teknisk störning” verkar ohederliga om mer blir känt senare.
- Skuldbeläggande: hänvisningar till webbhotell, leverantörer eller tillverkare hjälper inte de berörda och kan få rättsliga följder.
- Tekniska detaljer som är till nytta för angripare: konkreta sårbarheter i era system hör inte hemma i offentliga meddelanden.
- Garantier: uttalanden som ”helt säkert” eller ”ohackbart” går inte att hålla.
Webbplats, sökmotorer och nätfiskevåg
Efter ett angrepp mot en webbplats tillkommer ofta två följdföreteelser. För det första kan Google visa en varning om skadlig kod har hittats; hur ni får bort den efter saneringen står under Ta bort Googles varning. För det andra utnyttjar bedragare kända incidenter för förfalskade mejl i det drabbade företagets namn. Varna era kunder aktivt för det och ange vilka vägar ni faktiskt kommunicerar via.
Tar ni webbplatsen offline förebyggande räcker en enkel statisk sida med ett kort meddelande och en kontaktväg som inte beror på den drabbade servern.
När incidenten är avslutad lönar sig ett avslutande meddelande till alla som ni tidigare har informerat: vad undersökningen har kommit fram till, vilka åtgärder som har genomförts varaktigt och vem man fortsatt kan vända sig till. Många företag hoppar över det steget eftersom trycket avtar. Just det visar dock att ni tog incidenten på allvar. Utvärdera dessutom internt vad som gick bra i kommunikationen och vad som inte gjorde det, och anpassa mallar och ansvar i er beredskapsplan därefter.
Hur hjälper PHP SOS konkret?
- Vi levererar de tekniska fakta begripligt uppberedda och skiljer tydligt mellan belagt, sannolikt och okänt.
- Vi granskar utkast till era meddelanden med avseende på teknisk riktighet och detaljer som kan hjälpa angripare.
- Vi ställer med kort varsel upp en statisk underhållssida som körs oberoende av det drabbade systemet.
- Via Incident Response håller vi tekniken i takt med er kommunikation så att utfästelser om informationsläget kan hållas.
Vanliga frågor
Ska vi offentliggöra ett angrepp medan allt ännu inte är klart?
Det beror på läget, skyldigheterna och de berörda. Ofta är ett kort, sakligt meddelande med det kända läget bättre än tystnad, eftersom kunder och partner annars får veta det från andra källor. Samråd om tidpunkten med juridisk rådgivning och försäkringsgivare.
Vad får absolut inte stå i ett kundmeddelande?
Antaganden som framstår som fakta, skuldbeläggande av tredje part, tekniska detaljer som hjälper angripare och löften som ni inte säkert kan hålla. Formuleringar som helt uteslutet bör ni bara använda om de är belagda.
Vem bör tala utåt?
En utsedd person, oftast ur ledningen eller företagskommunikationen, med stöd av tekniken och juridisk rådgivning. Alla andra hänvisar till den kontaktpunkten. Då förblir uttalandena enhetliga.
Måste vi ta vår webbplats offline och förklara det?
Om ni förebyggande tar webbplatsen offline hjälper ett kort meddelande, till exempel på en statisk underhållssida. Det behöver inte vara tekniskt. Att förebyggande ta något offline betyder inte automatiskt att ett angrepp lyckades.