Na kratko: Dobro krizno komuniciranje po kibernetskem napadu je hitro, iskreno in enotno. Najprej obvestite interno, nato prizadete in partnerje, in povejte samo, kar je zanesljivo, jasno ločeno od tistega, kar se še preiskuje. Obveznosti obveščanja, na primer po 34. členu GDPR, uskladite s pooblaščencem za varstvo podatkov in pravnim svetovalcem; ta stran ni pravno svetovanje.
Zakaj je komuniciranje del obravnave incidenta
Napad na spletni strežnik je najprej tehnična težava. Zelo hitro pa postane tudi vprašanje zaupanja: stranke opazijo nedosegljivo spletno stran, partnerji prejemajo sumljiva e-sporočila, zaposleni sprašujejo. Kdor takrat molči ali odgovarja nasprotujoče, izgubi več zaupanja kot zaradi samega incidenta.
Trenutni položaj okoli PHP2Shell to naredi otipljivo. Mnoga podjetja so svoje spletne strani previdnostno odklopila ali jih kratkoročno vzdrževala. To ne pomeni samodejno, da so bila vdrta. Prav to razliko morate znati navzven jasno in mirno pojasniti.
Krizno komuniciranje po kibernetskem napadu: pravi vrstni red
Preizkušen vrstni red preprečuje, da bi pomembne skupine izvedele iz tiska ali od tretjih:
- Krizna ekipa interno: poslovodstvo, tehnika, varstvo podatkov, po potrebi pravno svetovanje in zavarovalnica. Tu se odloči, kaj bo rečeno.
- Zaposleni: kratka interna informacija s prošnjo, naj se povpraševanja posredujejo imenovani osebi, in z napotki o previdnosti pri sumljivih e-sporočilih.
- Organi, kjer je potrebno: na primer nadzorni organ za varstvo podatkov po 33. členu GDPR, BSI ob obveznosti po NIS2, policija ob ovadbi. Vrstni red uskladite s svojim pravnim svetovalcem.
- Prizadete stranke in partnerji: neposredno in po možnosti pred javno izjavo.
- Javnost: obvestilo na spletni strani, po potrebi izjava za tisk.
Po 34. členu GDPR je treba prizadete nemudoma obvestiti, če kršitev varstva podatkov verjetno povzroči visoko tveganje zanje. Osnove pojasnjuje stran Obveznost prijave po GDPR: 72 ur.
Kaj sodi v obvestilo
Dobro obvestilo je kratko in odgovarja na vprašanja, ki si jih zastavljajo prizadeti. Ta členitev se je obnesla:
| Razdelek | Vsebina |
|---|---|
| Kaj se je zgodilo? | Stvarni opis v preprostih besedah, z obdobjem |
| Kaj vemo, česa ne? | Zanesljiva dejstva ločena od tekoče preiskave |
| Kdo je prizadet? | Skupine oseb ali podatkov, kolikor je znano |
| Kaj smo storili? | Takojšnji ukrepi, vključitev strokovnjakov in organov |
| Kaj naj storite vi? | Konkretna priporočila, na primer zamenjava gesla, pozornost na lažno predstavljanje (phishing) |
| Kako nas dosežete? | Stalna kontaktna točka za vprašanja |
Napovejte, kdaj boste znova obvestili, in to zavezo izpolnite. Tudi „še ni novih ugotovitev“ ob napovedanem času ustvarja zaupanje.
Pripravite predloge za interno informacijo, obvestilo strankam in objavo na spletni strani, preden se kaj zgodi. V resni situaciji je treba nato samo še vstaviti dejstva.
Česa se raje izogibajte
Nekatere formulacije in vedenja redno škodijo:
- Prenagljeno pomirjanje: „Podatki niso bili odtujeni“ je dopustno samo, če je dokazano. Nameščen popravek ne dokazuje, da se prej ni zgodilo nič.
- Pomanjševanje: izrazi, kot je „majhen tehnični incident“, delujejo neiskreno, če se pozneje izve več.
- Obtoževanje: napotila na ponudnika gostovanja, izvajalca ali proizvajalca prizadetim ne pomagajo in imajo lahko pravne posledice.
- Tehnične podrobnosti, uporabne za napadalce: konkretne ranljivosti vaših sistemov ne sodijo v javna obvestila.
- Jamstva: izjav, kot sta „popolnoma varno“ ali „nepremagljivo“, ni mogoče držati.
Spletna stran, iskalniki in val lažnega predstavljanja
Po napadu na spletno stran se pogosto pojavita dva spremljevalna pojava. Prvič, Google lahko prikaže opozorilo, če je bila najdena škodljiva koda; kako ga po čiščenju odstranite, piše na strani Odstranitev opozorila Google. Drugič, goljufi znane incidente izkoriščajo za ponarejena e-sporočila v imenu prizadetega podjetja. Stranke pred tem aktivno opozorite in navedite, po katerih poteh dejansko komunicirate.
Če spletno stran previdnostno odklopite, zadošča preprosta statična stran s kratkim obvestilom in kontaktno potjo, ki ni odvisna od prizadetega strežnika.
Ko je incident zaključen, se splača končno obvestilo vsem, ki ste jih prej obvestili: kaj je pokazala preiskava, kateri ukrepi so bili trajno uvedeni in na koga se lahko še naprej obrnejo. Mnoga podjetja ta korak izpustijo, ker pritisk popusti. Prav on pa pokaže, da ste incident vzeli resno. Interno tudi ovrednotite, kaj je pri komuniciranju šlo dobro in kaj ne, ter ustrezno prilagodite predloge in odgovornosti v svojem načrtu ukrepanja.
Kako PHP SOS konkretno pomaga?
- Tehnična dejstva dostavimo razumljivo pripravljena in jasno ločimo med dokazanim, verjetnim in neznanim.
- Osnutke vaših obvestil preverimo glede tehnične pravilnosti in podrobnosti, ki bi lahko pomagale napadalcem.
- Kratkoročno zagotovimo statično vzdrževalno stran, ki teče neodvisno od prizadetega sistema.
- Prek Incident Response tehniko držimo v taktu vašega komuniciranja, da je mogoče izpolniti zaveze o informacijskem stanju.
Pogosta vprašanja
Ali naj napad objavimo, dokler še ni vse jasno?
To je odvisno od položaja, obveznosti in prizadetih. Pogosto je kratko, stvarno obvestilo z znanim stanjem boljše kot molk, ker bi sicer stranke in partnerji izvedeli iz drugih virov. Čas uskladite s pravnim svetovalcem in zavarovalnico.
Česa v obvestilu strankam nikakor ne sme biti?
Domnev, ki se kažejo kot dejstva, obtoževanja tretjih, tehničnih podrobnosti, ki pomagajo napadalcem, in zavez, ki jih ne morete zanesljivo izpolniti. Izrazov, kot je popolnoma izključeno, ne uporabljajte, razen če so dokazani.
Kdo naj govori navzven?
Imenovana oseba, praviloma iz poslovodstva ali podjetniškega komuniciranja, ob podpori tehnike in pravnega svetovanja. Vsi drugi napotijo nanjo. Tako ostanejo izjave enotne.
Ali moramo spletno stran odklopiti in to pojasniti?
Če spletno stran previdnostno odklopite z omrežja, pomaga kratko obvestilo, na primer na statični vzdrževalni strani. Ni treba, da je tehnično. Previdnostni odklop ne pomeni samodejno, da je bil napad uspešen.