Реагирование на инциденты
Реагирование на инциденты это структурированный процесс обнаружения, сдерживания, устранения причины и восстановления после инцидента безопасности, за которым следует разбор того, что вообще позволило инциденту произойти.
Почему заранее подготовленный план меняет исход
Принимать решения о сдерживании, расследовании и восстановлении во время активного взлома приводит к более медленным и ошибочным решениям, чем следование плану, написанному спокойно заранее, когда нет давления и не идёт отсчёт времени.
Шаг, который чаще всего пропускают
Разбор после восстановления, изучение того, что вообще позволило инциденту произойти, представляет собой шаг, который чаще всего пропускают, как только сервис снова онлайн, и именно так одна и та же первопричина позже вызывает повторный инцидент.
Пошаговый разбор реального взлома читайте в нашем руководстве по реагированию на взлом сервера.
Как фазы реагирования выглядят на одном VPS
В апреле 2025 года NIST опубликовал SP 800-61 Revision 3, заменивший редакцию Revision 2 от 2012 года. В аннотации реагирование на инциденты описано как часть повседневного управления киберрисками (в связке с CSF 2.0), а не отдельная аварийная процедура: подготовиться к инцидентам, снизить их число и последствия и улучшить обнаружение, реагирование и восстановление. Подробности на странице публикации NIST.
В плейбуке CISA по реагированию на инциденты это превращено в пять рабочих фаз: подготовка, обнаружение и анализ, сдерживание, устранение и восстановление, действия после инцидента. Подготовка включает разработку и проверку сценариев сдерживания и устранения, а также организацию сбора криминалистических данных.
На небольшом VPS подготовка это в основном короткая записка: у кого есть root, как попасть на сервер, если SSH недоступен (консоль провайдера), из какой резервной копии вы будете восстанавливаться и когда её проверяли, и где хранится копия логов вне машины. Два недостающих чаще всего элемента разобраны в руководстве по резервным копиям 3-2-1 и руководстве по анализу логов.
Сохраните доказательства, прежде чем что-либо менять
Любое действие по очистке перезаписывает то, что хотел бы увидеть следователь. RFC 3227 перечисляет данные от самых до наименее изменчивых: регистры и кэш, затем таблица маршрутизации, таблица процессов и память, затем временные файловые системы, затем диск, затем данные удалённого журналирования. Там же сказано не доверять программам на подозрительной системе, так как руткит может заставить их лгать.
Плейбук CISA требует делать криминалистические образы на этапе сдерживания и сохранять доказательства до начала устранения. Если провайдер предлагает снапшоты, сделайте его первым. Для быстрой записи текущего состояния сохраните вывод вне сервера:
ss -tupan > ss.txt
ps auxf > ps.txt
last -a -F > last.txtСчитайте это лишь ориентиром, потому что команды используют собственные бинарные файлы сервера. Не перезагружайте и не переустанавливайте систему, пока не снято всё нужное: перезагрузка стирает память и состояние процессов. Когда доказательства в безопасности, продолжайте по руководству по реагированию на взлом.
Связанные термины: Сдерживание, RECOVERED и VERIFIED, Мониторинг целостности файлов, SIEM.
Часто задаваемые вопросы
Действительно ли малому бизнесу нужен формальный план реагирования на инциденты?
Да, даже короткий и простой. Заранее согласованные шаги для сдерживания, коммуникации и восстановления заметно снижают как время простоя, так и стресс при принятии решений во время реального инцидента.
Какой первый шаг в реагировании на инциденты?
Сдерживание, то есть остановка распространения инцидента, как правило идёт раньше полного расследования или зачистки, так как несдержанный взлом может продолжать усугубляться во время анализа.
Кто должен быть вовлечён в реагирование на инциденты даже в небольшой компании?
Как минимум все, у кого есть доступ к серверу и полномочия принимать решения, плюс понятный путь эскалации к тем, кого может потребоваться привлечь, например хостинг-провайдеру или подрядчику по безопасности.
Является ли восстановление из бэкапа полноценным реагированием на инцидент?
Нет. CISA называет переустановку из заведомо чистых источников одним из шагов устранения, но также требует закрыть уязвимость или условие, которым воспользовались. Восстановление, оставляющее ту же слабость или возвращающее бэкдор вместе с данными, приглашает повторный инцидент.
Когда нужно собирать доказательства?
До устранения. CISA просит убедиться, что учтены все способы постоянного доступа и собраны все доказательства, и только потом удалять артефакты, а RFC 3227 советует сначала собирать самые изменчивые данные.
Хотите увидеть, в каком состоянии ваш сервер?
Запустите бесплатную read-only проверку сервера или откройте Security Lab и посмотрите цикл обнаружение, сдерживание, восстановление, проверка в действии.
Получить бесплатную проверку сервераОткрыть Security Lab