Threat modeling: STRIDE, PASTA, attack trees

Threat modeling — это процесс систематического выявления и анализа угроз безопасности на этапе проектирования системы, до её реализации и развёртывания. В отличие от пентестов и аудитов, которые находят уязвимости в уже работающих системах, threat modeling работает на ранних этапах, когда исправление проблем дешевле в десятки раз. Идея проста: вместо того чтобы лечить уязвимости, лучше их не создавать.

Несмотря на ясную ценность, threat modeling остаётся одной из самых недоразвитых практик в индустрии. Многие команды о нём слышали, но мало кто применяет систематически. Часть проблемы — кажущаяся сложность процесса и необходимость в специализированных навыках. На практике существуют простые и масштабируемые подходы — STRIDE, PASTA, attack trees, OCTAVE — позволяющие интегрировать threat modeling в обычный процесс разработки. Эта статья описывает эти методологии, инструменты автоматизации и подходы к встраиванию practice в команды.

Что такое threat modeling

Threat modeling — структурированный подход к анализу безопасности системы, отвечающий на четыре фундаментальных вопроса:

1. Что мы строим (модель системы)
2. Что может пойти не так (выявление угроз)
3. Что мы будем с этим делать (mitigations)
4. Сделали ли мы хорошую работу (валидация)

Эти четыре вопроса, сформулированные Адамом Шостаком в его книге «Threat Modeling: Designing for Security», формируют ядро любой методологии. Конкретные подходы (STRIDE, PASTA и другие) различаются деталями реализации, но отвечают на те же базовые вопросы.

Зачем нужен threat modeling

• Выявление security-проблем на этапе проектирования, до написания кода
• Информированный выбор архитектурных решений с учётом security
• Документирование принятых решений и обоснований
• Создание общего понимания угроз в команде
• Приоритизация security-инвестиций по реальным рискам
• Подготовка к incident response через знание потенциальных проблем
• Соответствие compliance-требованиям (NIST, ISO 27001, многие требуют threat modeling)

Экономика threat modeling

Стоимость исправления security-уязвимости растёт экспоненциально по мере её прогрессирования через стадии разработки:

STRIDE

STRIDE — методология, разработанная Microsoft в конце 1990-х. Самая известная и часто применяемая. Аббревиатура соответствует шести классам угроз.

Применение STRIDE

STRIDE применяется к компонентам системы. Для каждого компонента команда проходит по шести категориям и спрашивает: возможна ли эта угроза здесь.

Пример анализа web-приложения с базой данных:

STRIDE-per-element vs STRIDE-per-interaction

Существуют два варианта применения. STRIDE-per-element анализирует угрозы для каждого компонента изолированно. STRIDE-per-interaction анализирует угрозы для каждой interaction между компонентами. Второй вариант более детальный, но более трудоёмкий.

PASTA

Process for Attack Simulation and Threat Analysis — методология, разработанная Тони UcedaVelez. Более тяжеловесная и формальная по сравнению со STRIDE, ориентирована на бизнес-контекст.

Семь этапов PASTA

1. Define objectives: бизнес-цели и контекст системы
2. Define technical scope: технологические компоненты и зависимости
3. Application decomposition: детальная архитектурная разбивка
4. Threat analysis: идентификация релевантных угроз
5. Vulnerability analysis: выявление уязвимостей в архитектуре
6. Attack analysis: моделирование возможных атак
7. Risk and impact analysis: оценка бизнес-влияния

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

STRIDE vs PASTA

Attack trees

Attack tree — иерархическая модель, описывающая, как атакующий может достичь определённой цели. Корень дерева — цель атаки, ветви — способы её достижения, листья — конкретные атаки.

Пример attack tree

Цель атакующего: «Получить доступ к учётной записи администратора»

• Украсть credentials администратора
  • Phishing-атака
  • Перехват трафика
    • MITM-атака на нешифрованном канале
    • Атака на TLS-конфигурацию
  • Кейлоггер на устройстве
• Скомпрометировать учётную запись напрямую
  • Брутфорс пароля
  • Использование украденных credentials из других утечек
  • Эксплуатация уязвимостей в системе аутентификации
• Получить административный доступ через другой компонент
  • Privilege escalation от обычного пользователя
  • Эксплуатация уязвимости в админ-панели
  • Социальная инженерия с сотрудниками

Attack trees полезны для визуализации alternative paths атаки и для приоритизации защитных мер: ветка с самым низким cost для атакующего часто становится приоритетом для защиты.

OCTAVE

Operationally Critical Threat, Asset, and Vulnerability Evaluation — методология, разработанная CERT/SEI. Фокусируется на организационных аспектах безопасности, не только технических. OCTAVE применяется на уровне всей организации, не отдельной системы.

OCTAVE Allegro

Упрощённая версия для практического применения. Восемь шагов: установление критериев измерения риска, разработка профиля активов, идентификация угроз, разработка mitigation strategies. Подходит для compliance-проектов в средних компаниях.

Data Flow Diagrams

DFD — стандартный способ визуализации системы для threat modeling. Базовые элементы:

• External entities: пользователи, внешние системы (квадраты)
• Processes: компоненты, обрабатывающие данные (круги)
• Data stores: базы данных, файлы, кеши (параллельные линии)
• Data flows: потоки данных между элементами (стрелки)
• Trust boundaries: границы доверия между разными зонами (пунктирные линии)

Trust boundaries — самые важные. Они показывают, где данные пересекают границу безопасности (например, от пользовательского ввода к серверу, между микросервисами, при выходе во внешнюю сеть). Большинство уязвимостей возникает именно на этих границах из-за недостаточной валидации.

Процесс threat modeling в команде

Подготовительный этап

• Определить scope: какая система, какая часть, какой период
• Собрать команду: разработчики, архитекторы, security-эксперт, продакт-менеджер
• Подготовить материалы: архитектурные диаграммы, документация, прежние threat models
• Выбрать методологию: STRIDE для большинства команд

Workshop по threat modeling

Базовая практика — групповая сессия (обычно 2–4 часа) для команды над конкретным компонентом или фичей.

1. Построить DFD системы (30–60 минут)
2. Идентифицировать trust boundaries
3. Применить STRIDE к каждому компоненту или interaction
4. Записать выявленные угрозы
5. Оценить severity каждой угрозы (DREAD или CVSS)
6. Согласовать mitigations и owners
7. Документировать результаты

DREAD-оценка

Методология оценки риска угроз по 5 параметрам:

• Damage potential — потенциальный ущерб
• Reproducibility — повторяемость атаки
• Exploitability — простота эксплуатации
• Affected users — затронутые пользователи
• Discoverability — простота обнаружения

Каждый параметр оценивается от 1 до 10, общая оценка — среднее. Альтернатива — использовать CVSS, более стандартизированный, но менее адаптированный к design-фазе.

Инструменты для threat modeling

Threat modeling as code

Молодой тренд — описание моделей системы кодом, с автоматической генерацией DFD и идентификацией угроз. pytm — наиболее известный представитель. Преимущества: версионирование в Git, code review, интеграция в CI/CD. Недостатки: меньше визуальная коммуникация по сравнению с диаграммами.

Mitigations — что делать с угрозами

После идентификации угрозы команда выбирает one of four basic strategies:

Документация решений

Каждая угроза с выбранной стратегией документируется. Это создаёт audit trail и помогает в incident response. Хорошие практики:

• ADR (Architectural Decision Records) для security-решений
• Привязка mitigation к конкретным backlog items
• Owners для каждой mitigation с deadline
• Регулярный review threat models при изменениях системы

Интеграция в SDLC

Threat modeling эффективен только при систематическом применении, не разовых сессиях. Интеграция в существующий процесс разработки — ключ к sustainable practice.

Triggers для threat modeling

• Старт нового проекта или продукта
• Major feature, меняющий архитектуру
• Изменение trust boundaries (новые external entities)
• Изменение в обработке sensitive data
• Интеграция с external systems
• Migration на новые технологии
• Регулярный review (раз в год или квартал)

Roles и responsibilities

• Security champion в каждой команде — facilitate сессии, обладает базовой security-экспертизой
• Architect — обеспечивает архитектурный контекст
• Developers — представляют technical implementation
• Product manager — представляет бизнес-контекст
• Central security team — методологическая поддержка, training

Agile-friendly approach

В agile-командах threat modeling делается light-weight для каждого story, более глубоко — для эпиков и больших features. Не каждая user story требует полного threat modeling — это создаст overhead и замедлит работу.

Практические подходы:

• Security questions в template story
• Threat modeling в начале каждого эпика
• Periodic security architecture review (раз в квартал)
• Threat modeling как часть design review для major изменений

Типичные ошибки

Pretending to threat model

«Мы делаем threat modeling» — но на практике это формальный 30-минутный мозговой штурм без структуры. Результат — несколько generic угроз и ложное чувство security. Реальный threat modeling требует структуры и времени.

Threat model в вакууме

Документ threat modeling создан, согласован, и забыт. Найденные угрозы не превращаются в реальные mitigations, не контролируются в развитии. Без integration с backlog и development workflow это пустая трата времени.

Слишком детальный или слишком общий

Слишком детальный threat modeling каждого микро-компонента занимает недели и парализует разработку. Слишком общий пропускает реальные угрозы. Правильный уровень детализации — компромисс, обычно достигаемый через несколько итераций для каждой команды.

Только технические угрозы

Игнорирование социальной инженерии, insider threats, operational security даёт неполную картину. Хороший threat model включает и эти аспекты, даже если основной фокус на технологиях.

Single point in time

Threat model, сделанный один раз и не обновляемый при изменениях системы, быстро устаревает. Хорошая practice — review threat model каждые 6–12 месяцев и при существенных архитектурных изменениях.

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

Threat modeling для разных типов систем

Web-приложения

Фокус на OWASP Top 10: injections, broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, XSS, insecure deserialization, vulnerable components, insufficient logging. STRIDE с фокусом на boundary между frontend, backend, БД.

Mobile-приложения

Дополнительные угрозы: local storage уязвимости, reverse engineering, jailbreak/root detection bypass, certificate pinning bypass, insecure inter-process communication. OWASP MASVS как структурный референс.

Cloud-инфраструктура

Фокус на IAM misconfigurations, secrets management, network security в облаке, multi-tenancy issues. AWS Well-Architected Security Pillar и аналогичные документы Azure/GCP как референсы.

IoT-системы

Дополнительные специфические угрозы: physical access, firmware tampering, key extraction, supply chain attacks. OWASP IoT Top 10 как референс.

ML-системы

Новые классы угроз: adversarial examples, data poisoning, model extraction, prompt injection (для LLM). MITRE ATLAS как развивающийся фреймворк.

Метрики зрелости threat modeling

Большинство компаний находятся на Level 0–1. Level 2 уже считается зрелым подходом. Level 3–4 встречаются в крупных tech-компаниях и регулируемых индустриях.

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

Кто должен делать threat modeling

Команда, а не один security-эксперт. Разработчики знают код, architects — архитектуру, product managers — бизнес-контекст. Security-эксперт играет роль facilitator и предоставляет специализированную экспертизу. Если только security-команда делает threat modeling без разработчиков, теряется значительная часть ценности.

Сколько времени должно занимать threat modeling

Для small feature — 30–60 минут. Для нового сервиса или major refactor — 2–4 часа workshop с документированием. Для нового продукта с большой архитектурой — несколько сессий по 2–3 часа с follow-up работой. Не недели — это сигнал, что scope слишком широкий или процесс слишком тяжёлый.

STRIDE или PASTA — что выбрать

STRIDE для подавляющего большинства команд: простой, доступный, эффективный. PASTA для регулируемых индустрий (финансы, медицина, государство), где требуется глубокая интеграция с business risk management. Для стартапов и средних компаний STRIDE почти всегда правильный выбор.

Нужен ли специальный инструмент

На старте достаточно whiteboard или Miro для DFD и spreadsheet или Notion для документации угроз. Специализированные инструменты (Microsoft TMT, OWASP Threat Dragon) полезны при масштабировании practice на много команд и для consistency между ними.

Как мотивировать команду к threat modeling

Показывать ROI: примеры из реальных инцидентов в индустрии, которые могли быть предотвращены. Делать процесс понятным и не слишком тяжёлым. Интегрировать в существующий workflow, не создавая отдельную бюрократию. Признавать вклад команды через performance reviews. Включать в DoD на уровне организации.

Как измерить эффективность threat modeling

Несколько метрик: количество найденных угроз на сессию, процент mitigations реализованных в срок, security incidents которые не были предусмотрены в threat models (post-mortem-метрика), стоимость fix security-bugs после vs до внедрения threat modeling. Качественные метрики — feedback команд об ускорении принятия security-решений.

Заключение

Threat modeling — одна из самых ценных и недооценённых security-практик. Систематическое применение на этапе проектирования позволяет предотвращать большую часть security-уязвимостей до их возникновения, экономя ресурсы и снижая риски. STRIDE остаётся самой доступной методологией для большинства команд, PASTA подходит для регулируемых индустрий с более formal-требованиями. Attack trees, DFD, OCTAVE дополняют инструментарий для специфических задач.

Главный фактор успеха — не выбор методологии, а интеграция practice в обычный процесс разработки. Threat modeling как разовая активность даёт минимальную ценность; как часть SDLC с security champions, регулярными reviews и связью с development backlog — становится мощным инструментом improvement security posture организации. Начать стоит с light-weight подхода: STRIDE workshop для одного нового feature, simple документация, follow-up по выявленным угрозам. С этой базы можно постепенно расширять practice на всю команду и продукт, добавляя инструменты автоматизации и more sophisticated approaches по мере накопления опыта.