Процесс управления уязвимостями: этапы, методика ФСТЭК и автоматизация

Управление уязвимостями (Vulnerability Management, VM) — один из базовых процессов информационной безопасности. Без выстроенного VM организация накапливает технический долг: незакрытые уязвимости превращаются в точки входа для атакующих. В 2025 году ФСТЭК зафиксировала более 25 000 новых записей в БДУ, а средний MTTR в российских компаниях превышал 60 дней — втрое больше рекомендуемого порога.

В этой статье разберём процесс управления уязвимостями от и до: определение, пять этапов цикла, требования руководства ФСТЭК, работу с CVSS v3.1, таблицу SLA, ключевые метрики и подход к автоматизации через SGRC.

Что такое управление уязвимостями

Определение

Управление уязвимостями — это непрерывный, циклический процесс выявления, оценки, приоритизации, устранения и верификации уязвимостей в ИТ-инфраструктуре организации. VM охватывает серверы, рабочие станции, сетевое оборудование, СУБД, веб-приложения и контейнерные среды.

Ключевое слово — «непрерывный». В отличие от разового аудита или пентеста, VM работает постоянно: новые уязвимости появляются ежедневно, инфраструктура меняется, а окно эксплуатации сокращается. По данным Mandiant, среднее время от публикации CVE до появления эксплойта в 2025 году составило 15 дней.

Непрерывный цикл

Процесс управления уязвимостями представляет собой замкнутый цикл из пяти этапов:

1. Мониторинг и выявление — обнаружение уязвимостей в инфраструктуре.
2. Оценка критичности — расчёт CVSS, анализ контекста.
3. Приоритизация — ранжирование с учётом бизнес-контекста.
4. Устранение — патчинг, компенсирующие меры, изоляция.
5. Верификация — подтверждение устранения, закрытие тикета.

После верификации цикл начинается заново. Частота полного цикла зависит от зрелости организации: от ежеквартального сканирования у начинающих до непрерывного мониторинга у зрелых команд.

Руководство ФСТЭК

ФСТЭК России выпустила руководство по организации процесса управления уязвимостями, обязательное для операторов ГИС, ИСПДн, значимых объектов КИИ и АСУ ТП. Документ закрепляет пятиэтапную модель, определяет роли участников и устанавливает требования к срокам устранения. Нормативно-методическая сторона руководства подробно разобрана в статье Методика управления уязвимостями ФСТЭК. Подробнее о базе данных, на которой строится процесс, — в статье БДУ ФСТЭК России: руководство по базе угроз.

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

Пять этапов управления уязвимостями

Этап 1. Мониторинг и выявление

Первый этап — обнаружение уязвимостей. Источники информации делятся на два класса:

Активное сканирование. Сканеры уязвимостей (Nessus, MaxPatrol VM, RedCheck, Qualys) проверяют хосты по базам известных уязвимостей. Сканирование бывает агентным (установка агента на хост) и безагентным (сетевое обращение). Агентное сканирование точнее, безагентное — проще в развёртывании.

Пассивный мониторинг. Отслеживание публикаций в БДУ ФСТЭК, NVD (National Vulnerability Database), бюллетеней вендоров (Microsoft MSRC, Red Hat Errata, Debian Security Advisories). SGRC-платформы автоматически загружают обновления БДУ и сопоставляют их с реестром активов организации.

Результат этапа — перечень выявленных уязвимостей с привязкой к конкретным активам. Каждая запись содержит идентификатор (CVE/BDU), затронутый компонент и версию.

Практический пример. Сканер обнаруживает на веб-сервере уязвимость CVE-2024-6387 (regreSSHion) в OpenSSH 8.5–9.7. Уязвимость позволяет неаутентифицированному злоумышленнику выполнить произвольный код с правами root. Запись попадает в очередь оценки.

Этап 2. Оценка критичности (CVSS)

Каждой обнаруженной уязвимости присваивается числовая оценка критичности по стандарту CVSS (Common Vulnerability Scoring System). Текущая версия — CVSS v3.1. Подробнее о методике расчёта — в разделе «CVSS v3.1» ниже.

На этом этапе аналитик ИБ:

• Проверяет базовую оценку CVSS из NVD/БДУ.
• Уточняет временные метрики: доступен ли публичный эксплойт, выпущен ли патч.
• Определяет контекстные метрики: доступность актива из интернета, наличие компенсирующих мер (WAF, сегментация).

Оценка критичности — не механическое копирование CVSS Base Score. Уязвимость с базовой оценкой 7.5 на изолированном тестовом сервере менее критична, чем уязвимость с оценкой 6.0 на публичном веб-сервере с персональными данными.

💡 На практике: Используйте NVD Calculator для быстрого расчёта CVSS v3.1 прямо в браузере. Результат вставляйте в карточку уязвимости с указанием вектора атаки — это важно для аудита ФСТЭК. SGRC-платформы рассчитывают контекстную оценку автоматически при привязке уязвимости к классу актива.

Этап 3. Приоритизация

Приоритизация переводит техническую оценку в бизнес-контекст. Факторы:

• Ценность актива. Продуктивный сервер с ПДн приоритетнее тестового стенда.
• Наличие эксплойта. Уязвимость с публичным PoC-эксплойтом в Metasploit устраняется в первую очередь.
• Ландшафт угроз. Активная эксплуатация уязвимости APT-группами (по данным CISA KEV, Kaspersky ICS CERT).
• Зависимости. Затронутый компонент используется другими системами — каскадный эффект.
• Компенсирующие меры. Наличие WAF, IPS-правил или сетевой сегментации снижает приоритет.

На выходе — ранжированный список уязвимостей с назначенным SLA на устранение. Подробнее о SLA — в разделе ниже.

Типичная ошибка: приоритизация только по CVSS Base Score. Критическая уязвимость на изолированном хосте без доступа к чувствительным данным может быть менее срочной, чем высокая уязвимость на периметровом сервере. Контекст определяет приоритет, а не голая цифра.

Этап 4. Устранение

Устранение — самый ресурсоёмкий этап. Варианты реагирования:

Патчинг. Установка обновления, закрывающего уязвимость. Основной и предпочтительный способ. Перед накатом патча — тестирование на staging-среде.

Компенсирующие меры. Если патч недоступен или его установка нарушает работу системы:

• Правила WAF/IPS для блокировки вектора атаки.
• Отключение уязвимого компонента (неиспользуемый протокол, сервис).
• Сетевая изоляция (VLAN, ACL, микросегментация).

Принятие риска. Для уязвимостей с низкой критичностью на некритичных активах — документирование решения и регулярный пересмотр. Решение утверждает владелец риска.

Миграция. Замена устаревшего компонента, для которого вендор прекратил поддержку (EOL). Пример: миграция с Windows Server 2012 R2 на актуальную версию.

Каждое действие фиксируется в системе задач — кто, когда, что именно сделал. Это обеспечивает аудитопригодность процесса и необходимо при проверках регулятора.

Этап 5. Верификация

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

1. Повторное сканирование целевого актива тем же сканером, который обнаружил уязвимость.
2. Ручная проверка (для критических уязвимостей) — аналитик ИБ проверяет, что патч применён, версия компонента обновлена, эксплойт не воспроизводится.
3. Закрытие тикета в системе управления задачами с указанием способа устранения и даты.

Если повторное сканирование обнаруживает уязвимость повторно — тикет возвращается на этап устранения. Цикл повторяется до полного закрытия.

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

Руководство ФСТЭК по управлению уязвимостями

Область применения

Руководство ФСТЭК распространяется на:

• Государственные информационные системы (ГИС).
• Информационные системы персональных данных (ИСПДн).
• Значимые объекты критической информационной инфраструктуры (КИИ).
• Автоматизированные системы управления технологическими процессами (АСУ ТП).

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

Роли участников

Руководство определяет следующие роли:

• Подразделение ИБ — организация процесса, контроль SLA, формирование отчётности. Отвечает за этапы оценки, приоритизации и верификации.
• Подразделение ИТ — техническая реализация устранения: установка патчей, настройка компенсирующих мер, обновление систем. Отвечает за этап устранения.
• Владельцы информационных систем — принятие решений по рискам, утверждение SLA, выделение ресурсов на устранение. Участвуют в приоритизации.
• Руководство организации — обеспечение ресурсов, утверждение политики VM, контроль общих показателей.

Разделение ролей важно: ИБ выявляет и приоритизирует, ИТ устраняет, владелец системы принимает остаточный риск. Без формализации ролей процесс буксует на согласованиях.

Инструменты и источники

Руководство предписывает использовать:

• БДУ ФСТЭК (bdu.fstec.ru) как основной источник информации об уязвимостях. Модуль БДУ ФСТЭК в SGRC-платформе автоматизирует загрузку и сопоставление данных. Бесплатный онлайн-реестр БДУ с CVSS v4.0, EPSS и расчётом SLA по приказу №117.
• Сертифицированные средства анализа защищённости для сканирования инфраструктуры.
• Систему управления задачами для отслеживания хода устранения с фиксацией ответственных и сроков.

CVSS v3.1: метрики и контекст

Группы метрик

CVSS v3.1 включает три группы метрик:

Базовые метрики (Base Metrics) — неизменные характеристики уязвимости:

• Attack Vector (AV) — вектор атаки: сетевой (N), смежная сеть (A), локальный (L), физический (P).
• Attack Complexity (AC) — сложность: низкая (L), высокая (H).
• Privileges Required (PR) — требуемые привилегии: нет (N), низкие (L), высокие (H).
• User Interaction (UI) — взаимодействие с пользователем: не требуется (N), требуется (R).
• Scope (S) — изменение области воздействия: без изменения (U), изменение (C).
• Confidentiality / Integrity / Availability (C/I/A) — влияние на конфиденциальность, целостность, доступность: нет (N), низкое (L), высокое (H).

Временные метрики (Temporal Metrics) — изменяются со временем:

• Exploit Code Maturity (E) — зрелость эксплойта: не доказан (U), PoC (P), функциональный (F), высокая (H).
• Remediation Level (RL) — уровень исправления: официальный патч (O), временное решение (T), обходной путь (W), нет (U).
• Report Confidence (RC) — достоверность: не подтверждено (U), частично (R), подтверждено (C).

Контекстные метрики (Environmental Metrics) — специфичны для организации. Позволяют скорректировать базовую оценку с учётом конкретной среды.

Примеры CVE с разбором вектора

CVE-2024-6387 (regreSSHion, OpenSSH). Базовая оценка: 8.1 (High). Вектор: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Расшифровка: сетевой вектор атаки, высокая сложность эксплуатации, привилегии не требуются, взаимодействие с пользователем не нужно. Полное влияние на конфиденциальность, целостность и доступность. Несмотря на высокую сложность (AC:H), уязвимость критична из-за повсеместного использования OpenSSH и потенциального получения root-доступа.

CVE-2024-3094 (бэкдор в xz-utils). Базовая оценка: 10.0 (Critical). Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Расшифровка: сетевой вектор, низкая сложность, привилегии не нужны, scope изменяется (влияние выходит за пределы уязвимого компонента). Максимальная критичность — supply chain атака, затрагивающая sshd через зависимость liblzma.

CVE-2023-44487 (HTTP/2 Rapid Reset). Базовая оценка: 7.5 (High). Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Расшифровка: сетевой вектор, низкая сложность, влияние только на доступность. Отказ в обслуживании без компрометации данных. Несмотря на «среднюю» базовую оценку, уязвимость массово эксплуатировалась и требовала приоритетного устранения.

Контекст важнее цифры

CVSS Base Score — отправная точка, но не финальный вердикт. Контекстная оценка учитывает:

• Расположение актива (DMZ, внутренняя сеть, air-gapped сегмент).
• Тип обрабатываемых данных (ПДн, коммерческая тайна, открытая информация).
• Наличие компенсирующих мер (WAF, IPS, сегментация).
• Зрелость эксплойта (теоретическая уязвимость vs. активная эксплуатация).

Организации, внедрившие контекстную оценку, сокращают объём приоритетных задач на 40–60% без увеличения реального риска.

Таблица SLA: критичность и класс актива

SLA (Service Level Agreement) определяет максимально допустимое время на устранение уязвимости от момента обнаружения до верификации. Сроки зависят от двух параметров: критичности уязвимости (CVSS) и класса актива.

Пояснения к таблице:

• Для объектов КИИ сроки определяются руководством ФСТЭК и могут быть жёстче.
• При наличии публичного эксплойта (Exploit Code Maturity = Functional или High) SLA сокращается на один уровень вверх. Пример: высокая уязвимость с рабочим эксплойтом обрабатывается как критическая.
• Отсчёт SLA начинается с момента подтверждения уязвимости (после этапа оценки), а не с момента сканирования.
• SLA включает время на устранение и верификацию. Если верификация не пройдена — таймер не останавливается.

Установление SLA — зона ответственности CISO и владельцев информационных систем. SLA фиксируется в политике управления уязвимостями и доводится до подразделений ИТ.

SLA устранения уязвимостей по требованиям ФСТЭК

Существующая таблица выше описывает SLA по классам активов. Ниже — сопоставление с тем, что требует и рекомендует ФСТЭК, и что принято в отрасли.

ФСТЭК в методических рекомендациях по управлению уязвимостями 2022 года не устанавливает жёстких нормативных сроков в виде конкретных цифр, но указывает на обязанность зафиксировать SLA в организационных документах — политике управления уязвимостями или плане обеспечения безопасности. Для значимых объектов КИИ (Приказ ФСТЭК №239) план обеспечения безопасности является обязательным, и сроки устранения в нём проверяются.

Разрыв между рекомендацией ФСТЭК и практикой отрасли объясняется просто: российские ИТ-команды часто не имеют возможности патчить продуктивные системы без длительного согласования с бизнесом и тестирования на staging. Реалистичный SLA, зафиксированный в документах и выполняемый на 90%+, лучше амбициозного SLA с 50% выполнением.

⚠️ Важно: Для значимых объектов КИИ (Приказ №239) и ГИС (Приказ №117) SLA на устранение критических уязвимостей — 24 часа, высоких — 7 дней (168 ч). Нарушение зафиксированных сроков проверяется инспектором ФСТЭК по плану обеспечения безопасности. Устное «не успели» — не аргумент: нужен документированный перенос с обоснованием и компенсирующей мерой.

Матрица ответственности в процессе управления уязвимостями (RACI)

Половина проблем с пропуском SLA — не технические, а организационные: неясно, кто за что отвечает. RACI-матрица устраняет эту неопределённость.

R = Responsible (исполнитель), A = Accountable (принимает решение и несёт ответственность), C = Consulted, I = Informed

Обратите внимание на разделение ролей в строке «Устранение»: ИТ-инженер — исполнитель (R), руководитель ИТ — ответственный (A). Это означает, что ИБ не может напрямую требовать от инженера закрыть задачу в обход его руководителя. Без явной матрицы именно здесь возникают конфликты и задержки.

Типичные причины пропуска SLA и как их устранить

• Нет назначенного ответственного за каждую уязвимость — устранить автоматическим назначением по владельцу актива в SGRC. Если актив принадлежит подразделению X, задача автоматически уходит его инженеру.
• Ответственный не знает о задаче — устранить автоматическими уведомлениями с эскалацией по SLA в SGRC: за 3 дня до дедлайна — аналитику ИБ, в день дедлайна — руководителю ИТ.
• Актив не идентифицирован в инвентаризации — устранить связкой VM-модуля с CMDB. Уязвимость без привязки к активу не имеет владельца и зависает навсегда.
• Нет доступа к патчу — устранить трекингом статуса «ожидание патча» с переносом SLA и аргументацией. Перенос должен быть зафиксирован, а не «забыт» в очереди.

Метрики эффективности VM-процесса

Без метрик управление уязвимостями превращается в формальность. Ниже — ключевые показатели, которые необходимо отслеживать.

Рекомендации по использованию метрик:

• Отслеживайте MTTR в разрезе критичности: отдельно для Critical, High, Medium, Low.
• Покрытие сканирования ниже 80% означает, что значительная часть инфраструктуры — «слепая зона».
• SLA Compliance ниже 70% сигнализирует о системной проблеме: нехватка ресурсов, неработающий процесс согласования или нереалистичные SLA.
• Растущий backlog — красный флаг. Если темп обнаружения стабильно превышает темп устранения, необходимо пересмотреть приоритизацию или увеличить ресурсы.

Метрики формируются автоматически в SGRC-платформе и выводятся на дашборд CISO. Ручной сбор метрик из разрозненных систем — типичная проблема организаций без централизованного инструмента.

🔗 Нужен дашборд для отслеживания VM-цикла? КиберОснова показывает MTTR, SLA Compliance и покрытие сканирования в реальном времени — без Excel и ручного сбора данных. Запросить демо →

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

Проблема ручного процесса

В организации с 500+ активами ручное управление уязвимостями невозможно. Типичный результат одного сканирования — тысячи записей. Без автоматизации:

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

Автоматизируйте весь цикл VM: КиберОснова принимает отчёты ScanOVAL и RedCheck, привязывает уязвимости к активам и контролирует SLA по приказам ФСТЭК автоматически. Запросить демо →

Сканеры уязвимостей

Сканеры — основа технической части VM-процесса:

• Nessus (Tenable) — один из наиболее распространённых сканеров. Широкая база плагинов, агентное и безагентное сканирование.
• MaxPatrol VM (Positive Technologies) — российский сканер с поддержкой БДУ ФСТЭК, сертифицированный ФСТЭК. Включает asset management.
• RedCheck (АЛТЭКС-СОФТ) — сертифицированный ФСТЭК сканер, интеграция с БДУ, поддержка отечественных ОС (Astra Linux, РЕД ОС).
• ScanOVAL (АЛТЭКС-СОФТ / ФСТЭК) — бесплатный локальный сканер для проверки соответствия конфигурации требованиям ФСТЭК. HTML-отчёт ScanOVAL загружается в личный кабинет КиберОснова, где уязвимости автоматически привязываются к активам и попадают в VM-процесс.
• Qualys VMDR — облачный сканер с модулем приоритизации на основе threat intelligence.

Подробный разбор российских сканеров и их сравнение — в статье Сканеры уязвимостей ФСТЭК: обзор и сравнение.

Сканеры обнаруживают уязвимости, но не управляют процессом их устранения. Для оркестрации нужна SGRC-платформа.

SGRC как оркестратор VM-процесса

SGRC (Security Governance, Risk and Compliance) — класс систем, объединяющих управление рисками, комплаенсом и операционными процессами ИБ. В контексте VM платформа SGRC:

• Агрегирует данные из нескольких сканеров в единое пространство. Устраняет дублирование, нормализует форматы.
• Привязывает уязвимости к активам из CMDB. Каждая уязвимость имеет конкретного владельца и класс актива.
• Автоматически рассчитывает приоритет с учётом CVSS, класса актива, наличия эксплойта и компенсирующих мер.
• Контролирует SLA — автоматические эскалации при приближении к дедлайну и оповещения ответственных.
• Формирует отчётность для CISO (дашборды с метриками) и регулятора (формализованные отчёты по требованиям ФСТЭК).
• Связывает VM с моделью угроз — уязвимости привязываются к актуальным угрозам из БДУ.

КиберОснова: VM в рамках SGRC

Платформа КиберОснова реализует полный жизненный цикл управления уязвимостями в рамках SGRC-подхода. Система управления уязвимостями КиберОснова включает:

• Модуль VM — единая рабочая среда: от импорта отчётов сканеров до верификации и отчётности для регулятора.
• Модуль БДУ ФСТЭК — автоматическая загрузка и актуализация базы уязвимостей и угроз.
• Интеграция со сканерами — импорт результатов MaxPatrol VM, RedCheck, ScanOVAL; дедупликация, нормализация.
• Привязка к реестру активов — каждая уязвимость связана с конкретным активом, владельцем и подразделением. Работает в связке с модулем инвентаризации.
• Система задач — назначение ответственных, контроль SLA, журнал действий для аудита ИБ.
• Дашборды и метрики — MTTR, SLA Compliance, покрытие, backlog в реальном времени.
• Интеграция с моделью угроз — связь уязвимостей с угрозами УБИ и оценкой рисков.

Результат: вместо разрозненных инструментов и таблиц — единая платформа, в которой весь VM-процесс прозрачен для CISO, ИТ-подразделения и регулятора. Запросить демо и оценить модуль управления уязвимостями можно на сайте.

Типичные ошибки при внедрении VM-процесса

1. Сканирование без устранения

Организация запускает сканер, получает отчёт на 200 страниц — и откладывает его до следующего аудита. Сканирование без выстроенного процесса устранения создаёт иллюзию контроля. Регулятор при проверке спросит не о результатах сканирования, а о том, что с ними сделали.

2. Приоритизация только по CVSS Base Score

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

3. Нереалистичные SLA

SLA «устранить все критические уязвимости за 4 часа» при штате ИТ в два человека — гарантия провала. SLA должны быть амбициозными, но достижимыми. Лучше начать с реалистичных сроков и постепенно сокращать их по мере роста зрелости процесса.

4. Отсутствие верификации

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

5. VM в отрыве от управления рисками

Управление уязвимостями — не самоцель, а часть системы управления рисками. Если VM-процесс существует отдельно от модели угроз, реестра рисков и комплаенс-контроля, организация теряет целостную картину. SGRC-подход связывает VM с остальными процессами ИБ.

6. Игнорирование покрытия

Сканирование 60% инфраструктуры оставляет 40% в «слепой зоне». Shadow IT, неучтённые виртуальные машины, забытые dev-серверы — частые источники инцидентов. Перед запуском VM необходима инвентаризация активов: без актуального реестра система управления уязвимостями не знает, что сканировать.

7. Ручной сбор метрик

Если MTTR и SLA Compliance считаются вручную раз в квартал — это не метрики, а археология. Метрики должны быть автоматическими и доступными в реальном времени, иначе они не влияют на принятие решений.

Заключение

Процесс управления уязвимостями — это не установка сканера и не разовый аудит. Это непрерывный цикл из пяти этапов: мониторинг, оценка, приоритизация, устранение, верификация. Руководство ФСТЭК формализует этот цикл для операторов ГИС, ИСПДн и КИИ, превращая лучшие практики в нормативное требование.

Эффективный VM-процесс опирается на три компонента: технические средства (сканеры), организационные меры (роли, SLA, политика) и платформу оркестрации (SGRC). Без автоматизации процесс деградирует при масштабировании: ручное управление тысячами уязвимостей в таблицах — путь к пропущенным SLA и инцидентам. Для формализации процесса разработайте регламент управления уязвимостями — документ, закрепляющий роли, сроки и процедуры. Сравнение инструментов для автоматизации VM-процесса — в статье Системы управления уязвимостями: обзор и сравнение.

КиберОснова объединяет все три компонента: интеграция с БДУ ФСТЭК и сканерами, управление задачами с контролем SLA, связь уязвимостей с моделью угроз и метрики для CISO. Запросите демо и оцените, как SGRC-платформа закрывает VM-процесс от и до.