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

Причины могут быть вполне буднич- ными: на сервере отключили аудит, агент завис после обновления или поме- нялась конфигурация syslog. С агрега- торами ситуация еще сложнее: SIEM видит стабильный поток с syslog-сервера и считает источник живым, хотя один из десятков хостов за ним уже несколько часов ничего не отправляет. Платформа продолжает работать, график EPS не проседает и ошибок нет, но у аналитика при этом появляется слепая зона. Количество правил тоже ничего не гарантирует, потому что тысяча детектов в базе мало говорит о качестве монито- ринга. Одно правило после изменения инфраструктуры засыпает SOC ложными срабатываниями, другое месяцами мол- чит, а третье ловит отдельную технику, но не связывает ее с предыдущими дей- ствиями атакующего. В итоге команда тратит время на шум и при этом не знает, насколько хорошо работает весь набор детектов. Даже хороший детект не дает анали- тику готового ответа, поскольку для рас- следования нужно понять, что происхо- дило на узле до инцидента, какие про- цессы запускались, какие учетные запи- си использовались и с какими системами связывался хост. Контекст часто прихо- дится собирать вручную в нескольких системах, переключаясь между SIEM, CMDB, EDR и сетевыми средствами, поэтому расследование легко растяги- вается на часы. SOC недостаточно принять лог и про- гнать его через корреляцию: нужно понимать, все ли необходимые данные поступают, работают ли детекты и что происходило вокруг срабатывания. Про- изводительность характеризует воз- можности SIEM, а качество монито- ринга лучше отражают полнота данных, работа детектов и скорость расследо- вания. Качество данных SOC мало знать, что источник под- ключен: нужно понимать, передает ли он те данные, на которые рассчитывают правила корреляции. Проблема часто скрывается не в полном обрыве потока, а в его деградации, когда хост продол- жает отправлять события, но часть жур- налов уже пропала. После изменения политики аудита может исчезнуть нуж- ная категория событий, а работающий агент иногда передает заметно меньше данных, чем обычно. Технически источ- ник остается доступным, но качество детектирования уже снижается. Поэтому SIEM должна контролировать не только доступность коннектора, но и поток событий от каждого источника. Объем событий, допустимые паузы, состав журналов и отклонения от при- вычного профиля позволяют заметить проблему до того, как она превратится в слепую зону. В Security Vision SIEM 1 эту задачу решают профили контроля сбора. Для каждого источника можно задать допу- стимое время молчания, пороги откло- нения потока и требования к полноте журналирования. Отдельный дашборд показывает, какие узлы работают штат- но, где объем событий снизился, а где они перестали поступать. Аналитику при этом не приходится вручную проверять тысячи источников, поскольку система отмечает те из них, где телеметрия перестала соответство- вать ожидаемому профилю. Статуса "источник подключен" для такого конт- роля недостаточно: SOC важно видеть полноту телеметрии, а не только наличие соединения. Многоуровневое детектирование Одного механизма детектирования недостаточно для всех сценариев. Пра- вило корреляции хорошо работает там, где команда знает, какую последова- тельность событий искать. Статистиче- ский анализ замечает отклонения от привычного поведения, которые трудно заранее описать жесткими условиями. ML-модели помогают дополнительно оценить найденную активность: веро- ятность ложного срабатывания, критич- ность инцидента или сходство с уже расследованными случаями. Security Vision SIEM поставляется с более чем 1200 правилами корреляции, которые покрывают свыше 70% техник MITRE ATT&CK и сопоставлены со спо- собами реализации угроз из БДУ ФСТЭК. Готовую базу можно дорабаты- вать в графическом редакторе, а также импортировать правила из общедоступ- ных источников в формате Sigma. Правило стоит проверять и после внедрения. Перед запуском его можно прогнать по историческим событиям и посмотреть, что оно обнаружило бы за выбранный период. После запуска SIEM собирает статистику срабатываний и ложноположительных результатов, поэтому команда видит детекты, кото- рым требуется тюнинг. Корреляционный движок поддерживает обязательные, опциональные и отрицающие условия, в том числе отсутствие ожидаемого события, а события от разных источников синхронизирует по времени. Там, где жестких условий недостаточ- но, подключается статистика. Сервис StatAnalyser ищет необычную активность пользователей, аномальные объемы тра- фика, редкие действия и другие откло- нения от нормального профиля. Анома- лия при этом еще не означает атаку: она дает аналитику повод проверить активность в контексте остальных собы- тий. 24 • СПЕЦПРОЕКТ Эволюция SIEM от EPS до расследования IEM обычно сравнивают по цифрам: сколько EPS система переварит, сколько источников подключит, как быстро найдет событие и сколько данных удержит в горячем хранении. Для эксплуатации эти параметры нужны, но о качестве работы SOC они говорят мало, поскольку даже при обработке миллионов событий в сутки можно не заметить атаку, если нужное событие вообще не попало в систему. S Максим Анненков, менеджер продуктов Security Vision SIEM, SOAR, NG SOAR Фото: Security Vision 1 https://www.securityvision.ru/blog/security-vision-siem-ot-kontrolya-kachestva-dannykh-do-rassledovaniya-i-reagirovaniya- v-edinom-kontu/