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

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

Договор не заменяет готовность

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

На практике план реагирования часто живёт отдельно от реальных систем. В документе указан ответственный, но его учётная запись не имеет нужных прав. В списке есть консоль EDR, Endpoint Detection and Response (англ. выявление угроз на рабочих станциях и реагирование), но никто не знает, кто может выдать доступ внешним экспертам. Логи собираются, но хранятся слишком мало.

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

Сначала — учётные записи и права

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

В первые часы расследователям нужен доступ на чтение к провайдеру идентификации, каталогам пользователей, SSO, Single Sign-On (англ. единый вход), событиям многофакторной проверки, выпуску токенов и изменениям прав. Им также нужен понятный путь для срочных действий: сброса паролей, отзыва сессий, временного ограничения администраторских аккаунтов.

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

Облако и рабочие станции нельзя подключать по ходу пожара

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

Команде нужны права на просмотр облачных подписок, SaaS-платформ, журналов аудита, настроек ролей, рабочих нагрузок, ключей и секретов. Часть телеметрии живёт недолго. Если её не забрать сразу, она исчезнет до того, как расследователи поймут масштаб атаки.

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

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

Четырнадцать дней логов — слишком мало

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

По данным специалистов по расследованию, срок хранения в 14 дней всё ещё встречается часто. Для реального анализа этого мало: атакующий может находиться в сети неделями до сигнала тревоги. Минимальной базой эксперты называют 90 дней для ключевых источников.

К таким источникам относятся SIEM, Security Information and Event Management (англ. управление событиями безопасности), межсетевые экраны, системы обнаружения атак, почтовая защита, облачные журналы, события удалённого доступа и SaaS-аудит. Если эти данные разбросаны по разным панелям, закрыты отдельными администраторами или быстро удаляются ради экономии, компания сама снижает свои шансы на точное расследование.

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

Каналы связи тоже могут быть скомпрометированы

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

Компании нужен отдельный канал связи, не завязанный на основной корпоративный контур. Его стоит проверить заранее: кто добавляет участников, где хранятся контакты, как передаются чувствительные файлы, что делать, если основной мессенджер недоступен. Иначе первые минуты уйдут на бытовую диагностику вроде запросов «is discord down» или «дискорд вечная загрузка при входе», а не на сдерживание атаки.

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

Что проверить до первого тревожного звонка

  • Составьте список систем, к которым команда реагирования должна получить доступ в первые часы: учётные записи, облако, EDR, SIEM, почта, сетевые журналы.
  • Создайте заранее согласованные роли с доступом на чтение и отдельным порядком для срочных действий: сброса паролей, отзыва токенов, изоляции узлов.
  • Проверьте многофакторный вход для внутренних и внешних расследователей до инцидента, а не во время атаки.
  • Увеличьте хранение ключевых логов минимум до 90 дней там, где это критично для расследования.
  • Проведите учение: засеките, сколько времени уходит от объявления инцидента до доступа к нужным консолям.
  • Подготовьте отдельный канал связи на случай, если корпоративная почта и чат окажутся под контролем злоумышленника.
  • Назначьте владельцев каждой консоли и зафиксируйте, кто может включить доступ ночью, в выходной или во время отпуска администратора.
  • После учения уберите лишние права и сохраните журнал всех действий, чтобы быстрый доступ не превратился в новую дыру в защите.
Поделиться: