Как построить модель угроз по методологии ФСТЭК: разбор на примере реальной системы

Для контекста — история, которая произошла у коллег не так давно. Компания купила где-то типовую модель угроз, прошла аттестацию и вернулась к работе. Через год специалист подрядчика подключился к сети под действующей учётной записью, выгрузил кадровые данные и скачал информацию с сервера расчёта зарплаты. Потом выяснилось, что подрядчика указали лишь как внешнего исполнителя, не описав его права, подключение и маршруты к базам данных.

Так происходит, когда документ готовят по шаблону и не сверяют с устройством ИС. Разберём пошаговое построение модель угроз ФСТЭК на примере кадрово-зарплатной системы ИСПДн «Кадры» (систему кадрового учёта) по новой методике.

Что такое модель угроз и зачем она нужна на самом деле

Модель угроз безопасности информации описывает защищаемые данные и компоненты, возможных нарушителей, пути атаки и последствия. Она связывает риски с решениями: условно, доступ подрядчика к административной консоли требует контроля привилегий, MFA и аудита, остановка расчётов — проверки резервирования и сроков восстановления, и так далее. На основе этой модели организации для защиты выбирают СЗИ, СКЗИ и организационные меры.

Методика ФСТЭК от 5 февраля 2021 года закрепила сценарный подход для разных типов систем. Её применяют при построении моделей для ГИС, ИСПДн, значимых объектов КИИ и АСУ:

• для ГИС приказ ФСТЭК № 117 от 11 апреля 2025 года действует с 1 марта 2026 года вместо № 17
• с 1 сентября 2026 года действуют изменения по приказу № 137 от 8 мая 2026 года
• отдельное положение вступит в силу 1 марта 2027 года. 

Приказы ФСТЭК для других категорий проверяют отдельно.

Ранее для разных классов систем применялись отдельные методики и перечни. Теперь оценка связывает объект воздействия, возможности нарушителя, путь атаки и ущерб.

Шаг 1: Описание системы и определение защищаемых активов

Возьмём для примера ИСПДн «Кадры» — систему кадрового учёта на 1 200 сотрудников. Она довольно популярна и применяется во многих российских организациях. В ней, в том числе, обрабатываются ФИО, паспортные данные, ИНН, СНИЛС, зарплата, банковские реквизиты. Уровень защищённости такой системы — УЗ-3 по ПП-1119.

Описание начинается с границ системы. Что сюда входит: 

• сервер приложений 
• сервер БД
• АРМ кадровиков
• VPN-канал в филиал (допустим, что он есть) 
• и интеграция с бухгалтерией 

Корпоративная почта, сайт и СКУД в границы не входят, потому что это внутренние системы

Дальше определите активы — данные и ресурсы, потеря конфиденциальности, целостности или доступности которых повлияет на компанию:

• персональные данные работников и кадровые документы
• начисления, удержания и банковские реквизиты;
• базы данных, серверы, файловые ресурсы и резервные копии;
• учётные записи, привилегии, журналы и настройки интеграций;
• каналы обмена с банком, бухгалтерией и подрядчиком.

Для каждого актива укажите владельца и пользователей. 

Шаг 2: Определение нарушителей и их потенциала

Теперь определите, кто может реализовать угрозу, какими знаниями, ресурсами и правами он располагает или потенциально может получить. Для выбранной ИС в качестве потенциальных угроз надо рассмотреть внешнего злоумышленника, сотрудника, администратора и специалиста подрядчика. Дело в том, что их исходные позиции различаются, потому что у каждого свой набор доступов и знаний об инфраструктуре (методика также разделяет нарушителей на внешних и внутренних по наличию прав доступа к системе и её ресурсам).

Методика 2021 года выделяет четыре уровня возможностей:

1. Н1 — базовые: общедоступные средства и известные уязвимости
2. Н2 — базовые повышенные: настройка инструментов и планирование атаки
3. Н3 — средние: самостоятельная разработка средств и эксплуатация неизвестных уязвимостей
4. Н4 — высокие: доступ к исходному коду и внедрение закладок на этапах разработки или поставки ПО и оборудования.

Потенциал нарушителя оценивают по квалификации, инструментам, времени, финансированию, знаниям об инфраструктуре и привилегиям. В примере мы рассматриваем внутреннего пользователя уровня Н1, подрядчика Н2 и внешнего нарушителя Н1–Н2.

Шаг 3: Формирование перечня угроз из банка данных ФСТЭК

Банк данных угроз безопасности информации (БДУ) — открытый ресурс ФСТЭК с описаниями угроз и сведениями об их реализации. Он помогает сформировать Базовый набор угроз для анализа. В 2025 году ФСТЭК добавила раздел по угрозам для систем искусственного интеллекта: в него входят кража модели, отравление обучающих данных, атаки через API и агенты. Если в вашей системе есть ИИ-модуль, это повод пересмотреть модель угроз.

В нашем случае для ИСПДн «Кадры» нужно проверить угрозы несанкционированного доступа, компрометации учётных записей, злоупотребления полномочиями, эксплуатации уязвимостей ПО, внедрения вредоносного кода, нарушения целостности и доступности данных. После этого сопоставьте записи с компонентами ИС и возможностями нарушителей, отметив точку входа и дальнейшие действия.

БДУ часто дополняют обследованием, аудитом конфигураций, анализом уязвимостей и тестированием на проникновение. Векторы и сценарии атак и можно уточнить по методологиям MITRE ATT&CK, CAPEC и OWASP.

БДУ часто дополняют обследованием, аудитом конфигураций, анализом уязвимостей и тестированием на проникновение. Векторы и сценарии атак и можно уточнить по методологиям MITRE ATT&CK, CAPEC и OWASP.

Для типовой ИСПДн актуальными обычно оказываются 30–60 угроз. Среди них, например, есть УБИ.067 (несанкционированный доступ через веб-приложение), УБИ.100 (фишинг) и другие.

В статье о требованиях ФСТЭК по персональным данным мы подробно разбирали, как ошибки в классификации ИСПДн и выборе средств защиты приводят к штрафам: с 2025 года за повторные утечки действуют оборотные санкции — до 3% годовой выручки.

Шаг 4: Оценка последствий и финальная матрица угроз

Для кадрово-зарплатной системы надо оценить ущерб от утечки данных, подмены реквизитов, остановки расчётов и восстановления. Параллельно ИБ-специалисты уточнят масштаб события, длительность простоя и доступность резервов.

Финальная матрица связывает угрозу с объектом, нарушителем, сценарием, последствиями и обоснованием актуальности. Например:

Это, конечно, не финальная матрица, но она позволяет понять, что должно быть в документе и как одно связано с другим. В ней всегда указывают идентификатор угрозы из БДУ, интерфейс, сценарий и обоснование статуса.

Модель пересматривают после изменений архитектуры, данных, ПО, внешних подключений и прав, а также после инцидентов, аудита, тестирования на проникновение или обновления БДУ. Проверку поручают владельцу документа и проводят совместно с ИТ, ИБ и владельцами процессов.

FAQ

Можно ли использовать одну модель угроз для нескольких информационных систем?

Нет, если системы различаются по архитектуре, обрабатываемым данным или категории нарушителей. Методика предполагает частную модель для каждой системы. Одна модель допустима для кластера однотипных систем с идентичной архитектурой и одинаковым уровнем значимости, но это скорее исключение.

Обязательно ли пользоваться БДУ ФСТЭК?

Методика указывает банк данных как один из основных источников исходных данных для оценки угроз. Формально можно использовать другие каталоги, но на практике регулятор ожидает увидеть обоснование актуальности со ссылками на БДУ. Для систем с ИИ с 2025 года нужно учитывать и специализированный раздел БДУ по угрозам ИИ.

Нужна ли модель угроз коммерческой системе, если она не относится к ГИС или КИИ?

Если система обрабатывает персональные данные, требование о модели угроз содержится в приказе ФСТЭК № 21. Если она не подпадает ни под ГИС, ни под КИИ, ни под ПДн — модель угроз можно не делать, но она остаётся инструментом управления рисками. После введения оборотных штрафов за утечки коммерческие организации всё чаще делают модель добровольно, потому что цена ошибки значительно выросла.

Заключение

Модель угроз показывает, какие события повлияют на данные и работу системы, откуда начнётся атака и какие условия сделают её возможной. Для оценки нужны схема ИС, сведения о данных, пользователях, подключениях и последствиях сбоя. Начните с инвентаризации компонентов, данных, ролей и внешних подключений. О работе с персональными данными читайте в статье о требованиях ФСТЭК и типичных ошибках при внедрении.