Threat Modeling

«Безопасность посмотрим за неделю до релиза» — типичный антипаттерн, который я регулярно вижу в командах без моделирования угроз. Код написан, архитектура зафиксирована, безопасник приходит и находит фундаментальные дыры в дизайне: починка стоит примерно столько же, сколько сама фича, либо релиз уезжает. Threat Modeling — это дисциплина этапа проектирования: четыре вопроса из Manifesto (что мы строим, что может пойти не так, что мы с этим сделаем, достаточно ли сделали), схема потоков данных с границами доверия, STRIDE по каждому элементу и меры защиты с явным статусом. Открывает L1 Secure Development: разбор угроз на дизайне стоит раньше кода, сборки и зависимостей.

Что должен уметь

Главный навык на уровне L4 — применять STRIDE к каждому элементу схемы, а не к «угрозам вообще». Я регулярно вижу модели, которые начинаются со свободного штурма на тему «какие угрозы у нас возможны», и получается длинный список несвязанных пунктов. STRIDE применяется к конкретному элементу: внешнему актору, процессу, хранилищу, потоку данных. Шесть категорий на элемент, релевантны не все, но пройдены все. На выходе получается полный и проверяемый разбор, а не «кажется, мы что-то забыли».

Понимает базовые threat categories по STRIDE: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Различает угрозу и меру защиты.
Читает существующие модели угроз; понимает границы доверия на схеме потоков данных (DFD); находит на ней свой сервис.

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

Ведёт сессию разбора: собирает нужных людей (разработчик, эксплуатация, безопасность), проводит их через STRIDE или PASTA, расставляет приоритеты по формуле «вероятность × ущерб».
Связывает модель с кодом: у каждой меры защиты есть ссылка на код, конфигурацию, runbook или тест, а тесты безопасности в CI закрывают известные категории.
Применяет дерево атак и разбор цепочки атаки для сложных многошаговых сценариев; берёт MITRE ATT&CK как общий словарь.

L6+

Встраивает моделирование угроз в жизненный цикл разработки: когда оно обязательно, какой фреймворк брать (STRIDE в большинстве случаев, PASTA для высокого риска), кто ревьюит, по каким критериям разбор считается закрытым.
Связывает его с комплаенсом (SOC 2, PCI-DSS, ISO 27001, GDPR), управлением уязвимостями и реагированием на инциденты безопасности.

Материалы

Книги

Adam Shostack — Threat Modeling: Designing for Security (Wiley, 2014). Канонический учебник. Саму аббревиатуру STRIDE придумали в Microsoft ещё в 1999 году Лорен Конфельдер и Праерит Гарг, а Шостак довёл её до методики и вынес наружу — из внутренней записки в отраслевой стандарт. Прикладные разборы: схемы потоков, STRIDE по элементам, деревья атак, работа с требованиями. По моим наблюдениям, это «один источник, если выбирать один».

Статьи и фреймворки

OWASP Threat Modeling Cheat Sheet. Структурированный справочник по STRIDE, PASTA, OCTAVE, LINDDUN и VAST; там же четыре базовых вопроса из Threat Modeling Manifesto.
Threat Modeling Manifesto. Ценности и принципы от индустрии (Shostack, Brook Schoenfield и др.); упор на ранний анализ и на разговор вместо документа. Раздел про антипаттерны (Hero Threat Modeler, Admiration for Problem, Tendency to Overfocus, Perfect Representation) — обязательное чтение.
MITRE ATT&CK. База знаний по тактикам и техникам противника: пятнадцать тактик и сотни техник. Работает как общий словарь для описания сложных многошаговых угроз.

Инструменты

DFD-инструмент — draw.io / diagrams.net / Excalidraw / Microsoft Threat Modeling Tool. Главный артефакт модели — схема потоков данных с границами доверия.
Шаблон модели угроз в markdown в репозитории команды или сервиса (docs/threat-model.md рядом с архитектурой). По моим наблюдениям, в зрелых командах именно так и хранят: ревью через PR, история в git, перекрёстные ссылки на код.
Microsoft Threat Modeling Tool — настольная программа с шаблонами STRIDE, которая сама предлагает угрозы по схеме. Полезна новичку как учебный вход; зрелые команды чаще ведут markdown.
OWASP Threat Dragon — открытый инструмент со STRIDE и LINDDUN, в браузере или на десктопе.

Best practices

Порядок здесь важнее содержания. Модель пишется до кода. Переделать фундаментальное решение после того, как код написан, стоит примерно столько же, сколько стоила сама фича. Security или старший инженер сидит в этой сессии как равный участник, а не как приёмка на выходе.

Сначала DFD, потом угрозы. Без диаграммы потоков данных разговор скатывается к «вот код, найди уязвимости», а на этот вопрос никто честно не ответит: непонятно, что входит в систему, какие границы пересекают данные и кому мы вообще доверяем. Компоненты, потоки, границы доверия — и только после этого STRIDE по каждому элементу.

Именно по элементу, а не «по системе». Свободный штурм на тему «какие угрозы у нас возможны» даёт длинный список несвязанных пунктов, который невозможно ни проверить, ни закрыть. Шесть категорий на каждый элемент дают результат, про который видно, что он полный.

Границы доверия рисуются явно, а не «внутри сети всё своё». Zero-trust на бумаге и доверие по периметру на деле — частая пара. Каждое пересечение границы (сетевая зона, единица деплоя, роль) — точка, где угрозы размножаются, поэтому граница рисуется явно, а угрозы на ней получают повышенный вес при приоритизации. Я регулярно вижу модели без явных границ. В них не видно, где именно нужны аутентификация и авторизация, и всё «как-то проверяется».

У каждой угрозы своя мера защиты и явный статус. «Мы знаем про SQL injection, надо учесть» — формулировка, которая через полгода превращается в инцидент. У каждой выявленной угрозы есть мера со статусом: сделано, запланировано с датой или риск принят — и тогда у риска есть владелец. Без статуса модель угроз превращается в список пожеланий.

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

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

Связанные листья

Secrets Management — угрозы категорий Information Disclosure и Tampering нередко закрываются именно дисциплиной работы с секретами.
Vulnerability Management — граница: моделирование угроз ищет, что может пойти не так, а VM разбирается с тем, что уже не так.
Supply Chain Security — цепочка поставок — одна из границ доверия на схеме; уровень SLSA выбирается с оглядкой на модель.
Architecture Decision Records — компромиссы по безопасности (модель аутентификации, граница шифрования, топология сети) фиксируются в ADR, опираясь на модель угроз.
Service Ownership — каталог сервиса хранит ссылку на актуальную модель; за её свежесть отвечает владелец.
Infrastructure as Code — контроли безопасности (политики IAM, сетевые политики, шифрование) описываются как код.
Incident Response — модель угроз питает реагирование: классы инцидентов из неё предсказуемы заранее.
Access Control & IAM — STRIDE категория Elevation of Privilege — основной источник IAM-требований; trust boundaries проводятся по identity границам.
Compliance Frameworks — SOC 2 CC3.x / ISO 27001 A.5.7 требуют risk assessment; threat model — наиболее операциональная форма.
Security Code Review — модель говорит, что искать в ревью; ревью проверяет, что меры защиты в коде действительно есть.

Открытые вопросы

Vulnerability Management, Access Control & IAM, Compliance Frameworks и Security Code Review уехали отсюда в отдельные листья — ссылки в разделе выше.

Осталось одно живое направление: инструменты SAST и DAST. Автоматические проверки (SonarQube, Snyk, Semgrep) дополняют разбор угроз статическим и динамическим анализом. Разбор на дизайне не спасает от уязвимости, которая приедет в готовой библиотеке через полгода после релиза; для этого есть Vulnerability Management, и граница между двумя практиками проходит ровно здесь.