Как выбрать SOAR/IRP: критерии выбора системы автоматизации реагирования

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

Сравнение лицензий и совокупной стоимости владения — на последнем шаге, когда список кандидатов уже сужен по функциям.

SOAR (Security Orchestration, Automation and Response) — класс систем, которые подключаются к разным средствам защиты через коннекторы и по заданному сценарию (плейбуку) выполняют цепочку действий: собирают контекст об инциденте из нескольких источников, обогащают его данными Threat Intelligence, изолируют хост, блокируют IP или учётную запись, создают и ведут кейс — без ручного переключения аналитика между консолями разных продуктов.

IRP (Incident Response Platform) — близкий по функциям класс, который на рынке чаще делает акцент на самой задаче: управлении жизненным циклом инцидента, кейс-менеджменте и координации команды реагирования, с автоматизацией части шагов, а не обязательно всей цепочки через десятки коннекторов. В Реестре российского ПО оба относятся к одному коду класса — «Автоматизация ИБ (SOAR/SGRC)», и на практике часть вендоров продаёт SOAR и IRP как один продукт под разными названиями, так что при выборе стоит сверять конкретный набор функций, а не только ярлык в маркетинге.

Отдельно не стоит путать SOAR/IRP с SGRC (Security Governance, Risk and Compliance) — тот же код реестра формально включает и системы учёта рисков, комплаенса и подготовки к аудитам, но это другая задача, не оперативное реагирование на инцидент. Для команды реагирования это разные категории функций, даже если у конкретного вендора они собраны в одной линейке продуктов.

Не всегда. Часть SIEM-платформ включает базовый модуль реагирования — простой кейс-менеджмент и ручные или полуавтоматические действия по инциденту, и для команды с небольшим потоком алертов этого хватает. Отдельная SOAR/IRP-платформа становится оправданной инвестицией, когда однотипные действия реагирования повторяются регулярно и затрагивают несколько разных систем защиты одновременно — а ручное переключение между их консолями отнимает у аналитиков больше времени, чем занял бы сам инцидент при автоматизированном сценарии.

Три практических признака, что пора рассматривать отдельный SOAR/IRP: количество инцидентов в день выросло настолько, что команда не успевает обрабатывать их вручную без потери качества; в контуре защиты уже стоит несколько разных СЗИ (SIEM, EDR, NGFW, DLP), и цепочка реагирования требует действий в каждом из них; руководству или регулятору нужна отчётность по MTTR/MTTD, которую сейчас приходится собирать вручную по логам и переписке.

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

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

Один и тот же продукт может закрывать задачу зрелого SOC и быть избыточным для команды из двух аналитиков — вес критериев зависит от того, кто и зачем внедряет платформу.

1. Опишите текущий процесс реагирования на инциденты и убедитесь, что у вас есть хотя бы несколько документированных сценариев для автоматизации.
2. Составьте список СЗИ и других систем, с которыми должна взаимодействовать платформа, и сверьте его со списком готовых коннекторов у каждого кандидата.
3. Определите, какие действия реагирования можно автоматизировать полностью, а какие требуют подтверждения аналитика.
4. Проверьте кейс-менеджмент — назначение, эскалацию, SLA, интеграцию с текущей системой тикетов.
5. Уточните совместимость обогащения из Threat Intelligence с фидами, на которые вы уже подписаны.
6. Убедитесь, что платформа считает MTTR/MTTD автоматически и выдаёт отчётность без ручной сборки.
7. Для субъектов КИИ — проверьте, поддерживает ли продукт подготовку и отправку сведений через техническую инфраструктуру НКЦКИ.
8. Сверьте статус и срок действия сертификата ФСТЭК в госреестре СЗИ ФСТЭК, если сертификат обязателен для вашего сценария.
9. Определите модель развёртывания — on-prem или облако — с учётом требований по локализации данных.
10. Оцените модель лицензирования — по аналитикам, по коннекторам или по объёму кейсов — и её поведение при росте нагрузки.
11. Посчитайте TCO на 3 года: лицензия, разработка плейбуков под свой стек, обучение аналитиков, поддержка.
12. Запросите пилот на реальных инцидентах и реальном наборе своих СЗИ, а не на демо-плейбуках вендора.

• Пытаться автоматизировать всё с первого дня без документированных процессов. Плейбук, построенный на непроговорённой практике конкретного аналитика, закрепляет его ошибки, а не устраняет их.
• Недооценивать объём работы по интеграциям. Отсутствующий коннектор к нужной СЗИ превращается в отдельную задачу разработки, которая растягивает сроки проекта и часто не входит в изначальную оценку внедрения.
• Игнорировать совместимость с существующим кейс-менеджментом. Если SOAR не встраивается в привычный для команды workflow тикетов, аналитики продолжают вести инциденты в старой системе, а платформа остаётся невостребованной.
• Ставить критичные действия на полный автомат без точки подтверждения. Ошибка в логике плейбука, который без подтверждения блокирует учётную запись или рвёт сессию, способна остановить бизнес-процесс быстрее, чем сама атака.
• Не измерять MTTR/MTTD до внедрения. Без базовой точки отсчёта невозможно доказать эффект от автоматизации — ни себе, ни руководству, которое утверждало бюджет проекта.

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

Смежные классы, которые часто внедряют вместе с SOAR/IRP: SIEM — источник событий и инцидентов для оркестрации, EDR — точка автоматизированного реагирования на конечных точках. Для субъектов КИИ регуляторные требования к взаимодействию с государственной системой обнаружения атак разобраны в разделе «ГосСОПКА» на SecRadar.