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

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

Это один из базовых процессов информационной безопасности, наравне с харденингом и мониторингом.

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

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

Ключевое отличие от простого патч-менеджмента — в объёме задачи. Управление уязвимостями решает, что вообще нужно чинить и в каком порядке, с учётом критичности конкретной уязвимости, наличия рабочего эксплойта и ценности актива, на котором она обнаружена; собственно патчинг — лишь один из возможных способов устранения наравне с компенсирующими мерами, когда патч ещё не вышел или его установка рискованна для стабильности системы.

Методический документ ФСТЭК России «Руководство по организации процесса управления уязвимостями в органе (организации)», утверждённый 17 мая 2023 г., описывает цикл из мониторинга и выявления уязвимостей, оценки их критичности, приоритизации, устранения и контроля результата. Документ применяется государственными органами и организациями, включая субъектов критической информационной инфраструктуры, при принятии мер по устранению уязвимостей программных и программно-аппаратных средств информационных систем.

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

Критичность уязвимости в российской регуляторике считается по «Методике оценки уровня критичности уязвимостей программных, программно-аппаратных средств», утверждённой ФСТЭК России 30 июня 2025 г., которая заменила предыдущую версию методики от 28 октября 2022 г. Новая редакция использует только базовую оценку CVSS (Base Score) — из БДУ ФСТЭК, данных вендора или международных баз, а не полный расчёт с временными и контекстными метриками, как требовала версия 2022 года.

↔ таблицу можно прокрутить вбок

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

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

• Сканеры и VM-платформы. Класс VM (Vulnerability Management) объединяет сканеры уязвимостей и платформы, которые автоматизируют весь цикл — от инвентаризации активов и сканирования до расчёта критичности, приоритизации и контроля сроков устранения по каждой найденной записи.
• БДУ ФСТЭК. Банк данных угроз безопасности информации (БДУ ФСТЭК) — российский реестр уязвимостей (идентификаторы вида BDU:ГГГГ-NNNNN) и угроз (идентификаторы вида УБИ.NNN), который используется при построении модели угроз и как источник данных для оценки критичности по методике ФСТЭК.
• CVE и NVD. Международная система идентификаторов CVE (ведёт MITRE) и национальная база данных уязвимостей NVD (NIST, США) — источники базовой оценки CVSS и описаний уязвимостей, на которые кросс-ссылается часть записей БДУ ФСТЭК.
• Приоритизация. Что патчить первым, определяет не только оценка CVSS сама по себе, а сочетание факторов: критичность по методике, ценность и доступность актива из внешнего периметра, наличие подтверждённого рабочего эксплойта и фактическая эксплуатация уязвимости в реальных атаках.

Управление уязвимостями работает прежде всего с уже известными и раскрытыми уязвимостями — теми, у которых есть идентификатор CVE или запись в БДУ ФСТЭК, а зачастую уже и патч; против уязвимости нулевого дня, о которой ещё никто официально не знает, классический процесс патчинга просто не успевает сработать. Это не делает управление уязвимостями бесполезным против zero-day — оно закрывает соседнюю и не менее опасную часть риска.

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

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

Требование выстроить процесс анализа и устранения уязвимостей входит в состав мер защиты информации по трём ключевым приказам ФСТЭК России — в зависимости от типа информационной системы. Классификация самих уязвимостей при этом опирается на отдельный национальный стандарт.

↔ таблицу можно прокрутить вбок

Помимо самой методики процесса, ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем» задаёт единый язык для описания найденных дефектов — классифицирует их по области происхождения, типу недостатка и месту возникновения в системе. Этот же стандарт, наряду с БДУ ФСТЭК, используется при построении модели угроз: уязвимость, обнаруженная в ходе процесса управления уязвимостями, встраивается в модель как конкретная реализация уже описанной в ней категории угрозы.