Накратко: Добрата кризисна комуникация след кибератака е бърза, честна и единна. Информирайте първо вътрешно, после засегнатите лица и партньорите и казвайте само това, което е сигурно, ясно отделено от онова, което още се разследва. Задълженията за уведомяване, например по чл. 34 от ОРЗД, се съгласуват с длъжностното лице по защита на данните и с правната консултация; тази страница не е правен съвет.
Защо комуникацията е част от обработката на инцидента
Атаката срещу уеб сървър отначало е технически проблем. Много бързо обаче става и въпрос на доверие: клиентите забелязват недостъпен уебсайт, партньорите получават подозрителни имейли, служителите питат. Който тогава мълчи или отговаря противоречиво, губи повече доверие, отколкото от самия инцидент.
Актуалната ситуация около PHP2Shell прави това осезаемо. Много фирми са изключили уебсайтовете си превантивно от мрежата или са ги поддържали за кратко. Това не означава автоматично, че са били хакнати. Именно това разграничение трябва да можете да обясните навън ясно и спокойно.
Кризисна комуникация след кибератака: правилният ред
Доказаният ред не допуска важни групи да научат от пресата или от трети лица:
- Кризисен екип вътрешно: ръководство, техника, защита на данните, при нужда правна консултация и застраховател. Тук се решава какво ще бъде казано.
- Служители: кратка вътрешна информация с молба запитванията да се препращат към определеното звено и с указания за предпазливост при подозрителни имейли.
- Органи, където е нужно: например надзорът по защита на данните по чл. 33 от ОРЗД, BSI (Федерална служба за информационна сигурност на Германия) при задължение по NIS2, полицията при сигнал. Реда съгласувате с правната консултация.
- Засегнати клиенти и партньори: директно и преди публична декларация, ако е възможно.
- Обществеността: бележка на уебсайта, при нужда прессъобщение.
По чл. 34 от ОРЗД засегнатите лица трябва да бъдат уведомени без забавяне, ако нарушението на защитата на данните вероятно води до висок риск за тях. Основните положения обяснява Задължение за уведомяване по ОРЗД: 72 часа.
Какво влиза в съобщението
Доброто съобщение е кратко и отговаря на въпросите, които си задават засегнатите. Доказала се е тази структура:
| Раздел | Съдържание |
|---|---|
| Какво се е случило? | Делово описание с прости думи, с период |
| Какво знаем и какво не? | Сигурни факти, отделени от текущото разследване |
| Кой е засегнат? | Групи лица или данни, доколкото са известни |
| Какво сме направили? | Незабавни мерки, привличане на специалисти и органи |
| Какво трябва да направите Вие? | Конкретни препоръки, например смяна на паролата, внимание за фишинг |
| Как да се свържете с нас? | Постоянно звено за въпроси |
Обявете кога ще информирате отново и спазете това обещание. Дори „още няма нови констатации“ в обявеното време създава доверие.
Подгответе образци за вътрешна информация, съобщение до клиентите и бележка на уебсайта, преди да се е случило нещо. При истински случай остава само да се впишат фактите.
Какво е по-добре да избягвате
Някои формулировки и поведения редовно вредят:
- Прибързано успокояване: „Не са изтекли данни“ е допустимо само ако е доказано. Внесеният пач не доказва, че преди това нищо не се е случило.
- Омаловажаване: изрази като „малък технически инцидент“ изглеждат нечестни, ако по-късно се узнае повече.
- Обвинения: препратки към доставчика на хостинг, доставчици на услуги или производители не помагат на засегнатите и могат да имат правни последици.
- Технически подробности с полза за нападателите: конкретни уязвимости на Вашите системи не принадлежат в публични съобщения.
- Гаранции: твърдения като „напълно сигурно“ или „неуязвимо“ не могат да се удържат.
Уебсайт, търсачки и вълна от фишинг
След атака срещу уебсайт често се добавят две съпътстващи явления. Първо, Google може да покаже предупреждение, ако е открит зловреден код; как да го премахнете след почистването, е описано в Премахване на предупреждението на Google. Второ, измамниците използват известни инциденти за фалшиви имейли от името на засегнатата фирма. Предупредете активно клиентите си за това и посочете по кои пътища действително комуникирате.
Ако изключите уебсайта превантивно от мрежата, е достатъчна проста статична страница с кратка бележка и път за контакт, който не зависи от засегнатия сървър.
Когато инцидентът е приключен, си струва заключително съобщение до всички, които сте информирали преди това: какво е показало разследването, какви мерки са въведени трайно и към кого да се обръщат занапред. Много фирми пропускат тази стъпка, защото натискът отслабва. Именно тя обаче показва, че сте приели инцидента сериозно. Анализирайте вътрешно и какво е вървяло добре в комуникацията и какво не, и съответно коригирайте образците и отговорностите във Вашия авариен план.
Как помага PHP SOS конкретно?
- Предоставяме техническите факти в разбираем вид и разграничаваме ясно доказано, вероятно и неизвестно.
- Проверяваме проектите на Вашите съобщения за техническа вярност и за подробности, които биха могли да помогнат на нападателите.
- Осигуряваме в кратък срок статична страница за поддръжка, която работи независимо от засегнатата система.
- Чрез Incident Response държим техниката в такт с Вашата комуникация, за да могат да се спазят обещанията за състоянието на информацията.
Често задавани въпроси
Да огласим ли атаката, докато още не е всичко ясно?
Това зависи от ситуацията, задълженията и засегнатите лица. Често кратко, делово съобщение с известното състояние е по-добро от мълчанието, защото иначе клиентите и партньорите научават от други източници. Съгласувайте момента с правната консултация и със застрахователя.
Какво в никакъв случай не бива да има в съобщението до клиентите?
Предположения, които изглеждат като факти, обвинения към трети лица, технически подробности, които помагат на нападателите, и обещания, които не можете да изпълните със сигурност. Формулировки като напълно изключено използвайте само ако са доказани.
Кой трябва да говори навън?
Определено лице, най-често от ръководството или от фирмената комуникация, подпомагано от техниката и правната консултация. Всички останали препращат към това звено. Така изказванията остават единни.
Трябва ли да изключим уебсайта от мрежата и да го обясним?
Ако изключите уебсайта превантивно, помага кратка бележка, например на статична страница за поддръжка. Не е нужно тя да е техническа. Превантивното изключване от мрежата не означава автоматично, че атаката е била успешна.