Что проверить на пилоте SIEM-системы, чтобы подготовиться к промышленному запуску

Привет! Меня зовут Андрей Баранцев, я аналитик группы развития и сопровождения Solar SIEM в ГК «Солар». Наша команда проводит пилоты Solar SIEM у клиентов: разворачивает систему, подключает источники, проверяет ее под нагрузкой и вместе с ИБ-командами тестирует сценарии.

В первой половине 2026 года мы провели 40 пилотов Solar SIEM. За это время несколько проблем повторялись на разных проектах: инфраструктура по характеристикам подходит, а реальный поток не держит; большая часть пилота уходит на развертывание и интеграции, а сценарии остаются на конец; команда только во время тестирования выясняет, насколько самостоятельно сможет работать с контентом.

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

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

Урок 1. Что делать, если инфраструктура не выдерживает фактический поток событий

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

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

При этом одних данных об объеме оперативной памяти и количестве процессоров недостаточно. Для SIEM критична фактическая производительность дисковой подсистемы, прежде всего скорость чтения и записи. Оборудование может соответствовать требованиям по заявленным характеристикам, но под нагрузкой не выдавать нужные показатели.

На одном из пилотов Solar SIEM развернули в системе виртуализации клиента и подали поток 1,5 тыс. EPS, то есть событий в секунду. На сервисе корреляции быстро сформировалась очередь. По заявленным характеристикам виртуальные машины соответствовали требованиям, поэтому инженеры проверили компоненты по отдельности и обнаружили недостаточную скорость дисковой подсистемы.

Клиент не мог заменить диски во время пилота. Специалисты Solar SIEM увеличили объем оперативной памяти инсталляции с 64 до 80 ГБ и настроили лимиты ее использования для микросервисов под фактический поток. После изменения конфигурации сервисы корреляции и обогащения стабильно обрабатывали поступающие события.

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

Проблемы с дисковой подсистемой лучше выявить на старте. Уже в ходе пилота быстро заменить диски или пересобрать инфраструктуру получается не всегда.

Урок 2. Почему сценарии нельзя оставлять на конец пилота

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

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

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

В конце каждого пилота команда Solar SIEM совместно с клиентом моделирует сценарий нарушения в тестовом контуре. Инженеры проверяют правила корреляции, получение дополнительного контекста, работу интеграций и реакцию системы.

Один из демонстрационных сценариев связан с очисткой журнала Windows. Solar SIEM фиксирует действие, определяет пользователя и хост, получает информацию об активных учетных записях и блокирует учетную запись, от имени которой очистили журнал. Клиент видит всю цепочку – от события в источнике до автоматизированного реагирования – и понимает, какие операции можно передать системе, а где решение остается за специалистом.

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

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

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

Урок 3. Как проверить, сможет ли команда развивать контент сама

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

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

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

Особенно заметна эта проблема на внутренних информационных системах. У компании может быть собственное приложение с нетиповыми событиями, на котором завязан важный бизнес-процесс. Готового контента для него у производителя может не быть.

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

По оценке специалистов Solar SIEM, два-три клиента из десяти активно развивают конфигурацию уже во время тестирования.

На одном из проектов команда клиента совместно со специалистами Solar SIEM настроила обработку событий из 1С: подготовила нормализацию, создала корреляционное правило и сценарий автоматизированного реагирования.

Для проверки участники смоделировали перебор паролей к учетной записи 1С. Solar SIEM обнаружила последовательные попытки входа и завершила соединение с атакуемой учетной записью. Финальную демонстрацию провели специалисты клиента: самостоятельно воспроизвели действие и показали работу созданных правил.

Если на пилоте изменить правило без помощи пока не получается, в план внедрения можно сразу добавить обучение или сопровождение.

Заложите в пилот несколько часов на тестирование возможностей команды клиента

Урок 4. Где теряется время при подключении источников

Даже с готовым коннектором подключение источника иногда занимает несколько дней. Хорошо это видно на базах данных.

Инженеру нужно указать тип СУБД, периодичность обращения, размер пакета, адрес и порт сервера, имя базы данных, учетные данные, SQL-запрос и настройки сортировки. При ошибке причина может быть в сети, правах учетной записи, самом запросе или формате полученных данных.

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

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

На пилоте мы смотрим, сколько времени занимает такая адаптация и что приходится менять в нормализации и связанном контенте.

Подключение баз данных показало еще одну точку, на которой терялось время, – диагностику. Часть первичной проверки команда продукта перенесла в интерфейс Solar SIEM.

Теперь инженер заполняет параметры и запускает тест. SIEM-система проверяет сетевое соединение и возможность чтения данных, а результат показывает в том же окне.

Если соединение установить не удалось, интерфейс показывает адрес и порт, на которых возникла ошибка, и предлагает повторить тест после изменения параметров. Инженер последовательно проверяет настройки, не переключаясь между Solar SIEM, базой данных и журналами.

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

Демонстрационный источник показывает работу коннектора в подготовленных условиях. Реальные источники дают более точное представление о трудозатратах в конкретной инфраструктуре.

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

Что должно быть понятно к концу пилота

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

Отдельная тема – подготовка самого клиента к пилоту. Проект может затянуться еще до технических проверок: не выделили вовремя инфраструктуру, не настроили сетевые доступы или не собрали нужных специалистов. С такими ситуациями мы тоже сталкивались. В следующем материале разберем, что нужно подготовить до старта пилота и какие организационные проблемы чаще всего его тормозят.

А подробный список того, что стоит проверить уже на самом пилоте и зафиксировать по его итогам, мы собрали в отдельном чек-листе.