SOAR: автоматизация реагирования на инциденты

Скорость реагирования на киберинциденты всё чаще определяет размер ущерба и всё чаще за эту скорость отвечает не только команда SOC (Security Operations Center), но и платформа класса SOAR (Security Orchestration, Automation and Response). SOAR объединяет разрозненные средства защиты информации в единый управляемый процесс: собирает данные, обогащает контекст, запускает плейбуки и координирует действия аналитиков — от обнаружения угрозы до закрытия инцидента.

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

• Илья Силантьев, эксперт Security Vision.
• Фёдор Музалевский, директор технического департамента RTM Group.
• Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC.
• Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline).
• Станислав Прищеп, руководитель продукта STEP Smart SOC.
• Кирилл Добрынин, директор департамента автоматизации «Группы Астра», Product Director Astra Automation.
• Дмитрий Чеботарев, менеджер по развитию UserGate SIEM.
• Максим Ежов, руководитель продукта R-Vision SOAR.
• Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision.
• Николай Казанцев, генеральный директор SECURITM.
• Дмитрий Пензов, технический директор компании ATLAS.

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

Где SOAR экономит минуты и часы

Рутинные типовые инциденты с готовыми плейбуками — точка максимальной отдачи SOAR, здесь эксперты единодушны. Фёдор Музалевский и Константин Карасев акцентируют: важнее не сценарии, а условия — слаженность команды и качество подготовки. Кирилл Добрынин напоминает: в ночные смены SOAR не столько ускоряет, сколько обеспечивает реагирование. Станислав Прищеп указывает на горизонт: AI SOAR формирует плейбуки автоматически.

Дмитрий Пензов, технический директор компании ATLAS, киберэксперт, задал тон дискуссии: SOAR «отбивает» вложения не на сложных целевых атаках, а на рутине, которая ежедневно забирает время у команды SOC — компрометация учётных записей, подозрительный запуск скриптов, фишинг. Без платформы аналитикам приходится вручную переключаться между множеством консолей: SIEM (Security Information and Event Management — управление событиями ИБ), EDR (Endpoint Detection and Response — защита конечных точек), AD (Active Directory — служба каталогов), прокси, тикет-системы. SOAR собирает всё в единую последовательность — обогащает данные, проверяет хосты, изолирует их, блокирует учётные записи, создаёт кейсы и уведомляет ответственных. Особенно это ощущается в небольших командах, где круглосуточный режим не всегда покрывается, а процессы продолжаются:

«Максимальный эффект от SOAR мы наблюдаем не в кинематографичных APT-атаках, а в рутинных операционных задачах, которые ежедневно забирают много времени у команды SOC».

От фишинга до ночных инцидентов

Наглядный пример привёл Илья Силантьев, эксперт Security Vision. Для реагирования на массовую фишинговую рассылку без SOAR нужно выполнить целую цепочку действий: проверить тему, URL и вложения на почтовом сервере, проверить артефакты во внешних аналитических сервисах, найти другие письма от того же отправителя, удалить письмо и добавить отправителя в чёрный список, проверить наличие вредоносного вложения на почтовом сервере и хостах, запустить антивирусное сканирование, оповестить пользователей и провести пост-инцидентный анализ. С SOAR большинство этих действий автоматизируется: в карточке инцидента отображается комплексная аналитика, окрестности инцидента, а также действия по централизованному реагированию в ручном и автоматическом режимах:

«Аналитику остается через консоль SOAR лишь заблокировать вредоносное вложение на уровне АВЗ и отправителя на уровне почтового сервера».

Кирилл Добрынин, директор департамента автоматизации «Группы Астра», Product Director Astra Automation, выделил три основных типа сценариев. Первый — массовые однотипные действия: фишинг, брутфорс учётных записей, срабатывание антивируса, когда изоляция хоста и блокировка учётной записи занимают секунды вместо минут ручной работы первой линии, ручной труд исчезает полностью. Второй — инциденты, требующие действий сразу в нескольких системах: заблокировать на фаерволе, завести тикет, отправить уведомление, и без автоматизации на переключение между системами теряется время. Третий — инциденты в выходные и ночное время, когда у компании нет отдельной дежурной смены:

«В этом случае SOAR не ускоряет реагирование, а обеспечивает его».

Повторяемость, чёткую последовательность действий и высокую нагрузку на сотрудников отметил Дмитрий Чеботарев, менеджер по развитию UserGate SIEM. Отдельно он выделил работу с ложными срабатываниями и фишингом, но подчеркнул: если инцидент несёт уникальный и разовый характер, скорость реагирования будет дольше за счёт привлечения аналитиков в большем объёме. Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, отметил, что можно сразу указать в плейбуке автоматизированные действия, например, по изоляции подозрительного хоста, но в реалиях такие действия, как правило, ещё остаются за человеком.

Автоматизация на каждом этапе жизненного цикла

Максим Ежов, руководитель продукта R-Vision SOAR, наиболее детально описал автоматизацию по этапам реагирования. При первичном анализе SOAR автоматически связывает инцидент с контекстной информацией: на какой системе он произошёл, какие пользователи могли быть затронуты и на какие бизнес-процессы это может повлиять. Аналитику не нужно вручную собирать данные из CMDB (Configuration Management Database — база управления конфигурациями) или AD. Далее SOAR автоматизирует назначение ответственных и позволяет из одного окна ставить задачи другим сотрудникам через каналы коммуникаций или таск-трекеры, например, автоматически создавать задачи в Jira. Обогащение инцидента происходит по преднастроенным сервисам, которые выдают предварительный вердикт о вредоносности источника атаки, а сдерживание подразумевает преднастроенные действия — блокирование учётных записей, сессий или доступов:

«При грамотно настроенной системе SOAR все описанные выше действия можно выполнить за секунды, исключая необходимость в понимании администрирования ИТ-систем и прочих СЗИ».

Для SOC, работающих в модели MSSP (Managed Security Service Provider — «ИБ по подписке»), SOAR открывает особые возможности, отметил Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline). На примере сценария подозрительной сетевой активности — атаки или сканирования — платформа позволяет автоматически обогатить событие данными об атакующих адресах и при необходимости заблокировать их на межсетевом экране. В сценариях, где требуется верификация действий конечным пользователем, SOAR может направить оповещение со сформированными рекомендациями непосредственно ответственному лицу, минуя стандартные и часто многоступенчатые линии мониторинга. Для обеспечения максимальной оперативности каналы связи могут гибко настраиваться, например, переключаться с электронной почты на мессенджеры в зависимости от времени суток.

Николай Казанцев, генеральный директор SECURITM, описал SOAR как оркестратор, который синхронизирует процессы между SIEM, IRP (Incident Response Platform — платформа реагирования на инциденты), EDR и ITSM (IT Service Management — управление ИТ-услугами), минимизируя ручные переключения и заметно ускоряя полный цикл от обнаружения угрозы до её устранения. Это особенно ценно, когда ручное реагирование и действия в инфраструктуре тормозят SOC-команду, а автоматизированная оркестрация позволяет мгновенно запускать цепочки действий. Наибольший эффект SOAR демонстрирует в снижении MTTR (Mean Time To Respond — среднее время реагирования) там, где рутинные операции повторяются часто, а поток оповещений огромен: автоматизация оповещений, запуска дополнительных проверок, блокировки или ограничения приложений, процессов или сетевого взаимодействия, а также действий по восстановлению инфраструктуры позволяет радикально ускорить процесс. Автоматизация сортировки алертов, их обогащения контекстом и первых мер реагирования, по оценке Николая Казанцева, даёт наиболее ощутимый результат.

Условия важнее сценариев

Иной акцент расставил Фёдор Музалевский, директор технического департамента RTM Group: сценарии могут быть разными, а вот условия, в которых SOAR полезен, известны точно. Первое — команда реагирования не слажена, перегружена или формируется ситуативно, SOAR выступает как регламент, помогает делиться артефактами проникновения через собственное хранилище с контролем целостности файлов и одновременно напоминает о сроках внесения сведений для Роскомнадзора в случае утечки персональных данных. Второе — команда реагирования внешняя по отношению к субъекту инцидента, SOAR автоматизирует взаимодействие со средствами защиты и оформляет порядок работы с внутренними специалистами.

«SOAR является, фактически, платформой обмена данными между тремя сторонами — инфраструктурой, внешними и внутренними специалистами».

О необходимости серьёзной подготовки перед внедрением автоматизации напомнил Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision. Заметное сокращение времени реагирования возможно только тогда, когда у команды эксплуатации есть чёткое понимание, какие действия действительно подлежат автоматизации, а какие должны оставаться в зоне ответственности аналитика. Сначала нужно сформировать и формализовать процесс, определить шаги для автоматизации, проверить гипотезы на практике, определить границы автоматических действий и провести тестирование. Только после этого автоматизацию имеет смысл внедрять в рабочую среду, иначе существует риск получить обратный эффект и завышенные ожидания от инструмента. На практике максимальный эффект достигается там, где действия аналитика хорошо понятны и регулярно повторяются, а цель каждого шага и ожидаемый результат понятны, например, в ходе расследования аналитик собирает данные из нескольких систем, проверяет типовые признаки кибератаки, уточняет контекст, уведомляет ответственных и выполняет стандартные меры сдерживания. Именно такие сценарии лучше всего подходят для автоматизации: они позволяют сократить время на рутинные операции и сделать реагирование более точным и предсказуемым. При этом Константин Карасев подчеркнул: процессы и сценарии автоматизации необходимо регулярно пересматривать и дорабатывать, поскольку условия работы SOC постоянно меняются.

На горизонте принципиально иной подход к автоматизации, отметил Станислав Прищеп, руководитель продукта STEP Smart SOC. В классических SOAR лучший результат достигается в сценариях с высокой степенью формализации плейбука, с однозначными условными операциями и поддающимися автоматизации действиями. Однако в SOAR-системах с функциями искусственного интеллекта степень формализации сценария тоже очень важна, но приобретает иные формы за счёт автоматического формирования плейбука и толкования результатов его выполнения самой системой. При этом максимальное сокращение времени реагирования, по наблюдению Станислава Прищепа, достигается на инцидентах с высоким уровнем достоверности или степенью критичности.

Плейбуки: почему написать сложнее, чем развернуть

Коробочный контент вендоров — стартовая точка, которую признаёт большинство. Илья Силантьев подчёркивает: вендоры закладывают сценарии «в коробку» на основе БДУ ФСТЭК России и MITRE ATT&CK, предлагая не просто инструмент, а фундамент для развития SOC. Константин Карасев возражает: логика важнее коннекторов, одинаковых сценариев не существует. Станислав Прищеп предлагает радикальную альтернативу: в AI SOAR классический плейбук заменяется текстовым описанием полномочий и целей. Дмитрий Пензов описывает, как плейбук созревает итерациями — от простого сценария до полной автоматизации.

Проблема выходит за рамки одного класса решений, обратил внимание Фёдор Музалевский, директор технического департамента RTM Group. Вопрос передачи экспертизы через решение касается не только SOAR, с ним сталкиваются и решения класса SGRC (Security Governance, Risk and Compliance — управление безопасностью), и NGFW (Next Generation Firewall — межсетевой экран нового поколения), и даже сканеры уязвимостей. Основных способов решения два: формирование базы знаний на высоком уровне с тем, чтобы детальные действия оформлялись на местах (например, общее действие «получение логов с сервера администрирования антивируса» дополняется на местах описанием для конкретных вендоров или кнопками интеграции), и подробное описание процесса для частных случаев, где, однако, описание для одного продукта может быть, а для другого — нет.

Коробочный контент как фундамент

Ведущие производители SOAR-решений пытаются удовлетворить потребности рынка, привлекая внутреннюю и внешнюю экспертизу для формирования сценариев реагирования на каждой из фаз инцидента, применяя в них лучшие отечественные и международные практики в соответствии с БДУ ФСТЭК России и MITRE ATT&CK, рассказал Илья Силантьев, эксперт Security Vision. Разработка плейбуков требует учёта множества факторов — модель угроз, классификация подозрений на инцидент, назначение ответственных, вероятность дальнейшего развития атаки, формирование мер по реагированию на каждой из фаз и многое другое. Тем не менее эти сценарии закладываются производителем «в коробку», предлагая конечному потребителю «не просто инструмент, а полноценный фундамент для дальнейшего развития SOC».

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, выделил два подхода: первый — процесс управления инцидентами ИБ уже существует или его будут разрабатывать персонифицированно для компании с последующей имплементацией, второй — использовать коробочные наработки вендоров SOAR как основу для адаптации рабочего плейбука. Оба подхода непростые, но коробочный контент вендора позволит внедрить систему быстрее.

Качественные SOAR-системы имеют под капотом no-code-инструменты автоматизации (без написания кода), отметил Максим Ежов, руководитель продукта R-Vision SOAR. Зрелые вендоры часто предлагают коробочные шаблоны плейбуков, коннекторы, скрипты и триггеры, что позволяет быстро автоматизировать типовые сценарии реагирования, снижает порог входа и позволяет команде SOC начать автоматизацию без разработки с нуля.

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

Логика важнее коннекторов

Одинаковых сценариев не существует, возразил Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision. Для каждого заказчика всегда создаётся уникальная автоматизация, несмотря на схожие действия в различных системах. Сценарий реагирования — это набор конкретных действий в определённый момент времени, а какие именно действия нужны, определяет либо сам заказчик при наличии накопленного опыта, либо консультанты, которые помогают выстроить процессы реагирования. Именно из-за этой уникальности и необходимости экспертизы написание рабочего плейбука часто оказывается сложнее, чем базовая инсталляция системы:

«Вопрос чаще не в коннекторах и интеграциях, а в самой логике — когда и какие действия должны быть выполнены».

Дмитрий Пензов, технический директор компании ATLAS, описал поэтапное созревание плейбука. Развернуть SOAR сравнительно простая задача, гораздо сложнее трансформировать реагирование в автоматизированные плейбуки, которые не повлияют негативно на продакшен, не парализуют бизнес-процессы и не превратят SOC в источник лишнего шума. Рынок решает эту проблему поэтапно: сначала начинают с простых и понятных сценариев, затем переходят к полуавтоматическому режиму, когда SOAR предлагает действия, а специалист подтверждает их выполнение. Только после многократных успешных кейсов и нескольких циклов ревью плейбук переводят в полностью автоматический режим. Такой плейбук фактически рождается в нескольких итерациях совместно с SOC, ИТ, владельцами систем и службой безопасности.

Low-code-системы существенно снижают трудозатраты на техническую разработку плейбуков, признал Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline). Но в чистом виде коробочный контент редко закрывает все потребности конкретной организации — его почти всегда приходится адаптировать. При этом нельзя забывать о необходимости технической и сетевой интеграции между системами, а также о проработке самой логики плейбука. Ключевые требования к команде остаются прежними: нужны грамотные аналитики и инженеры, но время на реализацию плейбуков после внедрения SOAR существенно сокращается. Аналогичная ситуация, по наблюдению Алексея Тихонова, складывается и с внедрением искусственного интеллекта в информационную безопасность.

От плейбука к ИИ-агенту

Самую радикальную позицию занял Станислав Прищеп, руководитель продукта STEP Smart SOC. Чтобы плейбук заработал, необходимо формализовать всю цепочку действий по реагированию с учётом всех возможных результатов и условий, а результат действий должен быть чётко структурирован и однозначно интерпретирован системой — в условиях постоянно изменяющейся ИТ-среды это может быть очень сложно. Перспективным решением Станислав Прищеп назвал системы класса AI SOAR со встроенными ИИ-агентами:

«В таких системах плейбук, в его классическом понимании, отсутствует. Его место занимает текстовое описание полномочий и целей реагирования».

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

Важность написания плейбуков сложно переоценить, и нет ничего лучше, чем написать плейбук самостоятельно, но это очень сложный и трудоёмкий процесс, признал Дмитрий Чеботарев, менеджер по развитию UserGate SIEM. С развитием нейросетей и генеративного ИИ процесс можно значительно упростить, но любые результаты работы нейросетей необходимо самостоятельно проверять и не доверять слепо бездушной машине, которой иногда свойственно ловить галлюцинации в ответах.

Сколько интеграций нужно для реальной автоматизации

Разброс оценок огромен — от двух систем (Максим Ежов) до десятков (Алексей Тихонов). Кирилл Добрынин, Константин Карасев и Дмитрий Пензов настаивают: качество интеграций важнее количества. Контрпозицию занял Фёдор Музалевский: SOAR самодостаточен и работает даже без интеграций, поскольку его главная задача — систематизация, а не автоматизация. Николай Казанцев конкретизирует: 5–10 систем покрывают 70–80% типичной рутины. Илья Силантьев напоминает о законодательном аспекте: объекты КИИ и финансовые организации обязаны интегрироваться с ГосСОПКА и FinCERT.

Самую неожиданную позицию занял Фёдор Музалевский, директор технического департамента RTM Group: в большинстве случаев работа SOAR возможна и без интеграций. Основная задача платформы — систематизация работы, а не её автоматизация, поэтому большинство SOAR самодостаточны. Чтобы автоматизировать работу, Фёдор Музалевский рекомендовал вести интеграции в определённой последовательности: сначала SIEM, XDR и ITSM, затем антивирусы, EDR и CMDB, далее межсетевые экраны и DLP (Data Loss Prevention — предотвращение утечек данных). Интеграции с TI-решениями (Threat Intelligence — киберразведка) стоят особняком: они либо уже встроены в SOAR, либо взаимодействуют с XDR или EDR:

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

От двух до десятков

Минимальную планку установил Максим Ежов, руководитель продукта R-Vision SOAR: достаточно интеграции с двумя системами — SIEM для получения инцидентов и AD для выполнения базовых действий реагирования. При более зрелом уровне автоматизации SOAR, как правило, интегрируют практически со всем ИБ-ландшафтом: от NGFW и DLP до различных ИТ-систем. По оценке Максима Ежова, идеальный сценарий — это взаимодействие с триадой SIEM + EDR + NTA (Network Traffic Analysis — анализ сетевого трафика).

Автоматизация начинает давать реальный эффект уже при четырёх-пяти интеграциях, считает Кирилл Добрынин, директор департамента автоматизации «Группы Астра», Product Director Astra Automation. Минимальный набор: источник событий, инструмент блокировки, тикет-система и канал уведомлений — для большинства типовых сценариев этого достаточно. Однако, проблема не в количестве интеграций, а в их качестве:

«Интеграция, которая перестает корректно работать после обновления системы не просто бесполезна — она опасна, т.к. создает иллюзию автоматизации там, где ее нет».

На практике, по рекомендации Кирилла Добрынина, стоит начинать с интеграций, которые покрывают самые частые и болезненные сценарии, и только после их стабилизации наращивать количество.

Николай Казанцев, генеральный директор SECURITM, назвал ориентиром 5–10 систем в зависимости от уровня SOC — важно обеспечить SOAR возможность принимать верные решения на основании предоставленных данных. Начать лучше с основ: SIEM для сигналов тревоги, EDR/XDR для мониторинга устройств, IRP для управления процессом, ITSM для тикетов, Threat Intelligence и средства активного реагирования вроде файрволов или IAM (Identity and Access Management — управление идентификацией и контролем доступа). Такой набор обеспечивает непрерывный цикл от обнаружения угрозы до её нейтрализации без простоев в данных или процессах и покрывает 70–80% типичной рутины, от сортировки до изоляции.

В крупной распределённой среде количество коннекторов может исчисляться десятками, отметил Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline). Помимо SIEM, SOAR-платформа может собирать события напрямую с источника, получать информацию об активах, обогащать данные через платформы TI, отправлять и принимать уведомления по разным каналам связи, обеспечивать двустороннюю синхронизацию с ITSM-решениями, отправлять отчёты в FinCERT и реализовывать механизмы активного реагирования на инциденты.

Не количество, а связность

Вопрос не в количестве интеграций, а в качестве их реализации, убеждён Дмитрий Пензов, технический директор компании ATLAS. Важно, чтобы SOAR не просто получал алерты, но мог собирать контекст и выполнять обратные действия, только тогда можно говорить об автоматизации. Интеграция «принять событие» — это лишь красивая витрина, но не полноценная автоматизация. Минимальный набор должен включать источник событий (SIEM), работу с хостами (EDR), управление учётными записями (AD, IAM), почтовый сервер (например, Exchange), систему трекинга инцидентов и желательно песочницу для анализа. Речь идёт не просто о трёх интеграциях, а о нескольких надёжных связках, обеспечивающих полноценное взаимодействие:

«Без этого SOAR превратится в дорогой „переадресатор» алертов между экранами, а не в эффективного оркестратора процессов».

Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision, сформулировал принцип иначе: SOAR должен интегрироваться со всеми системами, из которых необходимо получить данные для сокращения времени реагирования, и с теми, в которые данные требуется передавать. Главное, чтобы был подходящий интерфейс для взаимодействия, а логика определяется исходя из требований и детальной проработки процесса. Если нет понимания, какую задачу должна решать интеграция с конкретной системой, нет смысла тратить ресурсы на её реализацию, какой бы интересной система ни была. На практике Константин Карасев сталкивался с ситуацией, когда по техническому заданию требовалась интеграция с системой, но у заказчика не было понимания, для каких задач она вообще нужна, и в ходе совместной проработки процессов реагирования перечень интеграций корректировался:

«Главная задача при внедрении SOAR — выстроить грамотные сквозные процессы расследования и реагирования киберинцидентов с помощью единого окна, а не просто настроить различные интеграции».

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, подчеркнул необходимость баланса: любые действия по реагированию могут оказать как положительный, так и отрицательный эффект, и не каждый CISO готов иметь одну систему, которая может оказывать прямое влияние на все бизнес-процессы компании.

Возможности SOAR по автоматизации реагирования проявятся даже при небольшом наборе интегрируемых решений, уверен Станислав Прищеп, руководитель продукта STEP Smart SOC. Базовые задачи он разделил на три функции: верификация инцидентов (подключение SIEM и источников Threat Intelligence для сопоставления инцидентов, событий и индикаторов угроз), информирование (как минимум интеграция с электронной почтой для обеспечения надёжности и подотчётности) и сдерживание (средства управления и блокировки — антивирусы, EDR/XDR, Identity Management, межсетевые экраны).

Точного количества систем, которые нужно интегрировать с SOAR, не существует — это напрямую зависит от инфраструктуры заказчика, типа активов, сферы деятельности и имеющихся СЗИ, указал Илья Силантьев, эксперт Security Vision. При этом он разделил рекомендуемые интеграции на две группы: системы, откуда поступают алерты и алиасы для формирования подозрений на инцидент (SIEM, межсетевые экраны, NGFW, IPS/IDS, СОВ, антивирусы, EDR, средства защиты почтовых серверов, песочницы), и системы, помогающие в реагировании (хосты, сервисы каталогов, внешние ITSM/SD). Отдельно Илья Силантьев напомнил о TI-решениях для обогащения контекста и о законодательном требовании: если организация относится к объектам КИИ (критической информационной инфраструктуры) или является финансовой организацией, зрелая SOAR-платформа должна иметь интеграцию с центрами ГосСОПКА (государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак) и FinCERT (центр мониторинга и реагирования на инциденты Банка России).

Дмитрий Чеботарев, менеджер по развитию UserGate SIEM, привёл развёрнутый перечень обязательных систем для старта: Jira или аналоги, почта и корпоративные мессенджеры, Active Directory, сетевая часть в лице NGFW и SWG, SIEM, TI, EDR, песочница (при её наличии) — и подчеркнул, что это далеко не полный список.

Как меняется работа SOC-аналитика

Большинство экспертов сходятся: рутина уходит, роль усложняется. Дмитрий Пензов отмечает: аналитик становится больше похож на инженера — меньше механики, больше аналитики. Константин Карасев фиксирует смену приоритетов: аналитические навыки выходят на первое место, а технические — на второе. Николай Казанцев конкретизирует: автоматизация берёт на себя 60–80% типичных задач. Фёдор Музалевский напоминает исходную точку: из гугл-таблиц — в единое окно.

При правильном внедрении SOAR аналитик перестаёт выполнять монотонные операции — копирование индикаторов компрометации (IOC), клики по повторяющимся карточкам и ручной сбор контекста из множества систем, отметил Дмитрий Пензов, технический директор компании ATLAS. Это одна из ключевых выгод: снижение рутинной, повторяемой работы, которая часто ведёт к выгоранию. Роль усложняется и становится более ответственной — меньше механики, больше аналитики и контроля качества:

«После запуска SOAR аналитик становится больше похож на инженера, который принимает решения, отслеживает спорные кейсы, улучшает сценарии, анализирует ложные срабатывания и контролирует корректность работы плейбуков».

Однако Дмитрий Пензов предупредил: если процессы изначально не структурированы, SOAR лишь масштабирует хаос, поэтому важно внедрять автоматизацию на основе упорядоченных и зрелых процессов.

Единое окно вместо десятков консолей

Фёдор Музалевский, директор технического департамента RTM Group, описал изменения через бытовую деталь: грамотно настроенный SOAR даёт эксперту «одно окно», в котором он получает данные, вносит данные и планирует дальнейшую деятельность. Если раньше карточка инцидента была на сетевом диске (хорошо, если не в гугл-таблицах), результаты сканирования сканера на почте, а планирование в системе задач, то теперь это один логин-пароль, один интерфейс. Сокращается количество переключений между системами, не только съедавшее время, но и приводившее к ошибкам.

С использованием SOAR аналитик становится более самостоятельной единицей и уже кратно меньше зависит от других специалистов и своего руководителя, отметил Максим Ежов, руководитель продукта R-Vision SOAR. Такая опора в виде SOAR принципиально важна для новых сотрудников, аналитиков первой линии SOC. Платформа предоставляет готовые сценарии реагирования и преднастроенные действия для работы с различными СЗИ — аналитику уже не требуется разбираться в администрировании каждой системы, запрашивать какие-либо доступы или уточнять дополнительную информацию. Иначе говоря, он получает единое окно для работы, которое позволяет быстрее и точнее реагировать на инциденты.

После успешного внедрения SOAR, реализации требуемого процесса управления инцидентами ИБ и возможностей по реагированию аналитик SOC получает инструмент, который позволяет ему в единой консоли выполнять весь перечень повседневных операций, пояснил Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC. Переезд в новую систему для кого-то может быть болезненным на первом этапе, но в перспективе внедрение SOAR — позитивный момент, поскольку механизмы системы предназначены для систематизации и упрощения работы, а в некоторых случаях позволяют минимизировать или исключить «детские» ошибки.

От рутины к стратегии

Повседневная работа SOC-аналитика существенно меняется: рутина уходит на второй план, а фокус смещается на стратегический анализ и сложные угрозы, констатировал Николай Казанцев, генеральный директор SECURITM:

«Автоматизация берёт на себя 60–80% типичных задач, высвобождая время для проактивной охоты за атаками».

SOAR может усиливать этот эффект, предоставляя готовые коннекторы для оркестрации с российскими системами мониторинга и compliance-инструментами. Аналитик больше не тратит часы на триаж сотен алертов: SOAR автоматически фильтрует ложные срабатывания, группирует инциденты и запускает плейбуки для обогащения (VirusTotal, whois) и сдерживания (изоляция хостов, блокировка IP). Вместо ручного ввода в тикеты система сама создаёт задачи в ITSM и уведомляет по Slack/Teams. Дополнительную ценность добавляют преднастроенные интеграции с локальными SIEM/EDR, автоматизирующие сбор логов и ускоряющие реагирование.

Задача аналитиков SOC непроста — круглосуточно проводить анализ аномальных активностей, классифицировать инциденты, учитывать их контекст и окрестности инцидентов, принимать корректные и эффективные меры по реагированию в соответствии со сценариями реагирования, и самое главное, делать это оперативно, ведь зачастую риски велики, напомнил Илья Силантьев, эксперт Security Vision. Всё это сопровождается работой с множеством ИТ-систем и СЗИ, между которыми постоянно нужно переключаться. SOAR в «боевом» режиме оптимизирует и автоматизирует рутинные действия, минимизирует влияние человеческого фактора, при этом не ограничивает сотрудника в возможностях, а наоборот, предоставляет инструмент централизованного управления жизненным циклом инцидента. SOAR кратно сокращает время реагирования на инциденты, что позволяет аналитикам заняться более важными задачами: анализом новых угроз, разработкой для них корреляционных правил, плейбуков и адаптацией существующих процессов.

Эксплуатация SOAR в боевом режиме — это непрерывная эволюция процессов реагирования, подчеркнул Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline). У команды центра мониторинга появляется принципиально больше возможностей для автоматизации рутинных операций, написания сложных многоступенчатых плейбуков и реализации того функционала и интеграций, о которых ранее только задумывались, но откладывали в силу существенных трудозатрат на разработку. Всегда найдутся направления, которые можно улучшить и автоматизировать.

Работа аналитиков становится интереснее, кратко сформулировал Станислав Прищеп, руководитель продукта STEP Smart SOC. Автоматизация позволяет переключиться с рутинных задач на творческие: вместо ручного повторения заданного набора действий по реагированию аналитики дорабатывают алгоритм автоматизации в SOAR. Значительно снижается информационный шум, но появляется потребность в понимании используемых в SOC систем и алгоритмов, а фокус внимания смещается на анализ нетиповых сработок и улучшение плейбуков.

Подготовка SOAR к работе в боевом режиме — процесс крайне сложный и трудоёмкий, но все эти усилия безусловно стоят того, убеждён Дмитрий Чеботарев, менеджер по развитию UserGate SIEM. SOAR позволяет значительно сократить время реагирования в том числе и за счёт уменьшения «шума» в инцидентах, отнимающего больше всего времени у аналитиков. Большую роль берёт на себя система, а не сотрудник, что позволяет ему потратить время эффективнее на действительно сложные инциденты, требующие тщательного анализа и подключения человека. После внедрения SOAR работа аналитика становится эффективнее.

Глубже всех трансформацию роли описал Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision: аналитик становится лицом, принимающим решения на основе данных, полученных автоматизированно из различных источников. Больше не требуется открывать десятки консолей сторонних систем для получения контекста — в начале расследования в SOAR уже есть вся необходимая информация. Это колоссально экономит время, обеспечивая более высокую продуктивность, меньшее количество ошибок, качественные отчёты и комплексное понимание ситуации не только в рамках одного инцидента, но и в целом. Если сценарии качественно продуманы и протестированы, нивелируется фактор разницы в технических навыках между аналитиками:

«Теперь на первое место выходят как раз аналитические навыки, чтобы работать с данными, а не технические — чтобы понять, как эти самые данные получить».

SOAR или дополнительные аналитики

Порог зрелости процессов — ключевой критерий, и здесь эксперты единодушны. Кирилл Добрынин сформулировал парную формулу: «SOAR без людей — бессмысленная инвестиция, люди без SOAR — немасштабируемая». Станислав Прищеп предупреждает: автоматизация хаоса приведёт к ещё большему хаосу. Фёдор Музалевский привёл экономический аргумент: окупаемость SOAR порядка года, это сравнимо с зарплатой одного специалиста.

Выбор не должен быть «либо SOAR, либо люди» — важен порядок действий и зрелость процессов, убеждён Дмитрий Пензов, технический директор компании ATLAS. Если у компании уже есть устоявшийся поток инцидентов, повторяющиеся операции, несколько интегрированных систем и понятная логика эскалации, то внедрение SOAR обычно выгоднее постоянных наймов, платформа приносит предсказуемость, стабильное качество реакции и снижает нагрузку, особенно при ночных сменах. Но если в SOC царит хаос, процессы не выстроены, детекты сырые и отсутствует согласованность, то автоматизировать нечего. В таких случаях сначала необходимы опытные аналитики, которые приведут процессы в порядок, очистят сценарии и определят зоны автоматизации:

«SOAR хорошо масштабирует зрелость, но не создаёт её с нуля. Если база слабая — сперва инвестируем в людей и процессы, если база готова — автоматизируем».

Самую ёмкую формулу предложил Кирилл Добрынин, директор департамента автоматизации «Группы Астра», Product Director Astra Automation. Внедрять SOAR стоит тогда, когда уже есть аналитики, понимающие, что автоматизировать, и вместе с тем регулярный поток однотипных инцидентов, чтобы эту автоматизацию окупить. Платформа не создаёт экспертизу, она её умножает. Если некому писать и поддерживать плейбуки, никакого смысла в SOAR нет. Аналитиков стоит нанимать тогда, когда команда не справляется с нетиповыми инцидентами, требующими привлечения человека для принятия решения, поскольку такие случаи не автоматизируются по определению. Если поток инцидентов не высок и рост не прогнозируется, внедрение SOAR может просто не окупиться:

«SOAR без людей — бессмысленная инвестиция. Люди без SOAR — немасштабируемая».

Порог зрелости

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

«Иначе автоматизация хаоса приведёт к ещё большему хаосу».

Илья Силантьев, эксперт Security Vision, привёл наглядный пример: если в организации все активы исчисляются парой десятков, департамент ИБ состоит из нескольких сотрудников или отсутствует вовсе, из защиты только антивирус и межсетевой экран, которые фиксируют несколько инцидентов в месяц, а полноценных сценариев реагирования не предусмотрено, то работать с инцидентами можно вручную, параллельно развивая внутреннюю экспертизу, расширяя штат ИБ или внедряя новые процессы и СЗИ. Решения класса SOAR тяжеловесные и подходят не всем. Зрелость заказчика определяется не только размером инфраструктуры, но и отлаженностью процессов ИБ внутри организации. Перед внедрением должна быть организована дежурная смена аналитиков SOC, способная круглосуточно осуществлять мониторинг событий и реагирование на инциденты ИБ, а также необходимо иметь сценарии реагирования. Внутри организации важно «обрасти» экспертизой по работе с инцидентами и выстроить процессы, иначе внедрять систему не имеет смысла.

Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC, предложил простой критерий: если в компании есть SOC, то вопрос о внедрении SOAR стоять не должен, этот инструмент появится рано или поздно. Если же отдел ИБ состоит из двух-трёх человек, внедрение SOAR скорее будет избыточным, а дополнительный сотрудник может принести пользу.

Многое зависит от зрелости информационной безопасности, согласился Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline). Существуют крупные компании, где SIEM не используется вовсе, структуры, где штат ИБ ограничен одним-двумя специалистами, совмещающими функции по организационно-распорядительной документации и сопровождению средств защиты информации, и ситуации, когда целый SOC представлен в единственном лице. При таком подходе поддержка ещё одной сложной платформы становится заведомо невыполнимой задачей. Но даже в небольшом SOC грамотное применение SOAR способно впоследствии высвободить существенный временной ресурс команды за счёт автоматизации.

Экономика решения

Экономический аргумент озвучил Фёдор Музалевский, директор технического департамента RTM Group. Дополнительные аналитики имеют смысл, когда в компании не хватает экспертизы — SOAR будет работать на тех принципах, что есть в организации: периодичность контроля за обновлениями сигнатур сканера уязвимостей, глубина поиска артефактов, сроки расследования. Эти и другие параметры вносятся в SOAR в первую очередь на основании действующих регламентов, а экспертиза внедренцев позволит увеличить эффективность лишь кратковременно. Если же в компании есть классные специалисты, но им не хватает времени и собранности, однозначно требуется техническое решение:

«Окупаемость SOAR в среднем порядка года, это сравнимо с зарплатой одного специалиста с учетом налогов и социальных отчислений».

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

Как правило, вопрос «SOAR или аналитики» возникает у организаций, у которых уже есть SOC, отметил Максим Ежов, руководитель продукта R-Vision SOAR. Если SOC существует, значит ИТ-ландшафт уже достаточно большой и есть потребность в ускорении реагирования на инциденты и максимально быстром их нивелировании. В этом случае речь идёт не только об оптимизации ФОТ, но и о снижении финансовых потерь, которые бизнес может понести в случае серьёзного инцидента.

Константин Карасев, руководитель отдела процессной и системной аналитики, R-Vision, обозначил точку перелома: SOAR становится необходимостью, когда бизнес понимает, что при увеличении числа аналитиков скорость и качество реагирования уже не растут. Без автоматизации требуются аналитики высокой квалификации, понимающие, что делают и что должны делать при работе с инцидентом. Растить аналитиков с нуля всегда сложно, а нанимать опытных — дорого. Внедрение SOAR позволяет сбалансировать скорость и качество реагирования, а также стоимость владения как самой системой, так и командой, обеспечивающей её работу и процессы реагирования.

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

Российские SOAR в гетерогенной инфраструктуре

Эксперты настроены оптимистично. Алексей Тихонов делится личным опытом: за три года — от «сырости» к зрелости. Алексей Федоров фиксирует: отечественные производители идут на одном уровне с зарубежными, а иногда эффективнее. Единственная оговорка — от Станислава Прищепа: санкции усложняют интеграцию с иностранными продуктами. Фёдор Музалевский смещает фокус: проблема не в платформе, а в разрозненных СЗИ и неподготовленных исполнителях.

Около трёх лет Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline), занимается развитием SOAR-платформы в SOC своей компании. На начальном этапе массового перехода на отечественные ИТ-решения многие сталкивались с определённой «сыростью» продуктов — для решения собственных задач приходилось разрабатывать дополнительные модули, хотя SOAR уже тогда предлагал высокую гибкость в low-code-разработке и широкие возможности интеграции с внешними системами. За это время продукт серьёзно вырос: вендор оперативно устраняет выявленные недостатки и активно развивает библиотеку коробочных функциональных модулей, что заметно ускоряет внедрение у новых заказчиков. Сегодня SOAR вполне готов к решению широкого круга задач, хотя направления для дальнейшего развития ещё остаются.

Опыт работы с зарубежными и российскими решениями показал, что отечественные производители идут на одном уровне с иностранными, а иногда, с учётом импортозамещения и необходимости интеграции с российскими информационными системами, оказываются даже эффективнее и функциональнее, отметил Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC:

«В настоящее время нет технологического стоп-фактора по использованию SOAR-платформ в инфраструктуре любой сложности».

Рынок ИБ в России в последние годы неумолимо растёт, подтвердил Илья Силантьев, эксперт Security Vision. Производители активно развивают свои продукты в этой нише, внедряется множество ИИ-инструментов, а целевые заказчики видят в решении практическую пользу. Для SOAR, как агрегатора множества процессов ИБ, важно уметь безболезненно интегрироваться в инфраструктуру, не нарушив целостность этих процессов. Для организации взаимодействия с внешними системами существуют универсальные механизмы и протоколы: HTTP (API), PowerShell, SSH, WMI, SNMP, LDAP и пр. Большинство отечественных SOAR поддерживает эти транспорты, при этом не ограничивает пользователя и позволяет настроить их самостоятельно напрямую в интерфейсе системы, то есть платформа готова к интеграции со всем «зоопарком» оборудования и ПО в инфраструктуре:

«Да, российские SOAR-платформы готовы к таким задачам».

Российские SOAR-платформы полностью готовы, полагает Максим Ежов, руководитель продукта R-Vision SOAR. На рынке есть ряд достаточно зрелых российских SOAR-платформ с большим количеством преднастроенных инструментов для интеграции и взаимодействия с любой другой ИТ и ИБ системой. При этом многое зависит не только от самой платформы, но и от наличия готовых коннекторов, открытого API и зрелости инструментов интеграционного слоя для настройки взаимодействия. Именно это определяет, насколько быстро SOAR можно встроить в существующий ИТ-ландшафт заказчика и начать использовать. Ключевой вопрос сегодня, по мнению Максима Ежова, скорее не в том, может ли российский SOAR работать в сложной гетерогенной среде, а в том, насколько хорошо он сможет поддержать конкретные процессы заказчика, не создав лишних проблем.

Николай Казанцев, генеральный директор SECURITM, отметил: чистота и работа SOAR зависит от того, как система будет интегрирована с остальными СЗИ внутри компании. Для работы в сложной инфраструктуре SOAR-система должна иметь как минимум API, а по-хорошему — большой набор встроенных интеграций с SIEM, EDR, NGFW, DLP и пр., что обеспечивает беспрерывность работы и даёт возможность быстро настроить систему службам ИБ.

Иной угол зрения предложил Фёдор Музалевский, директор технического департамента RTM Group: сложность инфраструктуры не сильно влияет на готовность SOAR, проблемы создают разрозненные средства защиты и неподготовленные исполнители, но именно для организации их работы и нужен SOAR. В качестве примера Фёдор Музалевский привёл промышленное предприятие с сегментами Ethernet и Profibus: действие «сбор трафика из заражённых сегментов» может не быть выполнено «в один клик», но может быть поставлена задача нескольким экспертам на сбор трафика в обоих сегментах параллельно, с дальнейшим анализом и соблюдением регламента.

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

Останется ли у SOAR собственная ниша

Вендоры SIEM и XDR наращивают встроенную автоматизацию, и вопрос о будущем SOAR как самостоятельного класса вызвал разногласия. Большинство экспертов уверены: пока инфраструктура остаётся разнородной, SOAR сохранит роль межсистемного оркестратора. Единственным оппонентом выступил Фёдор Музалевский, предсказывающий размывание ниши по аналогии с антивирусами. Илья Силантьев считает сравнение SIEM, XDR и SOAR некорректным: эти системы решают разные прикладные задачи и при зрелом уровне ИБ дополняют друг друга.

Самую чёткую границу между SOAR и смежными классами провёл Дмитрий Пензов, технический директор компании ATLAS. По его оценке, встроенная автоматизация в SIEM или XDR хорошо работает внутри собственной экосистемы и часто достаточно эффективна для обогащения событий, применения политик, изоляции хостов или выполнения локальных действий. Однако когда процесс выходит за рамки одного продукта и требует взаимодействия между разными системами — почтой, сетью, IAM, тикет-системами, песочницами, а также согласования между несколькими командами с разными зонами ответственности, встроенная автоматизация начинает ограничивать. В таких случаях необходим отдельный уровень оркестрации, который обеспечивает связность и управление сквозным процессом от получения сигнала до закрытия инцидента:

«Автоматизация в SIEM и XDR сосредоточена на действиях внутри конкретных инструментов, а SOAR объединяет разнородные компоненты инфраструктуры в единый процесс. Пока инфраструктура остается разношерстной и требует межсистемной координации, SOAR сохранит свою важную и независимую нишу».

Единственным оппонентом стал Фёдор Музалевский, директор технического департамента RTM Group. По его наблюдению, крупные проекты, прежде всего XDR, уже давно играют на «полянках» друг друга, а ограниченных ниш, подобных SOAR, в общем-то, никогда и не было — продукт, решающий узкоспециализированную задачу, никому не интересен. Границы между классами решений размываются, и остаться самостоятельным решением практически нереально. Он привел пример эволюции антивирусов, которые со временем получили функционал межсетевого экрана и EDR, а сами решения класса XDR во многом просто «продвинутые SIEM»:

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

Оркестрация без вендорских ограничений

Илья Силантьев, эксперт Security Vision, считает сравнение SIEM, XDR и SOAR некорректным — эти системы решают абсолютно разные прикладные задачи, но при зрелом уровне ИБ внутри организации дополняют друг друга. SIEM и XDR не обладают таким обширным инструментарием, как SOAR, среди особенностей которого Илья Силантьев выделил три: построение гибкого процесса обработки инцидентов по лучшим отечественным и международным методикам с применением динамических сценариев реагирования, автоматизированный сбор данных в окрестности инцидента для максимального погружения в контекст, а также интеграции с внешними аналитическими системами для обогащения инцидента и выявления индикаторов из общедоступных бюллетеней безопасности. При этом SIEM и XDR могут интегрироваться с SOAR, например, в части работы с табличными списками для SIEM или редактирования политик на конечных узлах для XDR.

Того же мнения придерживается Николай Казанцев, генеральный директор SECURITM: SOAR сохранит свою уникальную нишу даже при усилении автоматизации внутри SIEM и XDR-платформ. Его главное преимущество — это координация действий в сложных, разнородных инфраструктурах благодаря гибким настраиваемым плейбукам, которые позволяют эффективно решать сложные задачи для автоматизации.

Станислав Прищеп, руководитель продукта STEP Smart SOC, уверен: ниша SOAR точно сохранится и, скорее всего, будет расти вместе с рынком. Многие компании уже внедрили узкоспециализированные SIEM/XDR-решения, получили необходимый опыт и видят свою потребность в автоматизации процессов с использованием зонтичного продукта:

«Ключевым критерием его выбора часто становится вендоронезависимость».

При этом Станислав Прищеп признаёт: комбинированные решения «всё в одном» позволяют оптимизировать расходы на внедрение и эксплуатацию, они оптимальны на старте или при создании SOC-сервиса в тесном партнёрстве с разработчиком.

На пути к единой экосистеме

Несколько экспертов прогнозируют сближение классов решений, но расходятся в деталях.

Одна из основных функций SOAR — это оркестрация подозрений на инциденты ИБ из разных систем, напомнил Алексей Федоров, руководитель практики внедрения решений для центров мониторинга и реагирования на инциденты ИБ STEP LOGIC. У решений этого класса нет вендорских ограничений по источнику подозрения на инциденты ИБ: они могут отдавать команды реагирования в XDR разных производителей, а инциденты можно формировать, например, из DLP-системы напрямую, параллельно с SIEM и ручным вводом. Команды на реагирование или обогащение контекстом можно отправлять в любую информационную систему, которая имеет интерфейс взаимодействия. С другой стороны, сами вендоры SOAR не ограничивают свой портфель только данным классом решений, как правило, у них есть минимум SIEM. В перспективе, по мнению Алексея Федорова, возможна полная конвергенция:

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

Алексей Тихонов, руководитель группы расследования инцидентов ИБ Infosecurity (ГК Softline), полагает, что SIEM, XDR и SOAR в перспективе должны быть объединены в единую экосистему, намёки на это уже видны у некоторых зарубежных вендоров. Экспансия взаимна: некоторые SOAR-платформы уже предлагают встроенные SIEM-модули с готовыми пакетами правил корреляции, и иногда за этим стоит не только маркетинг, но и вполне рабочий инструментарий. Как минимум, конкуренция двигает прогресс, и в обозримом будущем возможно появление качественных универсальных платформ либо тесной коллаборации продуктов разных вендоров. При этом Алексей Тихонов подчеркнул: автоматизация и применение искусственного интеллекта меняют форму реализации процессов, но не их суть — по-прежнему необходимо создавать правила корреляции, разрабатывать плейбуки и выстраивать интеграции.

Для MSSP-провайдеров критически важны широкая функциональность и гибкость инструментов, и с тем объёмом возможностей, который сегодня предлагают классические SIEM-решения, поставленных целей не достичь. При этом Алексей Тихонов не исключает, что для некоторых корпоративных SOC достаточно будет одного универсального продукта, и вовсе не факт, что таким продуктом станет именно SIEM. В пользу SOAR говорит, в частности, то, что его область применения не ограничивается событиями из SIEM или средств защиты информации:

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

Границы между SIEM, XDR, IRP и SOAR действительно очень размыты, уже не понятно, какой продукт за что в точности отвечает и где заканчиваются границы одного и начинаются границы другого, признаёт Дмитрий Чеботарев, менеджер по развитию UserGate SIEM. Он сослался на концепцию TDIR (Threat Detection, Investigation and Response) от коллег из Gartner, согласно которой функциональность IRP/SOAR заберёт на себя SIEM. Тем не менее самостоятельные решения IRP и SOAR активно развиваются, в том числе в России:

«Я бы сделал прогноз на то, что SIEM, IRP и SOAR будут развиваться параллельно друг другу и работать в рамках единой экосистемы».

Заключение

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

Написать рабочий плейбук, по мнению участников дискуссии, сложнее, чем развернуть платформу. Рынок отвечает коробочным контентом на базе БДУ ФСТЭК России и MITRE ATT&CK, как подчеркнул Илья Силантьев, вендоры предлагают «не просто инструмент, а полноценный фундамент для дальнейшего развития SOC» — low-code-конструкторами и no-code-инструментами, но адаптация под конкретного заказчика неизбежна. Станислав Прищеп обозначил радикальный горизонт: AI SOAR со встроенными ИИ-агентами может вовсе отказаться от классического плейбука, заменив его текстовым описанием полномочий и целей реагирования.

По числу необходимых интеграций мнения разошлись — от двух (Максим Ежов: SIEM + AD) до десятков (Алексей Тихонов). При этом Кирилл Добрынин, Константин Карасев и Дмитрий Пензов единодушны: качество интеграций важнее их количества, а без понимания задачи интеграция превращается в «иллюзию автоматизации». Единственную контрпозицию занял Фёдор Музалевский, напомнив, что SOAR работает и без интеграций, его главная ценность в систематизации работы. Илья Силантьев добавил законодательный аспект: объекты КИИ и финансовые организации обязаны интегрироваться с ГосСОПКА и FinCERT.

Трансформация роли SOC-аналитика — вопрос, по которому мнения экспертов наиболее близки: рутина уходит, роль усложняется. Дмитрий Пензов отметил, что аналитик становится больше похож на инженера — меньше механики, больше аналитики; Константин Карасев зафиксировал смену приоритетов, от технических навыков к аналитическим. По оценке Николая Казанцева, автоматизация берёт на себя 60–80% типичных задач.

Выбор между SOAR и наймом аналитиков эксперты не считают дилеммой «или/или». Порог зрелости процессов — обязательное условие: автоматизация хаоса, как предупредил Станислав Прищеп, приведёт лишь к большему хаосу. Самую ёмкую формулу предложил Кирилл Добрынин: «SOAR без людей — бессмысленная инвестиция. Люди без SOAR — немасштабируемая».

Готовность российских SOAR-платформ к работе в сложной гетерогенной все эксперты оценили позитивно. Алексей Тихонов подтвердил это личным трёхлетним опытом, Алексей Федоров — сравнением с зарубежными решениями. Среди оговорок — Станислав Прищеп указал, что санкции усложняют интеграцию с иностранными продуктами, а Алексей Тихонов отметил, что на начальном этапе импортозамещения некоторые продукты отличались «сыростью», хотя направления для развития уже определены.

Будущее SOAR как самостоятельного класса вызвало наиболее острую дискуссию. Большинство уверено: пока инфраструктура остаётся разнородной, межсистемная оркестрация необходима. Илья Силантьев назвал сравнение SIEM, XDR и SOAR некорректным — эти системы решают разные задачи и дополняют друг друга. Фёдор Музалевский стал единственным оппонентом, проведя аналогию с антивирусами: ниша растворится, а функциональность переместится внутрь более крупных платформ.

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

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