Разработка модели угроз информационной безопасности: кому нужна, как проводится и что должна содержать

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

Кратко по теме

С 1 марта 2026 года вступил в силу Приказ ФСТЭК № 117, который заменил действовавший более десяти лет Приказ № 17 и закрепил риск-ориентированный подход. Теперь нужно обосновывать выбор мер защиты реальными сценариями атак и оценкой ущерба для конкретной информационной системы — просто одного документа уже недостаточно.

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

Что такое модель угроз

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

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

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

Что изменилось в требованиях к модели угроз в 2026 году

Риск-ориентированный подход вместо формального выполнения нормативов

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

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

Учет облачных, распределенных и гибридных архитектур

Приказ № 17 создавался в эпоху, когда большинство систем работало на физических серверах внутри периметра организации. Сегодня бизнес активно использует облачные сервисы, программное обеспечение и гибридные архитектуры. Приказ № 117 прямо требует учитывать эти особенности при разработке модели угроз.

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

Удаленные рабочие места как объект анализа

До 2026 года удаленные рабочие места часто оставались вне периметра модели угроз либо описывались вскольз. Приказ № 117 исправляет этот пробел. Теперь модель угроз информационной безопасности должна содержать анализ рисков, связанных с удаленным доступом: незащищенные домашние сети, личные устройства сотрудников, использование публичных Wi-Fi-сетей, отсутствие физического контроля над рабочими станциями.

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

Детализация мер защиты и контроля подрядчиков

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

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

Изменение структуры документа

Приказ № 117 ввел новые требования к содержанию модели угроз. По сравнению с ранее действовавшими нормами документ должен дополнительно включать:

1. обоснование выбора мер защиты с привязкой к конкретным угрозам;
2. описание сценариев реагирования на инциденты;
3. порядок взаимодействия с ГосСОПКА для значимых объектов КИИ;
4. оценку остаточного риска после внедрения мер защиты.

Когда разработка модели угроз обязательна

Информационные системы персональных данных (ИСПДн). Часть 2 статьи 19 Федерального закона № 152-ФЗ обязывает операторов ПДн принимать меры по обеспечению безопасности данных, а Постановление Правительства РФ № 1119 требует определять уровень защищенности ИСПДн. Модель угроз ИСПДн — обязательный документ, на основе которого обосновывается этот уровень.

Государственные информационные системы. Приказ ФСТЭК № 117 обязывает формировать модели угроз для всех ГИС. Без этого документа невозможна аттестация системы и допуск к эксплуатации.

Объекты критической информационной инфраструктуры (КИИ). Статья 7 Федерального закона № 187-ФЗ и Приказ ФСТЭК № 239 прямо предписывают субъектам КИИ разрабатывать модель угроз для значимых объектов. Документ является частью системы безопасности и подлежит проверке при категорировании.

Корпоративные информационные системы. Даже если организация не подпадает под перечисленные категории, разработка модели угроз организации рекомендуется как элемент управления рисками. При внутреннем аудите, страховании киберрисков или подготовке к сертификации по ISO/IEC 27001 наличие такого документа обязательно.

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

Какие нормативные документы регулируют разработку

Разработка модели угроз опирается на несколько нормативных актов.

1. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» — закрепляет обязанность оператора принимать меры по обеспечению безопасности ПДн (ст. 19) и определять уровень защищенности ИСПДн.
2. Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» — устанавливает общие принципы защиты информации и требования к государственным информационным системам.
3. Приказ ФСТЭК от 18.02.2013 № 21 — определяет состав и содержание организационных и технических мер по обеспечению безопасности ПДн при их обработке в ИСПДн.
4. Приказ ФСТЭК от 25.12.2017 № 239 — устанавливает требования к созданию систем безопасности значимых объектов КИИ.
5. Приказ ФСТЭК от 11.04.2025 № 117 — заменил Приказ № 17 с 1 марта 2026 года, закрепив риск-ориентированный подход к защите информации в ГИС.
6. Методика оценки угроз безопасности информации, утвержденная ФСТЭК 5 февраля 2021 года — содержит алгоритм определения актуальных угроз, критерии оценки вероятности и ущерба, а также рекомендуемую структуру документа.

Что включает модель угроз

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

1. Описание информационной системы. Назначение, область применения, архитектура, состав технических и программных средств, сетевые соединения, режимы обработки данных и взаимодействие с внешними системами.
2. Перечень объектов защиты. Информационные ресурсы, носители, каналы связи, серверы, рабочие станции — все элементы, подлежащие защите, с указанием их критичности для бизнеса.
3. Модель нарушителя. Описание потенциальных источников угроз: внешние злоумышленники, внутренние сотрудники, техногенные факторы, сбои оборудования. Для каждого нарушителя указываются мотивы, уровень компетенции, доступные ресурсы и возможные цели.
4. Описание уязвимостей и каналов реализации. Слабые места системы, через которые каждая угроза может быть реализована: уязвимости конфигураций, прав доступа, процессов резервирования, обновления программного обеспечения.
5. Перечень угроз безопасности информации. Используется Банк данных угроз ФСТЭК — из него выбираются типовые угрозы, соответствующие архитектуре и условиям эксплуатации конкретной системы.
6. Оценка актуальности угроз. Для каждой угрозы рассчитывается возможность реализации и потенциальный ущерб. Актуальность определяется на основе двух коэффициентов: исходной степени защищенности системы и вероятности возникновения угрозы.
7. Рекомендации по мерам защиты. Организационные и технические контрмеры для нейтрализации выявленных угроз с привязкой к исполнителям и срокам.
8. Порядок актуализации. Периодичность пересмотра документа, условия, при которых требуется внеочередная актуализация, и ответственные лица.

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

Как разрабатывается модель угроз

Процесс разработки модели угроз состоит из восьми этапов:

1. Сбор информации. Запрашиваются сведения об архитектуре системы, установленном программном обеспечении, сетевых соединениях, действующих политиках безопасности. Проводится интервью с владельцами бизнес-процессов и IT-специалистами.
2. Определение объекта защиты. Фиксируется, для какой информационной системы создается модель, какие данные обрабатываются, кто является пользователями, как система взаимодействует с внешней средой. Границы системы должны быть четко очерчены.
3. Анализ архитектуры. Изучаются технические и программные компоненты, каналы связи, точки интеграции с внешними системами. Выявляются критические узлы, отказ которых приведет к остановке бизнес-процессов.
4. Определение нарушителей. Формируется модель нарушителя: типы, цели, потенциал, способы реализации угроз. Учитываются внешние злоумышленники, внутренние сотрудники, техногенные источники.
5. Анализ угроз. Из БДУ ФСТЭК выбираются типовые угрозы, применимые к конкретной системе. Каждая угроза сопоставляется с объектами защиты и оценивается на предмет возможности реализации.
6. Выбор актуальных угроз. По методике ФСТЭК угроза признается актуальной, если она может быть реализована, способна привести к негативным последствиям, а принятых мер защиты недостаточно для ее нейтрализации. Неактуальные угрозы исключаются из перечня с обоснованием.
7. Подготовка документа. Модель угроз оформляется в соответствии с рекомендуемой структурой. Включаются все обязательные разделы, а также приложения со схемами архитектуры, таблицами угроз и результатами анализа рисков.
8. Утверждение модели. Документ подписывается руководителем организации и вводится в действие приказом. С этого момента модель угроз ФСТЭК становится обязательной для исполнения всеми подразделениями, задействованными в обработке данных.

Частые ошибки

№1: использование чужого шаблона. Такой документ не учитывает архитектуру конкретной системы, не содержит реального перечня угроз и не проходит проверку регулятора.
№2: неверное определение границ системы. Часть компонентов «выпадает» из описания, либо, наоборот, включается лишнее. Это приводит к тому, что актуальные угрозы остаются неучтенными.
№3: формальный подход к оценке актуальности. Угрозы включаются в перечень без количественной оценки вероятности и ущерба, тогда документ будет бесполезен при принятии решений о защите.
№4: отсутствие актуализации. Модель угроз не пересматривается годами, даже после миграции в облако или внедрения новых сервисов. При проверке есть риск получить предписание надзорного органа.
№5: игнорирование внутренних нарушителей. Многие организации фокусируются только на внешних атаках, забывая, что значительная доля инцидентов связана с действиями сотрудников.

Когда необходимо актуализировать модель угроз

Модель угроз информационной безопасности нужно пересматривать в следующих случаях:

1. изменение архитектуры информационной системы;
2. внедрение CRM или иных корпоративных сервисов;
3. переход в облачную инфраструктуру;
4. запуск сайта с формами сбора данных;
5. появление подрядчиков, которым поручена обработка ПДн;
6. подключение новых сервисов (онлайн-чат, системы аналитики);
7. изменение законодательства, регулирующего защиту информации;
8. истечение трехлетнего срока с даты последнего утверждения документа;
9. выявление нового типа атак, актуального для отрасли;
10. инцидент безопасности, повлекший утечку или компрометацию данных.

Чек-лист

1. Определите, для какой информационной системы разрабатывается модель угроз, и зафиксируйте ее границы.
2. Соберите исходные данные: архитектуру, перечень программного обеспечения, сетевые соединения, действующие политики безопасности.
3. Проведите инвентаризацию активов и определите объекты защиты.
4. Сформируйте модель нарушителя: типы, цели, потенциал, способы реализации угроз.
5. Используйте БДУ ФСТЭК для выбора типовых угроз, применимых к вашей системе.
6. Проведите оценку актуальности каждой угрозы по методике ФСТЭК.
7. Исключите неактуальные угрозы с обоснованием.
8. Оформите документ в соответствии с рекомендуемой структурой.
9. Утвердите модель угроз приказом руководителя.
10. Запланируйте пересмотр документа не реже одного раза в три года или при изменении инфраструктуры.

Часто задаваемые вопросы

Кто должен разрабатывать модель угроз?
Разработка модели угроз возлагается на владельца информационной системы. В небольших компаниях это может быть штатный специалист по информационной безопасности, в крупных — служба ИБ. При сложной архитектуре или наличии ГИС и КИИ привлекаются аттестованные эксперты. Утверждает документ всегда руководитель организации.

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

Когда нужна модель угроз для сайта?
Если сайт собирает персональные данные, модель угроз нужна. Форма обратной связи, корзина интернет-магазина, личный кабинет — все это делает сайт элементом ИСПДн. В этом случае модель угроз при обработке персональных данных обязательна по статье 19 ФЗ №152-ФЗ.

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

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