Trumpai: Gera krizių komunikacija po kibernetinės atakos yra greita, sąžininga ir vieninga. Pirmiausia informuokite viduje, po to paveiktus asmenis ir partnerius, ir sakykite tik tai, kas patvirtinta, aiškiai atskirdami nuo to, kas dar tiriama. Informavimo pareigas, pavyzdžiui, pagal BDAR 34 straipsnį, derinkite su duomenų apsaugos pareigūnu ir teisine konsultacija; šis puslapis nėra teisinė konsultacija.
Kodėl komunikacija yra incidento tvarkymo dalis
Ataka prieš žiniatinklio serverį iš pradžių yra techninė problema. Tačiau labai greitai ji tampa ir pasitikėjimo klausimu: klientai pastebi neprieinamą svetainę, partneriai gauna įtartinus laiškus, darbuotojai klausinėja. Kas tada tyli arba atsako prieštaringai, praranda daugiau pasitikėjimo nei dėl paties incidento.
Dabartinė PHP2Shell padėtis tai padaro apčiuopiamą. Daug įmonių prevenciškai atjungė savo svetaines arba trumpam jas patikrino. Tai automatiškai nereiškia, kad jos buvo nulaužtos. Būtent šį skirtumą turėtumėte sugebėti aiškiai ir ramiai paaiškinti išorėje.
Krizių komunikacija po kibernetinės atakos: tinkama eilė
Patikrinta eilė neleidžia svarbioms grupėms apie įvykį sužinoti iš spaudos ar iš trečiųjų šalių:
- Krizių komanda viduje: vadovybė, technika, duomenų apsauga, prireikus teisinė konsultacija ir draudikas. Čia sprendžiama, kas bus sakoma.
- Darbuotojai: trumpa vidinė informacija su prašymu užklausas perduoti paskirtam asmeniui ir nurodymais būti atsargiems su įtartinais laiškais.
- Institucijos, kur reikia: pavyzdžiui, duomenų apsaugos priežiūros institucija pagal BDAR 33 straipsnį, BSI (Vokietijos Federalinė informacijos saugumo tarnyba) esant NIS2 pareigai, policija pateikus pareiškimą. Eiliškumą suderinkite su savo teisine konsultacija.
- Paveikti klientai ir partneriai: tiesiogiai ir prieš viešą pareiškimą, jei įmanoma.
- Visuomenė: pranešimas svetainėje, prireikus pranešimas spaudai.
Pagal BDAR 34 straipsnį susiję asmenys turi būti nedelsiant informuojami, jei duomenų apsaugos pažeidimas tikėtinai sukelia didelę riziką. Pagrindus paaiškina BDAR pranešimo pareiga: 72 valandos.
Kas turi būti pranešime
Geras pranešimas yra trumpas ir atsako į klausimus, kuriuos sau užduoda paveikti asmenys. Pasiteisino tokia struktūra:
| Skyrius | Turinys |
|---|---|
| Kas įvyko? | Dalykiškas aprašymas paprastais žodžiais, nurodant laikotarpį |
| Ką žinome, ko ne? | Patvirtinti faktai atskirti nuo vykstančio tyrimo |
| Kas paveikti? | Asmenų ar duomenų grupės, kiek žinoma |
| Ką padarėme? | Skubios priemonės, specialistų ir institucijų įtraukimas |
| Ką turėtumėte daryti jūs? | Konkrečios rekomendacijos, pavyzdžiui, pakeisti slaptažodį, saugotis sukčiavimo (phishing) |
| Kaip mus pasiekti? | Nuolatinis kontaktinis punktas papildomiems klausimams |
Paskelbkite, kada vėl informuosite, ir šį pažadą išpildykite. Net „dar nėra naujų žinių“ paskelbtu laiku kuria pasitikėjimą.
Parenkite vidinės informacijos, klientų pranešimo ir svetainės pranešimo šablonus, kol dar nieko neįvyko. Kritiniu atveju tereikės įrašyti faktus.
Ko geriau vengti
Kai kurios formuluotės ir elgesys reguliariai kenkia:
- Skubotas nuraminimas: „Duomenys nebuvo išsunkti“ leistina tik jei tai įrodyta. Įdiegta pataisa neįrodo, kad anksčiau nieko neįvyko.
- Sumenkinimas: Sąvokos, pavyzdžiui, „nedidelis techninis incidentas“, atrodo nesąžiningai, jei vėliau paaiškėja daugiau.
- Kaltinimai: Nuorodos į hostingo teikėją, paslaugų teikėją ar gamintoją paveiktiems asmenims nepadeda ir gali turėti teisinių pasekmių.
- Techninės detalės, naudingos atakai: Konkretūs jūsų sistemų pažeidžiamumai viešuose pranešimuose netinka.
- Garantijos: Teiginių, pavyzdžiui, „visiškai saugu“ ar „nenulaužiama“, išlaikyti neįmanoma.
Svetainė, paieškos sistemos ir sukčiavimo banga
Po atakos prieš svetainę dažnai atsiranda du palydovai. Pirma, Google gali rodyti įspėjimą, jei rastas kenkėjiškas kodas; kaip po išvalymo jį pašalinti, aprašyta puslapyje Google įspėjimo pašalinimas. Antra, sukčiai žinomus incidentus naudoja suklastotiems laiškams paveiktos įmonės vardu. Aktyviai įspėkite savo klientus ir nurodykite, kokiais keliais iš tikrųjų komunikuojate.
Jei svetainę prevenciškai atjungiate, pakanka paprasto statinio puslapio su trumpu pranešimu ir kontaktu, kuris nepriklauso nuo paveikto serverio.
Kai incidentas baigtas, verta galutinio pranešimo visiems, kuriuos anksčiau informavote: ką parodė tyrimas, kokios priemonės įgyvendintos nuolat ir kam galima toliau kreiptis. Daug įmonių šio žingsnio praleidžia, nes spaudimas atslūgsta. Tačiau būtent jis parodo, kad incidentą vertinote rimtai. Be to, viduje įvertinkite, kas komunikacijoje sekėsi, o kas ne, ir atitinkamai pritaikykite šablonus bei atsakomybes savo avariniame plane.
Kaip PHP SOS padeda konkrečiai?
- Pateikiame technines aplinkybes suprantamai ir aiškiai atskiriame, kas įrodyta, kas tikėtina ir kas nežinoma.
- Tikriname jūsų pranešimų projektus dėl techninio teisingumo ir detalių, galinčių padėti užpuolikams.
- Trumpam laikui parengiame statinį priežiūros puslapį, veikiantį nepriklausomai nuo paveiktos sistemos.
- Per incidentų valdymą technikos darbą derename su jūsų komunikacijos tempu, kad pažadai dėl informacijos būsenos būtų įvykdomi.
Dažni klausimai
Ar turime paskelbti apie ataką viešai, kol dar ne viskas aišku?
Tai priklauso nuo padėties, pareigų ir paveiktų asmenų. Dažnai trumpas, dalykiškas pranešimas su žinoma būsena yra geriau nei tylėjimas, nes klientai ir partneriai kitaip sužino iš kitų šaltinių. Laiką suderinkite su teisine konsultacija ir draudiku.
Ko klientų pranešime tikrai neturi būti?
Spėjimų, pateikiamų kaip faktai, kaltinimų trečiosioms šalims, techninių detalių, padedančių užpuolikams, ir pažadų, kurių negalite užtikrintai įvykdyti. Formuluočių, pavyzdžiui, visiškai pašalinta, vartokite tik jei tai įrodyta.
Kas turėtų kalbėti išorėje?
Paskirtas asmuo, dažniausiai iš vadovybės ar įmonės komunikacijos, kuriam padeda technika ir teisinė konsultacija. Visi kiti nukreipia į šį asmenį. Taip pareiškimai išlieka vienodi.
Ar turime atjungti savo svetainę ir tai paaiškinti?
Jei svetainę prevenciškai atjungiate nuo tinklo, padeda trumpas pranešimas, pavyzdžiui, statiniame priežiūros puslapyje. Jis neturi būti techninis. Prevencinis atjungimas automatiškai nereiškia, kad ataka buvo sėkminga.