За последние два года я перенёс больше 200 правил корреляции из Splunk SPL и QRadar AQL в MaxPatrol SIEM и KUMA. Скажу честно: ни один вендорский гайд не описывает и половины того, с чем сталкиваешься при реальной миграции. Вендор обещает «бесшовный переход за три месяца», а на практике ты проводишь ночи, разбираясь, почему правило детекции Kerberoasting, работавшее в Splunk три года, в новой системе генерирует либо шторм ложных срабатываний, либо молчит вовсе.
Это не маркетинговый обзор российского SIEM 2025 и не пересказ слайдов вендора. Это технический разбор того, что именно ломается при переходе с Splunk на российский SIEM, как переносить правила корреляции без потери покрытия MITRE ATT&CK и где отечественные решения пока объективно уступают западным платформам.
Если вы пентестер - вам особенно полезно понимать, какие детекции SOC теряет в период миграции. Это то самое окно, в которое красная команда может работать значительно комфортнее обычного. Запомните таблицу из раздела про MITRE - пригодится.
Почему переход с Splunk на российский SIEM - не замена одного окна другим
Регуляторное давление стало главным двигателем импортозамещения SIEM. Указ Президента РФ No 250 от 1 мая 2022 года запретил с 1 января 2025 года использование СЗИ, произведённых в недружественных государствах, для субъектов КИИ, органов власти и системообразующих организаций. По ФЗ-187 «О безопасности КИИ» субъекты КИИ обязаны обеспечить взаимодействие с ГосСОПКА (ст. 5), а категорирование объектов КИИ (ст. 7) определяет уровень требований к используемым СЗИ. Под действие этих нормативов подпадает около 500 тысяч организаций. Отечественный SIEM, сертифицированный ФСТЭК по Приказу No 76, стал единственным легальным путём.
Параллельно подталкивает и сам рынок. IBM в мае 2024 продала QRadar SaaS-активы Palo Alto Networks; сделка закрыта 4 сентября 2024 года. On-premises QRadar остался у IBM, но клиентам рекомендована миграция на Palo Alto Cortex XSIAM. По данным Blumira со ссылкой на Palo Alto Networks End-of-Life Summary, QRadar Cloud достигает конца жизненного цикла 14 апреля 2026 года, QRadar EDR и XDR - 31 августа 2026 года. On-premises версия формально без объявленной даты EOL, но инвестиции IBM в платформу фактически прекращены. Аналитики Forrester прямо назвали это «сдачей» IBM рынка SIEM. По сути - QRadar медленно умирает, и все это понимают.
По данным Positive Technologies, средний срок миграции крупной организации - около двух лет (с учётом бюджетного цикла и переноса контента в разветвлённых инфраструктурах). Основная сложность не в установке нового ПО, а в трёх вещах: перенос правил корреляции событий, воссоздание дашбордов с нуля и переподключение десятков интеграций - от AD и антивирусов до SOAR и тикетинг-систем.
Перенос правил корреляции SIEM: где автоматический конвертер бессилен
Синтаксис SPL и AQL против отечественных языков запросов
Splunk SPL - зрелый язык с макросами, lookup-таблицами, подзапросами и конвейерной обработкой. QRadar AQL ближе к SQL, с JOIN и агрегацией. Отечественные SIEM используют собственные синтаксисы: MaxPatrol SIEM работает с PDQL и формулами корреляции на основе табличных правил, KUMA - со своим движком корреляции и визуальным редактором. Конвертация Splunk SPL в синтаксис отечественной системы - это не синтаксический перевод. Это семантический.Когда пишешь в Splunk
index=wineventlog EventCode=4688 New_Process_Name="[I]mimikatz[/I]", ты неявно полагаешься на то, что поле New_Process_Name нормализовано из Windows Event XML определённым Splunk-парсером. В MaxPatrol SIEM аналогичное поле будет в иерархии вида object.process.name или object.process.fullpath - и конкретный маппинг зависит от версии нормализатора источника. То же правило, та же логика - но работает только при корректном маппинге полей. Одна опечатка в иерархии - и правило тихо молчит.Первый шаг перед миграцией - инвентаризация существующих правил. Для Splunk есть запрос из документации Microsoft Sentinel, выгружающий все активные алерты с метаданными:
Код:
| rest splunk_server=local count=0 /servicesNS/-/-/saved/searches
| search disabled=0 is_scheduled=1
| table title, search, description, cron_schedule,
dispatch.earliest_time, alert.severity,
alert_comparator, alert_threshold
| tojson | table _raw
| rename _raw as alertrulesappend - рекомендую использовать её для полноты картины. Для QRadar аналогичная задача решается через API /api/analytics/rules с фильтрацией по enabled=true. По опыту CYREBRO, процесс конвертации правил - «time-consuming and error-prone»: дашборды не транслируются, а ограниченные интеграции могут вынудить менять инструментарий в стеке.Маппинг полей: одно событие - разные имена
Главная боль миграции - не синтаксис, а таксономия полей. Одно и то же Windows Security Event в разных SIEM маппится по-разному. Вот реальная таблица соответствия для ключевых полей, которую я составлял при миграции с QRadar на отечественный SIEM:| Понятие | Splunk CIM (raw-поле Windows TA) | QRadar DSM | MaxPatrol SIEM (PDQL) |
|---|---|---|---|
| IP источника | src (CIM) / src_ip (raw) | sourceIP | event.src.host |
| IP назначения | dest (CIM) / dest_ip (raw) | destinationIP | event.dst.host |
| Имя пользователя | user (CIM) / Account_Name (raw) | userName | subject.account.name |
| Имя процесса | process_name (CIM) / New_Process_Name (raw) | Process Name (property) | object.process.name |
| ID события Windows | signature_id (CIM) / EventCode (raw) | Event ID (normalized) | event.id / msgid |
| Имя хоста | dest (CIM) / host, ComputerName (raw) | Log Source | event.src.host |
Обратите внимание на последнюю строку. В Splunk
host - это хост, отправивший лог. В QRadar Log Source - источник в нормализованной модели. В MaxPatrol SIEM event.src.host может содержать как IP, так и hostname в зависимости от нормализатора конкретного источника. Разница кажется мелкой, но при переносе правил с корреляцией по хосту через JOIN она убивает детекцию: сопоставление IP и hostname даёт пустой результат, правило тихо перестаёт срабатывать. Я на этом потерял два дня, пока не догадался проверить типы данных в полях.Практический совет: перед миграцией создайте полную таблицу маппинга для ваших TOP-50 правил. Не для всех полей в системе - для полей, используемых в корреляционной логике. Это сэкономит недели работы.
Какие детекции MITRE ATT&CK теряются при импортозамещении SIEM
По данным CardinalOps (5th Annual State of SIEM Detection Risk Report, 2025), enterprise-SIEM в среднем покрывают активными детекциями лишь 21% техник MITRE ATT&CK. Ещё 13% существующих правил нефункциональны - они никогда не сработают из-за ошибок конфигурации или отсутствия нужных источников. При миграции эти цифры не улучшаются. Они ухудшаются, потому что даже работавшие правила временно выходят из строя.Из моего опыта, чаще всего при миграции на российский SIEM «теряются» детекции из тактики Defense Evasion:
| Техника MITRE ATT&CK | Причина потери при миграции |
|---|---|
| Disable or Modify Tools (T1562.001, Defense Evasion) | Правило опирается на специфичные поля EDR-интеграции (CrowdStrike, Carbon Black), которые в отечественном SIEM маппятся иначе или не маппятся совсем |
| Clear Windows Event Logs (T1070.001, Defense Evasion) | Детекция Event ID 1102 привязана к lookup-таблице допустимых очисток в Splunk; при переносе lookup теряется, правило начинает давать ложные срабатывания |
| Disable Windows Event Logging (T1562.002, Defense Evasion) | Требует корреляции с registry-событиями Sysmon (ID 13), нормализация которых в каждом SIEM сделана по-своему |
| Spoof Security Alerting (T1562.011, Defense Evasion) | Сложная корреляция по цепочке событий - оконные функции и таймфреймы в разных движках работают по-разному |
Отдельная история - техники из тактики Discovery: Security Software Discovery (T1518.001) и Log Enumeration (T1654). Правила для них часто опираются на whitelist-ы легитимного ПО и процессов, хранящиеся в lookup-таблицах Splunk или reference sets QRadar. При замене иностранного SIEM эти списки нужно переносить вручную в формат табличных списков целевой системы - и не забывать поддерживать их актуальность.
Для пентестеров это критически важная информация. Период активной миграции SOC - окно пониженной видимости. Если вы проводите Red Team в организации, где идёт SIEM импортозамещение, техники Defense Evasion из таблицы выше - ваши лучшие друзья. Особенно T1070.001 (Clear Windows Event Logs): если правило на Event ID 1102 ещё не перенесено и не валидировано, очистка журналов пройдёт незамеченной. А T1213 (Data from Information Repositories, Collection) часто вообще не имеет аналога в отечественных пакетах экспертизы, потому что детекция строилась на специфичных логах SharePoint/Confluence через Splunk-аддоны. По сути - SOC в этот момент слеп на один глаз, и красная команда может этим пользоваться.
Миграция дашбордов SIEM: что автоматизируется, а что строится заново
Русскоязычные материалы о миграции полностью игнорируют тему дашбордов - будто визуализации не часть SOC-процесса. На практике дашборды - это глаза дежурной смены. Без них аналитик слеп.
На западном рынке Elastic уже реализовал автоматическую миграцию дашбордов из Splunk с использованием LLM. По данным блога Elastic, функция Automatic Migration for Dashboards (technical preview, Enterprise-лицензия) парсит XML-структуру Splunk-дашборда, анализирует каждую панель через LLM, транслирует SPL-запросы в ES|QL и создаёт Kibana-объект. Система сканирует ссылки на макросы и lookup-таблицы, запрашивая их загрузку для сохранения функциональной эквивалентности. Summary-вкладка объясняет логику выбора полей и команд.
В отечественных SIEM ничего подобного нет. Миграция дашбордов SIEM на российскую платформу выглядит так:
| Аспект | MaxPatrol SIEM | KUMA |
|---|---|---|
| Импорт дашбордов из Splunk | Нет, ручное пересоздание | Нет, ручное пересоздание |
| Визуальный конструктор | Да, виджеты и панели | Да, конструктор отчётов |
| Поддержка drill-down | Частично | Частично |
| Шаблоны для SOC | Поставляются в пакетах экспертизы | Базовый набор |
| Кастомные визуализации | Ограничены типами виджетов | Ограничены типами виджетов |
Мой подход - не копировать старые дашборды один в один, а сначала провести аудит: какие панели реально использует дежурная смена, а какие висят мёртвым грузом. Обычно из 30 дашбордов Splunk реально нужны 8-10. Четыре, без которых SOC не работает: обзор инцидентов за 24 часа с разбивкой по severity, топ-10 источников по объёму событий (контроль pipeline), алерты в разрезе тактик MITRE ATT&CK, статус подключения источников с детекцией «молчащих» устройств.
Последний пункт - самый коварный. По данным Databahn, традиционные pipeline-архитектуры не способны определить, когда устройство перестало отправлять логи из-за ошибки конфигурации. Это остаётся незамеченным, пока инцидент не обнажит пробел. При миграции число таких пробелов временно возрастает. Для красной команды это ещё один подарок: источник может «отвалиться» при переключении, и SOC об этом узнает не сразу.
Перенос интеграций SIEM: коннекторы, форматы, ГосСОПКА
Интеграции - третий столп миграции после правил и дашбордов. Типичная инсталляция Splunk или QRadar в крупной организации подключена к 20-50 источникам через разные транспорты: Syslog UDP/TCP/TLS, CEF, LEEF, WinCollect (QRadar), Universal Forwarder (Splunk), REST API, JDBC.При переходе на отечественный SIEM замена Splunk означает пересборку каждого коннектора. Вот ключевые отличия по категориям.
Syslog-источники (МЭ, IDS/IPS, сетевое оборудование) переносятся относительно легко - достаточно перенаправить поток на новый коллектор. Но парсинг и нормализация будут другими, поэтому проверяйте каждый source type после переключения. Лично у меня был случай, когда CEF от Palo Alto после переключения терял поле
src - оказалось, нормализатор ожидал другой порядок extension-полей.Windows-события собираются в Splunk через Universal Forwarder или HEC, в QRadar - через WinCollect. MaxPatrol SIEM миграция Windows-логов происходит через собственные агенты или WEC (Windows Event Collection); KUMA Kaspersky миграция - аналогично через свои коллекторы с поддержкой WEC. Перенастройка Windows-инфраструктуры - самая трудоёмкая часть: агенты нужно переустановить на каждом хосте. На парке в 500+ машин это отдельный проект.
EDR/AV-интеграции - отдельный нюанс. Если SOC использовал CrowdStrike или SentinelOne с нативными модулями для Splunk, в отечественном SIEM этих модулей нет. При переходе на Kaspersky EDR интеграция с KUMA будет нативной. С другими отечественными SIEM - через стандартные механизмы. Но если EDR остаётся западным (частая ситуация: EDR ещё не заменён), интеграция потребует написания кастомного парсера. И вот тут для пентестера опять окно: пока парсер не написан и не отлажен, EDR-алерты до SIEM не доходят.
ГосСОПКА - обязательное требование для субъектов КИИ по ФЗ-187, ст. 5. Отечественные SIEM поддерживают интеграцию с НКЦКИ нативно, и это объективное преимущество: в Splunk и QRadar такая интеграция всегда была кастомной разработкой.
| Транспорт | Splunk | QRadar | MaxPatrol SIEM | KUMA |
|---|---|---|---|---|
| Syslog (UDP/TCP/TLS) | Нативно | Нативно | Нативно | Нативно |
| CEF | Нативно | Нативно | Нативно | Нативно |
| LEEF | Через парсинг | Нативно | Через парсинг | Через парсинг |
| Windows Events (агент) | Universal Forwarder | WinCollect | MaxPatrol Agent / WEC | Коллектор / WEC |
| REST API | Нативно | Нативно | Частично | Частично |
| JDBC | Нативно | Нативно | Частично | Частично |
| ГосСОПКА | Кастомная разработка | Кастомная разработка | Нативно | Нативно |
Пошаговый план: 5 фаз перехода на отечественный SIEM
Требования к окружению
Перед началом миграции убедитесь:- Отечественный SIEM развёрнут и лицензирован (минимум пилотная лицензия)
- Есть доступ к API или CLI текущего Splunk/QRadar для экспорта правил (в Splunk нужна роль admin)
- Сетевая инфраструктура позволяет отправлять логи одновременно на два коллектора (dual-destination routing)
- Команда SOC прошла хотя бы базовое обучение синтаксису нового SIEM
- Составлен реестр подключённых источников - без инвентаризации активов (NIST CSF ID.AM-01) миграция превращается в хаос
- Определён baseline сетевых потоков (NIST CSF DE.AE-01) для валидации после переключения
Фаза 1: параллельная установка
Разверните отечественный SIEM параллельно с действующей системой. Настройте дублирование потока логов от 3-5 ключевых источников (AD, МЭ, DNS) на обе платформы. Это позволяет валидировать нормализацию и парсинг на реальных данных без прерывания текущего мониторинга. По данным Databahn, подход с единым pipeline-слоем между источниками и SIEM позволяет сократить миграцию с месяцев до недель, но в отечественной реальности такой «фабрики данных» обычно нет - дублирование настраивается вручную на уровне Syslog или копирования сетевого трафика.Фаза 2: перенос TOP-20 правил
Начните с 20 наиболее критичных правил корреляции. Не пытайтесь перенести всё сразу - это гарантированный путь к выгоранию команды и каше из полуработающих детекций. Для каждого правила: выгрузите SPL/AQL-логику, идентифицируйте используемые поля и lookup-таблицы, создайте маппинг полей в таксономию нового SIEM, напишите правило на языке целевой платформы, сравните результаты на одних и тех же событиях. Одно и то же действие должно генерировать алерт в обеих системах. Если не генерирует - ищите проблему в маппинге полей, а не в логике. В 9 случаях из 10 дело именно в маппинге.Фаза 3: миграция источников
Последовательно переключайте источники на новый SIEM. Начинайте с облачных и Syslog-источников - они мигрируются быстрее всего. Windows-источники переключайте последними: замена агентов (UF/WinCollect на агенты отечественного SIEM) требует раскатки по всему парку хостов.Критически важен контроль «молчащих» источников. После переключения каждого source проверяйте поступление событий. Рекомендую создать простейший дашборд с подсчётом событий по источнику за последние 15 минут - это ваш индикатор здоровья pipeline. Если счётчик упал в ноль - что-то отвалилось, и чем быстрее вы это заметите, тем меньше будет слепая зона.
Фаза 4: перенос оставшегося контента
На этом этапе переносятся оставшиеся правила корреляции, пересоздаются приоритетные дашборды, мигрируются white/black-листы и lookup-таблицы, настраиваются отчёты для compliance, интеграция с SOAR/IRP и тикетинг-системой. Для субъектов КИИ - настройка взаимодействия с ГосСОПКА, включая уведомление НКЦКИ об инцидентах в установленные сроки (не позднее 24 часов с момента обнаружения, а для атак на госорганы - 3 часа, согласно Приказу ФСБ России No 367 от 24.07.2018).Фаза 5: вывод старого SIEM
Отключайте Splunk/QRadar только после минимум 30 дней работы нового SIEM в полном объёме без критичных пробелов. Сохраните доступ к архивным данным: QRadar хранит историю в проприетарном формате, который сложно экспортировать. По данным Databahn, организации вынуждены либо поддерживать QRadar в read-only режиме, либо смириться с потерей ретроспективного анализа. Тут каждый решает сам, но терять возможность ретроспективного поиска по инцидентам - больно.Что в отечественном SIEM пока уступает Splunk и QRadar - честный разбор
Говорить только о преимуществах - лицемерие. Вот слабые стороны, с которыми я столкнулся лично при SIEM импортозамещении.Язык запросов. SPL - зрелый, документированный язык с сотнями команд, макросами, подзапросами и огромным community. По данным CyberSilo, SPL «purpose built for time series correlation and includes rich transformations and macros that experienced SOC teams use to build scalable detections». PDQL и языки запросов KUMA функционально беднее. Сложные корреляции, которые в SPL пишутся в 5 строк с
stats, eval и transaction, в отечественных системах требуют обходных путей или вообще нереализуемы средствами запросного языка. Это не придирка - это реальность, с которой SOC-инженер сталкивается каждый день.Экосистема приложений. Splunkbase содержит тысячи приложений и add-on-ов. В Splunk ты ставил TA для Palo Alto и получал готовый парсинг, нормализацию и дашборды. В отечественном SIEM пишешь нормализатор самостоятельно или ждёшь, пока вендор добавит поддержку. Иногда ждёшь долго.
ML/UEBA. Splunk Enterprise Security включает зрелые модели машинного обучения и UEBA, QRadar тоже имел развитую поведенческую аналитику. В отечественных SIEM ML-возможности на более ранней стадии. MaxPatrol SIEM активно развивает поведенческий анализ, KUMA интегрируется с Kaspersky TI - но по зрелости ML-моделей разрыв остаётся.
Автоматическая миграция. Microsoft Sentinel и Elastic Security уже предлагают инструменты автоматического переноса правил и дашбордов с LLM-анализом. Ни один отечественный SIEM пока не имеет подобного инструментария. Переносим руками - как в 2015-м.
Что объективно лучше в отечественных решениях: нативная интеграция с ГосСОПКА, сертификация ФСТЭК, техподдержка на русском языке в вашем часовом поясе, адаптация пакетов экспертизы под российские угрозы. Для ряда организаций отечественные SIEM также дешевле по совокупной стоимости владения - Splunk печально известен ценообразованием по объёму индексируемых данных (и счета за него могут вызвать инфаркт у финдиректора).
SOC импортозамещение - процесс, который при грамотном подходе улучшает зрелость центра мониторинга. Миграция заставляет пересмотреть правила, убрать нефункциональные детекции и заново оценить источники. Но только если вы относитесь к процессу как к инженерному проекту, а не как к административной формальности с галочкой в отчёте.
Вопрос к читателям
При переносе правил из Splunk SPL в MaxPatrol SIEM самой проблемной категорией в моей практике оказались детекции T1562.001 (Disable or Modify Tools, Defense Evasion) - из-за зависимости от EDR-специфичных полей, которые в PDQL-таксономии нормализуются иначе. А с какой техникой MITRE ATT&CK у вас были наибольшие сложности при конвертации правил корреляции? Интересуют конкретные примеры: исходное SPL или AQL-правило, целевая платформа (MaxPatrol SIEM, KUMA, RuSIEM) и что именно пришлось переписывать - маппинг полей, логика оконной корреляции, зависимость от lookup-таблицы или отсутствие аналогаtransaction / tstats в целевом языке?
Последнее редактирование модератором:
