Title here
Summary here
Построение процесса управления уязвимостями по Руководству ФСТЭК от 17.05.2023
1. Общая архитектура процесса управления уязвимостями
Руководство ФСТЭК от 17 мая 2023 года определяет управление уязвимостями не как разовое мероприятие, а как непрерывный циклический процесс из 5 этапов.
graph TB
subgraph "Цикл управления уязвимостями (п. 2.1)"
ETAP1["Этап 1
Мониторинг и оценка
применимости"] ETAP2["Этап 2
Оценка
(скоринг)"] ETAP3["Этап 3
Определение методов
и приоритетов"] ETAP4["Этап 4
Устранение"] ETAP5["Этап 5
Контроль
устранения"] end ETAP1 --> ETAP2 --> ETAP3 --> ETAP4 --> ETAP5 ETAP5 -->|"Обратная связь
Улучшение процесса"| ETAP1 style ETAP1 fill:#1a237e,color:#fff style ETAP2 fill:#283593,color:#fff style ETAP3 fill:#3949ab,color:#fff style ETAP4 fill:#5c6bc0,color:#fff style ETAP5 fill:#7986cb,color:#fff
Мониторинг и оценка
применимости"] ETAP2["Этап 2
Оценка
(скоринг)"] ETAP3["Этап 3
Определение методов
и приоритетов"] ETAP4["Этап 4
Устранение"] ETAP5["Этап 5
Контроль
устранения"] end ETAP1 --> ETAP2 --> ETAP3 --> ETAP4 --> ETAP5 ETAP5 -->|"Обратная связь
Улучшение процесса"| ETAP1 style ETAP1 fill:#1a237e,color:#fff style ETAP2 fill:#283593,color:#fff style ETAP3 fill:#3949ab,color:#fff style ETAP4 fill:#5c6bc0,color:#fff style ETAP5 fill:#7986cb,color:#fff
Ключевой принцип: после контроля мы снова попадаем в мониторинг. Уязвимости появляются каждый день, и процесс должен работать непрерывно. Это не проект с датой завершения, а постоянная операционная деятельность.
Комментарий эксперта
Игорь Краев: «Многие организации до сих пор воспринимают управление уязвимостями как “запустили сканер раз в квартал — и забыли”. Это в корне неверно. Руководство ФСТЭК требует непрерывного цикла: мониторинг BDU и внешних источников должен быть ежедневным, оценка — немедленной, устранение — в жёсткие сроки. Без автоматизации и чёткого распределения ролей этот процесс не заработает».
2. Роли участников процесса
Пункт 2.4 и Таблица 2.1 Руководства определяют матрицу ответственности. Не должно быть «коллективной безответственности» — каждый участник имеет чётко определённую роль.
graph TB
subgraph "Подразделение защиты информации (ИБ)"
IB_HEAD["Руководитель (О)
Принимает решения
о приоритетах
и сроках"] IB_ANALYST["Аналитик угроз (И)
Мониторит BDU,
вендорские бюллетени,
Telegram-каналы"] IB_SCANNER["Специалист по оценке (И)
Запускает сканеры,
рассчитывает V"] IB_ENGINEER["Специалист по внедрению (И)
Настраивает СЗИ,
внедряет компенсирующие
меры"] end subgraph "Подразделение ИТ" IT_HEAD["Руководитель (У)
Согласует окна
обновлений"] IT_SPEC["Специалист (И)
Устанавливает патчи,
меняет конфигурации"] end IB_HEAD -->|"Ставит задачу"| IT_HEAD IB_HEAD -->|"Контролирует"| IT_SPEC IB_ANALYST -->|"Передаёт информацию"| IB_SCANNER IB_SCANNER -->|"Передаёт результаты"| IB_HEAD style IB_HEAD fill:#1a237e,color:#fff style IT_HEAD fill:#c62828,color:#fff
Принимает решения
о приоритетах
и сроках"] IB_ANALYST["Аналитик угроз (И)
Мониторит BDU,
вендорские бюллетени,
Telegram-каналы"] IB_SCANNER["Специалист по оценке (И)
Запускает сканеры,
рассчитывает V"] IB_ENGINEER["Специалист по внедрению (И)
Настраивает СЗИ,
внедряет компенсирующие
меры"] end subgraph "Подразделение ИТ" IT_HEAD["Руководитель (У)
Согласует окна
обновлений"] IT_SPEC["Специалист (И)
Устанавливает патчи,
меняет конфигурации"] end IB_HEAD -->|"Ставит задачу"| IT_HEAD IB_HEAD -->|"Контролирует"| IT_SPEC IB_ANALYST -->|"Передаёт информацию"| IB_SCANNER IB_SCANNER -->|"Передаёт результаты"| IB_HEAD style IB_HEAD fill:#1a237e,color:#fff style IT_HEAD fill:#c62828,color:#fff
Условные обозначения ролей
| Обозначение | Роль | Описание |
|---|---|---|
| О | Ответственный | Принимает решения, несёт ответственность за результат |
| У | Утверждающий | Согласует действия, выделяет ресурсы |
| И | Исполнитель | Выполняет конкретные операции |
Пример формулировки для Регламента
«Аналитик угроз (ФИО) ежедневно в 9:00 проверяет BDU ФСТЭК на наличие новых уязвимостей. В случае выявления критической уязвимости немедленно информирует Руководителя подразделения ИБ по телефону и электронной почте».
Комментарий эксперта
Игорь Краев: «Матрица ответственности — это фундамент. Если аналитик пропустил уязвимость в BDU, это его персональная ответственность. Если ИТ-специалист не поставил патч в срок — его. Если Руководитель ИБ не обеспечил ресурсы — его. Чёткое распределение ролей исключает ситуацию “все виноваты — никто не отвечает”. Пропишите это в Регламенте с указанием конкретных фамилий и должностей».
3. Этап 1: Мониторинг и оценка применимости
graph LR
subgraph "Источники информации (п. 3.1)"
INT["Внутренние
CMDB, документация,
базы знаний,
результаты сканирования"] EXT["Внешние
BDU ФСТЭК,
вендорские бюллетени,
CVE/NVD,
Telegram-каналы"] end subgraph "Операции" OP1["Анализ информации
об уязвимостях"] OP2["Оценка применимости
к ИТ-инфраструктуре"] OP3["Постановка задачи
на сканирование"] end INT --> OP1 EXT --> OP1 OP1 --> OP2 --> OP3 style INT fill:#1a237e,color:#fff style EXT fill:#c62828,color:#fff
CMDB, документация,
базы знаний,
результаты сканирования"] EXT["Внешние
BDU ФСТЭК,
вендорские бюллетени,
CVE/NVD,
Telegram-каналы"] end subgraph "Операции" OP1["Анализ информации
об уязвимостях"] OP2["Оценка применимости
к ИТ-инфраструктуре"] OP3["Постановка задачи
на сканирование"] end INT --> OP1 EXT --> OP1 OP1 --> OP2 --> OP3 style INT fill:#1a237e,color:#fff style EXT fill:#c62828,color:#fff
Ключевой вопрос применимости: уязвимость применима, если уязвимый компонент (конкретная версия ПО) присутствует в ИТ-инфраструктуре. Если этого ПО нет в CMDB, уязвимость не релевантна и не обрабатывается.
Важно: не нужно бросаться патчить всё подряд. Сначала сверяемся с CMDB. Если в организации нет Cisco, то уязвимость в Cisco не применима. Это экономит огромное количество времени.
4. Этап 2: Оценка (скоринг) уязвимостей
graph TB
subgraph "Операции этапа 2 (Таблица 4.1)"
S1["Получить выборку
объектов, подверженных
уязвимости"] S2["Определить уровень
опасности
(CVSS из BDU)"] S3["Определить влияние
на инфраструктуру
(I_infr)"] S4["Рассчитать V
по Методике оценки
критичности
(от 30.06.2025)"] end S1 --> S2 --> S3 --> S4 S4 -->|"V > 8.0"| CRIT["🔴 Критический"] S4 -->|"5.0 ≤ V ≤ 8.0"| HIGH["🟠 Высокий"] S4 -->|"2.0 ≤ V < 5.0"| MED["🟡 Средний"] S4 -->|"V < 2.0"| LOW["🟢 Низкий"] style CRIT fill:#c62828,color:#fff style HIGH fill:#e65100,color:#fff style MED fill:#f57f17,color:#fff style LOW fill:#2e7d32,color:#fff
объектов, подверженных
уязвимости"] S2["Определить уровень
опасности
(CVSS из BDU)"] S3["Определить влияние
на инфраструктуру
(I_infr)"] S4["Рассчитать V
по Методике оценки
критичности
(от 30.06.2025)"] end S1 --> S2 --> S3 --> S4 S4 -->|"V > 8.0"| CRIT["🔴 Критический"] S4 -->|"5.0 ≤ V ≤ 8.0"| HIGH["🟠 Высокий"] S4 -->|"2.0 ≤ V < 5.0"| MED["🟡 Средний"] S4 -->|"V < 2.0"| LOW["🟢 Низкий"] style CRIT fill:#c62828,color:#fff style HIGH fill:#e65100,color:#fff style MED fill:#f57f17,color:#fff style LOW fill:#2e7d32,color:#fff
Пример результата:
Уязвимость CVE-2025-XXXXX в ПО «1С:Предприятие». V = 7.2 → Уровень: Высокий.
5. Этап 3: Определение методов и приоритетов
graph TB
subgraph "Матрица решений"
Q1["Определён уровень
критичности V"] Q1 -->|"Патч доступен"| PATCH["Установка обновления
с тестированием
по методике от 28.10.2022"] Q1 -->|"Патча нет или
установка невозможна"| COMP["Компенсирующие меры"] COMP --> C1["Блокировка IP/порта
на межсетевом экране"] COMP --> C2["Добавление сигнатур
в СОВ"] COMP --> C3["Отключение
уязвимой службы"] COMP --> C4["Усиление мониторинга
событий безопасности"] end subgraph "Приоритеты по срокам" P1["🔴 Критический
⏰ 24 часа"] P2["🟠 Высокий
⏰ 7 дней"] P3["🟡 Средний
⏰ 4 недели"] P4["🟢 Низкий
⏰ 4 месяца"] end PATCH --> P1 PATCH --> P2 COMP --> P1 style PATCH fill:#2e7d32,color:#fff style COMP fill:#f57f17,color:#fff
критичности V"] Q1 -->|"Патч доступен"| PATCH["Установка обновления
с тестированием
по методике от 28.10.2022"] Q1 -->|"Патча нет или
установка невозможна"| COMP["Компенсирующие меры"] COMP --> C1["Блокировка IP/порта
на межсетевом экране"] COMP --> C2["Добавление сигнатур
в СОВ"] COMP --> C3["Отключение
уязвимой службы"] COMP --> C4["Усиление мониторинга
событий безопасности"] end subgraph "Приоритеты по срокам" P1["🔴 Критический
⏰ 24 часа"] P2["🟠 Высокий
⏰ 7 дней"] P3["🟡 Средний
⏰ 4 недели"] P4["🟢 Низкий
⏰ 4 месяца"] end PATCH --> P1 PATCH --> P2 COMP --> P1 style PATCH fill:#2e7d32,color:#fff style COMP fill:#f57f17,color:#fff
Срочная установка (п. 5.1): для критических уязвимостей допускается установка обновлений минуя плановые окна. Это должно быть прописано в Регламенте: кто имеет право объявить срочную установку и как это оформляется.
6. Этап 4: Устранение
graph TB
subgraph "Процесс установки обновления (Таблица 6.1)"
U1["Согласование
с руководством ИТ
(для срочных)"] U2["Тестирование обновления
по методике
от 28.10.2022"] U3["Установка
в тестовом сегменте"] U4["Принятие решения
о внедрении"] U5["Распространение
на все уязвимые
системы"] end U1 --> U2 --> U3 --> U4 --> U5 style U2 fill:#c62828,color:#fff style U5 fill:#2e7d32,color:#fff
с руководством ИТ
(для срочных)"] U2["Тестирование обновления
по методике
от 28.10.2022"] U3["Установка
в тестовом сегменте"] U4["Принятие решения
о внедрении"] U5["Распространение
на все уязвимые
системы"] end U1 --> U2 --> U3 --> U4 --> U5 style U2 fill:#c62828,color:#fff style U5 fill:#2e7d32,color:#fff
Важное правило: тестирование обновления обязательно, если его результатов нет в БДУ ФСТЭК (п. 6.2). Нельзя просто «поставить патч и надеяться на лучшее» — требуется полноценный цикл из 6 тестов (Т001–Т006) по методике от 28.10.2022.
7. Этап 5: Контроль устранения
graph TB
subgraph "Методы контроля (Таблица 7.1)"
CHECK1["Инструментальная проверка
Повторное сканирование
для подтверждения
закрытия уязвимости"] CHECK2["Экспертная проверка
Оценка защищённости,
тест на проникновение"] end subgraph "Если устранение неэффективно (Таблица 7.2)" FAIL1["Анализ причины:
пропуск, ошибка,
задержка"] FAIL2["Корректировка
механизмов мониторинга
или оценки"] FAIL3["Согласование
новых сроков"] end CHECK1 -->|"Уязвимость
не закрыта"| FAIL1 CHECK2 -->|"Уязвимость
не закрыта"| FAIL1 FAIL1 --> FAIL2 --> FAIL3 FAIL3 -->|"Возврат на Этап 3"| CHECK1 style CHECK1 fill:#1a237e,color:#fff style CHECK2 fill:#283593,color:#fff
Повторное сканирование
для подтверждения
закрытия уязвимости"] CHECK2["Экспертная проверка
Оценка защищённости,
тест на проникновение"] end subgraph "Если устранение неэффективно (Таблица 7.2)" FAIL1["Анализ причины:
пропуск, ошибка,
задержка"] FAIL2["Корректировка
механизмов мониторинга
или оценки"] FAIL3["Согласование
новых сроков"] end CHECK1 -->|"Уязвимость
не закрыта"| FAIL1 CHECK2 -->|"Уязвимость
не закрыта"| FAIL1 FAIL1 --> FAIL2 --> FAIL3 FAIL3 -->|"Возврат на Этап 3"| CHECK1 style CHECK1 fill:#1a237e,color:#fff style CHECK2 fill:#283593,color:#fff
Комментарий эксперта
Игорь Краев: «Этап контроля — это не просто “проверить, встал ли патч”. Это анализ причин отклонений: почему не успели за 24 часа? Может, нужно купить более быстрый сканер или расширить штат? Метрики процесса — время закрытия уязвимостей и количество просрочек — должны регулярно докладываться руководству. Это замкнутый цикл непрерывного улучшения».
8. Что должно быть в Регламенте управления уязвимостями
- Роли и ответственность Матрица (О/У/И) с ФИО и должностями
- Формула расчёта критичности V Ссылка на методику 2025
- Сроки устранения 24 часа / 7 дней / 4 недели / 4 месяца
- Процедура тестирования обновлений 6 тестов Т001–Т006
- Формы заявок На срочную установку, на компенсирующие меры
- Метрики процесса Время закрытия, количество просрочек
Как «Стратегия Ра» помогает с внедрением процесса управления уязвимостями
Мы выполняем полный цикл работ:
- Разработка Регламента управления уязвимостями. Готовим документ с матрицей ответственности, сроками устранения и формами заявок в соответствии с Руководством ФСТЭК.
- Автоматизация мониторинга. Настраиваем интеграцию с BDU ФСТЭК, вендорскими бюллетенями и сканерами уязвимостей.
- Внедрение процесса. Распределяем роли, проводим обучение участников, настраиваем отчётность и метрики.
- Аудит текущего состояния. Проводим тестовое сканирование, рассчитываем V по методике 2025 года, приоритизируем уязвимости.
Приглашаем к диалогу
Если вам нужно выстроить процесс управления уязвимостями «с нуля» или привести существующий в соответствие с Руководством ФСТЭК, — приглашаем на бесплатную консультацию. Мы разберём вашу ситуацию и предложим дорожную карту. Напишите нам, и мы договоримся о встрече.
Материал подготовлен на основе лекций и практических кейсов Игоря Краева, генерального директора ООО «Стратегия Ра», апрель 2026 г.