Title here
Summary here
Методический документ ФСТЭК от 12.04.2026: полный показный разбор новой методики оценки защищённости
Введение. Почему Методика 2026 года — это смена парадигмы
Методический документ ФСТЭК от 12 апреля 2026 года отменяет старую методичку 2014 года и в корне меняет подход к оценке защищённости. Ниже сравнительная таблица.
| Критерий | Методика 2014 | Методика 2026 |
|---|---|---|
| Основа | Приказ № 17 | Приказы № 17, 117, 239, 235 |
| Фокус | Меры защиты (техника) | Мероприятия (процессы) + Меры |
| Классы | К1, К2, К3, К4 | К1, К2, К3 (К4 исключён) |
| Цель | Аттестация (получить документ) | Зрелость процессов (Kзн, Пзн) + Аттестация |
| Периодичность контроля | Раз в 3 года | Kзн — раз в 6 мес., Пзн — раз в 2 года |
graph TB
OLD["Методика 2014
«Меры защиты в ГИС»
Статический подход"] NEW["Методика 2026
«Состав и содержание...»
Процессный подход"] OLD -->|"Отменена"| NEW NEW --> P2["Раздел II
Факторы, влияющие
на состояние защиты"] NEW --> P3["Раздел III
19 мероприятий
(процессов)"] NEW --> P4["Раздел IV
Меры защиты
(обновлённый состав)"] 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
«Меры защиты в ГИС»
Статический подход"] NEW["Методика 2026
«Состав и содержание...»
Процессный подход"] OLD -->|"Отменена"| NEW NEW --> P2["Раздел II
Факторы, влияющие
на состояние защиты"] NEW --> P3["Раздел III
19 мероприятий
(процессов)"] NEW --> P4["Раздел IV
Меры защиты
(обновлённый состав)"] 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 “Факторы” и Раздела III “Мероприятия”. Это означает, что ФСТЭК теперь проверяет не только наличие средств защиты, но и то, как выстроены процессы управления ИБ. Если раньше можно было “нарисовать” инструкцию, то теперь нужно доказать, что процесс работает: есть ответственные, есть журналы, есть автоматизация. Методика 2026 — это ваш настольный документ на ближайшие годы».
Раздел II. Факторы, влияющие на состояние защиты информации
Раздел II формирует теоретическую базу для оценки. Проверяющие будут смотреть на вашу систему через призму этих факторов.
graph TB
subgraph "Факторы, влияющие на защищённость (Раздел II)"
F1["2.11 Поверхность
компьютерных атак"] F2["2.14 Зарубежная ЭКБ
и ПО"] F3["2.15 Доверие при
взаимодействии"] end F1 -->|"Анализ всех
доступных интерфейсов"| ACTION1["Составить карту
внешнего периметра"] F2 -->|"Приоритет
отечественных решений"| ACTION2["Обосновать использование
зарубежного ПО/ЭКБ"] F3 -->|"Строгая аутентификация
и сертификаты"| ACTION3["Внедрить PKI
для межсистемного обмена"] style F1 fill:#c62828,color:#fff style F2 fill:#e65100,color:#fff style F3 fill:#f57f17,color:#fff
компьютерных атак"] F2["2.14 Зарубежная ЭКБ
и ПО"] F3["2.15 Доверие при
взаимодействии"] end F1 -->|"Анализ всех
доступных интерфейсов"| ACTION1["Составить карту
внешнего периметра"] F2 -->|"Приоритет
отечественных решений"| ACTION2["Обосновать использование
зарубежного ПО/ЭКБ"] F3 -->|"Строгая аутентификация
и сертификаты"| ACTION3["Внедрить PKI
для межсистемного обмена"] style F1 fill:#c62828,color:#fff style F2 fill:#e65100,color:#fff style F3 fill:#f57f17,color:#fff
Ключевые факторы:
| Фактор | Суть | Действие |
|---|---|---|
| Поверхность атак (2.11) | Анализ всех доступных извне интерфейсов, а не просто список уязвимостей | Составить карту внешнего периметра и векторов проникновения |
| Зарубежная ЭКБ и ПО (2.14) | Официальное признание угрозы недокументированных возможностей | Приоритет отечественных решений; обоснование для каждого зарубежного компонента |
| Доверие при взаимодействии (2.15) | Обязательная строгая аутентификация и проверка сертификатов | Внедрение PKI-инфраструктуры для межсистемного обмена |
Комментарий эксперта
Игорь Краев: «Раздел II — это не просто теория. Это “линза”, через которую инспектор ФСТЭК будет рассматривать вашу систему. Если у вас стоит зарубежный межсетевой экран и нет документально зафиксированного обоснования, почему нельзя поставить российский, — это зафиксируют как несоответствие современным угрозам. Даже если формально класс СЗИ соблюдён. Уже сейчас готовьте обоснования для каждого иностранного компонента в вашей инфраструктуре».
Раздел III. Мероприятия (Процессы) — сердце Методики
Это центральный раздел документа. Впервые вводятся 19 сквозных процессов, которые организация обязана внедрить, документировать и исполнять.
graph LR
subgraph "19 процессов Методики 2026"
G1["Выявление угроз"]
G2["Управление активами"]
G3["Управление доступом"]
G4["Мониторинг и реагирование"]
G5["Разработка и кадры"]
G6["Контроль"]
end
G1 --> P1["ВУ: Выявление и оценка
угроз безопасности"] G2 --> P2["КК: Контроль конфигураций"] G2 --> P3["КУ: Управление уязвимостями"] G2 --> P4["КО: Управление обновлениями"] G3 --> P5["ОД: Обработка информации
ограниченного доступа"] G3 --> P6["ЗУ: Защита конечных устройств"] G3 --> P7["МУ: Защита мобильных устройств"] G3 --> P8["УД: Защита удалённого доступа"] G3 --> P9["БД: Защита беспроводного доступа"] G3 --> P10["ПД: Защита привилегированного
доступа"] G4 --> P11["МБ: Мониторинг ИБ"] G4 --> P12["НФ: Непрерывность функционирования"] G4 --> P13["ОО: Защита от DDoS"] G5 --> P14["БР: Безопасная разработка ПО"] G5 --> P15["УЗ: Повышение уровня знаний
пользователей"] G5 --> P16["ЗП: Защита при взаимодействии
с подрядчиками"] G6 --> P17["ПК: Контроль уровня
защищённости"] style G1 fill:#1a237e,color:#fff style G6 fill:#c62828,color:#fff
угроз безопасности"] G2 --> P2["КК: Контроль конфигураций"] G2 --> P3["КУ: Управление уязвимостями"] G2 --> P4["КО: Управление обновлениями"] G3 --> P5["ОД: Обработка информации
ограниченного доступа"] G3 --> P6["ЗУ: Защита конечных устройств"] G3 --> P7["МУ: Защита мобильных устройств"] G3 --> P8["УД: Защита удалённого доступа"] G3 --> P9["БД: Защита беспроводного доступа"] G3 --> P10["ПД: Защита привилегированного
доступа"] G4 --> P11["МБ: Мониторинг ИБ"] G4 --> P12["НФ: Непрерывность функционирования"] G4 --> P13["ОО: Защита от DDoS"] G5 --> P14["БР: Безопасная разработка ПО"] G5 --> P15["УЗ: Повышение уровня знаний
пользователей"] G5 --> P16["ЗП: Защита при взаимодействии
с подрядчиками"] G6 --> P17["ПК: Контроль уровня
защищённости"] style G1 fill:#1a237e,color:#fff style G6 fill:#c62828,color:#fff
3.1. Процесс ВУ — Выявление и оценка угроз безопасности
graph LR
subgraph "Процесс ВУ"
VU1["Мониторинг BDU ФСТЭК
и внешних источников"] VU2["Анализ применимости
угроз к своим системам"] VU3["Приоритизация
по критичности"] VU4["Уведомление
подразделений"] VU5["Блокирование/
нейтрализация"] end VU1 --> VU2 --> VU3 --> VU4 --> VU5 style VU1 fill:#1a237e,color:#fff style VU5 fill:#c62828,color:#fff
и внешних источников"] VU2["Анализ применимости
угроз к своим системам"] VU3["Приоритизация
по критичности"] VU4["Уведомление
подразделений"] VU5["Блокирование/
нейтрализация"] end VU1 --> VU2 --> VU3 --> VU4 --> VU5 style VU1 fill:#1a237e,color:#fff style VU5 fill:#c62828,color:#fff
Что изменилось: В методике 2014 года был просто пункт о выявлении угроз. Теперь это полноценный процесс с непрерывным циклом. Требуется не разовая модель угроз, а постоянный мониторинг и реагирование на новые угрозы из BDU ФСТЭК.
Комментарий эксперта
Игорь Краев: «Модель угроз перестала быть статичным документом. Теперь вы обязаны непрерывно отслеживать BDU и внешние источники, анализировать применимость новых угроз и принимать меры. Рекомендую настроить автоматическую выгрузку из BDU и интеграцию с вашей системой управления уязвимостями. Это сэкономит время и обеспечит соответствие».
3.2. Процесс КУ — Управление уязвимостями
Самый жёсткий процесс с точки зрения KPI.
graph TB
subgraph "Процесс КУ: Сроки устранения"
KU1["Выявление уязвимости"]
KU1 --> KU2["Оценка критичности"]
KU2 -->|"Критический уровень"| KU3["⏰ 24 часа
на устранение"] KU2 -->|"Высокий уровень"| KU4["⏰ 7 календарных дней
на устранение"] KU2 -->|"Средний/Низкий"| KU5["Срок определяет
организация"] KU3 --> KU6["Контроль
устранения"] KU4 --> KU6 KU5 --> KU6 KU6 --> KU7["Отчётность
во ФСТЭК
(5 рабочих дней)"] end style KU3 fill:#c62828,color:#fff style KU4 fill:#e65100,color:#fff style KU5 fill:#f57f17,color:#fff
на устранение"] KU2 -->|"Высокий уровень"| KU4["⏰ 7 календарных дней
на устранение"] KU2 -->|"Средний/Низкий"| KU5["Срок определяет
организация"] KU3 --> KU6["Контроль
устранения"] KU4 --> KU6 KU5 --> KU6 KU6 --> KU7["Отчётность
во ФСТЭК
(5 рабочих дней)"] end style KU3 fill:#c62828,color:#fff style KU4 fill:#e65100,color:#fff style KU5 fill:#f57f17,color:#fff
Что изменилось: В методике 2014 года был просто пункт «Выявление и анализ уязвимостей». Теперь это полноценный процесс с жёсткими KPI. Если уязвимости нет в BDU ФСТЭК — вы обязаны сообщить о ней в течение 5 рабочих дней.
Комментарий эксперта
Игорь Краев: «24 часа на устранение критической уязвимости — это практически “пожарная тревога”. Это означает, что отдел ИБ должен иметь право экстренно ставить обновления в продуктовую среду без длительных согласований с бизнесом. Пропишите это право в Регламенте управления уязвимостями. Без автоматизированного сканера уязвимостей и системы patch management выполнить эти сроки нереально».
3.3. Процесс ОД — Обработка информации ограниченного доступа
graph LR
subgraph "Процесс ОД"
OD1["Определение
носителей ДСП"] OD2["Контроль
доступа"] OD3["Регистрация
всех фактов доступа"] OD4["Контроль
передачи"] OD5["Уведомление руководства
о неправомерном распространении"] end OD1 --> OD2 --> OD3 --> OD4 --> OD5 style OD1 fill:#1a237e,color:#fff style OD5 fill:#c62828,color:#fff
носителей ДСП"] OD2["Контроль
доступа"] OD3["Регистрация
всех фактов доступа"] OD4["Контроль
передачи"] OD5["Уведомление руководства
о неправомерном распространении"] end OD1 --> OD2 --> OD3 --> OD4 --> OD5 style OD1 fill:#1a237e,color:#fff style OD5 fill:#c62828,color:#fff
Комментарий эксперта
Игорь Краев: «Процесс ОД требует регистрации всех фактов доступа к носителям ДСП. Это означает, что система должна логировать, кто, когда и к какому файлу с пометкой “Для служебного пользования” обращался. DLP-система или специализированное ПО для работы с ДСП становится обязательным элементом инфраструктуры».
3.4. Процесс БР — Безопасная разработка ПО
graph TB
subgraph "Процесс БР: Цикл безопасной разработки"
BR1["Статический анализ
исходного кода"] BR2["Фаззинг-тестирование"] BR3["Динамический анализ
(для 1 категории)"] BR4["Контроль цепочек
поставки"] BR5["Безопасная сборка
и тестирование"] end BR1 --> BR2 --> BR3 --> BR4 --> BR5 style BR1 fill:#1a237e,color:#fff style BR3 fill:#c62828,color:#fff
исходного кода"] BR2["Фаззинг-тестирование"] BR3["Динамический анализ
(для 1 категории)"] BR4["Контроль цепочек
поставки"] BR5["Безопасная сборка
и тестирование"] end BR1 --> BR2 --> BR3 --> BR4 --> BR5 style BR1 fill:#1a237e,color:#fff style BR3 fill:#c62828,color:#fff
Комментарий эксперта
Игорь Краев: «Если ваша организация пишет скрипты для контроллеров, макросы для SCADA или дорабатывает ПО — процесс БР обязателен для вас. Нельзя просто “написать и запустить”. Нужен цикл безопасной разработки: статический анализ, фаззинг-тестирование, контроль библиотек. Для небольших команд рекомендую внедрить GitLab CI/CD с встроенными анализаторами — это покрывает базовые требования».
3.5. Процесс ЗП — Защита при взаимодействии с подрядчиками
graph LR
subgraph "Процесс ЗП"
ZP1["Установление требований
по ИБ к подрядчику"] ZP2["Контроль доступа
подрядчиков"] ZP3["Изоляция сред
разработки от прома"] ZP4["Запрет копирования
информации"] end ZP1 --> ZP2 --> ZP3 --> ZP4 style ZP1 fill:#1a237e,color:#fff style ZP4 fill:#c62828,color:#fff
по ИБ к подрядчику"] ZP2["Контроль доступа
подрядчиков"] ZP3["Изоляция сред
разработки от прома"] ZP4["Запрет копирования
информации"] end ZP1 --> ZP2 --> ZP3 --> ZP4 style ZP1 fill:#1a237e,color:#fff style ZP4 fill:#c62828,color:#fff
Комментарий эксперта
Игорь Краев: «Разработка ПО подрядчиками непосредственно в промышленной среде запрещена (п. 3.13 Методики). Для этого должны быть выделены изолированные стенды. Если у вас подрядчик правит код 1С “на лету” в рабочей базе — это прямое нарушение. Разворачивайте отдельные среды разработки и тестирования».
Сводная таблица по срокам критических процессов
| Процесс | Ключевой KPI | Срок |
|---|---|---|
| КУ | Устранение критических уязвимостей | 24 часа |
| КУ | Устранение высоких уязвимостей | 7 дней |
| КУ | Уведомление ФСТЭК о новой уязвимости | 5 рабочих дней |
| ВУ | Информирование руководителя о несоответствии Kзн/Пзн | 3 дня |
| ВУ | Направление результатов Kзн во ФСТЭК | 5 рабочих дней |
| МБ | Разработка отчёта о мониторинге | По регламенту |
| НФ | Проверка восстановления значимых функций | Раз в 2 года |
| ПК | Контроль уровня защищённости | Раз в 3 года |
Раздел IV. Меры защиты — обновлённый состав
4.1. Усиление аутентификации (ИАФ)
graph TB
subgraph "Требования к паролям (ИАФ.3)"
PASS1["Длина: не менее 12 символов
(было 6–8)"] PASS2["Алфавит: не менее 70 символов"] PASS3["Смена: не более 90 дней"] PASS4["Запрет повторного использования"] end subgraph "Строгая аутентификация (ИАФ.3 п. 10)" STRONG1["Двухфакторная аутентификация
для привилегированных пользователей"] STRONG2["Использование сертификатов ГОСТ"] STRONG3["Корпоративный Удостоверяющий центр"] end PASS1 --> PASS2 --> PASS3 --> PASS4 STRONG1 --> STRONG2 --> STRONG3 style PASS1 fill:#c62828,color:#fff style STRONG1 fill:#c62828,color:#fff
(было 6–8)"] PASS2["Алфавит: не менее 70 символов"] PASS3["Смена: не более 90 дней"] PASS4["Запрет повторного использования"] end subgraph "Строгая аутентификация (ИАФ.3 п. 10)" STRONG1["Двухфакторная аутентификация
для привилегированных пользователей"] STRONG2["Использование сертификатов ГОСТ"] STRONG3["Корпоративный Удостоверяющий центр"] end PASS1 --> PASS2 --> PASS3 --> PASS4 STRONG1 --> STRONG2 --> STRONG3 style PASS1 fill:#c62828,color:#fff style STRONG1 fill:#c62828,color:#fff
Комментарий эксперта
Игорь Краев: «Требование 12 символов и строгой двухфакторной аутентификации с сертификатами ГОСТ для администраторов — это “прощай, одноразовые пароли по SMS”. Нужно внедрять PKI-инфраструктуру и корпоративный УЦ. Для небольших организаций это затратно, но для К1 и К2 — обязательно. Начните с пилотного проекта на критичных системах».
4.2. Новые меры защиты
graph TB
subgraph "Новые разделы мер защиты (Раздел IV)"
ZKO["ЗКО
Контейнерные среды
и оркестрация"] ZAI["ИИ
Искусственный интеллект"] ZAPI["ЗПИ
Программные интерфейсы
(API)"] ZIV["ЗИВ
Интернет вещей
(IoT)"] ZVT["ЗВТ
Веб-технологии"] end ZKO -->|"Контроль целостности
образов, оркестрация"| ACTION_ZKO["Внедрить подписание
образов контейнеров"] ZAI -->|"Защита наборов данных,
фильтрация ответов"| ACTION_ZAI["Контролировать
промпты и ответы"] ZAPI -->|"Аутентификация,
ограничение частоты"| ACTION_ZAPI["Внедрить API Gateway
с валидацией схем"] ZIV -->|"Сегментация,
защита прошивок"| ACTION_ZIV["Изолировать IoT
в отдельный VLAN"] ZVT -->|"Защита от веб-атак,
безопасные заголовки"| ACTION_ZVT["Внедрить WAF
и 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
Контейнерные среды
и оркестрация"] ZAI["ИИ
Искусственный интеллект"] ZAPI["ЗПИ
Программные интерфейсы
(API)"] ZIV["ЗИВ
Интернет вещей
(IoT)"] ZVT["ЗВТ
Веб-технологии"] end ZKO -->|"Контроль целостности
образов, оркестрация"| ACTION_ZKO["Внедрить подписание
образов контейнеров"] ZAI -->|"Защита наборов данных,
фильтрация ответов"| ACTION_ZAI["Контролировать
промпты и ответы"] ZAPI -->|"Аутентификация,
ограничение частоты"| ACTION_ZAPI["Внедрить API Gateway
с валидацией схем"] ZIV -->|"Сегментация,
защита прошивок"| ACTION_ZIV["Изолировать IoT
в отдельный VLAN"] ZVT -->|"Защита от веб-атак,
безопасные заголовки"| ACTION_ZVT["Внедрить WAF
и 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
Комментарий эксперта
Игорь Краев: «Впервые в методичке ФСТЭК появились требования к Docker/Kubernetes (ЗКО) и Искусственному Интеллекту (ИИ). Если ваша организация использует контейнеры или внедряет ИИ-сервисы — вы обязаны выполнять эти разделы. Обратите внимание на запрет обучения ИИ на данных с пометкой ДСП — это критично для госорганов. Также впервые детализированы API (ЗПИ) и Интернет вещей (ЗИВ)».
План перехода на Методику 2026
- Актуализировать документацию Разработать 19 регламентов по новым процессам
- Настроить процессы Внедрить автоматизированные системы управления
- Усилить аутентификацию Пароли 12 символов, УЦ для администраторов
- Пересмотреть архитектуру Анализ поверхности атак, обоснование зарубежного ПО
- Обучить персонал Обучение по новым требованиям
- Подготовиться к расчёту Kзн/Пзн Начать сбор метрик для оценки зрелости
Приоритеты внедрения:
- Критический приоритет: Управление уязвимостями (КУ) и Управление обновлениями (КО) — это то, что ФСТЭК будет проверять в первую очередь.
- Высокий приоритет: Контроль конфигураций (КК) и Мониторинг ИБ (МБ).
- Средний приоритет: Защита удалённого доступа (УД), защита подрядчиков (ЗП), обучение (УЗ).
Как «Стратегия Ра» помогает с переходом на Методику 2026
Мы выполняем полный комплекс работ по приведению в соответствие с новой Методикой:
- Аудит текущего состояния. Оцениваем зрелость процессов по 19 направлениям, выявляем критические несоответствия.
- Разработка документации. Готовим полный комплект регламентов по Разделу III — от управления уязвимостями до защиты подрядчиков.
- Внедрение автоматизации. Настраиваем сканеры уязвимостей, системы patch management, SIEM для мониторинга.
- Расчёт Kзн и Пзн. Собираем метрики, готовим отчётность для ФСТЭК.
- Обучение персонала. Проводим семинары и практические занятия по новым процессам.
Приглашаем к диалогу
Если вы хотите понять, насколько ваша организация готова к требованиям Методики 2026 года, — приглашаем на бесплатную первичную консультацию. Мы проведём экспресс-оценку и предложим дорожную карту. Напишите нам, и мы договоримся о встрече.
Материал подготовлен на основе лекций и практических кейсов Игоря Краева, генерального директора ООО «Стратегия Ра», апрель 2026 г.