Программа управления уязвимостями в компании: как выстроить приоритеты

Для российской финансовой отрасли ситуация особенно острая: значимая доля уязвимостей начинает эксплуатироваться в течение суток после раскрытия. Это означает, что классический подход, основанный только на CVSS, уже не обеспечивает нужный уровень защиты. Уязвимость с высоким баллом CVSS на внутреннем сервере далеко не всегда опаснее средней уязвимости на публичном сервисе, который уже фигурирует в атаках и имеет рабочий эксплойт.

Дополнительная сложность связана с тем, что специалисты по ИБ нередко тратят значительную часть времени не на устранение рисков, а на согласование сроков с ИТ, объяснение приоритетов и повторную проверку закрытия. Если процесс не формализован, уязвимости либо теряются, либо закрываются слишком поздно. Поэтому программа управления уязвимостями должна строиться как управляемый процесс, а не как разовая операция сканирования.

За последние годы управление уязвимостями стало намного сложнее. Количество уязвимостей растёт быстрее, чем возможности организаций их закрывать. Параллельно сокращается время между публикацией уязвимости и её эксплуатацией. Это означает, что у команд ИБ остаётся всё меньше времени на оценку и реагирование.

На ситуацию также влияют машинное обучение, автоматизация атак, рост сервисов «киберпреступности как услуги», а также массовый переход организаций на новые технологии — контейнеризацию, облака и отечественные операционные системы. При этом импортозамещение снижает зависимость от зарубежных решений, но создаёт новую реальность: в инфраструктуре появляются другие продукты, другие уязвимости и другой цикл обновлений.

Отдельный фактор риска — атаки через подрядчиков и смежные компании. Если компания ограничивается только собственным периметром, она может не видеть существенную часть поверхности атаки. Поэтому управление уязвимостями должно охватывать не только ключевые серверы, но и все значимые активы, включая серые зоны.

Теперь перейдём к практике. Как выстроить процесс управления уязвимостями так, чтобы он работал в российской компании и соответствовал требованиям регуляторов? ФСТЭК уже дала методические рекомендации (Согласно методическому документу ФСТЭК РФ от 17.05.2023) — осталось их внедрить. В прикладном виде он включает пять этапов: мониторинг, оценку, приоритизацию, устранение и контроль.

На этапе мониторинга организация собирает данные из внешних и внутренних источников: CVE, трендовые уязвимости, рекомендации регуляторов и перечни активно эксплуатируемых слабых мест. На этапе оценки уязвимость сопоставляется с конкретной инфраструктурой: важно понять, присутствует ли уязвимое ПО на активе и насколько этот актив важен для бизнеса.

Приоритизация строится уже не вокруг абстрактного показателя CVSS, а вокруг риска. Здесь учитываются вероятность эксплуатации, наличие эксплойта, публичная доступность актива и его критичность. Далее следует устранение — через патчи, компенсирующие меры и, где это требуется, временные ограничения доступа. Завершает цикл контроль: повторное сканирование, проверка результата и фиксация метрик.

Отдельно стоит отметить требование ФСТЭК к инвентаризации активов и назначению владельцев. Без владельца уязвимость часто остаётся ничейной: ИБ видит риск, ИТ не считает его своим приоритетом, а бизнес не понимает последствия. Поэтому именно реестр активов и ответственность за них являются основой всей программы управления уязвимостями.

Ниже описана пятиэтапная схема (Согласно методическому документу ФСТЭК РФ от 17.05.2023), которая покрывает полный цикл: от мониторинга до контроля результатов.

Этапы процесса управления уязвимостями:

Самый частый вопрос от ИТ-команд: «Какую уязвимость устранять первой?». Если отвечать «ту, у которой CVSS 10», вы получите вечный спор и нулевую эффективность. Нужно считать приоритет по формуле, которая учитывает не только теоретическую опасность, но и реальную эксплуатацию. Согласно методическому документу ФСТЭК РФ, оценка опасности уязвимости проводится в несколько шагов:

Шаг 1 — Определение релевантности уязвимости. Проверяется, присутствует ли уязвимость в информационных системах организации. Для этого сканер сопоставляет установленное ПО на активах с базой CVE. Если уязвимое ПО не установлено на активе — уязвимость не релевантна.

Шаг 2 — Оценка актуальности уязвимости. Определяется, есть ли публичный эксплойт для уязвимости и эксплуатируется ли она в реальной жизни. ФСТЭК рекомендует использовать следующие источники:

• БДУ ФСТЭК — Банк данных угроз безопасности информации
• Трендовые уязвимости от отечественных экспертов - уязвимости, активно эксплуатируемые в APT-атаках по данным отечественных экспертов. Если уязвимость в списке трендовых — приоритет P1, обязательное устранение.
• EPSS (Exploit Prediction Scoring System) — вероятность эксплуатации уязвимости в ближайшие 30 дней в процентах. Приоритет уязвимостям с EPSS> 0.5%, критичные уязвимости — EPSS> 5%. Источником обогащения информации является сканер уязвимости.

Шаг 3 — Оценка опасности уязвимости. Рассчитывается комплексная оценка опасности на основе нескольких факторов:

• Базовая метрика CVSS v4 (теоретическая тяжесть уязвимости от 0 до 10. Это базовый фильтр, но не единственный критерий согласно ФСТЭК. Значение берётся из VM-сканера.)
• Временная метрика (наличие патча, доступность исправления)
• Контекстная метрика (критичность актива, доступность из интернета)

Шаг 4 — Определение уровня опасности. На основе комплексной оценки уязвимость попадает в один из четырёх уровней:

КВОИ (Критически важные объекты ИБ) — если актив является частью КИИ, ГИС или ПДн, уязвимость на нём получает автоматический приоритет. В формуле приоритета КВОИ умножается на 2.

Контекст актива — доступность из интернета и критичность для бизнеса. Публичный сервер с CVSS 7.0 опаснее внутреннего сервера с CVSS 9.0.

Для риск-ориентированного управления уязвимостями в российских компаниях можно использовать разные формулы приоритета. Она учитывают базовую оценку CVSS, критичность актива, наличие эксплойта, публичную доступность и актуальность уязвимости в инфраструктуре. В каждой организации формула может отличаться, но её задача одна — перевести технические характеристики в понятный приоритет устранения.

Как пример для российских компаний в риск-ориентированном управлении уязвимостями (RBVM) можно рассчитывать приоритет по формуле (в каждой организации пример формулы может отличаться):

Приоритет = ((CVSS + KVOI × 2 + EXPLOIT × 2 + ASSET × 2 + ACCESS × 2) × VULNSTAT) / 4*

Где:

• CVSS — базовая метрика от 0 до 10 (из сканера уязвимостей)
• KVOI = 1, если актив — часть критичной ИС (КВОИ)
• EXPLOIT = 1, если есть публичный эксплойт или уязвимость в трендовом списке, либо в БДУ ФСТЭК.
• ACCESS = 1, если актив доступен из интернета (публичный), иначе 0
• ASSET = 1, если актив критичен для бизнеса
• VULNSTAT = статус уязвимости (актуальность в инфраструктуре)

Полученное значение сравнивается с пороговыми значениями для определения уровня приоритета:

* Данная формула является примером авторской методики для российских компаний и не является официальной методикой ФСТЭК. Организации могут использовать авторскую формулу для внутреннего процесса, но в отчётности для регуляторов указывать уровни критичности согласно методике ФСТЭК

Возникает вопрос: «Что мы вообще делаем с уязвимостями?». Отвечать «мы закрыли 100 уязвимостей» — бесполезно. Бизнесу нужны метрики, которые показывают риск и эффективность процесса.

На практике уязвимости удобно делить на четыре уровня. Критические уязвимости устраняются в течение 24 часов, высокие — в течение 7 дней, средние — в течение 30 дней, низкие — в течение 90 дней или в ближайшее плановое окно. Такой подход позволяет связать техническую оценку с реалистичным сроком реагирования.

Ниже — какие метрики считать, как их рассчитывать и что может быть интересно бизнесу для выстраивания эффективной оценки устранения уязвимостей.

Время устранения (SLA) = (Количество уязвимостей, устранённых в срок / Общее количество уязвимостей) × 100%

Соблюдение установленных сроков ликвидации уязвимостей в зависимости от их критичности. Это ключевой показатель эффективности процесса управления уязвимостями. Даже правильно рассчитанный приоритет не будет работать без согласованных сроков устранения. Самая частая проблема заключается в том, что ИБ ожидает быстрого патчинга, а ИТ оперирует окнами обслуживания, зависимостями, отсутствием ресурсов и риском простоя. Если SLA не согласованы заранее, уязвимости будут закрываться либо формально, либо с серьёзным опозданием.

Процент устранённых уязвимостей = (Количество устранённых уязвимостей / Общее количество обнаруженных уязвимостей) × 100%

Соотношение закрытых уязвимостей к общему числу, обнаруженных за период. Показывает эффективность процесса устранения и загруженность команды.

Объём открытых критических уязвимостей = Количество уязвимостей уровня «Критический», которые остались открытыми на отчётную дату.

Количество критических уязвимостей, по которым пропущены регламентные сроки устранения. Прямой показатель текущего риска для организации.

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

Покрытие сканированием =(Количество отсканированных активов / Общее количество активов в организации) × 100%

Доля информационных активов организации, на которых регулярно проводится анализ защищённости. Без покрытия выше 95% организация не может гарантировать, что видит все уязвимости. Для КВОИ и публичных активов требуется покрытие в 100%. Устранение невозможно без хорошего обнаружения. Если сканированием покрыта только часть инфраструктуры, организация просто не видит значимую долю риска. Серые зоны, такие как забытые серверы, теневое ИТ, IoT, телефония и СКУД, должны быть выявлены и включены в процесс управления уязвимостями. Если эти активы не сканируются, они становятся естественной точкой входа для атакующего.

Среднее время обнаружения = Σ (Время обнаружения каждой уязвимости) / (Количество уязвимостей), где:

Время обнаружения = Дата сканирования, где обнаружена уязвимость − Дата появления уязвимости в сети

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

Главное правило метрик:

Метрики должны быть измеримыми, сравнимыми и ведущими к действию.

• Измеримыми: чёткая формула расчёта, понятные единицы измерения (дни, проценты, количество)
• Сравнимыми: можно сравнить квартал к кварталу (тренд), с целевыми значениями (SLA)
• Ведущими к действию: если метрика ниже цели — понятно, что делать (увеличить частоту сканирования, усилить автопатчинг, пересмотреть SLA)

На практике программы управления уязвимостями чаще всего ломаются по одним и тем же причинам:

Первая ошибка — отношение к ИБ как к состоянию, а не как к процессу, который надо обеспечивать каждый час работы. Управления уязвимостями — это непрерывный цикл: обнаружение рисков - оценка рисков - устранение или минимизация рисков - проверка результата. Эта цепочка должна выполняться максимально быстро.

Вторая ошибка — использование технологий без должного обеспечения необходимым персоналом и процессом. ИТ и ИБ представляют собой прежде всего совокупность технологий, персонала и процессов. Если из этого треугольника убрать одну из сторон, то вся конструкция будет неустойчивой. Мало внедрить новую меру защиты, надо еще проработать процессы ее реализации и найти того, кто будет следить и поддерживать ее работу.

Автор: Афанасий Клюнков, менеджер продукта SIEM Alertix, компания NGR Softlab

Источник: CISOCLUB