Начало...
7️⃣ Инструкции должны писать те, кто реально ими пользуется. Хорошая инструкция рождается не в кабинете. Ее пишут люди, которые:
➡️ сами выполняют эти действия
➡️ сами проходят их ночью
➡️ сами тестируют последовательность шагов.
После этого инструкцию обязательно нужно заставить выполнять других сотрудников. Именно тогда становится понятно, чего не хватает, где возникают ошибки, какие действия непонятны.
8️⃣ Еще один неожиданный вывод. Джуны чаще всего думают: "Лучше никого не будить. Вдруг тревога ложная." Руководители же говорили обратное: "Лучше разбудить меня зря, чем утром обнаружить разрушенный сервис". Получается, что культуру эскалации тоже приходится воспитывать.
9️⃣ Ручной режим – не пережиток прошлого. При катастрофических инцидентах компания должна иметь возможность:
➡️ перейти на бумагу
➡️ продолжить выпуск продукции
➡️ сохранить критичные процессы.
6️⃣1️⃣ Не все инциденты должны жить в одном процессе (хотя у кого-то были в одном). Была интересная дискуссия о том, что: ИТ-инциденты, ИБ-инциденты, инциденты службы безопасности и производственные аварии не всегда должны попадать в одну тикетницу. Но между всеми службами обязательно должна существовать быстрая схема обмена информацией. Во многих компаниях именно взаимодействие между ИТ и ИБ оказалось важнее, чем единая система регистрации недопустимых событий.
6️⃣6️⃣ Прозвучала еще одна очень жизненная мысль – настоящие аварии всегда отличаются от учений. Даже полностью протестированный DRP в реальной аварии работает иначе, потому что:
➡️ сервера стоят в воде
➡️ помещения затоплены
➡️ оборудование недоступно
➡️ люди действуют под стрессом.
Именно поэтому планы приходится постоянно дорабатывать после реальных происшествий.
6️⃣2️⃣ Запомнились несколько практических кейсов:
➡️ маркировка нужных кабелей красным цветом
➡️ поднятие серверов выше уровня возможного подтопления (Питер, что уж тут скажешь)
➡️ увеличение мощности дренажных насосов
➡️ перенос резервной серверной.
То есть реальные инциденты нередко меняют не только политику ИБ, но и инженерные решения.
6️⃣3️⃣ Интересный взгляд представителя страховщика – киберстрахование заставляет смотреть на инциденты через деньги. Они рекомендуют начинать не с технологий, а с вопросов:
➡️ сколько денег компания потеряет?
➡️ какие статьи затрат самые большие?
➡️ какие убытки можно компенсировать?
➡️ что будет стоить простой производства?
Фактически речь идет о переводе разговора с технического языка на язык финансовых рисков.
Если свести всю дискуссию к короткому списку, получится примерно следующее:
6️⃣ План реагирования должен исходить из принципа "не если, а когда".
2️⃣ Первые действия – сохранить бизнес, а не искать виноватых.
3️⃣ Паника опаснее многих технических проблем.
4️⃣ Каждый реальный инцидент обязан приводить к пересмотру плана.
5️⃣ Документировать расследование нужно в процессе, а не после.
6️⃣ Инструкции должны писать те, кто действительно ими пользуется.
7️⃣ Людей нужно учить не бояться эскалации.
8️⃣ Ручной режим должен существовать хотя бы для критичных процессов.
9️⃣ Учения не заменяют настоящие инциденты.
6️⃣1️⃣ Самые ценные изменения после инцидентов часто оказываются организационными и психологическими, а не техническими.
#управлениеинцидентами #bestpractice