Threat Modeling

«Security ревьюим за неделю до релиза» — типичный антипаттерн, который я регулярно вижу в командах без threat modeling. Код написан, архитектура зафиксирована, security приходит и находит фундаментальные проблемы дизайна — стоимость fix’а сравнима со стоимостью feature, либо релиз сдвигается. Threat Modeling — это дисциплина на design phase: четыре вопроса Manifesto (What are we building? What can go wrong? What will we do about it? Did we do enough?), DFD с trust boundaries, STRIDE per element, mitigation с явным статусом. Соседний лист к Secrets Management под L1 Information Security.

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

Главный навык на уровне L4 — применять STRIDE per element of DFD, не «угрозы вообще». Я регулярно вижу threat models, которые начинаются с brainstorm «какие угрозы возможны в системе» — получается длинный список несвязанных пунктов. STRIDE применяется к конкретному элементу DFD (внешний actor, process, data store, data flow) — 6 категорий per element, не все релевантны, но каждая рассматривается systematically. Результат — exhaustive, проверяемый, не «возможно мы что-то забыли».

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

Пишет threat model для нового feature: DFD с trust boundaries → identified threats per STRIDE category для каждого элемента → mitigations с явным статусом (implemented / planned / accepted).
Участвует в threat modeling sessions соседних команд как peer-reviewer; задаёт вопросы, выявляет упущенное; не «утверждает», а помогает.

Facilitates threat modeling session: собирает нужных людей (разработчик + ops + security), ведёт через STRIDE/PASTA, prioritizing threats по risk = likelihood × impact.
Связывает threat model с кодом: каждое identified mitigation имеет ссылку на код / config / runbook / test; security tests в CI отвечают за известные категории.
Применяет attack tree / kill chain analysis для complex multi-step threats; использует MITRE ATT&CK как vocabulary.

L6+

Устанавливает threat modeling как часть SDLC: когда обязателен, какой framework (STRIDE для большинства, PASTA для высокорискового), кто reviews, exit criteria.
Связывает threat modeling с compliance (SOC 2 / PCI-DSS / ISO 27001 / GDPR), vulnerability management, security incident response.

Материалы

Книги

Adam Shostack — Threat Modeling: Designing for Security (Wiley, 2014). Канонический учебник; автор разработал и популяризовал STRIDE в Microsoft. Practical guidance по DFD, STRIDE per element, attack trees, requirements analysis. По моим наблюдениям, это «один источник, если выбирать один».

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

OWASP Threat Modeling Cheat Sheet. Structured reference с STRIDE / PASTA / OCTAVE / LINDDUN / VAST; четыре foundational questions из Threat Modeling Manifesto.
Threat Modeling Manifesto. Ценности и принципы от индустрии (Shostack, Brook Schoenfield и др.); подчёркивает early analysis, dialog over documentation. Antipatterns (Hero Threat Modeler, Admiration for Problem, Tendency to Overfocus, Perfect Representation) — обязательное чтение.
MITRE ATT&CK. Knowledge base of adversary tactics & techniques; 15 tactics × hundreds techniques; vocabulary для описания complex / multi-step threats.

Инструменты

DFD-инструмент — draw.io / diagrams.net / Excalidraw / Microsoft Threat Modeling Tool. Главный артефакт threat model — DFD с trust boundaries.
Markdown threat model template в repo команды/сервиса (docs/threat-model.md рядом с архитектурой). По моим наблюдениям, в зрелых командах именно так и хранят — PR-based review, история через git, cross-ref на код.
Microsoft Threat Modeling Tool — desktop tool с STRIDE-templates и auto-generated threat suggestions из DFD. Полезен новичкам как обучающий вход; зрелые команды чаще ведут markdown.
OWASP Threat Dragon — open-source threat modeling tool с STRIDE / LINDDUN; web-based или desktop.

Best practices

Короткие правила:

Threat model на design phase, не «security review за день до релиза». Стоимость fix фундаментальной проблемы дизайна после написания кода сравнима со стоимостью feature. Threat model — первый артефакт design phase, до написания кода; security или senior инженер участвует как peer.
DFD first, threat second — не «вот код, найди уязвимости». Без data flow diagram непонятно, что входит в систему, какие boundaries пересекают данные, кому доверяем. DFD — основа: components → data flows → trust boundaries → STRIDE per element.
STRIDE per element of DFD, не «угрозы вообще». Brainstorm «какие угрозы возможны» даёт длинный список несвязанных пунктов. STRIDE применяется к конкретному element — exhaustive, проверяемый результат.

Подробнее:

Trust boundaries explicit, не «всё внутри сети безопасно». Zero-trust на бумаге, perimeter-trust по факту — частая ситуация. Каждое пересечение boundaries (network zone, deployment unit, role) — point, где threats умножаются. Boundary должен быть нарисован явно; threats per boundary получают повышенный вес в prioritization. Я регулярно вижу threat models без явных boundaries — там не видно, где именно требуется auth/auth, и всё «как-то проверяется».

Mitigation per threat с явным статусом. «Мы знаем про SQL injection, надо учесть» — через 6 месяцев не реализовано, инцидент. Каждое identified threat имеет mitigation с status (implemented / planned + дедлайн / accepted-with-risk + явным владельцем риска). Без status threat model — wish list.

Re-threat-modeling при major changes, не «однажды сделали — навсегда». Threat model написан два года назад, с тех пор архитектура поменялась, security predictions устарели. Triggers: major feature, изменение trust boundary, новый dependency, security incident, regulatory change. Cadence по-default — раз в год + по trigger.

Threat model = living document, не artifact для compliance. «Threat model заводится для аудита, после никто не открывает» — это compliance-театр. Living document: PR-flow, cross-references в код, security tests привязаны, обсуждение на 1:1 при изменении архитектуры. Когда документ живёт — он полезен; иначе — risk false sense of security.

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

Secrets Management — Information Disclosure / Tampering threats нередко mitigated через secret management practices.
Vulnerability Management — граница: threat modeling identifies what could go wrong (proactive); VM addresses what already is wrong (reactive).
Supply Chain Security — supply chain — один из trust boundaries в DFD; SLSA Level выбирается с учётом threat model.
Architecture Decision Records — security trade-offs (auth model, encryption boundary, network topology) фиксируются как ADR, опираясь на threat model.
Service Ownership — каталог сервиса содержит ссылку на текущую threat model; owner отвечает за её актуальность.
Infrastructure as Code — security controls (IAM policies, network policies, encryption) описываются как IaC.
Incident Response — threat model informs incident response: classes of incidents predictable из threat model.
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 — threat model говорит, что искать в ревью; security code review проверяет, что mitigations присутствуют в коде.

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

Vulnerability Management уже выделена в отдельный лист.
Access Control & IAM — выделен в отдельный лист (см. Связанные листья).
Compliance Frameworks — выделен в отдельный лист.
Security Code Review — выделен в отдельный лист (см. Связанные листья).
DAST / SAST tooling — automated security testing (SonarQube, Snyk, Semgrep) — дополняет threat modeling через runtime / static verification.