Всем привет! На связи снова Angara Security. И сегодня у нас разговор по-честному. У всех компаний разный уровень зрелости ИБ. Это нормально. Если у вас всё выверено, процессы отлажены, а системы управления уязвимостями (VM) и SIEM слаженно работают в паре — это уже сильный результат. Но даже тогда системы могут не складывать картину: VM знает, где уязвимость, а SIEM видит атаку.
Эта статья будет полезна, если:
у вас пока только VM-решение или вы уже начали думать: «А что дальше? Куда двигаться?»;
есть и системы классов VM, и SIEM, но они существуют параллельно: данные не пересекаются, корреляции нет, эффект от систем оставляет желать лучшего.
CVSS — может быть ловушкой
У вас есть сканер, вы регулярно сканируете активы и смотрите на CVSS. Часто оценки воспринимают так:
9.8 — страшно,
7.5 — относительно терпимо, хотя это высокий уровень серьёзности,
4.3 — кажется несущественным.
Уязвимости с оценкой 9.0 и выше требуют максимально оперативного устранения. Уязвимости с оценкой от 7.0 до 9.0 требуют просто оперативного устранения.
Давайте вернёмся к основам и разберёмся, из чего складываются эти оценки.
Ниже используется модель CVSS v3.1, в которой оценка серьёзности уязвимости — это число от 0,0 до 10,0, рассчитываемое на основе набора характеристик, сгруппированных в три группы. Каждая из них отвечает на свой вопрос:
Базовая (Base) — описывает внутренние свойства уязвимости. Это её постоянная характеристика, не зависящая от времени или конкретной среды.
Временная (Temporal) — отражает сведения об уязвимости на текущий момент. Этот параметр может меняться со временем: аналитические платформы регулярно пополняются данными, что позволяет своевременно учитывать новую информацию.
Среда окружения (Environmental) — показывает, насколько уязвимость опасна именно для вашей системы. Значения зависят от особенностей инфраструктуры и среды эксплуатации.
CVSS — это эффективный инструмент, математическая модель для оценки технической серьёзности уязвимости. Однако сам по себе CVSS не должен определять приоритет исправления. Если опираться лишь на Base Score, игнорируя остальные метрики и контекст среды, вы теряете часть картины. Доступность хоста из сети, критичность защищаемого сервиса, наличие публичного эксплойта, вероятность эксплуатации и компенсирующие меры — всё это влияет на реальный приоритет для компании.
Представьте, сканер фиксирует две уязвимости: одна с базовым CVSS 9.8 на изолированном сервере бэкапов (патч уже вышел, эксплойтов нет), вторая с базовым CVSS 6.5 на публичном платёжном шлюзе (эксплойт опубликован, патча от вендора пока нет, система критична для бизнеса).
Приоритеты этих уязвимостей могут поменяться местами, если учитывать не только CVSS, но и вероятность эксплуатации, доступность актива, наличие компенсирующих мер и бизнес-критичность. Грамотная команда не бросает все силы на «закрытие 9.8», а действует взвешенно: немедленно накладывает компенсирующие меры (WAF-правила) на уязвимость 6.5, параллельно ставит патч для уязвимости 9.8 и запускает процесс исправления кода на платёжном шлюзе. Такой подход учитывает и реальную угрозу, и бизнес-риск, а не только «красивые» цифры Base Score.
Чуть подробнее остановимся на среде окружения. Параметр Environmental рассчитывается с учётом следующих факторов:
модифицированных базовых метрик (например, доступен ли хост из интернета или только из внутренней подсети);
требований к конфиденциальности, целостности и доступности (CIA) для конкретного актива;
Ключевое условие: чтобы корректно применить Environmental, нужна актуальная инвентаризация активов (CMDB или Asset Inventory). Без неё вы не знаете, какие данные хранятся на сервере, где он находится в сети и какова его бизнес-критичность. Соответственно, вы не можете ответить на вопрос: «Уязвимость с CVSS 7.5 на этом сервере — это катастрофа или терпимо?»
Управление активами
На практике во многих компаниях процессы управления активами и инвентаризации остаются незрелыми: нет единого реестра оборудования и ПО, активы теряются, учетные записи плодятся бесконтрольно, а на вопросы руководства о составе инфраструктуры ответы получаются «приблизительные».
Если в общем смысле настройка процессов управления активами нужна для сохранения денег и порядка в компании, то для SIEM и VM она решает конкретные задачи безопасности. Без качественной инвентаризации возрастает вероятность слепых зон, неверной приоритизации и лишней нагрузки на аналитиков.
В управлении уязвимостями работает принцип «нельзя защитить то, чего не знаешь».
Приоритезация угроз: самое важное в управлении уязвимостями — понять, что исправлять в первую очередь. Для этого нужно не просто знать, что у вас есть уязвимость на каком-то сервере, но и понимать его бизнес-критичность. Уязвимость на тестовом сервере — это одно, а на сервере, через который проходят финансовые транзакции, — совсем другое.
Автоматическое сканирование: процессы сканирования должны быть настроены так, чтобы охватывать все новые устройства, появляющиеся в сети.
Управление «цифровым наследством»: в любой инфраструктуре есть устаревшее оборудование и ПО. Инвентаризация помогает выявить эти риски и принять решение об их изоляции или замене, а не просто забыть о них.
Для SIEM же инвентаризация активов важна как:
Контекст для расследований: в логах обычно есть IP, хостнейм, учётка — но этого мало. Инвентаризационные данные добавляют контекст: тип устройства (сервер, рабочая станция, межсетевой экран), ОС, роль в инфраструктуре (контроллер домена, платёжный шлюз, тестовый стенд), подразделение и ответственного. Это позволяет понять, насколько критично событие именно для этого актива.
Корреляция событий: чтобы выявить сложную атаку, SIEM должен сопоставлять события с разных устройств. Например, неудачный вход в систему с рабочей станции и подозрительный трафик с сервера баз данных. Для этого нужно точно знать, что является рабочей станцией, а что — сервером БД. При связке SIEM и VM можно усилить эффект от действия этих решений, адаптировав правила корреляции таким образом, чтобы повышение критичности событий происходило при обнаружении воздействий на хосты, имеющие реально опасные и не устранённые уязвимости, при этом базовое правило должно срабатывать на любую аномалию, а VM-контекст должен динамически повышать уровень серьёзности (Severity) инцидента, а не служить условием включения правила.
Покрытие средствами защиты: Инвентаризация позволяет SIEM видеть пробелы («слепые зоны») — активы, которые не защищены или с которых не собираются логи.
Как может выглядеть реальный инцидент сегодня
Рассмотрим конкретную цепочку действий злоумышленника, чтобы понять, где стандартная связка VM+SIEM даёт сбой:
Вход через периметр. Атакующий сканирует внешний контур и находит уязвимость со «средним» баллом 6.7 на публичном портале самообслуживания. Сканер давно видел эту CVE, но из-за того, что она не красная, владелец сервиса спокойно переносил патч на следующий месяц, ссылаясь на стабильность работы. В этом сценарии компенсирующих мер (WAF) нет, поэтому «средняя» уязвимость стала точкой входа.
Перемещение внутри (East-West). Получив точку опоры, злоумышленник начинает сканировать внутреннюю сеть. Его цель — соседние хосты, контейнеры и серверы внутри инфраструктуры. Он ищет среди них те, на которых висят «старые» или «неважные» (по версии CVSS) уязвимости. Используя внутренние сетевые взаимодействия, он движется к своему целевому активу.
Взаимодействие с уязвимыми хостами. Сканер уязвимостей давно знает об этих брешах на внутренних хостах. Однако его данные не передаются в SIEM либо передаются без достаточного контекста. В итоге SIEM не может сопоставить подозрительное поведение с конкретной уязвимостью и не повышает уровень тревоги.
Реакция SIEM без контекста VM. SIEM фиксирует подозрительную активность — например, нехарактерные запросы с одной виртуальной машины на другую или сканирование портов. Но для SIEM это просто событие. Без обогащения из VM аналитик не видит, что на целевом хосте есть эксплуатируемая уязвимость. SIEM мог бы сработать и по аномалии SMB-трафика, но без контекста причины этого трафика остаются неясными. Аналитик гадает, является ли этот трафик легитимным сбоем резервного копирования или же инцидентом, а атакующий спокойно завершает атаку.
Итог: вход через «среднюю» уязвимость, горизонтальное перемещение по внутренним хостам с «некритичными» CVE и отсутствие корреляции между данными VM и событиями SIEM приводят к тому, что атака проходит незамеченной. Злоумышленник достигает цели, а служба безопасности узнаёт об инциденте постфактум — из отчета о просочившихся данных или от внешних партнёров.
Какие именно данные из VM критичны для SIEM
Чтобы взять максимум пользы от связки SIEM и VM, необходимо передавать в SIEM не просто наличие уязвимости, а расширенный контекст. Вот минимальный набор полей, которые могут обогащать события SIEM:
Идентификатор CVE — точная ссылка на уязвимость.
Базовый скоринг CVSS — исходная оценка опасности.
Вероятность эксплуатации (EPSS) — ежедневно обновляемая оценка вероятности наблюдаемой эксплуатации конкретной CVE в ближайшие 30 дней.
Наличие публичного эксплойта (Exploit availability) и подтверждённая эксплуатация: например, наличие CVE в CISA KEV или аналогичном отраслевом перечне.
Критичность актива для бизнеса — например, «Платежный шлюз» против «Тестовой песочницы».
Доступность из сети (Network exposure) — доступен ли хост из интернета или только изолированно внутри сегмента.
Владелец системы (Owner) — контактное лицо, ответственное за хост.
SLA на исправление (Remediation SLA) — нормативный срок закрытия уязвимости для данного класса систем.
Пример корреляции: когда обычное событие становится критичным
Рассмотрим на практике, как добавление VM-контекста меняет приоритет инцидента в SIEM.
Без интеграции с VM: SIEM получает событие: «Аномальное количество подключений к SMB с хоста 10.0.4.22 на хост 10.0.4.88». Без контекста это просто «Средний» алерт.
С контекстом VM: SIEM видит, что 10.0.4.22 — веб-сервер, которому не положено обращаться к SMB, а 10.0.4.88 — критический контроллер домена. VM и конфигурационные данные показывают на целевом сервисе условия для NTLM Relay: например, доступную NTLM-аутентификацию без необходимых защитных механизмов. SIEM сопоставляет «Нехарактерный SMB-трафик от веб-сервера к DC» с критичностью актива и повышает приоритет до «Критического». Аналитик сразу видит контекст, а не гадает о причине события.
Оптимизация связи VM и SIEM
Предлагаемый подход не предполагает революции, а представляет собой поэтапный алгоритм:
Этап 1. Инвентаризация и категоризация активов
Проведите ревизию инфраструктуры и определите бизнес-функцию каждого хоста. Идентификация актива не должна ограничиваться IP-адресом: используйте hostname, FQDN, agent ID, cloud instance ID или CMDB ID. Для каждого элемента задайте критичность (Critical / High / Low) и сетевую доступность.
Этап 2. Обогащение данных об уязвимостях контекстной информацией
Оценка CVSS должна применяться в сочетании с дополнительными метриками и контекстом:
EPSS (Exploit Prediction Scoring System) — показатель вероятности наблюдаемой эксплуатации CVE в ближайшие 30 дней;
наличие публичного эксплойта (Exploit Availability) и подтверждённая эксплуатация (например, CISA KEV);
критичность актива и его доступность из внешней сети (Network Exposure): при этом важно учитывать не только сам актив, но и его сетевые пути: если хост имеет широкие исходящие соединения в другие сегменты, его уязвимости получают более высокий приоритет, так как компрометация такого хоста затронет множество сегментов (Blast Radius).
Этап 3. Интеграция VM и SIEM с передачей контекстных данных
Начните с минимального набора полей, перечисленных выше. Даже базовая передача CVE и критичности актива даст аналитикам контекст, которого сейчас возможно не хватает
Этап 4. Настройка правил корреляции
Базовые правила должны фиксировать аномальную или вредоносную активность независимо от VM-контекста. Данные VM должны влиять на критичность, маршрутизацию и SLA расследования; в отдельных высокоточных сценариях — быть дополнительным условием корреляции.
VM и SIEM по отдельности — это инструменты, а не решения. Без интеграции и качественной инвентаризации они не раскрывают весь потенциал защиты и могут оставлять слепые зоны. Соедините их правильно — и вы перестанете гадать, где реальная угроза, а где ложное срабатывание.
