На проверке Threat Modeling для разработчиков: STRIDE, PASTA и деревья атак на практике

[Сергей Попов]

За последний год я провёл больше тридцати threat modeling сессий с продуктовыми командами - от финтех-стартапов до enterprise-платформ. Каждая третья сессия заканчивалась одинаково: мы находили архитектурный дефект, невидимый ни для одного SAST-сканера. Типичный пример - отсутствие trust boundary между API Gateway и внутренними микросервисами. Результат: любой сервис обращался к данным другого без авторизации. Час у whiteboard экономил команде спринт на исправления в проде.

Три методологии закрывают большинство задач: STRIDE для систематического перебора угроз, PASTA для обоснования рисков перед бизнесом, Attack Trees для визуализации конкретных цепочек атак. Дальше - как каждую из них применять на этапе проектирования, без воды и «в теории оно работает так».

Зачем разработчикам threat modeling на этапе проектирования​

Моделирование угроз - не бюрократическая процедура и не документ ради документа. Суть проста: собрать команду, нарисовать архитектуру и задать вопрос «Что может пойти не так?». Согласно OWASP Threat Modeling Project, весь процесс сводится к четырём шагам: определить scope, найти угрозы, определить контрмеры и проверить результат. Звучит просто - пока не начинаешь делать.

Зачем это разработчикам, а не только безопасникам? Потому что архитектурные решения принимают именно разработчики и архитекторы. Когда security-инженер приходит на пентест и находит IDOR в API - поздно. Endpoint написан, интегрирован, покрыт тестами, и его переделка занимает дни. А на whiteboard-сессии, когда архитектор рисует Data Flow Diagram и видит, что эндпоинт /api/users/{id} не проверяет принадлежность ресурса текущему пользователю - исправление занимает одну строку в user story.

В этом суть shift left security: чем раньше найдена проблема, тем дешевле её устранение. По модели зрелости OWASP SAMM (Software Assurance Maturity Model) threat modeling входит в практику Threat Assessment бизнес-функции Design. Фреймворк NIST CSF 2.0 аналогично выделяет функцию IDENTIFY (ID.AM-01) - инвентаризацию активов как первый шаг к управлению рисками. Без понимания того, что вы защищаете, невозможно определить, от чего защищать.

На практике threat modeling для разработчиков работает по принципу «понемногу и часто»: короткие сессии по 30–60 минут, сфокусированные на конкретном компоненте, а не попытка описать всю систему за раз. Попытка объять всё сразу - верный способ убить инициативу на старте.

Моделирование угроз STRIDE: систематический перебор за whiteboard-сессию​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

STRIDE-per-interaction, описанный Адамом Шостаком в его работе в Microsoft, анализирует угрозы на стыках между компонентами - на каждом потоке данных. В микросервисных архитектурах с десятками компонентов per-interaction сокращает количество элементов для анализа и при этом покрывает угрозы, возникающие именно при коммуникации.

На whiteboard-сессиях с небольшими командами я обычно начинаю с per-element - он интуитивнее для разработчиков, которые впервые участвуют в threat modeling. Для систем с более чем 15 компонентами переключаюсь на per-interaction, иначе сессия растягивается на часы и люди начинают терять фокус.

Практика: STRIDE-анализ сервиса аутентификации​

Допустим, команда проектирует сервис аутентификации для API. Архитектура: мобильный клиент отправляет credentials на Auth Service, тот проверяет их в User DB и возвращает JWT. JWT передаётся во все последующие запросы через API Gateway к внутренним микросервисам.

Рисуем DFD: внешняя сущность (Mobile Client) → поток данных (HTTPS) → процесс (Auth Service) → поток данных (SQL) → хранилище (User DB). Auth Service → поток данных (JWT) → процесс (API Gateway) → внутренние сервисы. Trust boundary проходит между Mobile Client и Auth Service, а также между API Gateway и внутренними сервисами.

Проходим по STRIDE для Auth Service (процесс - подвержен всем шести категориям):

Spoofing. Может ли кто-то представиться Auth Service? Если внутренние сервисы не проверяют, откуда пришёл JWT - да, запросто. Митигация: mutual TLS между сервисами, валидация issuer в JWT.

Tampering. Может ли кто-то модифицировать JWT в транзите? Если используется алгоритм none или HMAC с утёкшим ключом - да. Это классика, и я видел такое в проде чаще, чем хотелось бы. Митигация: RS256/ES256 с ротацией ключей, проверка алгоритма на сервере.

Repudiation. Может ли пользователь отрицать действие? Если Auth Service не логирует попытки входа - да. Митигация: append-only audit log с временными метками.

Information Disclosure. Утечка данных через Auth Service? Если ошибка аутентификации возвращает «пользователь не найден» vs «неверный пароль» - timing oracle для перечисления пользователей. Митигация: единообразное сообщение об ошибке, одинаковое время ответа. Это напрямую связано с техникой Brute Force (T1110, Credential Access) - различие ответов помогает атакующему сузить перебор.

Denial of Service. Можно ли вывести Auth Service из строя? Без rate limiting - тривиально. Митигация: rate limiting по IP и по аккаунту, exponential backoff.

Elevation of Privilege. Можно ли через Auth Service получить права администратора? Если роль хранится в JWT payload и не перепроверяется на бэкенде - достаточно модифицировать claim role: admin. Митигация: роли проверяются по базе при каждом запросе, не по токену.

Каждая найденная угроза превращается в user story в бэклоге. Не в отдельный security-документ, который никто не откроет - в обычный бэклог команды.

Методология PASTA: от бизнес-целей до симуляции атак​

STRIDE отвечает на вопрос «какие угрозы существуют?», но не помогает приоритизировать их с точки зрения бизнеса. Когда нужно обосновать затраты на безопасность перед product owner или CTO, нужен другой инструмент. PASTA (Process for Attack Simulation and Threat Analysis) - риск-ориентированная методология, разработанная Тони Уседа-Велесом (VerSprite) и Марко Мораной, впервые представленная в 2012 году и подробно описанная в книге 2015 года Risk Centric Threat Modeling. По данным threat-modeling.com, PASTA используется в GitLab - что показательно для DevOps-ориентированной компании.

Главное отличие методологии PASTA от STRIDE: бизнес-контекст - не второстепенный фактор, а отправная точка всего анализа. Это делает PASTA рабочим инструментом для безопасной разработки ПО в организациях с развитой культурой управления рисками.

Семь стадий PASTA на примере API​

Каждая стадия PASTA подаёт данные в следующую, последовательно наращивая глубину анализа. Разберём на примере платёжного API:

Стадия 1: Определение целей. Фиксируем бизнес-цели (обработка платежей), требования безопасности (PCI DSS), классификацию данных (PAN - конфиденциальные). Тут без product owner не обойтись - чисто техническая задача превращается в разговор про деньги.

Стадия 2: Определение технического scope. Что защищаем: код API, конфигурация, база данных, облачная инфраструктура (AWS/GCP), сетевые взаимодействия, SaaS-интеграции. Что не в scope - тоже фиксируем явно. Без этого scope расползается как тесто.

Стадия 3: Декомпозиция приложения. Здесь создаются DFD - аналогично STRIDE. Определяются потоки данных, trust boundaries, точки входа. Результат - понимание того, как данные перемещаются между компонентами и где проходят границы доверия.

Стадия 4: Анализ угроз. Идентифицируем угрозы для каждого компонента. Здесь можно применять STRIDE как вспомогательную классификацию - методологии не исключают друг друга. Используем данные threat intelligence: какие атаки реально проводятся на платёжные API?

Стадия 5: Анализ уязвимостей. Какие известные уязвимости существуют в используемых компонентах? Проверяем зависимости, конфигурации, известные CVE для версий применяемого стека.

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

Стадия 7: Анализ рисков и импакта. Оцениваем каждый сценарий по вероятности и бизнес-импакту. Утечка PAN-данных = штраф PCI DSS + потеря репутации + отзыв лицензии процессинга. Вот это язык, который понимает бизнес. Не «у нас тут XSS», а «мы рискуем потерять лицензию процессинга».

Когда PASTA оправдывает затраты​

PASTA - ресурсоёмкая методология. Семь стадий требуют участия разных ролей: product owner, архитектор, разработчики, security-инженер, risk manager. Как справедливо отмечают авторы Software Secured, «PASTA requires a high level of expertise to implement correctly and is typically very time-consuming».

Применять PASTA целесообразно для:

• Систем с высоким бизнес-импактом (платёжные сервисы, медицинские данные, критическая инфраструктура)
• Организаций с зрелой программой безопасности (есть threat intelligence, есть процесс управления рисками)
• Ситуаций, когда нужно обосновать бюджет на security-контроли перед руководством

Для внутреннего микросервиса без внешнего exposure PASTA - overhead. Хватит STRIDE-сессии на 45 минут.

Деревья атак: визуализация цепочек для разработчиков​

Attack Trees - третий инструмент в арсенале. Если STRIDE отвечает на «какие угрозы?», а PASTA - на «какой бизнес-риск?», то деревья атак отвечают на «как именно атакующий дойдёт до цели?». Это диаграмма с иерархической структурой, где корень - цель атакующего, а листья - конкретные действия.

Деревья атак особенно хорошо работают в разговоре с разработчиками: вместо абстрактного «ваш API уязвим» вы показываете конкретную цепочку шагов от первого запроса до компрометации данных. Разработчик видит путь - и сразу понимает, где его закрыть.

Структура дерева атак: AND и OR логика​

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

Такая структура помогает визуально оценить, где одна митигация закрывает целую ветку (OR-узел), а где нужно закрыть все пути (AND-узел - чтобы атака не состоялась, достаточно заблокировать одно условие).

Практический пример: дерево атак на захват учётной записи​

Дерево атак для цели «Захват учётной записи пользователя». Текстовое представление структуры:

Захват учётной записи [OR]
├── Перехват credentials [OR]
│   ├── MITM на API-запрос [AND]
│   │   ├── Отсутствие certificate pinning
│   │   └── Доступ к сети жертвы
│   └── Кража токена из localStorage
├── Brute force пароля [AND]
│   ├── Отсутствие rate limiting
│   └── Предсказуемые пароли пользователей
└── Elevation of Privilege [OR]
    ├── IDOR на /api/users/{id}
    └── JWT без валидации подписи

Что видит разработчик: чтобы закрыть ветку «MITM на API-запрос», достаточно реализовать certificate pinning (AND-узел - без одного условия атака не работает). Чтобы закрыть «Brute force», тоже AND - rate limiting блокирует всю ветку. А «Elevation of Privilege» - OR, и нужно закрыть оба варианта.

Привязка к MITRE ATT&CK конкретизирует угрозы: перехват credentials связан с Adversary-in-the-Middle (T1557), brute force - с техникой Brute Force (T1110, Credential Access), а IDOR и JWT-проблемы - с Exploitation for Privilege Escalation (T1068, Privilege Escalation).

Дерево атак удобно строить прямо на whiteboard-сессии после STRIDE-анализа: найденные угрозы STRIDE становятся листьями дерева, а их комбинации - внутренними узлами. Так список угроз превращается в конкретные сценарии атак.

Анализ угроз на этапе проектирования: сравнение методологий​

Выбор методологии зависит от контекста. Как отмечают авторы Software Secured, «STRIDE is used to identify threats, DREAD is used to assess risk, and PASTA is used to model attacker behavior and business impact». На практике эти подходы не конкурируют - они дополняют друг друга.

Критерий	STRIDE	PASTA	Attack Trees
Фокус	Классификация угроз по 6 категориям	Бизнес-риск и симуляция атак	Визуализация конкретных путей атаки
Сложность внедрения	Низкая - одна сессия 30-60 минут	Высокая - 7 стадий, несколько ролей	Средняя - требует понимания цепочек атак
Кто участвует	Разработчики + security-инженер	Product owner + архитектор + security + risk	Security-инженер + разработчики
Когда применять	Каждый спринт, новые фичи	Новые продукты, высокий бизнес-импакт	После STRIDE - для углублённого анализа
Ограничения	Не приоритизирует риски по бизнес-импакту	Ресурсоёмкая, требует зрелой security-программы	Не даёт полной картины - только выбранные сценарии
Результат	Список угроз по категориям → user stories	Приоритизированные риски с бизнес-обоснованием	Диаграмма атак с конкретными шагами

Рабочая комбинация для большинства команд: STRIDE как регулярная практика в спринтах, Attack Trees для критичных компонентов, PASTA - раз в квартал для ревью всей системы или при запуске нового продукта.

Отдельно стоит упомянуть DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) - модель оценки рисков, которая хорошо дополняет STRIDE. Если STRIDE находит угрозу, DREAD помогает оценить её серьёзность по пятибалльной шкале. На практике многие команды используют упрощённую приоритизацию: высокий/средний/низкий - и этого достаточно для бэклога. Не надо усложнять там, где не требуется.

Инструменты threat modeling в SDLC​

Threat modeling можно проводить с маркером и whiteboard - инструменты не обязательны. Но для документирования и повторяемости результатов они помогают.

OWASP Threat Dragon - open-source инструмент для создания DFD с автоматической генерацией списка угроз. Работает в браузере, интегрируется с GitHub. Подходит для команд, которые хотят хранить threat model рядом с кодом. Я использую его для документирования результатов whiteboard-сессий - рисуем на доске, потом переношу в Threat Dragon для артефакта. UI, честно говоря, базовый, но своё дело делает.

Microsoft Threat Modeling Tool - десктопное приложение для Windows, использует STRIDE-per-element с предзаданными шаблонами. Согласно документации Microsoft, это «основной элемент жизненного цикла разработки защищённых приложений (SDL)». Инструмент автоматически предлагает угрозы на основе типа элемента и потока данных. Сильная сторона - шаблоны для Azure-сервисов. Ограничение - работает только под Windows и заточен под Microsoft-стек. Если вы не на Azure - пользы меньше.

Инструмент	Плюсы	Ограничения	Когда использовать
OWASP Threat Dragon	Open-source, браузерный, GitHub-интеграция	Нет автоматической приоритизации, базовый UI	Небольшие команды, DevSecOps-процесс
Microsoft TMT	Автоматическая генерация угроз, Azure-шаблоны	Только Windows, привязка к Microsoft-стеку	Enterprise на Azure, SDL-процесс
Whiteboard + фото	Нулевой порог входа, максимальная гибкость	Нет версионирования, трудно переиспользовать	Первые сессии, обучение команды

Выбор инструмента вторичен. Критично другое: результат threat modeling должен попадать в бэклог команды как обычные задачи, а не оседать в отдельном security-документе, который никто не читает. Если угроза найдена - она становится user story с acceptance criteria. Если принято решение принять риск - это документируется с указанием, кто принял решение и почему.

Интеграция threat modeling в SDLC выглядит так: при создании новой фичи или изменении архитектуры разработчик или архитектор инициирует 30-минутную сессию. Приглашаются 2–4 участника - те, кто понимает контекст. Результат - задачи в Jira/GitLab Issues с тегом security. Ревью - на ретроспективе спринта. Это не идеальная модель угроз - это рабочий процесс, который встраивается в существующий workflow без остановки разработки.

Из тридцати с лишним проведённых сессий я вынес одно наблюдение, которое переворачивает стандартное представление о secure by design разработке. Главное сопротивление threat modeling исходит не от разработчиков - они обычно увлекаются процессом, как только видят реальные сценарии атак на свой код. Сопротивление идёт от security-команд, которые требуют формальной «полной модели угроз» перед стартом работы. Это парализует процесс. Команда тратит две недели на документ, который устаревает к моменту завершения, и больше никогда не возвращается к моделированию угроз.

Работающий подход - обратный: начните с одного STRIDE-прогона для одного endpoint, потратьте 30 минут, получите три-четыре задачи в бэклог. Повторите через неделю для другого компонента. Через два месяца у команды сформируется привычка думать об угрозах на этапе проектирования - без формальных документов и без блокирующих согласований. PASTA подключится позже, когда команда дозреет до системного управления рисками. Attack Trees появятся естественно, когда кто-то из разработчиков скажет: «А давайте нарисуем, как атакующий дойдёт до нашей базы». И это будет означать, что DevSecOps моделирование угроз в команде заработало - не как навязанный процесс, а как способ мышления.

Попробуйте провести первую STRIDE-сессию на ближайшем планировании спринта. Возьмите один endpoint, 30 минут, маркер и доску. Если интересно, как другие команды выстраивают подобные сессии и какие грабли собирают - на форуме codeby есть тред по практике threat modeling в продуктовых командах.