MDR (Managed Detection and Response): что это такое и кому нужно в 2026 году?

17.06.2026

Алексей Мишаев

Автор

Модель управляемых сервисов информационной безопасности (MSSP) представлена на российском рынке не первый год. Но у классического MSSP есть системная проблема — он слаб в доведении инцидента до устранения. Клиент получает ворох алертов, часто с высоким уровнем шума, и всё равно должен был содержать квалифицированную команду, чтобы эти алерты интерпретировать и реагировать.

Именно из этого запроса родился класс сервисов Managed Detection and Response (MDR) — управляемое обнаружение и реагирование. Это эволюционное развитие MSSP, где провайдер берёт на себя не только мониторинг, но и активное подавление атаки: изоляцию хостов, блокировку сетевых соединений, запуск плейбуков по реагированию, а иногда и полное восстановление работоспособности сервиса. Клиенту остаётся контроль и принятие стратегических решений.

Для России MDR особенно актуален: уход западных вендоров заставил пересматривать подходы к аутсорсингу безопасности. Отечественные провайдеры активно развивают MDR-предложения, часто в связке с собственной телеметрией от EDR, NDR и сетевых средств. При этом один провайдер может называть MDR то, что другой считает просто расширенным MSSP.

Кибер Медиа рассмотрит, чем MDR отличается от традиционного MSSP, какие услуги входят в типовой контракт, кому такой сервис принесёт максимальную пользу, а для кого станет неоправданными затратами.

Содержание

Что такое MDR и чем он отличается от других подходов к мониторингу

MDR это управляемый сервис, в рамках которого внешний провайдер берёт на себя непрерывный мониторинг инфраструктуры клиента, обнаружение киберинцидентов и, что самое важное, активное реагирование на них. В классическом определении Gartner, MDR предоставляет удалённые возможности «как сервис» для управления средствами обнаружения и реагирования, включая анализ событий, «охоту за угрозами» (threat hunting) и контролируемые действия по блокированию или изоляции атакованных активов.

Ключевое отличие MDR от традиционного аутсорсинга ИБ заключается в «реагировании». MSSP-провайдер обычно доводит до клиента информацию о подозрительном событии, но не имеет прав или технических средств для его подавления. В модели MDR провайдер не только обнаруживает инцидент, но и инициирует контрмеры: изолирует заражённый хост в EDR, блокирует сетевые соединения на межсетевом экране, отключает скомпрометированную учётную запись, запускает плейбук по удалению вредоносного ПО. В некоторых случаях в контракт включается даже восстановление работоспособности сервисов после атаки.

Алексей Кузнецов

Генеральный директор CICADA8

MDR – не «лицензия EDR у подрядчика» и не полноценный SOC. В случае с MDR подрядчик отвечает за обнаружение и реагирование на инциденты там, где стоит его агент. В отличие от него, основная задача типичного MSSP – мониторинг СЗИ и отправка алертов. Здесь не предусмотрено полного цикла реагирования на инциденты. SOC – шире MDR: такой центр занимается мониторингом и обработкой инцидентов по всей организации. У зрелых внутренних и сервисных SOC управление уязвимостями (VM) обычно сшито с мониторингом: что патчить в первую очередь, исходя из экспозиции и актуальных угроз.

Для этого MDR-провайдер разворачивает на площадке клиента лёгкие агенты (часто на базе EDR-решения), а также может получать телеметрию из сетевых источников. Аналитики не просто наблюдают, а активно действуют в рамках SLA. Провайдер может автоматически изолировать хост или требовать согласование на удаление сервиса. SLA в MDR измеряются не временем доставки уведомления, а временем начала реагирования.

В реальности же границы между MSSP и MDR могут размываться. Некоторые российские провайдеры предлагают гибридные модели: базовый мониторинг на уровне MSSP и опциональный пакет активного реагирования как MDR.

Ольга Луценко

Консультант по информационной безопасности «КИТ»

Главное отличие – в совокупности технических и организационных сервисов, проактивном обнаружении угроз и помощи в восстановлении систем в случае инцидента. Провайдер не только фиксирует события, но и ведёт активный поиск скрытых угроз (Threat Hunting), и, что критически важно, имеет полномочия на блокировку/изоляцию узла до согласования с заказчиком в рамках четко оговоренного регламента.

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

Кому нужен MDR, а кому — нет

MDR не является универсальным решением «для всех». Во многих случаях компания может переплачивать за ненужный функционал или ожидать от MDR того, что он не может дать по определению.

Для начала разберём портрет компании, которой MDR выгоден и нужен.

Ольга Луценко

Консультант по информационной безопасности «КИТ»

Оптимальным решением MDR можно считать для:

субъектов КИИ, которые обязаны по 187-ФЗ мониторить инциденты и взаимодействовать с ГосСОПКА, но строить свой SOC им дорого и бюрократически сложно;

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

бизнеса, который прошел аудит и понял, что количество алертов от купленного EDR/XDR превышает возможности штатного специалиста по информационной безопасности.

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

Вторая категория — компании, у которых уже есть собственный SOC, но он перегружен или не справляется с объёмом событий. Например, это частая ситуация в финансовых организациях, у ритейлеров или промышленных холдингов. Их аналитики тонут в ложных срабатываниях, не успевают за сложными угрозами, а время реакции на реальный инцидент превышает допустимые лимиты. MDR в такой ситуации выступает надстройкой: провайдер берёт на себя рутинный мониторинг и первую линию реагирования, а собственный SOC фокусируется на стратегических задачах, расследовании сложных инцидентов и взаимодействии с бизнесом.

Андрей Шаляпин

Руководитель BI.ZONE TDR

Ключевое отличие MDR от покупки лицензий EDR: MDR — это сервис поверх технологии EDR. Отличия заключаются в процессах, людях и компетенциях. EDR-решение не может существовать автономно и требует постоянного контроля и тонкой настройки квалифицированными аналитиками. В рамках MDR клиент получает не просто инструмент, а экспертизу и опыт команды аналитиков, которые защищают инфраструктуру заказчика 24/7.

Третья категория — дочерние структуры и зрелые стартапы, которые используют облачную инфраструктуру и не имеют физических серверов. Классический MSSP для облачных сред работает плохо, потому что сбор сетевой телеметрии и логов ограничен. MDR-провайдеры, поддерживающие агентную модель (EDR, работающий на виртуальных машинах в облаке), обеспечивают и мониторинг, и реагирование в таких средах. Это особенно актуально для компаний, которые разрабатывают и хостят свои сервисы в российских облаках и обязаны защищать персональные данные.

Наконец, четвертая категория — компании, которые уже пострадали от атаки и хотят гарантированно защититься от повторения. У них есть бюджет, испорченный опыт и желание передать безопасность профессионалам. MDR с провайдером, имеющим доказанную экспертизу в расследовании инцидентов и противодействии APT-группировкам, для них — разумная страховка.

Теперь о том, кому MDR не нужен или даже вреден. Микробизнес и совсем маленькие компании (до 20 сотрудников, один сервер, коробочная бухгалтерия). У них обычно нет цифровых активов, интересных для серьёзного злоумышленника, а бюджет на ИБ близок к нулю. Им достаточно базовых средств защиты — антивируса, фаервола, регулярных бэкапов и здравого смысла. MDR для них будет дорогим и избыточным. Альтернатива — бесплатные или дешёвые облачные антивирусы с базовым EDR.

Алексей Кузнецов

Генеральный директор CICADA8

Крупный бизнес чаще строит полноценные SOC, а малый и микробизнес в большинстве своем еще не дозрел до MDR или SOC – там важнее базовая кибергигиена и осознание рисков. Поэтому основной заказчик MDR – средний бизнес, который ищет более доступный вариант классического SOC.

Компании со зрелым и полностью укомплектованным SOC, который демонстрирует стабильные показатели MTTD (время обнаружения) и MTTR (время реагирования), удовлетворяющие бизнес-требованиям. Если у вас есть своя команда уровня L3, процессы охоты за угрозами и бюджеты на развитие — MDR не добавит ценности, а только создаст лишний интерфейс согласования. Исключение — ситуация, когда собственный SOC не справляется с объёмом телеметрии из-за роста бизнеса, но это уже попадает во вторую категорию выше.

Андрей Шаляпин

Руководитель BI.ZONE TDR

Если у компании уже есть собственный центр мониторинга (как правило, это крупные компании и холдинги), то для таких организаций в первую очередь необходимо решение класса EDR, которое будет интегрировано в технологический стек собственного SOC. Однако даже компании с собственным SOC иногда прибегают к услугам MDR-провайдеров в качестве «второго мнения» — для усиления собственного центра мониторинга и получения дополнительной экспертизы.

Организации, которые работают с государственной тайной или информацией особой важности (по лицензии ФСТЭК). Для них законом может быть предписано использование только сертифицированных средств и недопустимость передачи данных третьим лицам (включая MDR-провайдера). В этом случае аутсорсинг мониторинга и реагирования невозможен — только собственный SOC.

Наконец, компании, которые не готовы предоставить провайдеру необходимый уровень доступа к своей инфраструктуре. MDR требует установки агентов на рабочие станции и серверы, а иногда и настройки сетевого сбора телеметрии. Если внутренние политики безопасности или культура «мы никому не даём доступ» блокируют это — MDR не взлетит. В таком случае остаётся только MSSP на основе логов (без агентов), но он не даст возможностей активного реагирования.

Помимо определения целевой аудитории, есть несколько критериев, которые помогают компании самой оценить, нужен ли ей MDR. Задайте себе пять вопросов.

Может ли компания в течение 15–30 минут отреагировать на киберинцидент в нерабочее время — ночью, в выходные, в праздники?
Есть ли внутренняя экспертиза по работе с EDR, анализу MITRE ATT&CK, проведению threat hunting?
Какой реальный уровень «шума» от систем безопасности — удаётся ли в сотнях алертов, поступающих за день, отделить важную информацию от ложных срабатываний?
Есть ли необходимость выполнять регуляторные требования к мониторингу и реагированию?
Какова цена потенциального простоя бизнеса при успешной атаке (например, шифровальщиком) в сравнении с годовой стоимостью MDR?

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

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

Российский рынок MDR в 2026 году

Российский рынок MDR-сервисов переживает бурный рост. Коммерческие центры мониторинга безопасности (SOC) и сервисы управляемого обнаружения и реагирования стали одним из самых быстрорастущих сегментов отечественной ИБ-индустрии.

Драйверы этого роста хорошо известны: кадровый голод, усложнение ландшафта угроз и уход зарубежных вендоров с их managed-сервисами. В итоге рынок развивается силами отечественных вендоров, каждый из которых строит сервис на базе собственных технологий и решений.

Ключевых игроков на российском рынке MDR условно можно разделить на несколько категорий.

Вендоры с собственной технологической платформой. Это компании, которые изначально разрабатывали средства защиты (EDR, SIEM, XDR) и на их основе построили managed-сервис. Среди них — «Лаборатория Касперского» с сервисом Kaspersky MDR. Это решение обеспечивает непрерывный мониторинг, проактивный поиск угроз и реагирование силами экспертов, включая сдерживание атак и рекомендации по усилению защиты ИТ- и ОТ-сегментов.

Другой крупный вендор — Positive Technologies с сервисом PT Expert Security Center. Компания обладает глубокой экспертизой в области безопасности приложений и сетевой инфраструктуры, а также собственными SIEM- и NTA-решениями. Их MDR-сервис построен на этой технологической базе и ориентирован на крупный бизнес, включая государственный сектор и финансовые организации.

F6 предлагает Managed XDR, объединяющий в себе возможности EDR, NDR и сетевых песочниц. Ключевое преимущество — опора на собственную разведку угроз (Threat Intelligence), что позволяет эффективно выявлять целевые атаки и APT-группировки. Отличительной чертой является использование данных собственной системы киберразведки F6 Threat Intelligence для оперативного отслеживания новых тактик и инструментов атакующих.

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

Другой подобный сервис предлагает BI.ZONE, объединяя классический «SOC-as-a-Service» и полноценный MDR. Компания предлагает мониторинг и активное реагирование с помощью собственных сенсоров BI.ZONE, выявление инцидентов (включая передовые атаки) по телеметрии, собираемой с конечных точек с помощью EDR.

RED Security, открытая экосистема ИБ-решений, в 2025 году запустила MDR-сервис, ориентированный на компании, которым необходим круглосуточный мониторинг и оперативное реагирование, но которые пока не готовы инвестировать в подключение всей инфраструктуры к SOC. В рамках сервиса специалисты RED Security SOC обеспечивают непрерывный мониторинг событий, выявление подозрительной активности и оперативное блокирование действий злоумышленников на серверах и рабочих станциях заказчика.

Системные интеграторы с собственной MDR-практикой. ГК Softline активно развивает сервис MDR и SIEM-as-a-service. Клиент получает полноценный конвейер обнаружения и реагирования: сбор и нормализацию событий, корреляцию, готовые плейбуки реагирования и круглосуточную команду, которая закрывает инцидент до того, как он станет кризисом.

В число значимых игроков также входит Angara Security. Компания оказывает услуги SOC/MDR множеству заказчиков и укрепила свою экспертизу, внедрив в свой SOC решение BI.ZONE Sensors для усиления возможностей защиты конечных точек.

При выборе провайдера MDR на российском рынке стоит обращать внимание на несколько ключевых параметров. Во-первых, это технологический стек — на каких средствах сбора телеметрии построен сервис (EDR какого вендора, есть ли NDR, SIEM, XDR). Во-вторых, необходимо убедиться, что провайдер имеет лицензию ФСТЭК России на деятельность по технической защите конфиденциальной информации (ТЗКИ) — это обязательное требование для легального оказания услуг мониторинга и реагирования. В-третьих, важно оценить уровень SLA — время реакции, доступность аналитиков 24/7, процедуры эскалации. В-четвёртых, отраслевая экспертиза: не все MDR-сервисы одинаково хорошо понимают специфику ритейла, промышленности, финансового сектора или КИИ. И наконец, в-пятых, прозрачность отчётности: получает ли клиент детальные данные о том, как инцидент был обнаружен и обработан, или только обезличенные метрики.

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

Что важно учесть при выборе провайдера MDR и запуске сервиса

Выбор провайдера нельзя сводить к сравнению ценников. Дешёвый MDR с непонятными компетенциями и отсутствием лицензий может оказаться переупакованным MSSP, где реагирование сводится к пересылке уведомлений на вашу почту. А дорогой MDR от крупного вендора может включать функции, которые на самом деле не нужны (например, threat hunting на уровне APT, если основной риск для компании — это рядовые шифровальщики).

Первый критерий для выбора провайдера — наличие лицензии ФСТЭК России на техническую защиту конфиденциальной информации (ТЗКИ). Без неё поставщик сервиса не имеет права законно обрабатывать данные, которые могут содержать ПДн, коммерческую тайну или иную охраняемую информацию. Убедитесь, что скоуп покрывает именно managed-сервис, а не просто консалтинг. Некоторые провайдеры работают по договорам, где лицензия формально есть у заказчика, а провайдер выступает субподрядчиком — такая схема возможна, но требует отдельной юридической проверки.

Второй критерий — технологический стек и возможности развёртывания. Уточните, на базе каких решений строится сбор телеметрии: собственный EDR провайдера, лицензионный EDR стороннего вендора или смешанный вариант с NDR и SIEM. Важно, чтобы агент MDR был совместим с вашей ОС (Windows, Linux, Astra Linux, ОС Аврора, Альт и др.) и не конфликтовал с уже установленным антивирусом или другими средствами защиты. Также спросите, как обрабатываются «слепые зоны» — например, серверы без возможности установки агента, legacy-системы, промышленные контроллеры. Хороший провайдер предложит компенсирующие меры: мониторинг через syslog, зеркалирование портов, использование сетевых датчиков.

Третий критерий — SLA и процедуры реагирования. Запросите детальное описание того, что произойдёт в реальном инциденте. Какие действия аналитик может предпринять автоматически (без вашего подтверждения), какие — только после согласования, и в какие сроки. Типичный пример: изоляция заражённого хоста может происходить автоматически в течение 1–5 минут после детектирования, а удаление критического системного файла потребует звонка ответственному лицу. SLA должно содержать метрики: MTTA (время до подтверждения инцидента), MTTR (время до начала реагирования), а также чётко прописанные каналы эскалации на случай, если дежурный аналитик не справляется.

Четвёртый критерий — состав команды и их сертификации. MDR работает на людях, а не на софте. Попросите провайдера рассказать о квалификации аналитиков SOC: есть ли у них сертификации, как часто они проходят переаттестацию, как организовано обучение на новых тактиках атакующих. Уточните, работает ли провайдер по модели «следуй за солнцем» или аналитики сидят только в московском часовом поясе.

Пятый критерий — опыт в вашей отрасли. Запросите case study или, если позволяет конфиденциальность, рекомендации от текущих клиентов из той же вертикали. Банки, промышленность, ритейл, госсектор имеют разную регуляторику, разные типы активов и разные атакующие. Провайдер, который десять лет защищает финансовые организации, может не понимать специфику АСУ ТП на заводе. Также поинтересуйтесь, как провайдер обрабатывает инциденты, связанные с КИИ, и есть ли у него собственное подразделение по реагированию на такие атаки.

Шестой критерий — прозрачность и отчётность. Что именно клиент видит в портале или дашборде? Получает ли он детальный timeline инцидента: что было обнаружено, какие действия предприняты, какие правила сработали, какой MITRE ATT&CK техники затронуты? Или только «всё хорошо, инцидентов нет»? Для внутреннего аудита и отчётности перед регулятором (например, при проверке Банка России или Роскомнадзора) обязателен детальный трейс.

Подводные камни при запуске MDR

Даже выбрав «правильного» провайдера, можно столкнуться с проблемами на этапе запуска. Администраторы не любят, когда кто-то посторонний получает доступ к серверам и тем более может их изолировать или блокировать. Без их поддержки внедрение MDR превратится в постоянное противоборство. Решение — вовлечь ИТ-команду на раннем этапе, объяснить, как MDR дополняет их работу. Также стоит чётко разграничить зоны ответственности: например, MDR управляет только EDR-агентом на ОС, а сетевое оборудование остаётся под контролем ИТ.

Проблема вторая: ложные срабатывания в первые недели. Первое время аналитики провайдера могут присылать уведомления о легитимных действиях администраторов (установка ПО, запуск PowerShell‑скриптов) как о подозрительных. Чтобы сократить поток, нужно с самого начала провести учёт штатных процессов, административных хостов, разрешённых сценариев. Это совместная работа провайдера и клиента.

Ещё один важный момент — совместимость с существующими средствами защиты. MDR-агент может конфликтовать с уже установленным антивирусом, DLP-системой или агентом резервного копирования. Перед пилотным внедрением обязательно проверьте совместимость на тестовом стенде. Возможно, придётся отказаться от некоторых старых решений или выбрать другого провайдера с более лёгким агентом.

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

После внедрения нужно регулярно оценивать, насколько сервис оправдывает ожидания. Ключевые метрики (они же должны быть в SLA):

Время обнаружения (MTTD) — от момента начала атаки до её фиксации аналитиком MDR. Хороший показатель для среднего бизнеса — менее 30 минут для критичных инцидентов.
Время реагирования (MTTR) — от обнаружения до начала активных действий (изоляция хоста, блокировка процесса). Цель — менее 5–10 минут.
Процент подтверждённых инцидентов, выявленных проактивно (threat hunting) — показывает, насколько провайдер ищет скрытые угрозы, а не только реагирует на срабатывания правил. Желательно >20%.
Уровень шума (ложные срабатывания) — сколько алертов в день приходит на вашу сторону после фильтрации провайдером. Хорошо, если не более 1–2 в сутки.
Доля инцидентов, где потребовалось участие клиента — чем меньше, тем лучше. В идеальном MDR клиент вмешивается только в самых сложных случаях.

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

MDR как стратегический выбор

MDR — это ответ на реальный запрос бизнеса, который не может строить собственную круглосуточную команду аналитиков.

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

MDR не отменяет необходимости в базовой защите: обновлениях, контроле доступа, обучении сотрудников, резервном копировании. Он не гарантирует, что атака не произойдёт — но гарантирует, что её заметят и начнут противодействие в считаные минуты.

Для ИБ-руководителей, которые читают этот текст, рекомендация будет следующей: оцените свои текущие возможности по обнаружению и реагированию. Проведите простое упражнение — смоделируйте атаку в нерабочее время (например, в субботу в 3 часа ночи). Кто в вашей компании её заметит? Кто начнёт действовать? Как быстро? Если ответы вас не устраивают, MDR достоин самого серьёзного рассмотрения.