Сергей Попов
Администратор
- 30.12.2015
- 6 206
- 6 957
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
По данным Mandiant M-Trends 2025, 57% организаций узнают о компрометации от внешней стороны - не от собственного SOC и не от MSSP, за услуги которого платят. Медианное время нахождения злоумышленника в сети - 11 дней (исторический минимум). 38% случаев initial access - эксплуатация уязвимостей, что соответствует технике T1190 Exploit Public-Facing Application. Звучит неплохо на слайде. А теперь реальность: цифры вашего конкретного провайдера могут быть хуже в разы - если вы ни разу не проверяли их реальные метрики, а не маркетинговые обещания из коммерческого предложения.
За последние три года я провёл аудит шести MSSP-контрактов на стороне заказчика. Ни один не соответствовал заявленным параметрам полностью. Ни один. Ниже - конкретные критерии выбора MSSP, которые помогают отсечь маркетинг от реальной экспертизы.
MSSP vs SOC собственными силами: когда аутсорсинг информационной безопасности оправдан
Прежде чем оценивать провайдеров, разберитесь - нужен ли MSSP вообще. Три базовых сценария, когда привлечение MSSP экономически и организационно оправдано:Сценарий 1: нужно запустить функцию быстро. Нет времени на наём L1–L3 аналитиков, закупку и настройку SIEM. MSSP даёт мониторинг за недели, а не за кварталы. Типичная ситуация - компания словила инцидент и осознала, что мониторинга нет вообще.
Сценарий 2: строите SOC с нуля и планируете in-house. MSSP работает как временная замена, пока внутренняя команда набирает зрелость. По мере готовности - передача функций по одной: сначала мониторинг, потом IR, потом threat hunting.
Сценарий 3: резкий рост инфраструктуры. Слияния, поглощения, выход на новые рынки - IT-хозяйство меняется быстрее, чем ИБ-команда успевает масштабироваться. MSSP покрывает разрыв.
Вне этих сценариев аутсорсинг SOC часто создаёт иллюзию безопасности. Если у вас нет внутреннего владельца, который понимает, что именно мониторит MSSP и какие зоны остаются слепыми - вы платите за отчёты, а не за защиту.
| Критерий | MSSP | SOC in-house |
|---|---|---|
| Время запуска | 2–6 недель | 6–12 месяцев |
| Стоимость первого года (SMB) | 3–8 млн ₽/год | 12–25 млн ₽/год (люди + инструменты) |
| Глубина тюнинга под инфраструктуру | Шаблонная, требует давления | Максимальная |
| Зависимость от подрядчика | Высокая | Отсутствует |
| Покрытие 24/7 | Нативно (если честный SLA) | Минимум 5–8 аналитиков для трёхсменного графика |
| Скорость эскалации на L3 | Зависит от нагрузки на SOC провайдера | Прямой доступ |
| Видимость сырых данных | Ограничена (часто - только алерты) | Полная |
Ключевой вопрос: готовы ли вы инвестировать 12–25 млн рублей в первый год для построения in-house SOC с реальным 24/7 покрытием, или бюджет ограничен 3–8 млн? Если второе - MSSP, но с жёстким контролем.
SLA MSSP провайдера: метрики, формулировки и ловушки в договоре
SLA - единственный юридически обязывающий инструмент контроля провайдера. Без конкретных числовых порогов и штрафных санкций SLA превращается в декорацию. Красивый фантик.MTTD и MTTR: числа, а не «быстрая реакция»
Два показателя, которые определяют всё:- MTTD (Mean Time to Detect) - среднее время от момента появления индикатора в логах до генерации алерта аналитиком.
- MTTR (Mean Time to Respond) - среднее время от подтверждения инцидента до начала активных действий по сдерживанию.
Требуйте разбивку по приоритетам:
| Приоритет | Пример инцидента | Целевой MTTD | Целевой MTTR |
|---|---|---|---|
| P1 (критический) | Ransomware, активная эксфильтрация | < 15 мин | < 1 час |
| P2 (высокий) | Lateral movement, компрометация учётной записи | < 30 мин | < 4 часа |
| P3 (средний) | Подозрительная активность, аномалия в логах | < 2 часов | < 8 часов |
| P4 (низкий) | Нарушение политики, информационное событие | < 8 часов | Следующий рабочий день |
Если провайдер не может назвать конкретные MTTD/MTTR по каждому приоритету - это первый red flag. Не второй и не третий. Первый.
«Время реакции» vs «время реагирования»: юридическая ловушка
Классическая формулировка в контрактах: «время реакции на инцидент P1 - 15 минут». Выглядит жёстко. На практике «реакция» = отправка автоматического уведомления «мы видим ваш алерт». Ни расследования, ни containment - формально SLA выполнен. Провайдер доволен, вы - нет, но доказать нечего.Формулировка, которая работает: «время начала расследования инцидента P1 аналитиком L2 - не более 15 минут с момента генерации алерта SIEM. Протокол первичного сдерживания инициируется не позднее 60 минут с момента подтверждения инцидента.»
Разница - в разграничении «получили уведомление» и «начали действовать». По документам первая формулировка - 15 минут. На практике реальное время до действий с такой формулировкой может составлять часы.
Покрытие услуг MSSP: проверка по MITRE ATT&CK
Заявление «мы покрываем все современные угрозы» проверяется за один звонок. Попросите провайдера предоставить матрицу покрытия по MITRE ATT&CK - конкретный список техник с указанием: (1) какие источники телеметрии используются, (2) какие правила детектирования написаны, (3) какой процент техник покрыт автоматизированно, а какой - через ручной threat hunting.Минимальный набор техник, покрытие которых стоит проверить для типовой корпоративной инфраструктуры:
- T1078 Valid Accounts (Initial Access, Persistence, Privilege Escalation) - IBM X-Force фиксирует рост атак с использованием действительных учётных данных на 71% год к году (2024). Если провайдер не детектирует аномальное использование легитимных учёток - он пропустит значительную часть инцидентов. Это не теория, это статистика.
- T1190 Exploit Public-Facing Application (Initial Access) - 38% случаев первичного доступа, по данным Mandiant. Нужны правила корреляции для WAF-логов и логов публичных приложений.
- T1133 External Remote Services (Initial Access, Persistence) - VPN-доступ, RDP, Citrix. Требуется baseline нормальной активности (соответствует NIST CSF DE.AE-01) и детектирование аномалий.
- T1562.001 Disable or Modify Tools (Defense Evasion) - если злоумышленник отключает агент EDR, а MSSP не видит пропадания heartbeat в течение минут - мониторинг бесполезен. Точка.
- T1070 Indicator Removal (Defense Evasion) - очистка логов. MSSP обязан хранить копии логов вне контролируемой заказчиком инфраструктуры, иначе атакующий сотрёт следы.
MSSP как вектор атаки: Trusted Relationship (T1199)
Аспект, который русскоязычные обзоры MSSP почти не затрагивают: провайдер управляемых услуг кибербезопасности сам является вектором атаки. Техника T1199 (Trusted Relationship) описывает именно этот сценарий - злоумышленник компрометирует доверенного подрядчика для получения доступа к целевой организации. Не гипотетически - вспомните SolarWinds.MSSP получает привилегированный доступ к SIEM, SOAR, EDR-консолям, иногда - к Active Directory заказчика. Вопросы, которые нужно задать до подписания контракта:
- Как провайдер защищает учётные записи своих аналитиков в вашей инфраструктуре? MFA обязательно, но достаточно ли?
- Используется ли принцип наименьших привилегий для доступа аналитиков провайдера (NIST 800-53 AC-1)?
- Как ротируются credentials? Как хранятся?
- Есть ли у вас логирование действий аналитиков MSSP в вашей инфраструктуре - независимое от самого MSSP?
- Что произойдёт, если сотрудник MSSP будет скомпрометирован через T1552.001 (Credentials In Files)?
Оценка зрелости MSSP провайдера: что проверять на аудите
Маркетинговые материалы обещают «экспертов мирового уровня» и «передовые технологии». Проверяется это конкретными вопросами, а не слайдами.Укомплектованность L1/L2/L3 и нагрузка на аналитика
Узнайте количество аналитиков каждого уровня и количество обслуживаемых клиентов. Если один L2-аналитик разгребает алерты 40 клиентов одновременно - его «глубокое расследование» сводится к беглому просмотру дашборда и нажатию кнопки «Close - False Positive».Конкретные числа для ориентира:
- L1: не более 150–200 алертов на аналитика в смену (8 часов). При превышении - рост false-negative, потому что аналитик начинает закрывать алерты без проверки. Я видел это на аудите: аналитик обрабатывал 350+ алертов за смену. Угадайте, сколько он реально расследовал.
- L2: не более 10–15 активных расследований одновременно на аналитика.
- L3 / threat hunters: должны присутствовать в штате, а не привлекаться «по запросу». Threat hunting - непрерывный процесс, а не разовая акция по праздникам.
Глубина плейбуков и кастомизация детектов
Два вопроса, которые вскрывают реальный уровень зрелости:- «Покажите плейбук реагирования на инцидент с ransomware для нашей инфраструктуры.» Если в плейбуке написано «изолировать затронутые системы» без указания конкретных действий (какие VLAN изолировать, через какой инструмент, кто принимает решение об отключении продуктивного сервера) - плейбук шаблонный. Его скачали с GitHub и поменяли логотип.
- «Какие custom detection rules вы написали для наших специфических приложений?» Если ответ «мы используем стандартные правила вендора SIEM» - детектирование будет шаблонным. Любой провайдер может включить дефолтные правила в Splunk, QRadar или Microsoft Sentinel. Ценность MSSP - в правилах, написанных под конкретного заказчика: бизнес-приложения, нестандартные сетевые потоки, специфические учётные записи с расширенными привилегиями.
Red flags при выборе MSSP: сигналы из реальных аудитов
Из аудитов MSSP-контрактов - конкретные паттерны, которые указывают на проблемы:| Red flag | Что это значит | Как проверить |
|---|---|---|
| «Мы мониторим всё» без перечня источников телеметрии | Нет понимания scope, подключены не все источники | Запросить полный список интегрированных log sources |
| MTTD/MTTR не фиксированы в SLA | Провайдер не хочет нести ответственность за скорость | Прочитать SLA буквально, не коммерческое предложение |
| Отказ показать sample-отчёт об инциденте | Нечего показать или отчёты поверхностные | Запросить анонимизированный отчёт до подписания |
| «AI-driven detection» без деталей | Маркетинг, за которым стоят дефолтные правила вендора | Спросить: какие модели, на каких данных обучены, кто валидирует |
| Нет выделенного account-менеджера | Ваши запросы попадают в общую очередь | Зафиксировать в контракте выделенного контактного лица |
| Один аналитик L2 на 30+ клиентов | Недоукомплектованность → пропуск инцидентов | Запросить ratio аналитиков к клиентам |
| Нет процедуры Exit / offboarding | Vendor lock-in, проблемы при смене провайдера | Прочитать раздел контракта о расторжении |
| Отказ от тестирования через Red Team / Purple Team | Провайдер не уверен в своих детектах | Предложить Purple Team учения как условие контракта |
| SLA считается по calendar time, не business impact | Инцидент в пятницу вечером → реагирование в понедельник | Требовать 24/7 SLA для P1–P2 без привязки к рабочим дням |
По данным Verizon DBIR 2025, 68% утечек связаны с человеческим фактором (ошибки, misuse, social engineering). Это общая статистика, не специфичная для MSSP, но она напоминает: обучение персонала - включая аналитиков провайдера - критично. Если MSSP не проводит регулярные учения для своих аналитиков и не может подтвердить это документально (NIST 800-53 AT-1) - человеческий фактор на стороне провайдера становится вашим риском.
Договор с MSSP: что учесть до подписания
Несколько пунктов, которые регулярно отсутствуют в типовых договорах (а потом больно):Право на аудит. Заказчик должен иметь право проводить аудит процессов MSSP не реже раза в год - включая проверку укомплектованности команды, тестирование SLA через учебные инциденты и анализ качества детектирующих правил.
Exit-план с передачей данных. При расторжении контракта провайдер обязан передать: все накопленные логи, custom detection rules, плейбуки, документацию по интеграциям. Формат передачи и сроки - в договоре. Без этого пункта смена провайдера превращается в повторное построение мониторинга с нуля. На одном из аудитов заказчик узнал об отсутствии exit-плана только при попытке сменить MSSP - потерял три месяца.
Ответственность за пропущенный инцидент. Формулировка «MSSP не несёт ответственности за ущерб» стандартна - и понятна. Но должна быть привязка к SLA: если MTTD P1 нарушен более N раз за квартал - финансовые санкции или право на досрочное расторжение без штрафа.
Уведомление об инциденте у самого MSSP. Если провайдер сам подвергся компрометации (вспоминаем T1199 Trusted Relationship) - в течение какого срока он обязан уведомить вас? 72 часа, как требует GDPR? Или «в разумный срок»? Фиксируйте конкретику. «Разумный срок» - это юридическая дыра размером с грузовик.
Перечень субподрядчиков. Многие MSSP используют субподрядчиков для ночных смен или отдельных функций. Вы должны знать, кто именно имеет доступ к вашим данным, и согласовывать изменения в цепочке.
Чеклист due diligence при выборе подрядчика по информационной безопасности
Нумерованный список для передачи в рабочую группу по выбору MSSP:Чеклист можно использовать как приложение к RFP или как внутренний документ для оценки предложений.
Каждый второй контракт с MSSP, который я видел за три года, содержал формулировки «время реакции 15 минут» и «покрытие 24/7» - и ни одной привязки к реальным действиям. Провайдер управляемых услуг кибербезопасности в 2025 году - это не роскошь, а операционная необходимость для компаний, у которых нет бюджета на 12+ специалистов in-house. Но рынок аутсорсинга SOC в России перегрет обещаниями.
В моей практике нередко провайдер заявляет «мы - ваш SOC», а по факту - шаблонные правила вендора SIEM и один L2-аналитик на тридцать клиентов в ночную смену. Часть MSSP оптимизирует издержки за счёт глубины тюнинга - потому что написать 50 custom rules для конкретного заказчика дороже, чем включить дефолтный пакет и отчитываться красивыми дашбордами.
Реальная проверка зрелости провайдера занимает два-три дня аудита, а не десять минут на просмотр коммерческого предложения. Если вы не готовы инвестировать эти два дня до подписания - будьте готовы потратить месяцы на разбирательства после первого пропущенного инцидента.
Мой прогноз: в ближайшие полтора-два года рынок начнёт жёстко делиться на провайдеров, которые могут доказать метрики, и тех, кто не переживёт первый серьёзный аудит заказчика. Те, кто выбирает MSSP по цене на слайде - окажутся в лагере тех самых 57%, узнающих о взломе от внешней стороны.
