Итак, вы столкнулись с инцидентом и перед вам стоит задача сообщить об этом неприятном факте широкой, ну или не очень, общественности. Как быстро надо это сделать?
Я исхожу из того, что об инциденте рано или поздно (скорее рано) станет известно и вам все равно лучше исходить из худшего.
Чтобы не ходить вокруг да около, я попробовал подсобрать в единую табличку все возможные варианты с указанием типов неблагоприятных киберсобытий, сроком первого публичного заявления и моим видением, почему именно такой срок должен быть.
|
Тип события |
Первое публичное заявление |
Почему именно такой срок? |
|---|---|---|
|
Массовая утечка персональных данных клиентов |
1–3 часа после подтверждения |
Если информация утечет через СМИ или исследователей раньше компании, компания сразу оказывается в позиции скрывающей проблему. Лучше признать факт расследования, чем ждать полной картины. |
|
Утечка платежных данных |
1–2 часа |
Пользователям необходимо немедленно менять карты, блокировать операции и следить за мошенничеством. Цена задержки очень высока. |
|
Компрометация учетных записей пользователей |
1–3 часа |
Пользователи должны успеть сменить пароль и включить MFA раньше злоумышленников. |
|
Взлом публичного веб-сайта (дефейс) |
30–60 минут |
Инцидент уже публичен. Любое молчание выглядит странно. Достаточно короткого сообщения “известно, расследуем”. |
|
Недоступность онлайн-сервиса из-за кибератаки (DDoS) |
30 минут – 2 часа |
Клиенты уже видят проблему. Лучше сразу подтвердить факт и периодически обновлять статус. |
|
Атака шифровальщика с остановкой бизнеса |
2–4 часа |
Обычно информация быстро просачивается через сотрудников и клиентов. При этом необходимо избежать публикации неподтвержденных данных. |
|
Подозрение на компрометацию инфраструктуры без подтверждения |
Не публиковать, пока нет уверенности |
Преждевременные заявления способны вызвать ненужную панику и юридические последствия. |
|
Подтвержденная компрометация Active Directory, домена, ключевых систем управления |
2–6 часов |
Даже если последствия пока неизвестны, сам факт означает высокий риск дальнейшего развития событий. Особенно для «офисной» компании. Для промышленных компаний риски могут быть чуть-чуть ниже. |
|
Компрометация корпоративной электронной почты руководства |
2–6 часов |
Необходимо предупредить партнеров о возможных мошеннических письмах. |
|
Компрометация сертификата электронной подписи |
Немедленно (до 1 часа) |
Нужно максимально быстро предотвратить использование сертификата злоумышленниками. |
|
Компрометация TLS-сертификата (закрытого ключа) |
1–3 часа |
Пока сертификат не перевыпущен, сохраняется риск MITM и подмены ресурсов. |
|
Отзыв TLS-сертификата CA (например, из-за санкций или компрометации) |
2–6 часов |
Пользователи должны понимать причины появления предупреждений браузеров и необходимые действия. |
|
Компрометация внутреннего удостоверяющего центра (PKI) |
1–4 часа |
Это один из наиболее критичных инцидентов доверенной инфраструктуры. |
|
Обнаружение вредоносного ПО внутри корпоративной сети без воздействия на клиентов |
Как правило, не публикуется |
Внутренний операционный инцидент, если не затрагивает внешние стороны. |
|
Атака на компанию через подрядчиков или цепочку поставок |
2–6 часов |
Необходимо предупредить клиентов о возможной угрозе их инфраструктуре. |
|
Компрометация обновлений программного обеспечения |
Немедленно (до 1 часа) |
Клиенты должны остановить установку обновлений как можно раньше. |
|
Уязвимость нулевого дня в собственном продукте |
В течение нескольких часов после подготовки рекомендаций |
Лучше одновременно сообщить проблему и способы защиты. |
|
Компрометация облачного провайдера, влияющая на клиентов |
1–3 часа |
Клиенты должны понимать возможные последствия и ограничения сервиса. |
|
Утечка исходного кода |
3–12 часов |
Обычно непосредственного риска для клиентов нет, поэтому допустимо сначала оценить масштаб. |
|
Компрометация секретов (API-ключи, токены, облачные ключи) |
После ротации ключей, обычно 2–6 часов |
Сначала нужно устранить непосредственную угрозу, затем информировать заинтересованные стороны. |
|
Внутренний инцидент без влияния на клиентов |
Обычно не публикуется |
Если нет общественно значимых последствий, публичность может только навредить. |
|
Подтверждение отсутствия компрометации после расследования |
В течение суток |
Позволяет закрыть информационный цикл и снизить число слухов. |
Сразу скажу, что это именно моя точка зрения. Она основана на моем опыте. Не надо считать это догмой – скорее руководством к действию.
Обратите внимание – в молчанку играть сутки и более не рекомендуется. Первая реакция должна наступать в течение нескольких часов. А это требует предварительной подготовки, шаблонов сообщений, антикризисных киберучения и т.п. Ну и в кибериспытания включите эту часть, чтобы проверить способность компании вовремя реагировать на недопустимые события.
Почему выбраны именно такие интервалы? Я ориентировался на следующую модель:
|
Интервал |
Когда применяется? |
Логика |
|---|---|---|
|
До 30 минут |
Инцидент уже видят все |
Компания должна успеть первой начать коммуникацию. |
|
До 1 часа |
Высокий риск причинения ущерба пользователям |
Пользователи должны успеть защититься. |
|
1–3 часа |
Критичный инцидент с высокой вероятностью публичной огласки |
Достаточно времени подтвердить факты, но не потерять инициативу. |
|
2–6 часов |
Сложные технические инциденты |
Можно собрать минимально достоверную информацию без затягивания. |
|
До 24 часов |
Инциденты со средней общественной значимостью |
Главное – не оставлять информационный вакуум дольше суток. |
|
Не публикуется |
Внутренние события без влияния на внешних лиц |
Публичность не приносит пользы заинтересованным сторонам. |
И еще один важный момент. Часто компании ждут окончания расследования, чтобы выступить со своим заявлением. Но я бы вообще отказался от идеи ждать финального вердикта. В зависимости от типа инцидента это может занять достаточно много времени, вплоть до нескольких дней или недель. То есть можно упустить драгоценное время. Лучше использовать трехэтапную модель:
|
Этап |
Срок |
Содержание |
|---|---|---|
|
Подтверждение |
15–120 минут |
«Мы знаем о ситуации, расследуем, специалисты работают». |
|
Факты |
2–12 часов |
Что произошло, кого касается, какие меры уже приняты, что нужно сделать пользователям. |
|
Извлеченные уроки |
3–30 дней |
Причины инцидента, исправления, изменения процессов, меры по предотвращению повторения. |
Именно такой подход сегодня чаще всего демонстрируют зрелые организации. Он позволяет не ждать завершения технического расследования, но и не делать поспешных заявлений, которые затем придется опровергать. Для киберкризисов это обычно оказывается наиболее эффективной стратегией как с точки зрения доверия клиентов, так и с точки зрения управления репутацией.
А что, если компания публичная (торгуется на бирже), то поменяется ли стратегия внешних коммуникаций? Да! Потому что их кризис развивается сразу по нескольким направлениям. Во-первых, падает не только доверие клиентов. Также начинают реагировать:
- инвесторы
- аналитики
- биржа
- рейтинговые агентства
- крупные институциональные фонды
- журналисты.
Фактически киберинцидент превращается уже не в ИБ-событие, а в событие корпоративного управления.
Хотя в России пока такого серьезного влияния не отмечено (ну или никто не проводил серьезных исследований такой связи).
Во-вторых, для публичной компании первый вопрос журналистов обычно звучит не «Как вас взломали?», а «Почему вы молчали?». Именно поэтому некоторые крупные компании публикуют заявление буквально через час после обнаружения инцидента, хотя технически знают всего три вещи:
- произошел инцидент
- работают специалисты
- привлечены внешние эксперты.
Этого уже достаточно.
Некоторые журналисты особенно любят придать негативную окраску любым промедлениям пострадавших компаний, обвинив их в сокрытии фактов. Желтизна есть желтизна, ничего не попишешь!
Есть и еще один срез, который можно учесть – скорость появления внешних свидетелей Иеговы инцидента. Очевидно, что если о проблеме уже известно извне, то смысла придерживаться упомянутых выше верхних границ временных интервалов нет смысла. Получается такая картина:
|
Кто узнает первым? |
Насколько быстро компания должна начать говорить? |
|---|---|
|
Пользователи уже видят проблему |
Немедленно |
|
СМИ могут узнать в течение часа |
Очень быстро |
|
Исследователь уже сообщил об уязвимости |
Очень быстро |
|
Злоумышленники начали публиковать украденные данные |
Немедленно |
|
Инцидент пока известен только внутри компании |
Можно сначала разобраться с фактами |
И тут уже не столь важно, публичная компания или нет. Важно, кто первым сформирует информационную повестку. Если это сделает сама компания, она сохранит доверие даже при тяжелом инциденте. Если повестку сформируют журналисты, исследователи или сами злоумышленники, кризис почти всегда окажется глубже, чем того заслуживают реальные технические последствия.
Повторю – я не претендую на абсолютную точность в указанных временных интервалах. Это именно мое видение. Вы можете иметь свою обоснованную точку зрения. Главное, чтобы вы понимали последствия в задержке в коммуникации, а также были просто готовы к такой коммуникации.
