Методический документ ФСТЭК от 12.04.2026: полный показный разбор новой методики оценки защищённости

Введение. Почему Методика 2026 года — это смена парадигмы#

Методический документ ФСТЭК от 12 апреля 2026 года отменяет старую методичку 2014 года и в корне меняет подход к оценке защищённости. Ниже сравнительная таблица.

  graph TB
    OLD["Методика 2014<br/>«Меры защиты в ГИС»<br/>Статический подход"]
    NEW["Методика 2026<br/>«Состав и содержание...»<br/>Процессный подход"]
    
    OLD -->|"Отменена"| NEW
    
    NEW --> P2["Раздел II<br/>Факторы, влияющие<br/>на состояние защиты"]
    NEW --> P3["Раздел III<br/>19 мероприятий<br/>(процессов)"]
    NEW --> P4["Раздел IV<br/>Меры защиты<br/>(обновлённый состав)"]
    
    style OLD fill:#9e9e9e,color:#fff
    style NEW fill:#c62828,color:#fff
    style P2 fill:#1a237e,color:#fff
    style P3 fill:#283593,color:#fff
    style P4 fill:#3949ab,color:#fff

Раздел II. Факторы, влияющие на состояние защиты информации#

Раздел II формирует теоретическую базу для оценки. Проверяющие будут смотреть на вашу систему через призму этих факторов.

  graph TB
    subgraph "Факторы, влияющие на защищённость (Раздел II)"
        F1["2.11 Поверхность<br/>компьютерных атак"]
        F2["2.14 Зарубежная ЭКБ<br/>и ПО"]
        F3["2.15 Доверие при<br/>взаимодействии"]
    end
    
    F1 -->|"Анализ всех<br/>доступных интерфейсов"| ACTION1["Составить карту<br/>внешнего периметра"]
    F2 -->|"Приоритет<br/>отечественных решений"| ACTION2["Обосновать использование<br/>зарубежного ПО/ЭКБ"]
    F3 -->|"Строгая аутентификация<br/>и сертификаты"| ACTION3["Внедрить PKI<br/>для межсистемного обмена"]
    
    style F1 fill:#c62828,color:#fff
    style F2 fill:#e65100,color:#fff
    style F3 fill:#f57f17,color:#fff

Ключевые факторы:

Раздел III. Мероприятия (Процессы) — сердце Методики#

Это центральный раздел документа. Впервые вводятся 19 сквозных процессов, которые организация обязана внедрить, документировать и исполнять.

  graph LR
    subgraph "19 процессов Методики 2026"
        G1["Выявление угроз"]
        G2["Управление активами"]
        G3["Управление доступом"]
        G4["Мониторинг и реагирование"]
        G5["Разработка и кадры"]
        G6["Контроль"]
    end
    
    G1 --> P1["ВУ: Выявление и оценка<br/>угроз безопасности"]
    
    G2 --> P2["КК: Контроль конфигураций"]
    G2 --> P3["КУ: Управление уязвимостями"]
    G2 --> P4["КО: Управление обновлениями"]
    
    G3 --> P5["ОД: Обработка информации<br/>ограниченного доступа"]
    G3 --> P6["ЗУ: Защита конечных устройств"]
    G3 --> P7["МУ: Защита мобильных устройств"]
    G3 --> P8["УД: Защита удалённого доступа"]
    G3 --> P9["БД: Защита беспроводного доступа"]
    G3 --> P10["ПД: Защита привилегированного<br/>доступа"]
    
    G4 --> P11["МБ: Мониторинг ИБ"]
    G4 --> P12["НФ: Непрерывность функционирования"]
    G4 --> P13["ОО: Защита от DDoS"]
    
    G5 --> P14["БР: Безопасная разработка ПО"]
    G5 --> P15["УЗ: Повышение уровня знаний<br/>пользователей"]
    G5 --> P16["ЗП: Защита при взаимодействии<br/>с подрядчиками"]
    
    G6 --> P17["ПК: Контроль уровня<br/>защищённости"]
    
    style G1 fill:#1a237e,color:#fff
    style G6 fill:#c62828,color:#fff

3.1. Процесс ВУ — Выявление и оценка угроз безопасности#

  graph LR
    subgraph "Процесс ВУ"
        VU1["Мониторинг BDU ФСТЭК<br/>и внешних источников"]
        VU2["Анализ применимости<br/>угроз к своим системам"]
        VU3["Приоритизация<br/>по критичности"]
        VU4["Уведомление<br/>подразделений"]
        VU5["Блокирование/<br/>нейтрализация"]
    end
    
    VU1 --> VU2 --> VU3 --> VU4 --> VU5
    
    style VU1 fill:#1a237e,color:#fff
    style VU5 fill:#c62828,color:#fff

Что изменилось: В методике 2014 года был просто пункт о выявлении угроз. Теперь это полноценный процесс с непрерывным циклом. Требуется не разовая модель угроз, а постоянный мониторинг и реагирование на новые угрозы из BDU ФСТЭК.

3.2. Процесс КУ — Управление уязвимостями#

Самый жёсткий процесс с точки зрения KPI.

  graph TB
    subgraph "Процесс КУ: Сроки устранения"
        KU1["Выявление уязвимости"]
        KU1 --> KU2["Оценка критичности"]
        
        KU2 -->|"Критический уровень"| KU3["⏰ 24 часа<br/>на устранение"]
        KU2 -->|"Высокий уровень"| KU4["⏰ 7 календарных дней<br/>на устранение"]
        KU2 -->|"Средний/Низкий"| KU5["Срок определяет<br/>организация"]
        
        KU3 --> KU6["Контроль<br/>устранения"]
        KU4 --> KU6
        KU5 --> KU6
        
        KU6 --> KU7["Отчётность<br/>во ФСТЭК<br/>(5 рабочих дней)"]
    end
    
    style KU3 fill:#c62828,color:#fff
    style KU4 fill:#e65100,color:#fff
    style KU5 fill:#f57f17,color:#fff

Что изменилось: В методике 2014 года был просто пункт «Выявление и анализ уязвимостей». Теперь это полноценный процесс с жёсткими KPI. Если уязвимости нет в BDU ФСТЭК — вы обязаны сообщить о ней в течение 5 рабочих дней.

3.3. Процесс ОД — Обработка информации ограниченного доступа#

  graph LR
    subgraph "Процесс ОД"
        OD1["Определение<br/>носителей ДСП"]
        OD2["Контроль<br/>доступа"]
        OD3["Регистрация<br/>всех фактов доступа"]
        OD4["Контроль<br/>передачи"]
        OD5["Уведомление руководства<br/>о неправомерном распространении"]
    end
    
    OD1 --> OD2 --> OD3 --> OD4 --> OD5
    
    style OD1 fill:#1a237e,color:#fff
    style OD5 fill:#c62828,color:#fff

3.4. Процесс БР — Безопасная разработка ПО#

  graph TB
    subgraph "Процесс БР: Цикл безопасной разработки"
        BR1["Статический анализ<br/>исходного кода"]
        BR2["Фаззинг-тестирование"]
        BR3["Динамический анализ<br/>(для 1 категории)"]
        BR4["Контроль цепочек<br/>поставки"]
        BR5["Безопасная сборка<br/>и тестирование"]
    end
    
    BR1 --> BR2 --> BR3 --> BR4 --> BR5
    
    style BR1 fill:#1a237e,color:#fff
    style BR3 fill:#c62828,color:#fff

3.5. Процесс ЗП — Защита при взаимодействии с подрядчиками#

  graph LR
    subgraph "Процесс ЗП"
        ZP1["Установление требований<br/>по ИБ к подрядчику"]
        ZP2["Контроль доступа<br/>подрядчиков"]
        ZP3["Изоляция сред<br/>разработки от прома"]
        ZP4["Запрет копирования<br/>информации"]
    end
    
    ZP1 --> ZP2 --> ZP3 --> ZP4
    
    style ZP1 fill:#1a237e,color:#fff
    style ZP4 fill:#c62828,color:#fff

Сводная таблица по срокам критических процессов#

Раздел IV. Меры защиты — обновлённый состав#

4.1. Усиление аутентификации (ИАФ)#

  graph TB
    subgraph "Требования к паролям (ИАФ.3)"
        PASS1["Длина: не менее 12 символов<br/>(было 6–8)"]
        PASS2["Алфавит: не менее 70 символов"]
        PASS3["Смена: не более 90 дней"]
        PASS4["Запрет повторного использования"]
    end
    
    subgraph "Строгая аутентификация (ИАФ.3 п. 10)"
        STRONG1["Двухфакторная аутентификация<br/>для привилегированных пользователей"]
        STRONG2["Использование сертификатов ГОСТ"]
        STRONG3["Корпоративный Удостоверяющий центр"]
    end
    
    PASS1 --> PASS2 --> PASS3 --> PASS4
    STRONG1 --> STRONG2 --> STRONG3
    
    style PASS1 fill:#c62828,color:#fff
    style STRONG1 fill:#c62828,color:#fff

4.2. Новые меры защиты#

  graph TB
    subgraph "Новые разделы мер защиты (Раздел IV)"
        ZKO["ЗКО<br/>Контейнерные среды<br/>и оркестрация"]
        ZAI["ИИ<br/>Искусственный интеллект"]
        ZAPI["ЗПИ<br/>Программные интерфейсы<br/>(API)"]
        ZIV["ЗИВ<br/>Интернет вещей<br/>(IoT)"]
        ZVT["ЗВТ<br/>Веб-технологии"]
    end
    
    ZKO -->|"Контроль целостности<br/>образов, оркестрация"| ACTION_ZKO["Внедрить подписание<br/>образов контейнеров"]
    ZAI -->|"Защита наборов данных,<br/>фильтрация ответов"| ACTION_ZAI["Контролировать<br/>промпты и ответы"]
    ZAPI -->|"Аутентификация,<br/>ограничение частоты"| ACTION_ZAPI["Внедрить API Gateway<br/>с валидацией схем"]
    ZIV -->|"Сегментация,<br/>защита прошивок"| ACTION_ZIV["Изолировать IoT<br/>в отдельный VLAN"]
    ZVT -->|"Защита от веб-атак,<br/>безопасные заголовки"| ACTION_ZVT["Внедрить WAF<br/>и CSP-заголовки"]
    
    style ZKO fill:#1a237e,color:#fff
    style ZAI fill:#283593,color:#fff
    style ZAPI fill:#3949ab,color:#fff
    style ZIV fill:#5c6bc0,color:#fff
    style ZVT fill:#7986cb,color:#fff

План перехода на Методику 2026#

1. Актуализировать документацию Разработать 19 регламентов по новым процессам
2. Настроить процессы Внедрить автоматизированные системы управления
3. Усилить аутентификацию Пароли 12 символов, УЦ для администраторов
4. Пересмотреть архитектуру Анализ поверхности атак, обоснование зарубежного ПО
5. Обучить персонал Обучение по новым требованиям
6. Подготовиться к расчёту Kзн/Пзн Начать сбор метрик для оценки зрелости

Приоритеты внедрения:

1. Критический приоритет: Управление уязвимостями (КУ) и Управление обновлениями (КО) — это то, что ФСТЭК будет проверять в первую очередь.
2. Высокий приоритет: Контроль конфигураций (КК) и Мониторинг ИБ (МБ).
3. Средний приоритет: Защита удалённого доступа (УД), защита подрядчиков (ЗП), обучение (УЗ).

Как «Стратегия Ра» помогает с переходом на Методику 2026#

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

• Аудит текущего состояния. Оцениваем зрелость процессов по 19 направлениям, выявляем критические несоответствия.
• Разработка документации. Готовим полный комплект регламентов по Разделу III — от управления уязвимостями до защиты подрядчиков.
• Внедрение автоматизации. Настраиваем сканеры уязвимостей, системы patch management, SIEM для мониторинга.
• Расчёт Kзн и Пзн. Собираем метрики, готовим отчётность для ФСТЭК.
• Обучение персонала. Проводим семинары и практические занятия по новым процессам.

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