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

Softline

Jul 03, 2026 • 11:50

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

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

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

Минимально жизнеспособный план для компании, которая только начинает выстраивать процессы ИБ, должен отвечать на несколько практических вопросов. Кто принимает решение об отключении сервера, сегмента сети или критичного сервиса. Где находятся точки экстренного управления: коммутаторы, межсетевые экраны, контроллеры домена, серверы резервного копирования. По каким каналам команда связывается, если корпоративная почта или телефония недоступны. Что делает инженер первой линии в первые минуты. Кто отвечает за уведомление руководства, юристов и регуляторов.

«Главное правило: план на три страницы, а не на тридцать. В нем должно остаться только то, что спасает, когда все “горит”. Кто и когда принимает решение об отключении, какие ключевые узлы нужны для сдерживания, какие резервные каналы связи есть у команды, что делает инженер первой линии и кто отвечает за информирование регулятора. Если в компании нет человека или четко обозначенной роли, которая в режиме “здесь и сейчас” может отключить зараженный сегмент, сервер или сеть без бесконечных согласований, наличие даже самого сильного SOC, SIEM или EDR становится бесполезным», - комментирует Иван Бурмистров, пресейл-инженер UDV Group.

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

В «золотой час» приоритет другой: ограничить движение атакующего и сохранить следы для дальнейшего анализа. Для этого зараженный хост или сегмент изолируют на коммутаторе или межсетевом экране. Трафик с хоста-жертвы запрещают во все направления, оставляя связь только с системами наблюдения, например SIEM и NTA. Это дает возможность видеть события и сетевую активность, но не позволяет злоумышленнику использовать узел как плацдарм.

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

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

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

«В первый час нужно забыть про полноценное расследование. Сначала - остановка кровотечения, потом диагноз. Команда должна изолировать зараженный сегмент, запретить трафик с хоста-жертвы на все, кроме систем наблюдения, заблокировать подозрительные учетные записи, завершить сессии, ограничить исходящий трафик и, если есть возможность, снять дамп оперативной памяти. Это не отменяет расследование, но дает шанс остановить распространение атаки и сохранить данные для анализа», - говорит Иван Бурмистров.

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

На этапе эрадикации плейбук должен помогать искать не только очевидный вредоносный файл, но и механизмы возврата. В Windows это задачи в планировщике, службы, WMI-подписки, ключи автозагрузки Run и RunOnce, папка Startup и подозрительные исполняемые файлы в пользовательских каталогах. В Linux, включая Astra Linux, РЕД ОС и Альт СП, нужно проверять добавленные SSH-ключи, cron-задачи, юниты systemd и измененные скрипты автозагрузки.

Если удалить только обнаруженный вредоносный файл, но оставить бэкдор, атака может повториться. Поэтому «очистка» системы должна начинаться не с желания быстрее вернуть сервис в работу, а с проверки мест, где злоумышленник мог закрепиться.

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

В течение первого часа генеральный директор и юрист должны получить короткую сводку: уровень критичности, возможное влияние на бизнес-процессы, риск утечки данных, связь с КИИ, персональными данными или иной регулируемой информацией, а также необходимость внешней помощи. Техническая группа подключается к действиям по сдерживанию, эрадикации и восстановлению. PR готовит сценарии внешних сообщений, но не раскрывает технические детали. Уведомление регулятора и клиентов возможно только после подтверждения ущерба и согласования с юристом.

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

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

Еще одна ошибка - запуск исполняемых файлов, библиотек, драйверов или обновлений без проверки в изолированной среде. Даже если файл лежит во внутреннем репозитории, его мог подменить злоумышленник. Нельзя возвращать сервисы в онлайн и до смены привилегированных паролей в Active Directory, на сетевом оборудовании, гипервизорах и системах резервного копирования.

«Возврат систем в онлайн нельзя воспринимать как простое восстановление из бэкапа. Сначала нужно убедиться, что резервная копия сделана до проникновения, затем проверить хосты EDR и антивирусом, посмотреть сетевой трафик за последние 72 часа после восстановления и вручную проверить ключевые серверы на скрытые механизмы автозапуска. Особенно важно сменить пароли в Active Directory и на сетевом оборудовании до включения сервисов. Если этого не сделать, злоумышленник может вернуться через оставленные учетные данные или бэкдоры», - подчеркивает Иван Бурмистров.

Минимальная проверка после восстановления должна включать полное сканирование хостов с расширенным поиском угроз, анализ сетевого трафика через NTA, межсетевой экран или IDS/IPS, а также ручную проверку критичных серверов. Особое внимание нужно уделять нехарактерным исходящим подключениям, каналам связи с командными серверами и скрытым туннелям, например внутри ICMP-пакетов. Для проверки автозагрузки на Windows-серверах можно использовать доступные инструменты вроде Autoruns из состава Sysinternals.

Если у компании нет собственного SOC или круглосуточной команды ИБ, часть задач можно автоматизировать или передать на аутсорс. Автоматизировать имеет смысл обнаружение аномалий, первичную фильтрацию ложных срабатываний, временную блокировку по индикаторам компрометации и регулярную проверку восстановления из резервных копий. Эти сценарии не заменяют человека, но сокращают время реакции на типовые угрозы.

MSSP может взять на себя круглосуточный мониторинг, первичную классификацию инцидентов, простые действия первой линии и периодический внешний аудит. Подрядчик способен фильтровать события SIEM, NTA и EDR, уведомлять ответственного сотрудника ночью или в выходные, блокировать подозрительный IP-адрес, собирать диагностические данные. Но ему нельзя отдавать решения, которые необратимо влияют на бизнес.

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

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