Журнал "Information Security/ Информационная безопасность" #4, 2026

ML-модели добавляют следующий слой анализа. Они оценивают веро- ятность ложного срабатывания и кри- тичность инцидента, находят похожие текущие и исторические случаи, подо- зрительные командные строки и нети- пичные цепочки процессов. Результаты доступны прямо в карточке инцидента. Так разные механизмы решают раз- ные задачи: правило корреляции ищет известный сценарий, статистика – отклонение от нормального поведения, а ML помогает оценить найденную активность и расставить приоритеты. SIEM – рабочее место аналитика Срабатывание детекта запускает расследование, и аналитику нужно вос- становить последовательность дей- ствий: что запустилось на хосте, какой процесс породил следующий, куда ушло сетевое соединение, под какой учетной записью выполнялись команды и какие еще узлы попали в цепочку. Обычный список событий дает для такого анализа слишком мало кон- текста. Security Vision SIEM ретроспективно восстанавливает цепочки процессов, пользовательские и сетевые сессии, а также переходы между хостами. Ана- литик может пройти от подозритель- ного процесса к его источнику или посмотреть, что происходило после запуска. Например, для PowerShell полезно видеть не только командную строку, но и сведения о том, кто его запустил, из какого процесса, с какими параметрами и какие действия после- довали дальше. Техническую картину дополняет кон- текст актива: его сегмент, роль, связи, критичность и место в ресурсно-сер- висной модели. Один и тот же детект на рабочей станции пользователя и на контроллере домена требует разной реакции, и этот контекст доступен ана- литику прямо во время расследования. Карточка инцидента собирает собы- тия, активы, пользователей, процессы и результаты корреляции в одном месте. Аналитик может проверить гипо- тезу, запустить дополнительный поиск и пройти по связанным объектам, не восстанавливая историю атаки вручную в нескольких интерфейсах. SIEM измеряет работу SOC Руководителю SOC недостаточно знать, сколько инцидентов команда закрыла за месяц. Гораздо полезнее видеть сроки расследования, наруше- ния SLA, нагрузку на аналитиков и причины задержек. Security Vision SIEM хранит в карточ- ке инцидента сроки обработки, комму- никации и связанные задачи, а отдель- ный дашборд контролирует соблюде- ние SLA расследования. Для разных типов инцидентов можно задать свои SLA и отслеживать просрочки, поэтому руководитель видит, где расследования начинают выходить за установленные сроки. При этом короткое время обработки еще не говорит о качестве работы. Аналитик может быстро закрывать десятки однотипных срабатываний, потому что правило шумит и каждый раз требует одинаковой реакции. В таком случае стоит тюнить детект или автоматизировать сценарий, а не ускорять аналитика. Долгое расследо- вание тоже не обязательно связано с работой специалиста: время может уходить на сбор контекста или ожида- ние эскалации. Метрики помогают уви- деть такие ситуации и разобраться в причинах, а не оценивать команду по количеству обработанных алертов. Руководитель SOC может сопоста- вить состояние источников, качество правил и сроки расследования, а даш- борд SLA дает общую картину с дета- лизацией по каждому аналитику. По этим данным уже можно понять, где SOC теряет время и что стоит менять – детект, процесс расследования, рас- пределение нагрузки или сценарии автоматизации. Автоматизация, когда аналитик принял решение После расследования вывод анали- тика нужно превратить в конкретные действия. Для типовых инцидентов набор таких действий обычно повто- ряется: собрать дополнительную инфор- мацию, проверить артефакт, выполнить команду или начать изоляцию узла. Security Vision SIEM предлагает более 100 готовых действий с хостами, учет- ными записями и артефактами. Ана- литик может запускать их прямо в процессе расследования, не переходя в другие системы. Более сложные сце- нарии можно передать в SOAR или NG SOAR. Security Vision SIEM интегриру- ется с этими платформами и позволяет автоматически отправлять обнаружен- ные инциденты на обогащение, марш- рутизацию и реагирование по сцена- риям NIST или SANS. За аналитиком остаются задачи, где действительно требуется его решение: оценить контекст, проверить гипотезу и определить масштаб инцидента. Повторяемые действия после этого можно автоматизировать. Новые источники без отдельной разработки Корпоративная инфраструктура редко ограничивается типовым набо- ром источников. Помимо Windows, Linux, сетевого оборудования и средств защиты, в SIEM прихо- дится подключать базы данных, платформы вир- туализации, Kubernetes, 1С и внутренние систе- мы. Для отраслевого или внутреннего решения готового коннек- тора может не оказаться, и тогда коман- да либо пишет интеграцию отдельно, либо собирает ее средствами SIEM. В Security Vision SIEM реализованы интеграции ко всем популярным систе- мам и сервисам, а для нетиповых источников есть No-Code-редактор кон- некторов. Он поддерживает JSON, текст с разделителями, структуры "ключ – значение", а также перемен- ные, вычисления и обогащение данных. Команда может собрать коннектор и настроить нормализацию прямо в SIEM, без отдельной разработки. За счет этого новый источник быстрее попада- ет в мониторинг, даже если готовой интеграции для него нет. SIEM, которую SOC настраивает под себя У каждого SOC свои правила эска- лации, роли аналитиков, карточки инцидентов, согласования и отчетность. Эти процессы продолжают меняться и после внедрения SIEM: появляются новые команды, источники, классы инцидентов и требования к расследо- ванию. Security Vision SIEM построена на Low-Code/No-Code-платформе. Коман- да может через визуальные инстру- менты настраивать интеграции, пра- вила корреляции, карточки инцидентов, рабочие процессы, дашборды и отчеты без отдельной разработки. Такая гиб- кость требует аккуратного управления изменениями. Настройки нужно доку- ментировать, сценарии – тестировать, версии – учитывать, а права админи- страторов – контролировать. Иначе через год будет сложно понять, зачем появилось очередное правило или ответвление процесса. Заключение Выбирать SIEM лучше на собствен- ном сценарии работы SOC: подключить реальные источники, отключить один из них, прогнать детект по истории, разобрать инцидент, восстановить цепочку действий и выполнить дей- ствия по реагированию. Такой тест скажет о платформе больше, чем сравнение EPS, количества правил и коннекторов. Через год после внедрения источни- ки, детекты и процессы все равно изменятся. Если команда сможет адап- тировать мониторинг своими силами, SIEM будет развиваться вместе с SOC. Если каждое изменение требует нового проекта с вендором или интегратором, эти затраты тоже нужно учитывать в стоимости системы. l • 25 SIEM www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ SECURITY VISION см. стр. 86 NM Реклама