SOC или MDR: как выбрать и не переплатить за безопасность

Главное за две минуты

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

Если в компании нет своего ИБ-подразделения с круглосуточной сменой, MDR в большинстве случаев экономит деньги, а не добавляет расходов. Парадоксально, но это так. Дальше объясняем почему.

Откуда вообще взялась путаница между SOC и MDR

Десять лет назад SOC означал одно и то же у всех. Пользовательские помещения с дюжиной мониторов, аналитики первой и второй линии, SIEM посередине, корреляционные правила на стене. Дальше произошло то же, что произошло с любой технологической категорией. Маркетологи начали добавлять префиксы. Появились SOC as a Service, hybrid SOC, virtual SOC, MSSP, MDR, XDR и ещё десяток названий. Часть из них действительно описывает разные подходы. Часть является пересборкой того же самого с новой обёрткой.

Чтобы не утонуть в терминологии, проще ориентироваться на один вопрос. Кто принимает действия, когда срабатывает алерт? Если ответ "ваша команда" — это классический SOC. Если ответ "команда провайдера" — это MDR. Всё остальное является вариациями этих двух подходов.

Что вы получаете в формате SOC как сервис

Сервисный SOC обычно включает три блока. Сбор и нормализация логов из ваших источников: межсетевых экранов, EDR, серверов, облачных сервисов, прокси, DNS, директорийных служб. Корреляция и обогащение событий в SIEM по правилам, которые провайдер либо предоставляет из коробки, либо создаёт под вашу инфраструктуру. Уведомление о подтверждённых инцидентах через тикет-систему, мессенджер, звонок или электронную почту, в зависимости от соглашения.

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

Такая модель работает, если у вас есть собственное ИБ-подразделение с дежурной сменой 24/7, готовое реагировать в любое время суток. Также она работает, если у вас есть формализованные плейбуки, которые позволяют дежурному инженеру действовать без эскалации до архитектора в три часа ночи. На практике обоих условий одновременно нет почти ни у кого, кроме крупных корпораций финансового сектора и КИИ.

Что добавляет MDR

Managed Detection and Response расширяет картину тремя ключевыми элементами. Активное реагирование на инциденты внутри согласованного периметра. Команда провайдера сама изолирует заражённые узлы, отключает скомпрометированные учётные записи, блокирует подозрительные процессы, останавливает горизонтальное распространение. Расследование инцидента силами провайдера. Восстановление хронологии атаки, определение точки входа, оценка масштаба компрометации, поиск артефактов закрепления. Регулярная проактивная охота на угрозы. Не только ожидание срабатывания правил, но и активный поиск аномалий, индикаторов компрометации и поведенческих паттернов, которые могут не давать прямых алертов.

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

Реальная стоимость владения и почему MDR часто оказывается дешевле

Сравнение по бирке "цена контракта" часто вводит в заблуждение. SOC выглядит дешевле, чем MDR, если смотреть только на ежемесячный платёж. Реальный расчёт совсем другой, потому что SOC требует от вас построить или сохранить внутренний ресурс реагирования. Этот ресурс нужно учитывать в TCO.

Минимальная команда внутреннего реагирования с покрытием 24/7 это четыре человека дежурной смены плюс архитектор и руководитель направления. По ставкам 2026 года в крупных российских городах стоимость такой команды с учётом налогов и накладных расходов начинается от четырнадцати миллионов рублей в год. Это нижняя граница для младших аналитиков. Реальный SOC второй линии стоит ближе к двадцати четырём миллионам в год.

Контракт на качественный MDR для среднего бизнеса размером в две тысячи устройств в нашей отрасли стоит ориентировочно от шести до двенадцати миллионов рублей в год, в зависимости от объёма источников и SLA. Даже с учётом частичной поддержки внутреннего ИБ-инженера это получается заметно дешевле, чем строить полноценную дежурную смену с нуля.

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

Когда классический SOC всё-таки правильный выбор

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

Первый случай — когда у вас уже есть собственный ИБ-департамент с круглосуточной сменой и налаженными процессами. Тогда передача реагирования наружу создаёт лишние интерфейсы и замедляет принятие решений. Достаточно качественного источника алертов. Второй случай — когда вы работаете с особыми режимами обработки, при которых внешний оператор не может физически касаться ваших систем. Государственная тайна, отдельные виды финансовых данных, медицинские записи под жёсткими режимами. Третий случай — когда специфика вашего бизнеса делает реагирование настолько контекстно-зависимым, что внешняя команда не сможет принимать решения быстрее ваших инженеров. Это редкий случай, и обычно он касается научно-технических разработок с уникальной инфраструктурой.

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

Что обязательно проверить в контракте

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

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

Объём активных действий по реагированию. Что именно провайдер имеет право делать без вашего подтверждения. Изоляция узла из сети. Блокировка учётной записи. Завершение процесса. Откат системного образа. Без этой ясности на бумаге MDR превращается обратно в SOC в момент первого серьёзного инцидента.

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

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

Регулярная отчётность. Ежемесячный отчёт об активности и инцидентах, ежеквартальный обзор тенденций, регулярные тестовые учения. Без отчётности невозможно объективно оценить, работает ли сервис вообще.

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

Типичные ошибки при внедрении

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

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

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

Третья ошибка — отсутствие реальных учений. Контракт подписан, отчёты приходят, метрики красивые. До первого реального инцидента, на котором выясняется, что плейбук написан без учёта особенностей корпоративной сети, и реагирование занимает в два раза больше времени, чем планировалось. Минимум раз в полгода нужно проводить настольные учения по согласованным сценариям.

Четвёртая ошибка — игнорирование внутреннего обучения. SOC или MDR это инструмент, а не замена корпоративной кибергигиены. Если ваши сотрудники продолжают переходить по фишинговым ссылкам, никакой провайдер не остановит это полностью. Программа awareness должна идти параллельно с внедрением сервиса мониторинга.

Гибридные модели и куда движется рынок

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

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

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

Простой алгоритм выбора

Если вы дочитали до этого места и всё ещё сомневаетесь, вот короткий алгоритм для принятия решения.

У вас есть собственная команда ИБ с круглосуточной сменой и плейбуками реагирования? Тогда подходит классический SOC как сервис, потому что вам нужны качественные алерты, а не дублирование внутренней функции.

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

У вас нет ни круглосуточной смены, ни внутренней экспертизы по инцидентам? Тогда подходит полный MDR с активным реагированием по всему периметру, в дополнение к программе обучения внутренней команды.

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

Что делать дальше

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