На прошедшем 10 дней назад в Питере Петербургском цифровом форуме, я модерировал секцию "Инцидент и последствия. Первые 72 часа и жизнь после" и теперь пришла пора подвести некоторые итоги. Я не буду пересказывать слова каждого участника, скорее поделюсь концентратом идей, которые я вынес с дискуссии. Для начала стоит сказать, что когда я перед мероприятием спрашивал участников, сталкивались ли они с инцидентами, только один участник честно сказал, что да, было дело (хотя у некоторых из коллег инциденты становились даже достоянием гласности). Но по ходу дискуссии стало понятно, что многие участники лукавили и они реально сталкивались с киберкризисами, что и позволило им достаточно интересно рассказывать о своем опыте.
6️⃣ Практически все участники независимо друг от друга пришли к одной мысли: план реагирования – это не инструкция, которая гарантирует успех. Это стартовая точка, которая после каждого реального инцидента должна переписываться. Никто из участников не сказал, что первоначальный план оказался идеальным. Наоборот, все отмечали, что именно реальные инциденты показали слабые места документов.
2️⃣ Главная цель реагирования – не расследование, а сохранение бизнеса. Один из участников несколько раз подчеркнул, что первая задача – не искать виноватых и не заниматься расследованием, а обеспечить непрерывность бизнеса. Сначала остановить хаос, сохранить производство, при необходимости перейти на ручной режим и только потом разбираться с причиной. Классная цитата прозвучала: "Мы уже ничего не можем изменить – событие произошло. Теперь наша задача – максимально сохранить способность компании работать". Кто-то из коллег больше фокусировался на технических вопросах и это тоже хорошо отражает отношение ИБ к своей работе – для кого-то это чисто техническая история, а для кого-то бизнесовая.
3️⃣ Практически никто не имеет раздела "борьба с паникой" в своих плейбуках, но все признали, что именно паника становится первой проблемой. Никто еще не понимает масштабов, руководители требуют мгновенных ответов, но пока все не соберутся в одной комнате, пока не остановится поток эмоций, пока не будет составлен короткий план ближайших действий, ничего не начнет выстраиваться.
4️⃣ Практически каждый участник сказал одно и то же – лучшие планы пишутся после аварии. Именно после первого серьезного инцидента:
➡️ переписывается порядок действий
➡️ уточняются инструкции
➡️ появляются новые чек-листы
➡️ убираются лишние пункты
➡️ добавляются реальные детали.
5️⃣ Самая слабая часть почти всех планов – уведомления и документирование. Во время первого серьезного инцидента команда полностью забывает порядок уведомлений, перестает вести журнал действий, концентрируется исключительно на техническом расследовании. А потом оказывается, что нужно:
➡️ отправлять уведомления
➡️ готовить отчеты
➡️ объяснять регуляторам свои действия
➡️ восстанавливать хронологию.
А вспомнить ничего уже нельзя. Прозвучал классный совет – возьмите джуна и пусть все записывает, что ему говорят.
6️⃣ Очень интересная мысль, которую повторили сразу несколько участников. Инструкция может быть правильной, но человек... боится ее выполнить. Охранник боится выдернуть кабель, DevOps боится погасить кластер, инженер боится отключить систему, оператор боится остановить сервис. А все потому, что есть опасение: "А вдруг потом виноватым окажусь я?" То есть реагирование тормозит не техника или нехватка навыков, а психология исполнителей.
Окончание...
#управлениеинцидентами #bestpractice
