Автор: Андрей Михалюк, CEO CoreWin
Приветствую коллег из сферы кибербезопасности и не только. Сегодня хотелось бы обсудить классический вопрос для всего IT-сектора: как восстанавливаться после инцидентов?
Конечно, хотелось бы жить в идеальном мире, где пинг всегда стабилен, загрузка процессора и оперативной памяти на всех системах не превышает 80%, а данные никогда не оказываются под угрозой. Но реальность устроена иначе. Та самая реальность за окном и та, которую обслуживают наши роутеры, коммутаторы и серверы.
Каждый IT-специалист либо уже сталкивался с восстановлением после инцидента или сбоя, либо рано или поздно столкнется. Это просто часть профессии. Хорошая архитектура, грамотное администрирование, резервное копирование, мониторинг и планирование позволяют снизить вероятность и последствия проблем, но не могут исключить их полностью.
Сбои случаются. Инциденты происходят. И будут происходить дальше.
Восстановление: что рекомендует NIST?
Для начала немного базы.
Согласно NIST SP 800-61 Rev. 2, процесс реагирования на инциденты включает четыре основных этапа:
- Подготовка
- Обнаружение и анализ
- Локализация, устранение и восстановление
- Анализ результатов инцидента
В этой статье речь пойдет о последней части третьего этапа, то есть о восстановлении.
Для простоты предположим, что угроза уже обнаружена, локализована и устранена.
При этом NIST можно считать одной из базовых основ в сфере реагирования на инциденты. Каждый из этих этапов заслуживает отдельной статьи, а то и целой книги. Поэтому тем, кто еще не знаком с этим подходом, точно стоит уделить ему время. Можно прочитать документ полностью, найти краткий обзор или даже послушать подкаст по дороге на работу.
Чтобы статья не превратилась в 50 страниц теории, введем еще одно упрощение. В самом широком смысле киберугрозы можно разделить на две категории: атаки с использованием вредоносного ПО, которые часто проводятся массово и автоматизированно, и целевые кампании конкретных групп злоумышленников.
Реальность, конечно, сложнее, но именно такое разделение помогает лучше понять несколько важных тенденций последних лет.
Тенденции
- Устранение угрозы и восстановление больше нельзя считать одним и тем же процессом. Удалить вредоносное ПО со всех затронутых систем еще не значит восстановить безопасность инфраструктуры.
- Разные категории злоумышленников оптимизируют атаки под разные цели. Одни, например операторы ransomware, делают ставку на скорость и максимальный ущерб. Другие, в том числе некоторые группы, связанные с государствами, наоборот, стараются как можно дольше оставаться незаметными внутри инфраструктуры. В таких случаях сама длительность присутствия становится частью стратегии.
- Доступ сам по себе превратился в актив. Существуют специализированные группы, задача которых заключается исключительно в получении доступа к инфраструктуре организации с последующей перепродажей этого доступа другим злоумышленникам. Для них первоначальная компрометация может быть не началом атаки, а ее конечной целью.
- Закрепление злоумышленника все чаще происходит за пределами тех систем, которые службы безопасности привыкли проверять в первую очередь. Это могут быть VPN, фаерволы, DevOps pipelines, скомпрометированные cloud-токены и другие учетные данные. Поэтому фокусироваться только на классических endpoint-системах уже недостаточно.
Дополнительные примеры современных подходов злоумышленников можно найти в M-Trends 2026.
Почему устранение угрозы еще не означает завершение инцидента?
Что все это меняет с точки зрения восстановления?
Типичный инцидент начинается с обнаружения чего-то подозрительного. SIEM генерирует alert, SOC регистрирует инцидент, а в системе появляется тикет с неприятно красным статусом и еще более неприятным уровнем приоритета. Письма начинают лететь в сторону CISO и команды, отвечающей за затронутую систему. Затем наступают знакомые стадии: отрицание, гнев, торг, а потом уже непосредственно техническая работа.
В какой-то момент непосредственную причину инцидента удается устранить. И вот здесь начинается самое интересное.
На практике команды часто начинают воспринимать весь инцидент через событие, которое его обнаружило. Это может быть несанкционированный доступ из неизвестного источника, компрометация production-системы или передача конфиденциальных данных.
Но первый заметный сигнал вовсе не обязательно является началом атаки.
Он может указывать на lateral movement, проверку ценности определенного файла, попытку создать дополнительный backdoor или просто на тот момент, когда злоумышленник, который уже несколько дней или недель находится внутри инфраструктуры, наконец сделал что-то достаточно заметное, чтобы сработало обнаружение.
При этом исходная точка доступа может находиться совсем не там, где ее искали в первую очередь: в забытом сетевом устройстве, принтере или, в особенно неудачном сочетании удобства и плохой безопасности, в кофемашине с Wi-Fi.
Это не означает, что обнаружение и защита не нужны. Наоборот, чем больше у организации источников телеметрии и защитных механизмов, тем лучше.
Например:
- EDR/XDR, например Cynet
- DLP, например Netwrix Endpoint Protector
- IAM
- аудит Active Directory
- сетевой сканер уязвимостей, например OPENVAS (Enterprise)
- антивирус
- фаервол
- VPN
- SIEM
- SOC
Все это действительно необходимо. Но следующий вопрос гораздо интереснее: что делать после того, как эти инструменты начали генерировать события и доказательства?
От отдельных инцидентов к полной картине атаки
Здесь проблема начинает напоминать то, с чем бизнес столкнулся примерно десять лет назад: Big Data. Да, именно тот самый Big Data, который когда-то появлялся почти в каждой презентации и статье примерно так же, как сегодня AI.
Для финансовых, торговых и логистических команд проблема заключалась не просто в наличии данных. Их стало слишком много, они поступали из слишком большого количества источников и хранились в разных форматах и системах. Одновременно с этим время на принятие решений сократилось с месяцев и лет до недель, а иногда и дней.
Ответом стал не один инструмент, а целый слой технологий, объединяющих разрозненную информацию. Data Virtualization и Data Lake помогали собирать и агрегировать данные, а Business Intelligence и Data Analysis превращали их в информацию, пригодную для принятия решений.
Кибербезопасность постепенно сталкивается с очень похожей проблемой. SIEM и SOC хорошо справляются с обнаружением событий и реагированием в реальном времени, но существует еще один уровень анализа, которому стоит уделять больше внимания: сбор критически важных событий безопасности за длительный период, их корреляция и поиск связей, которые невозможно увидеть, если каждый alert рассматривать отдельно.
Можно представить это так. Реагирование на отдельный alert похоже на выезд патрульной машины на место преступления. Это необходимо. Но если в разных частях города произошло пять похожих преступлений, кто-то должен собрать доказательства по всем пяти случаям, сравнить их, найти закономерности и понять, связаны ли они между собой. Это уже не патрульная работа. Это расследование.
Кибербезопасности нужен такой же подход. Вместо одного вопроса «Что произошло на этой системе?» стоит задавать и другие: что происходило до этого, что произошло после, какие учетные записи, хосты, приложения, сетевые устройства и cloud-ресурсы были задействованы и могут ли несколько на первый взгляд несвязанных alerts на самом деле быть разными этапами одной атаки?
Такой подход может помочь обнаруживать и тех злоумышленников, которые пока просто «ждут» внутри инфраструктуры. После тихой компрометации им требуется время на изучение среды, и именно в этот период часто возникают ошибки: необычная команда reconnaissance, странная попытка аутентификации, запрос к внутреннему сервису или низкоприоритетный alert, который сам по себе не выглядит опасно.
По отдельности эти события могут не вызывать особого внимания. Вместе они могут рассказывать совершенно другую историю.
Восстановление работы и проверка безопасности
Но вернемся из мира «было бы хорошо» в реальность. В какой-то момент любой инцидент упирается в практический вопрос: можно ли вернуть затронутый сервис в работу?
И здесь важно разделять восстановление доступности и завершение самого инцидента.
Инцидент стоит считать завершенным не тогда, когда сервис снова работает, а тогда, когда команда может аргументированно объяснить, как злоумышленник попал в инфраструктуру, насколько далеко он продвинулся, какие механизмы доступа или закрепления мог создать, почему эти механизмы больше не работают и какими данными телеметрии это подтверждается.
Вернуть сервис в online – только часть восстановления. Гораздо сложнее вернуть уверенность в том, что злоумышленник действительно больше не присутствует в инфраструктуре, что не осталось дополнительных каналов доступа и что учетные данные, токены, системы автоматизации, cloud-ресурсы или сетевые устройства не остались скомпрометированными.
И желательно, чтобы эта уверенность строилась на доказательствах, а не на надежде.
Как системно решать эту задачу, вопрос открытый. Организации со зрелыми командами реагирования могут встроить ретроспективный анализ непосредственно в incident response process. Если отдельной команды нет, кто-то все равно должен взять эту задачу на себя.
И здесь остается более широкий вопрос для CISO: как перейти от простой реакции на отдельные alerts к восстановлению полной последовательности атаки? Как коррелировать события, строить карту возможных действий злоумышленника и определять, что он все еще может контролировать внутри инфраструктуры?
Потому что вернуть сервис в online недостаточно.
В конце концов, кому-то все равно придется найти гада, который спрятался внутри инфраструктуры, и вышвырнуть его из системы. 😊
