Первые четыре часа киберинцидента кто и какие решения должен принять

У большинства крупных компаний есть регламент реагирования на инциденты. В нём перечислены ответственные подразделения, уровни критичности, каналы эскалации и технические действия.

Но во время настоящего кризиса выясняется, что регламент отвечает на вопрос «что необходимо сделать», но не всегда отвечает на вопрос «кто имеет право принять решение».

SOC видит подозрительную активность. Команда реагирования подтверждает компрометацию. Злоумышленник перемещается по инфраструктуре. Однако остановка сервиса может повлиять на клиентов, производство, выручку или обязательства перед партнёрами.

ИБ предлагает изоляцию. IT предупреждает о последствиях. Бизнес просит дополнительное подтверждение. Юристы хотят понять масштаб утечки. PR ждёт согласованной позиции. Руководство требует точной оценки ущерба, которой в первые часы ещё не существует.

И организация начинает согласовывать полномочия уже во время атаки.

Именно здесь теряется самое ценное — время.

На начальном этапе атака может выглядеть как набор технических индикаторов: подозрительный вход, необычный процесс, обращение к командному серверу или массовое изменение файлов.

Но как только возникает вероятность влияния на критичные сервисы, данные клиентов, производство, договорные обязательства или репутацию, инцидент становится управленческим.

Теперь необходимо одновременно принимать решения по нескольким направлениям:

Актуальная редакция NIST SP 800-61 Rev. 3, опубликованная в апреле 2025 года, рассматривает incident response не как изолированную функцию команды ИБ, а как часть общего управления киберриском, связанную со всеми функциями NIST CSF 2.0. (NIST Computer Security Resource Center)ый сдвиг. Реагирование — не операция SOC, к которой при необходимости подключают руководство. Это способность всей организации принимать согласованные решения в условиях неопределённости.

Первое управленческое решение — признать, что организация имеет дело не просто с событием безопасности, а с инцидентом, требующим специального режима управления.

На практике этот момент часто откладывают.

Команда хочет собрать больше доказательств. Руководители опасаются преждевременной эскалации. Владельцы систем не хотят останавливать процессы из-за неподтверждённой гипотезы.

Но объявление инцидента не означает признания катастрофы. Оно означает запуск заранее подготовленного механизма:

Если для объявления критического инцидента требуется собрать внеплановое совещание нескольких руководителей, организация уже теряет преимущество.

Должен существовать конкретный человек или роль, имеющие право сказать: «Мы переходим в режим управления инцидентом».

Технически остановить распространение атаки иногда можно быстро: отключить учётную запись, изолировать сервер, заблокировать сетевое соединение или временно остановить сервис.

Сложность начинается тогда, когда защитное действие само создаёт бизнес-ущерб.

Допустимо ли остановить клиентское приложение?

Можно ли отключить интеграцию с платёжной системой?

Следует ли изолировать производственный сегмент, если это приведёт к остановке операций?

Кто вправе принять риск продолжения работы потенциально скомпрометированной системы?

Это уже не выбор между безопасным и небезопасным вариантом. Это выбор между двумя видами ущерба:

Поэтому полномочия на containment должны быть определены заранее. ИБ должна знать, какие действия может выполнять самостоятельно, какие требуют согласования с владельцем сервиса, а какие немедленно передаются кризисному руководству.

CISA рекомендует начинать реагирование с определения затронутых систем и их изоляции, одновременно учитывая критичность сервисов и необходимость сохранения артефактов для расследования. Руководство при этом должно получать регулярные обновления по мере развития ситуации. (CISA)рекомендации «изолировать заражённую систему» недостаточно. Необходим ответ на более сложный вопрос: кто вправе принять последствия этой изоляции?

Ещё один конфликт первых часов — скорость containment против качества расследования.

Отключение сервера может остановить активность злоумышленника, но уничтожить данные из оперативной памяти. Массовая блокировка учётных записей может ограничить атаку, но усложнить восстановление последовательности событий. Перезапуск системы может вернуть её в работу, но удалить часть артефактов.

CISA отдельно рекомендует сохранять наиболее волатильные данные, включая память, журналы безопасности и ограниченные по сроку хранения буферы, а для облачных ресурсов — создавать снимки, пригодные для последующего анализа. (CISA)льном инциденте невозможно всегда сохранить всё.

Поэтому команда должна заранее понимать:

Зрелая модель не пытается избежать компромисса. Она позволяет быстро и осознанно его принять.

Техническая тяжесть инцидента и его существенность для бизнеса — не одно и то же.

Компрометация десятков серверов тестового контура может не остановить основные операции. Получение доступа к одной привилегированной учётной записи может создать риск для всей компании.

Поэтому техническая команда не должна в одиночку определять критичность инцидента. Необходима совместная оценка:

Показателен подход SEC к публичным компаниям в США: четырёхдневный срок раскрытия существенного киберинцидента отсчитывается не с момента обнаружения атаки, а с момента, когда компания определила её существенность. При этом такое решение должно приниматься без необоснованной задержки. (SEC)ниверсальное требование для всех организаций и юрисдикций. Но оно хорошо показывает, почему оценка business impact должна быть встроена в реагирование с первых часов, а не начинаться после завершения технического расследования.

Во время кризиса опасны две крайности.

Первая — молчание до получения полной картины. Полная картина может появиться через несколько дней, тогда как сотрудники, клиенты или партнёры уже заметят сбои.

Вторая — преждевременное заявление с неподтверждёнными деталями, которые впоследствии придётся опровергать.

Задача коммуникации в первые часы — не объяснить всё. Задача — обеспечить контролируемое движение подтверждённой информации.

Для этого заранее определяются:

CISA рекомендует иметь не только incident response plan, но и отдельный коммуникационный план, согласованный руководством, включая процедуры уведомления и заранее подготовленные шаблоны первоначальных заявлений. (CISA) сообщения «мы расследуем нарушение доступности некоторых сервисов» может оказаться полезнее пятидесятистраничного регламента, если он заранее согласован и может быть опубликован за несколько минут.

Эта модель не является универсальным нормативом. Она задаёт управленческий ритм, который можно адаптировать под масштаб и специфику организации.

ПериодКлючевые решения0–15 минутПодтвердить необходимость эскалации, объявить инцидент, назначить incident commander, открыть защищённый канал связи, начать журнал решений15–60 минутОпределить предварительный масштаб, изолировать очевидно затронутые активы, сохранить критичные доказательства, оценить риск для ключевых сервисов1–4 часаПринять решения об остановке или ограничении сервисов, подключить бизнес, юристов и коммуникации, привлечь внешнюю экспертизу, установить executive cadence4–12 часовПроверить эффективность containment, уточнить business impact, определить критерии безопасного восстановления, подготовить необходимые уведомления12–24 часаУтвердить приоритеты восстановления, организовать сменность команды, обновить руководство и заинтересованные стороны, пересмотреть первоначальные гипотезы

Важна не буквальная привязка каждого действия к минуте. Важно, чтобы в любой момент было понятно:

Если отключение любого критичного сервиса может санкционировать только генеральный директор, организация создаёт единую точку задержки.

Руководство должно определять пределы допустимого риска, но часть полномочий необходимо делегировать заранее.

У координатора инцидента должна быть возможность синхронизировать IT, ИБ, бизнес, юридическую функцию, коммуникации и внешних специалистов.

Иначе появляется несколько параллельных центров принятия решений.

Топ-менеджменту редко нужен перечень IP-адресов и хешей файлов.

Ему необходимо понимать:

В условиях стресса люди запоминают события по-разному.

Журнал решений должен содержать время, доступные факты, принятое действие, ответственного, ожидаемый результат и момент повторной оценки.

Он нужен не для поиска виновных, а для сохранения управляемости и последующего улучшения процесса.

Зрелая организация готовит не только технические playbooks.

Она заранее определяет:

Эту модель необходимо проверять на учениях.

Не вопросом «знает ли SOC номер телефона директора», а сценариями:

Если на tabletop exercise ответы занимают двадцать минут, в настоящем инциденте они займут ещё больше.

Первые часы инцидента — не время согласовывать полномочия.

Технологии могут обнаружить атаку, собрать телеметрию и заблокировать отдельные действия злоумышленника. Но они не решат, какой бизнес-ущерб допустим, какой сервис можно остановить и когда организация должна публично признать проблему.

Эти решения всегда останутся управленческими.

Поэтому готовность к инциденту определяется не толщиной регламента и не количеством инструментов в SOC. Она определяется тем, может ли организация под давлением быстро ответить на три вопроса:

Кто принимает решение? Какой риск он вправе принять? Когда решение должно быть пересмотрено?

Проверьте, может ли ваша организация сегодня:

Если хотя бы на три вопроса нет однозначного ответа, проблема находится не в incident response playbook.

Проблема — в системе управления.

Во время серьёзного инцидента компания почти всегда действует с неполной информацией.

Нельзя дождаться абсолютной уверенности, прежде чем изолировать систему. Нельзя заранее точно рассчитать ущерб от остановки сервиса. Нельзя сразу знать полный объём компрометации.

Но можно заранее определить, кто имеет право принимать решения в этой неопределённости.

Именно поэтому первые четыре часа — это экзамен не только для SOC и команды ИБ.

Это экзамен для всей управленческой модели компании.

Подписывайтесь на мой ТГ канал: @ib_decisions