Модель угроз ФСТЭК: пошаговое руководство по разработке и согласованию

Модель угроз — один из основных документов при построении системы защиты информации по требованиям ФСТЭК. Она используется не только для прохождения проверок, но и для формирования эффективной архитектуры безопасности. Cyber Media рассмотрит нормативную базу, пошаговый процесс подготовки и согласования модели угроз, а также типичные ошибки, которых стоит избегать.

Содержание:

Что такое моделирование угроз и зачем оно нужно по требованиям ФСТЭК

Модель угроз — это не просто «техническое приложение к приказу», а своего рода фундамент. На ее основе выбираются меры защиты, проектируются технические и организационные контуры, обосновываются затраты. Если модель сделана плохо, все последующие шаги — от выбора средств защиты до построения SOC — окажутся шаткими. 

Сергей Коловангин

Начальник отдела ИТ-компании «Газинформсервис»

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

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

• изменении архитектуры и условий функционирования системы, режима обработки информации, правового режима информации, влияющих на угрозы ИБ;
• выявлении, в том числе по результатам контроля уровня защищенности системы и содержащейся в ней информации (анализа уязвимостей, тестирований на проникновение, аудита), новых угроз ИБ или новых сценариев реализации существующих угроз;
• включении в банк данных угроз ИБ ФСТЭК России (bdu.fstec.ru) сведений о новых угрозах ИБ, сценариях (тактиках, техниках) их реализации.

Да, многие привыкли относиться к модели угроз как к обязательному «чекбоксу» для регулятора. Но на практике это инструмент, который может сэкономить много сил:

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

Хорошо составленная модель — это не стопка бумаг в папке «для проверки», а рабочая карта рисков, к которой удобно возвращаться при любом изменении инфраструктуры или требований бизнеса.

Нормативная база: приказы ФСТЭК № 17, 21, 31 и 239

Чтобы разработать модель угроз, сначала нужно понять, в какой «правовой вселенной» мы живем. Всю нормативную рамку для модели угроз формируют приказы ФСТЭК — № 17, 21, 31 и 239:

• Приказ № 17 ― базовый документ для государственных информационных систем. Именно он описывает, как строится защита и зачем нужна модель угроз в составе проектной документации.
• Приказ № 21 ― для персональных данных. Если вы работаете с базами клиентов или сотрудников, то без этого приказа никуда. Он диктует, что модель угроз должна учитывать специфику обработки ПДн.
• Приказ № 31 ― универсальный вариант для автоматизированных систем управления (АСУ ТП). Это «библия» для энергетиков, транспортников, промышленных предприятий.
• Приказ № 239 ― относительно свежий, он описывает общие требования к построению систем защиты, и именно его часто называют «надстройкой» над остальными приказами.

Как это соотносится между собой? Проще всего представить в виде «слоеного пирога». Есть общая методология из 239 приказа, поверх нее накладываются специальные правила: для ГИС — 17, для ПДн — 21, для АСУ ТП — 31. То есть, в зависимости от типа системы вы используете свой профильный документ, но логика построения модели угроз при этом остается одинаковой.

Для практика это значит одно: если вы умеете грамотно собрать модель угроз по одному приказу, то быстро разберетесь и в остальных. Отличается только контекст — объекты защиты, типы данных и сценарии атак.

Как составить модель угроз безопасности информации: пошаговый процесс

Начать стоит с определения границ системы и объектов защиты. Нужно понять, что именно вы защищаете: сервисы, базы данных, API, облачные ресурсы, CI/CD-пайплайны, рабочие станции и точки интеграции с внешними системами. Важно зафиксировать владельцев объектов, критичность данных и зоны доверия — где проходят критичные потоки, где хранятся секреты, какие интерфейсы открыты.

Марина Кондратенко

Эксперт УЦСБ

В настоящий момент основным нормативным документом, определяющим порядок определения актуальных УБИ, является Методика оценки УБИ, утвержденная ФСТЭК России 5 февраля 2021 г. (далее – Методика).

В соответствии с п. 2.10 Методики, УБИ определяются как для самих защищаемых систем и сетей, так и для информационно-телекоммуникационной инфраструктуры (далее – ИТ-инфраструктура), на базе которой они функционируют. Таким образом, при оценке УБИ гибридных систем необходимо учитывать, в том числе угрозы ИТ-инфраструктуре поставщика услуг.

Далее следует структурировать информацию и визуализировать систему. Для этого полезно использовать архитектурные схемы, которые показывают, как компоненты взаимодействуют друг с другом и где могут возникнуть уязвимости. На этом этапе стоит обратить внимание на несколько ключевых аспектов:

• Логическая схема — сервисы, данные, зависимости между компонентами.
• Сетевая схема — порты, протоколы, зоны безопасности.
• Схема доверия — привилегии, границы доступа и точки контроля.
• Последовательности критичных процессов — например, CI/CD-пайплайн или развертывание облачных сервисов.

После того как схема готова, наступает этап документирования обоснований выбора угроз. Каждая угроза должна быть подробно описана: объект защиты, сценарий атаки, возможности нарушителя, вектор реализации, последствия для конфиденциальности, целостности и доступности, текущие меры защиты и рекомендации по улучшению. 

Роман Писарев

Руководитель департамента аудита и консалтинга iTPROTECT

Проверяющие смотрят на системность и логическую связанность всех компонентов. Нельзя выделить один элемент.

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

Но именно качественное обоснование актуальности/неактуальности каждой угрозы показывает, что компания провела настоящую аналитическую работу, а не просто составила документ «для галочки». ФСТЭК России видит, насколько глубоко вы учли риски, исходя из специфики своей системы.

Такой подход превращает модель угроз из формального документа в рабочий инструмент, на основе которого можно строить эффективную защиту и управлять инцидентами.

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

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

Работать с БДУ достаточно просто: ищете угрозы, соответствующие вашим объектам защиты, и переносите их в проектную модель. Но важно помнить, БДУ — это база шаблонов, а не готовый «чек-лист для копирования». Чтобы модель угроз была реально полезной, нужно адаптировать перечень под конкретный проект.

Практически это выглядит так:

• выделяете из БДУ все угрозы, релевантные вашему типу системы;
• фильтруете по объектам защиты в вашей инфраструктуре;
• оцениваете, какие угрозы реально применимы с точки зрения контекста: кто может атаковать, какими ресурсами обладает, какие сценарии возможны;
• добавляете новые угрозы, которых нет в БДУ, но они актуальны для специфики проекта, например, публичный облачный endpoint, нестандартные интеграции, внутренние CI/CD-пайплайны.

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

Оценка возможностей нарушителя и построение модели нарушителя

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

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

Наталья Пономарева

Ведущий консультант по информационной безопасности, UDV Group

Конечно, ФСТЭК России смотрит модель угроз в целом и анализирует все представленные в ней данные. Однако можно сказать, что в первую очередь специалисты ФСТЭК России рассматривают итоговый перечень актуальных угроз безопасности информации. ФСТЭК России обладает информацией о том, какие угрозы чаще всего встречаются у типовых систем. Соответственно, ФСТЭК России может проводить сравнение со «среднестатистическими данными» и задавать вопросы при отсутствии типовых угроз.

Стоит отметить, что часть вопросов об отсутствии тех или иных угроз могут быть сняты, если в разработанной модели угроз прослеживается четкая логика определения угроз, начиная от последствий и заканчивая сценариями, а также если приведены аргументы неактуальности / неприменимости угроз. Поэтому вторым фактором, на который обращают внимание сотрудники ФСТЭК России, — это обоснования и аргументы, приведенные в модели угроз при оценке возможных негативных последствий, нарушителей (источников), способов и сценариев реализации, включая оценку возможных тактик и соответствующих им техник, а также обоснования для исключенных из рассмотрения угроз безопасности информации.

ФСТЭК при проверке обращает внимание на три ключевых аспекта:

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

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

Типичные ошибки при разработке модели угроз и как их избежать

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

Михаил Кадер

Архитектор клиентского опыта будущего UserGate

Я бы выделил две проблемы. Как обычно — организационную и техническую. Организационная возникает в том случае, если целью ставится максимальное упрощение модели угроз для снижения сложности и стоимости защитных мер. В этом случае, конечно же, возникнет необходимость ее доработки с учетом современных реальностей. Хорошо бы еще не после значимого инцидента.

Технические ошибки могут быть связаны с недостаточным пониманием современных процессов ИТ, а также поверхностным изучением БДУ ФСТЭК и других источников информации об актуальных угрозах. А также необходимо помнить, что управление моделью угроз, для поддержания ее в актуальном состоянии — это регулярный процесс.

Типичные ошибки включают:

• неправильно определены границы системы, что приводит к пропуску критичных объектов;
• забыты объекты защиты или данные, особенно новые сервисы и облачные ресурсы;
• угрозы не привязаны к конкретным активам, остаются абстрактными;
• не оценены возможности нарушителей и сценарии атак;
• шаблонное копирование угроз из БДУ без адаптации под проект.

Чтобы избежать постоянных доработок, полезно вести «дорожную карту» исправлений: фиксировать замечания, назначать ответственных и указывать сроки внедрения. 

Вячеслав Флеров

Ведущий инженер отдела ИТ-компании «Газинформсервис»

Что касается вопроса об исправлении ошибок, я бы предложил такой терминологией вовсе не пользоваться. Дело в том, что даже «плохая» модель угроз лучше, чем никакой, и любой специалист ИБ даже к самому лучшему варианту документа выставит любое количество замечаний по желанию. Поэтому прежде всего следует воспринимать моделирование угроз, как непрерывный процесс, позволяющий в непрерывном режиме подстраиваться под любые изменения ландшафта защищаемой системы.

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

Такой подход позволяет превращать модель угроз из формального документа в живой инструмент, который помогает оценивать риски, планировать защитные меры и управлять инцидентами.

Интеграция модели угроз в процессы ИБ

Модель угроз не должна оставаться отдельным документом «для проверки». Она становится ценным инструментом, если ее интегрировать в повседневные процессы информационной безопасности, в том числе в SOC и управление уязвимостями. Каждая зарегистрированная угроза связывается с контролями и событиями мониторинга: это позволяет SOC видеть, какие инциденты критичны именно для вашей системы, а какие — второстепенны.

На практике это работает так: угрозы из модели сопоставляются с уязвимостями, найденными сканерами и аудитами. Если выявленная уязвимость позволяет реализовать высокоприоритетную угрозу, она автоматически поднимается в SOC как критический инцидент. Это помогает выстраивать приоритеты: не все тревоги одинаково важны, а ресурсы команды реагирования используются максимально эффективно.

Александр Дроздов

Ведущий инженер по РБПО и информационной безопасности Axiom JDK

Когда есть модель угроз, можно предполагать возможные сценарии атаки и готовить SOC к таким событиям и их обнаружению. Например, расставлять honey pod`ы и канареечные данные. Honey pod`ы позволят обнаружить присутствие злоумышленника, а канареечные данные могут получить информацию о том, что произошла утечка данных. Например, когда кто-то воспользовался учетными данными для аутентификации, которые хранились в базе данных только для того, чтобы узнать, что кто-то получил к ней доступ.

Такой подход превращает модель угроз из формальности в рабочий инструмент: она напрямую влияет на реакцию на инциденты, помогает приоритизировать уязвимости и строить эффективный мониторинг всей инфраструктуры.

Заключение

Модель угроз — это не формальность, а рабочий инструмент для оценки и управления рисками. Чтобы она оставалась актуальной, регулярно обновляйте границы системы, объекты защиты и перечень угроз при изменениях инфраструктуры, внедрении новых сервисов или обнаружении новых уязвимостей. Такой подход позволяет использовать модель угроз как основу для приоритизации инцидентов, планирования защитных мер и построения эффективного мониторинга безопасности.