Threat modeling: как моделировать угрозы на старте проекта
Threat modeling (моделирование угроз) — это структурный разбор того, что и как может пойти не так в системе, ещё до того, как уязвимости попадут в код и продакшен. Команда смотрит на архитектуру глазами атакующего: где данные входят и выходят, где доверие меняется, что можно подделать, перехватить или сломать — и заранее закладывает контрмеры. **Если коротко:** моделировать угрозы дешевле и эффективнее всего на старте проекта, когда архитектура ещё на бумаге и менять её ничего не стоит. На практике достаточно трёх опор: схема потоков данных (DFD), классификация угроз по STRIDE и список рисков с приоритетами. Ниже — когда и как моделировать, готовая таблица «STRIDE → угроза → контрмера», пошаговый процесс, чек-лист и типичные ошибки. Threat modeling — часть зрелого Secure SDLC, поэтому сравнить инструменты и платформы для безопасной разработки можно в [рейтинге DevSecOps-платформ](/rating/devsecops-secure-sdlc).
Secure SDLC работает только как часть процесса поставки
DevSecOps требует автоматических проверок, понятных gates и обратной связи разработчикам без ручного торможения релизов.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Что такое threat modeling и зачем он нужен
Моделирование угроз отвечает на четыре вопроса, которые сформулировал OWASP: что мы строим, что может пойти не так, что мы с этим делаем и достаточно ли хорошо мы это сделали. Это не разовый аудит и не пентест: пентест ищет уязвимости в уже готовой системе, а threat modeling проектирует защиту до того, как уязвимости появятся.
Ценность в том, что разбор ведётся на уровне архитектуры, а не отдельных строк кода. Многие критичные проблемы — небезопасная аутентификация между сервисами, отсутствие шифрования канала, чрезмерные привилегии, незащищённые границы доверия — невозможно найти линтером или сканером, потому что это не баг в коде, а изъян замысла. Моделирование угроз ловит именно такие дефекты — и ловит их тогда, когда исправление стоит правки на схеме, а не переписывания половины системы.
Threat modeling: коротко о подходе
6 категорий угроз от Microsoft, де-факто стандарт
Диаграмма потоков данных с границами доверия
Этап проектирования архитектуры, до написания кода
Что строим / что не так / что делаем / достаточно ли
Методологии: STRIDE, DFD и attack trees
На практике три инструмента закрывают большинство задач, и их используют вместе, а не по отдельности:
- **DFD (Data Flow Diagram).** Схема потоков данных: внешние сущности, процессы, хранилища и потоки между ними. Главное на DFD — границы доверия (trust boundaries): линии, где данные переходят из менее доверенной зоны в более доверенную (интернет → API, фронтенд → бэкенд, сервис → БД). Именно на этих границах рождаются угрозы. - **STRIDE.** Мнемоника из шести категорий угроз: Spoofing (подмена), Tampering (искажение), Repudiation (отказ от авторства), Information Disclosure (утечка), Denial of Service (отказ в обслуживании), Elevation of Privilege (повышение привилегий). Для каждого элемента DFD проходимся по шести буквам и спрашиваем: применима ли эта угроза здесь? - **Attack trees (деревья атак).** Дерево, где корень — цель злоумышленника (например, «получить доступ к БД клиентов»), а ветви — способы её достичь. Удобно для углублённого разбора конкретного критичного актива, когда STRIDE дал общую карту, а нужно проработать сценарии детально.
Связка простая: рисуем DFD → по STRIDE генерируем угрозы на каждой границе → для самых критичных рисков достраиваем attack trees и продумываем контрмеры.
STRIDE: категория → угроза → контрмера
| Категория STRIDE | Что нарушает | Пример угрозы | Типовая контрмера |
|---|---|---|---|
| Spoofing (подмена) | Аутентификацию | Атакующий выдаёт себя за другого пользователя или сервис | Строгая аутентификация, MFA, mTLS между сервисами |
| Tampering (искажение) | Целостность | Подмена данных в запросе, в БД или в транзите | Подписи, контроль целостности, валидация ввода, TLS |
| Repudiation (отказ от авторства) | Неотказуемость | Пользователь отрицает совершённое действие | Защищённое логирование, аудит, неизменяемые журналы |
| Information Disclosure (утечка) | Конфиденциальность | Чтение чужих данных, утечка через ошибки и логи | Шифрование данных и каналов, минимизация выдачи, RBAC |
| Denial of Service (отказ) | Доступность | Перегрузка сервиса, исчерпание ресурсов | Лимиты, троттлинг, автоскейлинг, защита от DDoS |
| Elevation of Privilege (повышение привилегий) | Авторизацию | Получение прав выше положенных | Принцип наименьших привилегий, проверка авторизации на сервере |
Когда моделировать: чем раньше, тем дешевле
Главный тезис практики — моделировать угрозы нужно на старте проекта, на этапе проектирования архитектуры. Причина экономическая: дефект, пойманный на схеме, стоит правки стрелки на диаграмме; тот же дефект, найденный в продакшене, стоит инцидента, простоя и переписывания кода под давлением.
Это не значит «один раз и навсегда». Моделирование — итеративный процесс: его повторяют при существенных изменениях архитектуры, добавлении новой интеграции, нового хранилища данных или новой границы доверия. В зрелом Secure SDLC threat modeling встроен в процесс так же, как код-ревью: лёгкий пересмотр модели сопровождает каждое крупное изменение, а не превращается в отдельный тяжёлый проект раз в год.
Где threat modeling даёт наибольший эффект по этапам SDLC
Редакционная оценка относительной отдачи моделирования угроз по фазам жизненного цикла. Это качественный ориентир, а не измеренная метрика; цифры иллюстрируют принцип «раньше — дешевле».
Процесс моделирования угроз: 6 шагов
-
01
Определите объём и активы
Зафиксируйте, что именно моделируете (сервис, фича, система) и какие активы защищаете: данные пользователей, секреты, деньги, доступность.
-
02
Постройте DFD
Нарисуйте потоки данных: внешние сущности, процессы, хранилища и потоки между ними. Отметьте границы доверия — это будущие точки риска.
-
03
Выявите угрозы по STRIDE
Пройдитесь по каждому элементу и границе с шестью категориями STRIDE: для каждой спросите, применима ли угроза и как именно она реализуется.
-
04
Оцените и приоритизируйте риски
Ранжируйте угрозы по вероятности и ущербу (DREAD, CVSS или простая матрица «вероятность × влияние»), чтобы не распылять усилия.
-
05
Определите контрмеры
Для приоритетных рисков выберите меры защиты: аутентификация, шифрование, авторизация, лимиты, логирование — и заведите их как требования к реализации.
-
06
Зафиксируйте и пересматривайте
Сохраните модель как живой артефакт, заведите задачи в трекер и возвращайтесь к ней при изменениях архитектуры.
Типичные ошибки при моделировании угроз
Даже правильная методология не спасает, если процесс выстроен неудачно. Чаще всего команды спотыкаются об одно и то же:
- **Откладывают на потом.** Моделирование «после релиза» теряет главную ценность — дешевизну ранних правок. Делать его надо до кода, а не вместо ретроспективы инцидента. - **Делают разово.** Модель, нарисованная один раз и забытая, устаревает с первой же крупной фичей. Без пересмотра она вводит в заблуждение. - **Тонут в деталях.** Попытка описать каждую функцию убивает процесс. Уровень DFD — архитектура и границы доверия, а не отдельные методы. - **Не приоритизируют.** Список из сотни угроз без ранжирования невыполним. Без оценки риска команда либо делает не то, либо не делает ничего. - **Не доводят до задач.** Найденные угрозы без заведённых тикетов и контрмер остаются бумагой. Модель ценна только тем, что меняет реализацию. - **Делают в одиночку.** Threat modeling — командная работа: архитектор, разработчик и безопасник видят разные угрозы. В одиночку покрытие неполное.
Чек-лист внедрения threat modeling
Threat modeling в составе Secure SDLC
Моделирование угроз — не самостоятельная активность, а часть безопасной разработки. Оно встаёт в один ряд с SAST/DAST, управлением зависимостями, секрет-менеджментом и код-ревью, но работает на самом раннем уровне — архитектурном. В России безопасная разработка опирается на ГОСТ Р 56939 и требования ФСТЭК, где анализ угроз на этапе проектирования — обязательный элемент. Помогает и [Банк данных угроз ФСТЭК (БДУ)](https://bdu.fstec.ru/): актуальный каталог угроз, на который можно опираться при моделировании под российские требования.
Чтобы threat modeling работал, его нужно встроить в процесс и поддержать инструментами. Как это сделать пошагово — в материале [«Как внедрить DevSecOps: дорожная карта Secure SDLC»](/research/kak-vnedrit-devsecops), а требования российских стандартов разобраны в статье [«Безопасная разработка по ГОСТ Р 56939 и ФСТЭК»](/research/bezopasnaya-razrabotka-gost-56939).
Следующий шаг
Разобрались с методом — переходите к инструментам, которые встраивают анализ угроз и безопасность в процесс разработки: **[рейтинг DevSecOps-платформ и сервисов →](/rating/devsecops-secure-sdlc)**. Полезно прочитать рядом: [как внедрить DevSecOps](/research/kak-vnedrit-devsecops), [рейтинг DevSecOps-платформ 2026](/research/rejting-devsecops-platform-2026) и [безопасная разработка по ГОСТ Р 56939 и ФСТЭК](/research/bezopasnaya-razrabotka-gost-56939).
Частые вопросы
Чем threat modeling отличается от пентеста?
Пентест ищет уязвимости в уже готовой системе, моделирование угроз проектирует защиту до их появления. Threat modeling работает на уровне архитектуры и границ доверия, пентест — на уровне конкретной работающей системы. Это дополняющие, а не взаимозаменяемые активности.
Нужны ли специальные инструменты, чтобы начать?
Нет. Начать можно с доски, листа бумаги или простого редактора диаграмм — главное построить DFD и пройтись по STRIDE. Специализированные инструменты автоматизируют генерацию угроз и ведение модели, но они полезны на зрелом этапе, а не на старте.
Что такое границы доверия и почему они так важны?
Граница доверия — это место, где данные переходят из менее доверенной зоны в более доверенную: из интернета в API, из фронтенда в бэкенд, из приложения в БД. Именно на этих границах концентрируются угрозы, поэтому DFD без отмеченных границ доверия почти бесполезен для анализа.
Как часто пересматривать модель угроз?
Моделирование — итеративный процесс. Базовую модель строят на старте, а пересматривают при существенных изменениях архитектуры: новой интеграции, новом хранилище данных, новой границе доверия. В зрелом процессе лёгкий пересмотр сопровождает каждое крупное изменение, как код-ревью.
Где сравнить инструменты и платформы для безопасной разработки?
В рейтинге DevSecOps-платформ и сервисов — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Threat modeling (моделирование угроз) — это структурный разбор того, что и как может пойти не так в системе, ещё до того, как уязвимости попадут в код и продакшен. Команда смотрит на архитектуру глазами атакующего: где данные входят и выходят, где доверие меняется, что можно подделать, перехватить или сломать — и заранее закладывает контрмеры. **Если коротко:** моделировать угрозы дешевле и эффективнее всего на старте проекта, когда архитектура ещё на бумаге и менять её ничего не стоит. На практике достаточно трёх опор: схема потоков данных (DFD), классификация угроз по STRIDE и список рисков с приоритетами. Ниже — когда и как моделировать, готовая таблица «STRIDE → угроза → контрмера», пошаговый процесс, чек-лист и типичные ошибки. Threat modeling — часть зрелого Secure SDLC, поэтому сравнить инструменты и платформы для безопасной разработки можно в [рейтинге DevSecOps-платформ](/rating/devsecops-secure-sdlc).