- В
- Воронеж
- Е
- Екатеринбург
- К
- Казань
- Краснодар
- Новосибирск
- О
- Омск
- П
- Пермь
- У
- Уфа
- Ф
- Федеральный
- Ч
- Челябинск
Главная / База знаний / Категорирование объектов критической информационной инфраструктуры (КИИ) / Управление уязвимостями (Vulnerability Management) в инфраструктуре субъектов КИИ
Главная / База знаний / Категорирование объектов критической информационной инфраструктуры (КИИ) / Управление уязвимостями (Vulnerability Management) в инфраструктуре субъектов КИИ
С марта 2026 года управление уязвимостями становится обязательным элементом системы безопасности значимых объектов КИИ. В статье разбираем полный цикл VM-процесса — от мониторинга CVE до верификации устранения — с учётом требований приказов ФСТЭК и реальной практики.
Каждый значимый объект критической информационной инфраструктуры — это живая экосистема, где ежедневно появляются десятки новых CVE-записей, а окно эксплуатации сокращается до нескольких часов. По данным БДУ ФСТЭК, в 2025 году количество зарегистрированных уязвимостей в отечественном и зарубежном ПО превысило 30 000 записей. Для субъекта КИИ это означает одно: разовые проверки «раз в квартал» перестали быть достаточной мерой защиты.
VM (Vulnerability Management) — управление уязвимостями — представляет собой непрерывный циклический процесс выявления, приоритизации, устранения и верификации уязвимостей в ИТ-инфраструктуре организации. В контексте требований приказа ФСТЭК № 239 этот процесс приобретает обязательный характер и жёсткие временные рамки: критические уязвимости необходимо устранять в течение 24 часов, высокие — за 7 календарных дней.
В статье разберём, как выстроить полноценный VM-процесс на объектах КИИ: от инвентаризации активов до автоматизированного патч-менеджмента — без нарушения SLA критичных сервисов.
Регуляторное поле в области управления уязвимостями для субъектов КИИ формируется несколькими ключевыми документами. CISO обязан учитывать каждый из них при проектировании VM-процесса.
Закон «О безопасности КИИ» устанавливает обязанность субъектов обеспечивать непрерывность функционирования значимых объектов и реагировать на компьютерные инциденты. Управление уязвимостями прямо следует из требований по предотвращению неправомерного воздействия на информационные ресурсы.
Приказ определяет конкретные меры безопасности, включая группу мер «Управление обновлениями программного обеспечения» (ОПО) и «Анализ угроз безопасности информации» (АУБ). Меры ОПО.1–ОПО.4 обязывают субъекта регламентировать правила и процедуры получения, тестирования и установки обновлений из доверенных источников.
Методический документ описывает пятиэтапный процесс управления уязвимостями, обязательный к применению для государственных органов и субъектов КИИ. Документ определяет роли участников, требования к инструментарию и порядок взаимодействия с БДУ ФСТЭК.
Обновлённая методика вводит усовершенствованную шкалу оценки: вместо полного расчёта CVSS v3.1 с временны́ми и контекстными метриками теперь достаточно базовой оценки CVSS от вендора. Добавлены контекстные параметры — наличие эксплойтов в открытом доступе, факт использования уязвимости в реальных атаках и критичность актива.
Таким образом, с марта 2026 года управление уязвимостями становится не рекомендацией, а обязательным элементом системы безопасности значимых объектов КИИ. Несоблюдение грозит штрафами и предписаниями ФСТЭК.
Руководство ФСТЭК по организации процесса управления уязвимостями определяет пять последовательных этапов. Каждый из них имеет чёткие входы, выходы и ответственных.
На этом этапе ИБ-подразделение отслеживает публикации в БДУ ФСТЭК, NVD, бюллетенях вендоров и отраслевых CERT. Для каждой обнаруженной уязвимости проводится анализ применимости: используется ли уязвимое ПО в инфраструктуре организации, в какой конфигурации, на каких объектах.
Применимые уязвимости оцениваются по обновлённой методике ФСТЭК. Базовая оценка CVSS дополняется контекстными факторами: наличие публичного эксплойта, зафиксированные случаи эксплуатации, категория значимости объекта КИИ. Результат — уровень критичности: критический, высокий, средний или низкий.
Для каждой уязвимости определяется метод устранения: установка обновления (патча), применение компенсирующих мер, изменение конфигурации или изоляция уязвимого компонента. На объектах АСУ ТП нередко единственным допустимым методом остаётся сегментация сети, поскольку установка патча невозможна без остановки технологического процесса.
Непосредственное применение выбранных методов: развёртывание патчей, изменение конфигураций, обновление правил WAF/IPS. Этот этап требует тесного взаимодействия между командами ИБ и ИТ, а также согласования с владельцами бизнес-процессов для минимизации простоев.
Верификация результата: повторное сканирование, проверка конфигураций, подтверждение того, что уязвимость действительно закрыта. Результаты фиксируются в системе учёта и используются при формировании отчётности для ФСТЭК и ГосСОПКА.
Цикл повторяется непрерывно — от ежедневного мониторинга до еженедельной верификации
Методика ФСТЭК от 30.06.2025 устанавливает конкретные временные рамки для устранения уязвимостей в зависимости от уровня критичности. Для субъектов КИИ эти сроки фактически становятся SLA-обязательствами перед регулятором.
Важно понимать: сроки отсчитываются не с момента публикации CVE, а с момента завершения оценки критичности уязвимости в контексте конкретной инфраструктуры. Это даёт субъекту определённый «буфер», но не освобождает от оперативного мониторинга. Для организации SOC-центра рекомендуется настроить автоматические уведомления о новых критических уязвимостях.
Для кого эта услуга
Химическая промышленность
Оборонная промышленность
Энергетика
Атомная энергия
Здравоохранение
Горнодобывающая промышленность
Транспорт
Связь
Топливно-энергетический комплекс
О нашей компании
Постоянно сотрудничаем с крупными государственными и международными корпорациями
Четко выполняем требования контролирующих организаций
Непрерывно работаем над улучшением нашего профессионализма
Послепродажная поддержка в правовых аспектах
Беспроцентная рассрочка (до 4 месяцев)
Бесплатная доставка документации по регионам России лично к заказчику
Клиенты
Благодарственные письма
Приказ ФСТЭК № 239 требует использовать для анализа защищённости объектов КИИ сертифицированные средства защиты информации. Рынок отечественных VM-решений существенно вырос после ухода Qualys, Tenable и Rapid7, и на 2026 год представлен зрелыми продуктами с подтверждённым уровнем доверия.
При выборе сканера уязвимостей ФСТЭК для объектов КИИ ключевыми критериями являются: поддержка отечественных ОС (Astra Linux, РЕД ОС, ALT Linux), возможность агентного сканирования изолированных сегментов, интеграция с SIEM/SOAR и наличие модуля патч-менеджмента.
Главная боль ИБ-инженера на объектах КИИ — конфликт между необходимостью оперативно установить обновление безопасности и требованием обеспечить непрерывность критичного сервиса. Ниже представлена пошаговая методология, позволяющая разрешить это противоречие.
Все серверы и системы группируются по допустимому окну обслуживания. Инвентаризация ИТ-активов должна включать SLA-метки:
Для серверов с профилем «нулевой простой» и «минимальный» рекомендуется следующий алгоритм:
Шаг 1. Получение и верификация патча. Обновление загружается из доверенного репозитория, проверяется контрольная сумма и цифровая подпись вендора. На объектах КИИ запрещено устанавливать обновления, полученные из непроверенных источников.
Шаг 2. Тестирование на стенде. Патч разворачивается на тестовой копии продуктивной среды. Проводится регрессионное тестирование ключевых функций. Для систем, прошедших процедуру DevSecOps, этот этап автоматизируется через CI/CD-пайплайн.
Шаг 3. Snapshot / резервное копирование. Перед установкой создаётся снимок состояния системы (snapshot ВМ, LVM-снимок, резервная копия БД). Это обеспечивает возможность мгновенного отката.
Шаг 4. Развёртывание с канареечной стратегией. Обновление устанавливается сначала на одном узле кластера. После 15–30 минут мониторинга без аномалий — распространяется на остальные узлы.
Шаг 5. Верификация и ресканирование. После установки проводится повторное сканирование сканером уязвимостей для подтверждения закрытия CVE. Результат фиксируется в тикет-системе.
Управление уязвимостями не существует в вакууме. Для субъекта КИИ VM-процесс должен быть интегрирован в единую систему управления информационной безопасностью.
Данные об уязвимостях обогащают корреляционные правила SIEM: попытка эксплуатации уязвимости, для которой ещё не установлен патч, получает повышенный приоритет в SOC. Это позволяет оперативно выявлять целевые атаки на известные слабые места инфраструктуры.
Результаты VM-сканирования используются для актуализации модели угроз. Обнаружение новых уязвимостей может изменить перечень актуальных угроз и потребовать пересмотра набора защитных мер.
Данные сканирования уязвимостей служат входом для тестирования на проникновение. Пентестеры верифицируют эксплуатабельность обнаруженных уязвимостей в реальных условиях, что помогает уточнить приоритеты устранения.
Платформы SGRC агрегируют данные VM-сканеров и формируют единую картину compliance: сколько уязвимостей открыто, какой процент устранён в срок, какие объекты КИИ находятся в «красной зоне». Эта информация критична при подготовке к аудиту ФСТЭК.
Анализ десятков проектов по внедрению VM на объектах КИИ позволяет выделить повторяющиеся ошибки и дать конкретные рекомендации.
1. «Сканирование ради отчёта». Организация проводит ежеквартальное сканирование, формирует PDF-отчёт, но не выстраивает процесс устранения. В результате одни и те же уязвимости переходят из отчёта в отчёт. Решение: привязать каждую уязвимость к тикету с ответственным и дедлайном.
2. Игнорирование контекста актива. CVE с CVSS 9.8 на изолированном тестовом сервере получает тот же приоритет, что и на публично доступном веб-сервере. Решение: использовать контекстную приоритизацию с учётом категории значимости объекта КИИ и сетевой доступности.
3. Отсутствие тестирования патчей. Установка обновлений напрямую в продуктив приводит к инцидентам доступности. Решение: создать стенд, максимально приближённый к продуктивной среде, автоматизировать регрессионные тесты.
4. «Мёртвые» активы в периметре. Забытые серверы, неучтённые виртуальные машины, shadow IT — всё это слепые зоны для сканера. Решение: внедрить непрерывную инвентаризацию ИТ-активов с автообнаружением.
5. Отсутствие метрик эффективности. Без KPI невозможно оценить зрелость VM-процесса. Решение: отслеживать MTTR (Mean Time to Remediate), процент устранения в срок, coverage rate.
Для организаций, которые только начинают выстраивать процесс управления уязвимостями, предлагаем поэтапный план внедрения.
Фаза 1. Фундамент (1–2 месяца). Проведение полной инвентаризации ИТ-активов, определение периметра сканирования, выбор и развёртывание сертифицированного сканера уязвимостей, первичное сканирование и формирование baseline.
Фаза 2. Процесс (2–3 месяца). Разработка регламентов VM (роли, ответственные, SLA, эскалация), интеграция сканера с тикет-системой, настройка автоматической приоритизации по методике ФСТЭК, внедрение процедуры тестирования и установки патчей.
Фаза 3. Автоматизация (3–4 месяца). Интеграция VM с SIEM/SOC, настройка автоматических оповещений о трендовых уязвимостях, внедрение dashboards для руководства, автоматизация патч-менеджмента для некритичных систем.
Фаза 4. Зрелость (непрерывно). Регулярные тестирования на проникновение для верификации VM-процесса, бенчмаркинг метрик, адаптация процесса под новые требования регулятора, расширение покрытия на OT-сегменты и облачные среды.
Управление уязвимостями — один из элементов комплексной системы кибербезопасности КИИ. Изолированный VM-процесс, не связанный с остальными доменами ИБ, теряет значительную часть своей эффективности.
Для субъектов КИИ, которым необходимо выстроить процесс управления уязвимостями с нуля или привести существующий процесс в соответствие с требованиями ФСТЭК и приказа № 117, рекомендуем обращаться к специализированным интеграторам. Компания «Астелс» реализует проекты по построению комплексной защиты КИИ, включая внедрение VM-платформ, разработку регламентов и интеграцию с SOC.
Ключевые выводы для CISO и ИБ-инженеров:
— С марта 2026 года VM становится обязательным процессом для значимых объектов КИИ (приказ ФСТЭК № 117).
— Используйте только сертифицированные ФСТЭК сканеры уязвимостей и придерживайтесь пятиэтапной методики.
— Патч-менеджмент должен учитывать SLA-профили активов — не каждый сервер можно перезагрузить в рабочее время.
— Интегрируйте VM с SOC, SGRC, моделью угроз и пентестами для максимальной отдачи.
— Отслеживайте метрики MTTR, SLA Compliance Rate и Asset Coverage — это язык, на котором говорит регулятор.
Нужна помощь с внедрением управления уязвимостями на объектах КИИ? Оставьте заявку — специалисты sertifikat.bz проведут бесплатную экспресс-оценку вашей инфраструктуры и предложат оптимальное VM-решение.
Медиа
Была ли полезна вам данная статья?
Кирилл Соколов
8(800) 70-70-144
info@sertifikat.bz
|
г. Екатеринбург |
г. Москва |
г. Челябинск |
г. Казань |
г. Пермь |
|
г. Волгоград |
г. Нижний Новгород |
г. Омск |
г. Новосибирск |
г. Воронеж |
|
г. Санкт-Петербург |
г. Ростов-на-Дону |
г. Самара |
г. Красноярск |
г. Уфа |
* Обязательная добровольная сертификация, классификация гостиниц, СМК, ХАССП, ISO 22000.
© ООО «Астелс» - Консалтинговая группа» 2012 - 2024
* На нашем сайте мы используем cookie для сбора информации технического характера. Продолжая использовать этот сайт, вы даете согласие на использование файлов cookies и обработку персональных данных в соответствии с Политикой конфиденциальности
Последнее обновление сайта: 17.03.2026
8(800) 70-70-144
Москва, Санкт-Петербург, Екатеринбург, Новосибирск, Нижний Новгород, Казань, Челябинск, Омск, Самара, Ростов-на-Дону, Уфа, Красноярск, Пермь, Воронеж, Волгоград