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

1. Общая архитектура процесса управления уязвимостями#

Руководство ФСТЭК от 17 мая 2023 года определяет управление уязвимостями не как разовое мероприятие, а как непрерывный циклический процесс из 5 этапов.

  graph TB
    subgraph "Цикл управления уязвимостями (п. 2.1)"
        ETAP1["<b>Этап 1</b><br/>Мониторинг и оценка<br/>применимости"]
        ETAP2["<b>Этап 2</b><br/>Оценка<br/>(скоринг)"]
        ETAP3["<b>Этап 3</b><br/>Определение методов<br/>и приоритетов"]
        ETAP4["<b>Этап 4</b><br/>Устранение"]
        ETAP5["<b>Этап 5</b><br/>Контроль<br/>устранения"]
    end
    
    ETAP1 --> ETAP2 --> ETAP3 --> ETAP4 --> ETAP5
    ETAP5 -->|"Обратная связь<br/>Улучшение процесса"| 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

Ключевой принцип: после контроля мы снова попадаем в мониторинг. Уязвимости появляются каждый день, и процесс должен работать непрерывно. Это не проект с датой завершения, а постоянная операционная деятельность.

2. Роли участников процесса#

Пункт 2.4 и Таблица 2.1 Руководства определяют матрицу ответственности. Не должно быть «коллективной безответственности» — каждый участник имеет чётко определённую роль.

  graph TB
    subgraph "Подразделение защиты информации (ИБ)"
        IB_HEAD["<b>Руководитель (О)</b><br/>Принимает решения<br/>о приоритетах<br/>и сроках"]
        IB_ANALYST["<b>Аналитик угроз (И)</b><br/>Мониторит BDU,<br/>вендорские бюллетени,<br/>Telegram-каналы"]
        IB_SCANNER["<b>Специалист по оценке (И)</b><br/>Запускает сканеры,<br/>рассчитывает V"]
        IB_ENGINEER["<b>Специалист по внедрению (И)</b><br/>Настраивает СЗИ,<br/>внедряет компенсирующие<br/>меры"]
    end
    
    subgraph "Подразделение ИТ"
        IT_HEAD["<b>Руководитель (У)</b><br/>Согласует окна<br/>обновлений"]
        IT_SPEC["<b>Специалист (И)</b><br/>Устанавливает патчи,<br/>меняет конфигурации"]
    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 ФСТЭК на наличие новых уязвимостей. В случае выявления критической уязвимости немедленно информирует Руководителя подразделения ИБ по телефону и электронной почте».

3. Этап 1: Мониторинг и оценка применимости#

  graph LR
    subgraph "Источники информации (п. 3.1)"
        INT["<b>Внутренние</b><br/>CMDB, документация,<br/>базы знаний,<br/>результаты сканирования"]
        EXT["<b>Внешние</b><br/>BDU ФСТЭК,<br/>вендорские бюллетени,<br/>CVE/NVD,<br/>Telegram-каналы"]
    end
    
    subgraph "Операции"
        OP1["Анализ информации<br/>об уязвимостях"]
        OP2["Оценка применимости<br/>к ИТ-инфраструктуре"]
        OP3["Постановка задачи<br/>на сканирование"]
    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["Получить выборку<br/>объектов, подверженных<br/>уязвимости"]
        S2["Определить уровень<br/>опасности<br/>(CVSS из BDU)"]
        S3["Определить влияние<br/>на инфраструктуру<br/>(I_infr)"]
        S4["<b>Рассчитать V</b><br/>по Методике оценки<br/>критичности<br/>(от 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["Определён уровень<br/>критичности V"]
        
        Q1 -->|"Патч доступен"| PATCH["<b>Установка обновления</b><br/>с тестированием<br/>по методике от 28.10.2022"]
        Q1 -->|"Патча нет или<br/>установка невозможна"| COMP["<b>Компенсирующие меры</b>"]
        
        COMP --> C1["Блокировка IP/порта<br/>на межсетевом экране"]
        COMP --> C2["Добавление сигнатур<br/>в СОВ"]
        COMP --> C3["Отключение<br/>уязвимой службы"]
        COMP --> C4["Усиление мониторинга<br/>событий безопасности"]
    end
    
    subgraph "Приоритеты по срокам"
        P1["🔴 Критический<br/>⏰ 24 часа"]
        P2["🟠 Высокий<br/>⏰ 7 дней"]
        P3["🟡 Средний<br/>⏰ 4 недели"]
        P4["🟢 Низкий<br/>⏰ 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["Согласование<br/>с руководством ИТ<br/>(для срочных)"]
        U2["<b>Тестирование обновления</b><br/>по методике<br/>от 28.10.2022"]
        U3["Установка<br/>в тестовом сегменте"]
        U4["Принятие решения<br/>о внедрении"]
        U5["Распространение<br/>на все уязвимые<br/>системы"]
    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["<b>Инструментальная проверка</b><br/>Повторное сканирование<br/>для подтверждения<br/>закрытия уязвимости"]
        CHECK2["<b>Экспертная проверка</b><br/>Оценка защищённости,<br/>тест на проникновение"]
    end
    
    subgraph "Если устранение неэффективно (Таблица 7.2)"
        FAIL1["Анализ причины:<br/>пропуск, ошибка,<br/>задержка"]
        FAIL2["Корректировка<br/>механизмов мониторинга<br/>или оценки"]
        FAIL3["Согласование<br/>новых сроков"]
    end
    
    CHECK1 -->|"Уязвимость<br/>не закрыта"| FAIL1
    CHECK2 -->|"Уязвимость<br/>не закрыта"| FAIL1
    FAIL1 --> FAIL2 --> FAIL3
    FAIL3 -->|"Возврат на Этап 3"| CHECK1
    
    style CHECK1 fill:#1a237e,color:#fff
    style CHECK2 fill:#283593,color:#fff

8. Что должно быть в Регламенте управления уязвимостями#

1. Роли и ответственность Матрица (О/У/И) с ФИО и должностями
2. Формула расчёта критичности V Ссылка на методику 2025
3. Сроки устранения 24 часа / 7 дней / 4 недели / 4 месяца
4. Процедура тестирования обновлений 6 тестов Т001–Т006
5. Формы заявок На срочную установку, на компенсирующие меры
6. Метрики процесса Время закрытия, количество просрочек

Как «Стратегия Ра» помогает с внедрением процесса управления уязвимостями#

Мы выполняем полный цикл работ:

• Разработка Регламента управления уязвимостями. Готовим документ с матрицей ответственности, сроками устранения и формами заявок в соответствии с Руководством ФСТЭК.
• Автоматизация мониторинга. Настраиваем интеграцию с BDU ФСТЭК, вендорскими бюллетенями и сканерами уязвимостей.
• Внедрение процесса. Распределяем роли, проводим обучение участников, настраиваем отчётность и метрики.
• Аудит текущего состояния. Проводим тестовое сканирование, рассчитываем V по методике 2025 года, приоритизируем уязвимости.

Материал подготовлен на основе лекций и практических кейсов Игоря Краева, генерального директора ООО «Стратегия Ра», апрель 2026 г.