«Почему SOC не увидел шифровальщика?» – вопрос, который чаще всего задают, когда уже случился инцидент

Пока всё спокойно, никто не спрашивает SOC, что именно он видит, а чего не видит. Вопрос возникает постфактум – когда база уже зашифрована, а объяснить произошедшее нужно было ещё вчера.
Регулярно слышу одну и ту же историю: компания подключается к SOC по предписанию регулятора, для галочки в аудите или потому что «так положено». Экономит на охвате источников. А потом, после инцидента, выясняет отношения с провайдером: «Мы же вам платим! Почему вы это пропустили?!»😱

Разберём по существу – и с той, и с другой стороны.
 
Как это обычно выглядит на практике?
В SOC заводят не критические контроллеры домена, EDR с ключевых хостов и логи бизнес-критичных сервисов, а тестовый сегмент, пару второстепенных Linux-серверов и второстепенный файрвол. Формально требование выполнено, логи идут, отчёт для регулятора готов. Например, по факту в зоне видимости – 5% инфраструктуры.
Дальше – стандартный сценарий: фишинг на бухгалтера или забытый RDP, компрометация учётки на DC, боковое перемещение по сегменту без единого сенсора. Шифровальщик добирается до базы, бизнес встаёт.
 
Что здесь правда, а что – нет?
Правда в том, SOC анализирует только то, что ему дают. Если в зону мониторинга не попали DC, критичные хосты и периметр – задача физически нерешаемая, какой бы сильной ни была команда аналитиков. Это не вопрос компетенций, это вопрос архитектуры покрытия.
Но есть и вторая сторона, о которой честные провайдеры не молчат, если SOC на этапе подключения видит, что заказчик подключает источники-заменители вместо критической инфраструктуры, это должно быть зафиксировано в письменном виде с описанием конкретных рисков и слепых зон. Это должно быть не как формальная отписка в приложении к договору, а как понятный руководству документ: «Вот что вы видите, вот чего не видите, вот что это значит при реальной атаке».
Если этого не сделано – вина уже не только на заказчике.
 
Минимальный чек-лист охвата для реального (не бумажного) SOC:
1. Все контроллеры домена и критичные системы (AD, ADFS, PAM)
2. EDR/XDR на критичных серверах и рабочих станциях с высоким уровнем привилегий.
3. Логи периметра (VPN, публичные сервисы и т.п.).
4. Логи сегментов с критичными данными (БД, ERP, файловые хранилища).
5. Мониторинг и анализ сетевой активности ключевых узлов и сегментов с помощью NTA/NDR.
Если из этого списка закрыто меньше половины – это не MDR и не полноценный мониторинг, это дашборд для отчёта регулятору.
 
Мониторинг работает только тогда, когда видит то, что действительно нужно защищать. Всё остальное – это красивая отчётность до первого реального инцидента.

P.S. Я специально не стал затрагивать сложные таргетированные атаки и APT-группировки – это отдельный разговор. Описал только то, что на поверхности, с чем сталкиваются постоянно и что бьёт по бизнесу больнее всего.