Поделиться
Как проверить SIEM до покупки: три теста от Марата Афлетунова
По оценке Центра стратегических разработок, доля отечественных вендоров на российском рынке средств защиты превысила 94%. Экстренный этап замены уже позади: рынок, выросший за 2025 год на 16%, до 364 млрд руб., теперь покупает планово и хочет заранее понимать, что получит, поэтому решение о покупке SIEM часто принимают по итогам пилота. Такой пилот, как писал CNews, длится около месяца и требует 120–150 человеко-часов, хотя немалую часть вопросов к системе можно снять еще до него. Как это сделать и не принять красивый стенд за проверенный продукт, рассказывает Марат Афлетунов — инженер по информационной безопасности компании из пятерки лидеров этого рынка, создавший методику стендов тест-драйва для ее ключевых продуктов.
Что стенд показывает, а что нет, он знает изнутри: новые версии продуктов проходят его проверки до релиза, а сценарии атак он пишет сам, сразу для четырех классов средств защиты, от SIEM до WAF. Вендор сертифицировал инженера по трем системам — мониторинга событий, управления уязвимостями и защиты конечных точек. Поэтому и проверку SIEM он советует начинать задолго до пилота
Сначала тест-драйв, и только потом пилот
У этого разработчика знакомство заказчика с продуктом начинается с тест-драйва. Стенд развернут в облаке вендора: заказчик получает доступ и попадает в среду, где уже настроено все необходимое — конечные устройства, контроллер домена, машина атакующего и сам тестируемый продукт. Стенды собраны для ключевых продуктов линейки, а их больше двадцати, от системы мониторинга событий до защиты контейнеров; есть и интегрированные, где несколько средств защиты работают вместе и заказчик видит, как они дополняют друг друга. Методику построения таких стендов и руководства, по которым заказчик проходит тест-драйв самостоятельно, разработал Афлетунов.
Сценарий на таком стенде никто не запускает за заказчика. В руководствах описаны и атаки, и сценарии работы с продуктом: заказчик сам проводит атаку, смотрит, как система ее обнаруживает, и, если продукт это умеет, сам же реагирует. Каждый шаг расписан: что именно должна увидеть система и как аналитик будет это расследовать. Если вопросов после такого теста не осталось, дальше идет покупка.
Что при этом легко упустить, инженер объясняет на примере тех же стендов: «Хороший стенд всегда красивый, и заказчику легко на этом остановиться. На нем источники подключены как по учебнику, трафик чистый, и любой сценарий из руководства отрабатывает. А у заказчика источники живые, в трафике шумит все подряд, и за консолью сидят его люди, которые продукт видят впервые. Если после тест-драйва такие вопросы остались, их снимает только пилот: средство защиты разворачивают уже в боевой среде заказчика, в выделенном тестовом сегменте».
Такой порядок, по его словам, экономит ресурсы обеим сторонам: на пилот выходят только с теми вопросами, которые стенд закрыть не может.
Отсюда и три направления, по которым он предлагает оценивать пилот. Обнаружит ли система атаку, опасную именно для этой компании, на ее реальных источниках, в том числе «экзотических», которые еще предстоит распознать и нормализовать, и на фоновом трафике, где считают ложные срабатывания и шум. Выдержит ли она нагрузку реального потока событий, включая всплески EPS. И сможет ли команда заказчика эффективно работать с продуктом. Все остальное, от удобства интерфейса до количества базовых правил «из коробки», вторично.
Еще одно условие эксперт советует выполнить до старта пилота:
Атака должна быть максимально приближена к реальной
Первое направление касается сценариев атак. Ни один заказчик, по словам инженера, не разрешит проводить деструктивные тесты на своей боевой инфраструктуре, тем более в АСУ ТП, поэтому атаки на пилоте проводят в клонированной виртуальной среде. Подготовить такой клон должен сам заказчик, а вендор разворачивает и настраивает в нем средство защиты. Какую атаку брать, подсказывает модель угроз компании, пусть даже неформальная: именно ту цепочку, которой она боится больше всего, и надо пройти целиком, от первой подозрительной активности до реагирования.
Сценарии такого рода собирают по матрице MITRE ATT&CK, где техники атакующих разложены по 14 тактикам, от разведки до воздействия. Такие сценарии Марат Афлетунов прорабатывает для нескольких классов продуктов, SIEM, EDR, NDR и WAF: раскладывает атаку по техникам и фиксирует, что и на каком шаге должна увидеть каждая система, как аналитик это расследует и чем отвечает. Для демонстраций он готовит и датасеты, то есть записанную телеметрию атак, но на пилоте, по его словам, этого мало: «Заказчика синтетикой не впечатлишь, атака должна проводиться вживую». Хороший сценарий проверяет качество обнаружения: сколько ложных срабатываний система сгенерировала на фоновом легитимном трафике и сколько минут аналитик потратил, чтобы восстановить цепочку событий. Сам по себе факт обнаружения заранее известной атаки говорит лишь о базовой работоспособности, тогда как главная цель — проверить систему в условиях неопределенности.
Тот же принцип, считает он, работает и после покупки. Если правила корреляции и сценарии реагирования тонко настроены под инфраструктуру конкретного заказчика, а программа обучения аналитиков адаптирована под реалии его сети, расследования инцидентов проходят быстрее, количество ложных срабатываний снижается, а время на реагирование (MTTR) сокращается.
«Заказчики любят считать правила: у этих триста, у тех пятьсот, значит, те лучше. Ну это так не работает, — говорит он. — Смотрите, у нас новые правила появляются каждые две недели, через год картина будет совсем другая, а сколько коробочных правил заработает в сети заказчика, зависит от его источников. Поэтому главный вопрос к пилоту другой: сможет ли система не просто „увидеть“, а точно детектировать и обеспечить расследование той атаки, которая опасна именно вашему бизнесу, в условиях вашего реального трафика. И вот когда эта эффективность доказана на ваших данных, тогда есть предметный смысл обсуждать коммерческие условия и объем лицензий».
Нагрузку считают по потоку событий
Со вторым направлением все упирается в арифметику. Лицензию на SIEM вендоры считают по объему потока событий, но этот поток неровный: утренний час пик в понедельник или закрытие отчетного периода дают кратковременные всплески, и система, которая на пилоте показывала высокую скорость при тестовой нагрузке, в боевой среде может начать копить очередь. Поэтому считать нужно пиковый поток, и с запасом на рост.
В крупной инфраструктуре счет идет на сотни тысяч событий в секунду: например, SIEM, которую один из крупных розничных банков выбрал по итогам пилота, рассчитана, как сообщал CNews, на 500 тысяч. Инженер советует подключать на пилоте реальный поток данных с наиболее нагруженных узлов, скажем, с ключевых межсетевых экранов или контроллеров домена, чтобы увидеть поведение системы в условиях, приближенных к пиковым. До того как новая версия SIEM попадает к заказчику, Марат Афлетунов сам проверяет, при каком количестве EPS начинает расти очередь и как меняется задержка корреляции. Поэтому на пилоте он предлагает повторять ту же проверку уже на профиле конкретной компании.
Сможет ли команда работать с продуктом
Третье направление переносит проверку с системы на людей, которые будут с ней работать. На пилоте, по словам инженера, проверяют не квалификацию аналитиков, а то, подходит ли им продукт: насколько быстро специалисты заказчика могут прочитать события, разобраться в срабатывании и довести инцидент до реагирования. Именно на этом этапе внедрения часто возникают задержки: источник к SIEM подключают за день, а эффективно читать ее данные команда учится месяцами.
Базовую же квалификацию нарабатывают на внутренних киберучениях, которые дополняют пилот, но не заменяют его. Готовых аналитиков на рынке не хватает: по данным SuperJob, за первый квартал 2026 года число вакансий по ИБ выросло на 24%, хотя спрос на ИТ-специалистов в целом упал на 18%. Своих аналитиков растят и внутри компании: Марат Афлетунов рецензирует обучающие курсы коллег и ведет тренинги для новичков и стажеров, где дает им записанную атаку, ограничивает время, смотрит, до какого шага цепочки расследования каждый дошел, а затем разбирает ошибки вместе.
«Экскурсия по интерфейсу ничего не дает, через неделю все забывается, — говорит он. — Я стараюсь делать контент так, чтобы даже неподготовленный специалист понял, зачем система нужна и какую пользу он получит. Без кнопок: что он увидит на экране, когда у него что-то случится, и что будет делать дальше. Если это не получается объяснить за день на стенде, в реальной ситуации будет еще хуже».
На тест-драйве так устроен сам формат: атаку по руководству проводит заказчик, и команда сразу видит, насколько ей понятны консоль и логика продукта. На пилоте, советует он, за консолью тоже должны сидеть собственные аналитики компании, и расследовать атаку должны они, а не инженер вендора.
Что вендор делает с продуктом до тест-драйва
Стенд для тест-драйва вендор готовит задолго до предоставления доступа, и таких стендов нужно много: за 2025 год компания, по своей отчетности, добавила больше семисот новых клиентов. Раньше такие среды собирали вручную под каждую демонстрацию, пока Афлетунов не автоматизировал управление демо-стендами: теперь среду разворачивают из шаблона с нужным набором продуктов и датасетом под конкретный сценарий. Демонстраций стало больше, а освободившееся время инженеры тратят на проработку сценариев и индивидуальных задач заказчика.
Еще раньше, до этапа демонстраций, новая версия продукта попадает на внутренний контроль качества, который заказчик не видит. Через приемочные тесты и тесты производительности в департаменте инжиниринга, где он работает, до релиза проходят новые версии продуктов компании, в том числе и SIEM, на которую, по отчетности вендора, приходится треть всех отгрузок. Выявленные ошибки заносятся в систему трекинга, и вместе с продакт-менеджерами он определяет, какие из них нужно исправить до релиза в первую очередь. Он же вычитывает продуктовую документацию, с которой заказчик останется после покупки один на один.
«Средство защиты в одиночку не сделать, это всегда коллективная работа, и я вижу свой вклад в нее очень конкретно, — говорит он. — Продукт должен доехать до заказчика тщательно проверенным, а на пилоте подтвердить свою реальную эффективность. Поэтому я бы на месте покупателя спрашивал у вендора, как именно у него выстроены внутренние процессы контроля качества, и внимательно выслушал ответ».
Поделиться
Короткая ссылка 
