Vulnerability Management аналитика - выявление систем с наибольшим числом критических уязвимостей

В рамках курса по BI DWH для отдела информационной безопасности задача аналитики уязвимостей выходит за рамки простой отчетности. Необходимо объединить данные разных источников, выстроить устойчивую модель данных, качественно определить понятие критичности и построить практические дэшборды, которые позволяют оперативно идентифицировать «горячие точки» в инфраструктуре, планировать remediation и минимизировать бизнес-риски. В данной главе рассматриваются концептуальные основы, архитектура данных и практические методы реализации аналитики по vulnerability management с акцентом на систематическую идентификацию систем с наибольшим числом критических уязвимостей.

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

Архитектура данных и модель данных для Vulnerability Management в BI DWH
Метрики, критерии критичности и алгоритмы отбора
Реализация конвейера данных: источники, трансформации, загрузка и качество данных
Визуализация, дэшборды и операционные сценарии
Эксплуатационные аспекты и интеграции с инструментами SOAR/ITSM

Архитектура данных Vulnerability Management в BI DWH

Успешная аналитика начинается с правильной архитектуры данных. В контексте vulnerability management в BI DWH применяют ориентированную на бизнес-детерминацию звездную схему (star schema), где факт vulnerability_fact хранит факты по каждому зафиксированному уникальному уязвимому элементу, а размерные таблицы дают контекст для анализа по устройствам, уязвимостям, времени и источнику скана. Такая структура обеспечивает гибкость агрегаций (по времени, по среде, по бизнес-объектам) и позволяет легко строить топ-листы и тренды.

Ключевые компоненты модели данных:

Факт: vulnerability_fact
- host_id - идентификатор хоста;
- vuln_id - идентификатор уязвимости (CVE);
- cvss_score - балл CVSSv3;
- severity - текстовая категоризация (Critical, High, Medium, Low);
- scan_id - идентификатор скана;
- discovery_date - дата фиксации уязвимости;
  -Remediation_status - статус исправления (Open, In Progress, Remediated);
- patch_id - идентификатор патча, если применен;
- asset_vector - контекстная информация об asset/службе;
- environment - окружение (Prod, QA, Stage, Cloud).
Димы (Dimension Tables):
- dim_host: host_id, hostname, ip_address, os, location, owner, business_impact_class, criticality_rank;
- dim_vuln: vuln_id, cve_id, cvss_score, severity_class, vulnerability_type, publish_date;
- dim_time: date, week, month, quarter, year, fiscal_period;
- dim_source: scanner_name, scanner_version, scan_date, policy_group;
Связующие таблицы и дополнительные измерения:
- dim_asset: application, service, container, environment_criticality;
- dim_patch: patch_id, vendor, release_date, applicability_criteria;
- dim_business_unit: unit_id, unit_name, risk_owner.

Ниже приведена компактная таблица, иллюстрирующая ключевые элементы модели (показаны только основные поля; детали могут дополняться в зависимости от конкретной инфраструктуры):

Компонент	Роль	Примеры полей
Факт vulnerability_fact	Хранение единиц анализа уязвимостей	host_id, vuln_id, cvss_score, discovery_date, remediation_status
dim_host	Контекст по устройствам и владельцам	host_id, hostname, ip_address, os, business_impact_class
dim_vuln	Информация об уязвимости	vuln_id, cve_id, cvss_score, severity_class
dim_time	Временной контекст	date, week, month, quarter, year
dim_source	Источник скана	scanner_name, scanner_version, scan_date

Важной частью архитектуры является обеспечение качества данных. Взаимосогласованность идентификаторов (host_id, vuln_id), нормализация значений CVSS и устранение дубликатов по одному и тому же объекту на одном host в разные моменты времени - критические задачи. Пошаговый подход к качеству данных обычно включает:

нормализацию идентификаторов (CVE, host), привязку к единой кодировке;
привязку сканов к источникам и отслеживание версии скана;
приведение CVSS к единой версии и единым шкалам;
обработку пропусков и явных ошибок в полях.

Типовой процесс ETL/ELT включает загрузку сырого потока сканов в staging-модель, затем нормализацию и денормализацию в canonical_vuln, последующую агрегацию в фактовую модель и построение индексов для ускорения аналитики.

Иллюстративная схема архитектуры может выглядеть так: источник сканов (Nessus/OpenVAS/Qualys) - staging vulnerability_raw - canonical_vuln - vulnerability_fact (звездная схема) - агрегированные представления (top_hosts_by_critical_vulns, vulnerability_trends) - дэшборды и операционные сервисы.

Чтобы уточнить концепцию связей, полезна таблица соответствий между ключами:

host_id в dim_host соответствует host_id в vulnerability_fact
vuln_id в dim_vuln соответствует vuln_id в vulnerability_fact
scan_id связывает конкретный скан с набором фиксаций уязвимостей
time dimension позволяет быстро вычислять тренды по периодам

Метрики, критерии и алгоритмы отбора

Определение того, что считать «критической» уязвимостью, является фундаментальной задачей. В рамках Vulnerability Management под критичностью обычно подразумевают сочетание фактора опасности и бизнес-важности. Практическим подходом является использование CVSSv3 как базового критерия для количественной оценки и добавление факторов контекста, таких как наличие эксплойтов и критичность активов.

Ключевые принципы:

Критическая уязвимость определяется как CVSS_score >= 9.0 или как относится к критично важным классам уязвимостей по внешним признакам (например, эксплоитируемость, доступ по сети).
Роль бизнес-критичности актива: даже если уязвимость имеет высокий CVSS, на незначимый сервис это может оказывать меньший бизнес-уровень риска. Поэтому к доменным данным подключают dim_host.business_impact_class или dim_asset.environment_criticality для весовой корректировки.
Учет повторного выявления и дубликатов: при повторном сканировании одна и та же уязвимость на одном host может появляться несколько раз; разумная стратегия - агрегировать на уровне host и vuln, использовать максимум cvss_score и минимальное remediation_date, если таковое есть.
Временной аспект: для целей оперативной реакции полезна привязка к окну наблюдения (например, последние 30 дней, последние 7 дней). Для трендов - смотреть по месяцам и кварталам.

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

riskscore(host) = sum{vuln ∈ host} weight(vuln) age_factor(vuln, time_window) remediation_capability(host, vuln)
где weight(vuln) может быть функциональным весом CVSS_score, age_factor - коэффициент уменьшения риска с задержкой обнаружения, remediation_capability - индикатор возможности исправления на данном хосте (наличие патча, зависимость от downtime и т.д.).

Пример практических метрик:

Count_Critical_vulns_by_host: число критических уязвимостей на каждом хосте за заданный период.
Weighted_risk_by_host: агрегированное взвешенное значение риска.
Remediation_SLA_violation_rate: доля открытых критических уязвимостей со сроком remediation превышающим SLA.
Time_to_remediation: среднее время закрытия критических уязвимостей по каждому хосту.

Для иллюстрации формул и отбора можно привести следующий пример SQL-запроса, который считает топ-10 хостов по числу критических уязвимостей за последний месяц:

SELECT h.host_id, h.hostname, COUNT(*) AS critical_count
## FROM vulnerability_fact vf
JOIN dim_host h ON vf.host_id = h.host_id
JOIN dim_vuln dv ON vf.vuln_id = dv.vuln_id
## WHERE dv.cvss_score >= 9.0
  AND vf.discovery_date >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
GROUP BY h.host_id, h.hostname
ORDER BY critical_count DESC
LIMIT 10;

Такой запрос демонстрирует основной принцип: агрегация по host с фильтром по критическим уязвимостям и временным окном. Однако для оперативной эксплуатации требуется более сложная логика, включая учет дубликатов, устойчивые веса и динамическое обновление - об этом далее.

Дополнительно к числовому счету следует рассчитать скоринговый индекс, который учитывает контекст активов и желаемые SLA. Пример концептуального подхода:

weight_by_asset = функция бизнес-важности активов (например, базы данных с персональными данными > веб-приложения);
cvss_weight = нормированный CVSS_score;
time_decay = экспоненциальное затухание риска после времени обнаружения;
remediation_capability = 0-1, где 1 означает готовность к немедленной патч-реализации.

Эти элементы можно реализовать через пользовательские агрегаты в dbt или через OLAP-выражения в BI-платформе, с материализацией результатов в представлениях для быстрых дэшбордов.

Реализация конвейера данных: источники, трансформации, загрузка и качество данных

Эффективная аналитика требует надёжного конвейера данных, который обеспечивает непрерывное получение данных из источников сканов и их консолидацию в единый DWH-слой. Классический набор источников включает:

Сканеры уязвимостей (Nessus, OpenVAS, Qualys и аналогичные), предоставляющие списки по кажой находке, CVSS и статусу исправления;
Инвентаризация активов и CMDB, обеспечивающая контекст по устройствам, сервисам и владельцам;
Даные по патчам и исправлениям от центра управления изменениями (patch management).

Пайплайн обычно состоит из секций:

Ingestion: прием сырого потока данных из сканов и инвентаризации. Важна поддержка стандартов обмена данными и версий API.
Cleansing and normalization: унификация форматов CVSS, нормализация идентификаторов (CVE, host), устранение дублей, привязка сканов к конкретной среде.
canonicalization: привязка к единой схеме dim_host, dim_vuln, dim_time и др.
Loading into DW: загрузка в staging и далее в звездную схему.
Quality checks: контроль уникальности ключей, диапазонов CVSS, полноты полей, сверка суммарной критичности между источниками.
Aggregation and views: создание агрегатов: топ-хосты, временные тренды, показатели SLA и пр.

Для реализации можно использовать современные инструменты оркестрации и моделирования данных:

Оркестрация: Apache Airflow или Dagster для управления DAG-ами загрузок, контроля зависимостей и мониторинга.
Моделирование данных: dbt для версионирования трансформаций и тестирования качества моделей.
Хранилище: столбцово-ориентированные СУБД или колоночные хранилища, ориентированные на аналитические запросы (например, ClickHouse, PostgreSQL с расширениями или аналогичные решения). В контексте современной архитектуры часто применяют гибрид между облачными хранилищами и локальными ДБ.

Упоминания технологий. В рамках данного раздела допустимы краткие отсылки к инструментам:

Open-source: Apache Airflow, dbt; они позволяют выстроить прозрачную и воспроизводимую цепочку трансформаций.
Российские/локальные решения следует упоминать очень экономно и только если они действительно улучшают смысл: например, упоминание локального менеджера данных в рамках корпоративной инфраструктуры, если он реально применяется в проекте.

Визуализация и примеры дэшбордов

Эффективная визуализация позволяет трансформировать математическую модель в оперативные действия. Рекомендованные элементы дэшборда:

Таблица «Top hosts by critical vulnerabilities» с колонками: host_id, hostname, critical_count, cvss_mean, remediation_status.
График тренда по количеству критических уязвимостей за период времени (ежедневно/ежемесячно).
Карта активов по критичности: группировка по бизнес-единицам и среде.
SLA-индексы по времени устранения критических уязвимостей и процент выполненных в срок.
Drill-down: по каждой системе** - список критических CVE, статус патча, времени до remediation.

Реализация представлений для дэшбордов часто опирается на:

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

Пример SQL-реализаций для оперативной визуализации:

SELECT host_id, hostname, COUNT(*) AS critical_count, AVG(cvss_score) AS avg_cvss
## FROM vulnerability_fact vf
JOIN dim_host h ON vf.host_id = h.host_id
JOIN dim_vuln dv ON vf.vuln_id = dv.vuln_id
## WHERE dv.cvss_score >= 9.0
  AND vf.discovery_date >= DATE_TRUNC('month', CURRENT_DATE)
GROUP BY host_id, hostname
ORDER BY critical_count DESC
LIMIT 20;

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

Эксплуатация и интеграции: операционные аспекты

Первая задача операционной эксплуатации - определить точку принятия решения. Нужно переходить от «массив данных» к «операционных действий» через процессы и интеграции. Важные аспекты:

Governance и политики качества данных: кто отвечает за верификацию источников, кто имеет право изменять правила трансформаций, как фиксируются ошибки.
Регулярность обновления: частота загрузки должна соответствовать критичности инфраструктуры - например, ежедневные обновления для продакшн-среды, еженедельные для QA/Stage.
Интеграции с системами безопасности и ITSM: автоматическое создание тикетов на remediation в Jira/ServiceNow, интеграции с SIEM/SOAR для корреляции инцидентов.
Секьюрити и доступ: настройка ролей и минимальных прав, аудит изменений, защита вывода данных в BI-платформы.

Взаимодействие с инструментами и экосистемой:

Open-source и индустриальные решения: Apache Airflow обеспечивает оркестрацию пайплайна, dbt - формализацию трансформаций и тестирование моделей. Это дает прозрачность и воспроизводимость процессов.
Российские/локальные решения: использование внутренних систем для мониторинга качества данных или управления доступом может повысить управляемость и соответствие регуляторным требованиям, но требует должного контроля за интеграциями и поддержкой.

Операционные сценарии:

Ежедневные дэшборды для SOC: отображение топ-хостов по критичным уязвимостям на текущий день, SLA-метрики и уведомления при выходе за пороги.
Недельные и месячные обзоры для руководства: тренды, распределение по бизнес-единицам, риск-профили активов.
Инцидент-менеджмент: при обнаружении резкого роста количества критических уязвимостей автоматически создается тикет и формируется задача по remediation с привязкой к хостам и сервисам.

В рамках данного раздела полезно упомянуть интеграции с системами управления изменениями (ITSM) и SOAR. Такой подход позволяет не только увидеть проблему, но и инициировать плановые исправления и автоматизировать первичные действия. В реальных условиях часто применяют связку: BI-DWH данные → SOAR-оркестрация атак или уязвимостей → автоматические тикеты в Jira/ServiceNow → патч-обновления и отслеживание статуса.

Key takeaways

Взвешенная архитектура звездной схемы позволяет эффективно анализировать уязвимости в контексте хостов и активов.
Критичность уязвимости следует определять на основе сочетания CVSSscore и бизнес-критичности активов, учитывая возможность ремедиации.
Точность и консистентность данных - критический фактор: единая идентификация host/vuln, нормализация CVSS и устранение дубликатов.
Пайплайн данных должен быть воспроизводимым: использование Airflow (или аналогов) и dbt обеспечивает прозрачность изменений и контроль качества.
Визуализация должна поддерживать drill-down к конкретным системам и предоставлять оперативные SLA-метрики.
Интеграции с ITSM/SOAR повышают оперативность реакции на уязвимости и позволяют управлять remediation в рамках бизнес-процессов.
Регламентные политики по доступу и аудиту данных обеспечивают соответствие требованиям к безопасности и конфиденциальности.

FAQ

Какие источники данных наиболее критичны для расчета топ-хостов по критическим уязвимостям?

Ключевыми источниками являются данные сканирования уязвимостей (Nessus, OpenVAS, Qualys и т. п.) и инвентаризация активов/CMDB. Важна связка между этими данными: на каком host размещена конкретная уязвимость и какой актив принадлежит этому хосту. Также полезно подключать данные по патчам, чтобы оценивать возможность remediation и сроки исправления.

Как обеспечить точность подсчетов и избежать дублирования уязвимостей?

Необходимо реализовать канонизацию идентификаторов (host_id, vuln_id), унифицировать формат CVSS и использовать максимум cvss_score на уровне host-vuln. При этом следует агрегировать данные на уровне host_id и vuln_id за заданный период, чтобы исключить повторное считывание одной и той же уязвимости в разных сканах.

Как определить пороги для «критических» уязвимостей?

Пороги зависят от контекста: CVSS >= 9.0 как стандартный выбор; если имеется бизнес-объект, на котором критично важны сервисы, пороги можно корректировать для соответствия уровню риска. Рекомендуется иметь два порога: верхний (критический) и нижний (высокий) для разных дашбордов и управляющих уровней.

Какие метрики наиболее полезны для бизнес-руководителя?

Число критических уязвимостей на системном уровне (top hosts), распределение по бизнес-единицам, коэффициент SLA по времени remediation, тренд по критическим уязвимостям за последние периоды. Визуально полезна связка «число уязвимостей → риск по бизнес-единицам» и «тренд времени».

Как обеспечить актуальность данных в дэшбордах SOC?

Установить автоматизированные задачи обновления данных на ежедневной основе, с поддержкой SLA по времени обновления. В случае крупных сред можно применять более частые обновления внутри критических окон.

Какие меры безопасности необходимы при работе с данными DWH?

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

Какие риски возникают при внедрении такой аналитики?

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

Как внедрить аналитику в существующую BI-инфраструктуру?

Необходимо обеспечить совместимость моделей с текущими слоями BI (дампами, слоем представлений) и обеспечить полную прозрачность трансформаций. В идеале - реализовать через dbt-модели и Airflow DAG, чтобы регламентировать зависимые шаги и контролировать качество данных.

Как связать аналитику уязвимостей с операционной реакцией?

Встроить процесс автоматизированной выдачи тревог и тикетов в SIEM/SOAR и ITSM. При достижении пороговых значений можно автоматически формировать задачи по remediation и назначать ответственных, а затем отслеживать статус выполнения через дашборды.

Какие примеры open-source инструментов целесообразно использовать?

Apache Airflow для оркестрации и dbt для моделей трансформаций, что позволяет обеспечить воспроизводимость, вдумчивый контроль версий и тестирование моделей данных.

Глава охватывает базовый набор принципов и практических шагов для построения аналитики vulnerability management в BI DWH, фокусируясь на выявлении систем с наибольшим числом критических уязвимостей. Реализация предполагает не только техническую задачу агрегации и ранжирования, но и организационные аспекты: качество данных, процессы обновления, интеграции с операционными инструментами и обеспечение управляемых сценариев реагирования.

← Предыдущая статья

Vulnerability Management аналитика - анализ количества выявленных уязвимостей по системам

Следующая статья →

Vulnerability Management аналитика - анализ динамики появления новых уязвимостей