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

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

В российской средней компании (50–500 сотрудников) типичная ситуация: сканер уязвимостей выдает большое количество CVE при сканировании, ИТ-команда тонет в задачах по количеству уязвимостей, критические уязвимости остаются открытыми месяцами. Количество CVE в 2025 году превысило 39 000 за год, в 2026 также ожидается рост уязвимостей за год. Среднее время от обнаружения до начала эксплуатации сократилось в 20 раз за последние 2,5 года — менее 40 дней.

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

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

Почему подход изменился

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

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

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

Архитектура процесса управления уязвимостями по требованиям ФСТЭК

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

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

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

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

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

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

Этап	Задача	Ключевые действия
1. Мониторинг	Сбор данных из источников	Подписка на CVE, трендовые уязвимости, рекомендации ФСТЭК
2. Оценка	Применение к ИС организации	CVSS + EPSS + контекст актива + методика ФСТЭК
3. Приоритизация	Расставить приоритеты по риску	Матрица уровня приоритета.
4. Устранение	Патч-менеджмент и компенсирующие меры	Автопатчинг российских ОС (Астра Линукс, РЕД ОС, Альт Линукс), компенсирующие меры для КИИ
5. Контроль	Сбор данных о результатах	Повторное сканирование, дашборды

Приоритизация уязвимостей: от CVSS к риск-ориентированному подходу

Самый частый вопрос от ИТ-команд: «Какую уязвимость устранять первой?». Если отвечать «ту, у которой 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 = статус уязвимости (актуальность в инфраструктуре)

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

• P1 (Критический): срок устранения 24 часа. результат ≥ 3.5 ИЛИ EPSS>5% ИЛИ уязвимость в трендовом списке.
• P2 (Высокий): срок устранения 7 дней. результат от 2.0 до 3.4 ИЛИ EPSS от 1% до 5%
• P3 (Средний): срок устранения 30 дней. результат от 1 до 1.9 ИЛИ EPSS от 0.5% до 1%
• P4 (Низкий): срок устранения 90 дней или плановое окно. результат <1 ИЛИ EPSS <0.5%

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

Метрики устранения и приоритизации уязвимостей:

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

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

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

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

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

Уровень критичности	Значение	Срок устранения	Фактическое время (целевое)
Критический	V> 3.5	24 часа	≤ 1 день
Высокий	2.4–3.4	7 дней	≤ 7 дней
Средний	1–1.9	4 недели	≤ 30 дней
Низкий	<1	3 месяца	≤ 90 дней

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

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

Категория	Цель	Минимум
Критические (P1)	≥ 95%	≥ 90%
Высокие (P2)	≥ 90%	≥ 85%
Средние (P3)	≥ 80%	≥ 70%
Низкие (P4)	≥ 70%	≥ 60%
Все категории	≥ 85%	≥ 80%

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

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

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

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

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

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

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

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

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

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

Типичные ошибки в выстраивании процесса управления уязвимостями

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

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

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

Технические ошибки:

• Приоритизация только по CVSS без учёта EPSS, трендовости, контекста актива
• Нет владельцев активов — задачи повисают без исполнителя
• Ручное оповещение администраторов — задачи теряются в почте/чатах
• Нет повторного сканирования после устранения — фиктивная «закрытость»
• Слишком агрессивные SLA без учёта технологических ограничений — систематические нарушения, саботаж со стороны ИТ

Итог

Эффективная программа управления уязвимостями в российской средней компании строится не вокруг сканера, а вокруг процесса. Она должна связывать приоритизацию, SLA, владельцев активов, повторную проверку и понятные метрики, которые отражают реальный риск.

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