Threat Modeling: STRIDE & LINDDUN

Зачем

Threat modeling — это дисциплина дизайн-стадии: за 1-2 часа на whiteboard'е команда отвечает на 4 вопроса (Что строим? Что может пойти не так? Что с этим делаем? Хорошо ли поработали?) и фиксирует список конкретных угроз с mitigations. По данным NIST, ~50% уязвимостей закладываются на этапе дизайна и стоят в 30 раз дороже, если их чинить после релиза. STRIDE (Microsoft, 1999) — самая известная mnemonic-таксономия для шага «что может пойти не так», LINDDUN — её privacy-аналог для GDPR-чувствительных систем, DREAD/CVSS — для приоритизации найденных угроз.

Threat model — это не «отчёт для аудитора», а рабочий артефакт команды: фотография доски + одностраничный список threats с owner-ами и Jira-тикетами на mitigations. Если документ никто не читает после написания — он мёртв.

Mental model

Threat modeling = DFD (Data Flow Diagram) + trust boundaries + STRIDE walk.

DFD рисуется тремя элементами: processes (то, что выполняет код), data stores (БД, файлы, кеши), external entities (пользователь, third-party API). Соединяются они data flows (рёбра со стрелками). Поверх рисуем trust boundaries — линии, через которые данные переходят «из менее доверенной зоны в более доверенную» (интернет → DMZ → app tier → data tier).

Главное правило: анализ STRIDE применяется к каждому пересечению trust boundary, не к каждому компоненту. На пересечении ставим 6 вопросов:

• Spoofing — может ли атакующий выдать себя за легитимного отправителя? (нарушает authentication)
• Tampering — может ли он изменить данные in-flight или at-rest? (нарушает integrity)
• Repudiation — может ли пользователь потом отрицать действие? (нарушает non-repudiation)
• Information disclosure — может ли утечь чувствительная информация? (нарушает confidentiality)
• Denial of service — может ли он положить компонент? (нарушает availability)
• Elevation of privilege — может ли он получить больше прав, чем должен? (нарушает authorization)

Для каждой угрозы — конкретный mitigation (control), owner, тикет. Список угроз без mitigations — это bookkeeping, не безопасность.

Что на диаграмме

Канва — упрощённый, но реалистичный backend: внешний пользователь, атакующий, edge (LB + WAF), application tier (auth, API, upload service), data tier (PostgreSQL c PII, KMS, S3, audit log). Группы соответствуют trust zones — данные, переходя между ними, проходят STRIDE-проверки.

• Internet (untrusted) — браузер легитимного user'а и attacker Mallory. Всё, что отсюда приходит, по умолчанию враждебно.
• DMZ (trust boundary 1) — LB терминирует TLS, WAF фильтрует rate/OWASP-сигнатуры. Это первый барьер; всё, что не остановлено здесь, попадает в app tier.
• App tier (trust boundary 2) — бизнес-логика: auth issues JWT, API сервит REST, upload пишет файлы. Тут происходит большинство S/T/E-проверок.
• Data tier (trust boundary 3) — crown jewels: PostgreSQL с PII, KMS с ключами шифрования, S3 с файлами, audit log. Сюда нет прямого доступа извне; только через app tier с обязательным auth+authz.

Каждое ребро в диаграмме — физическое соединение через границу. На пересечениях должны висеть проверки: TLS, JWT validation, IAM-role с least privilege, encryption at rest, audit logging. Edge от attacker к LB существует, чтобы напомнить: attacker уже в сети, периметр не равен безопасности.

Сценарии

STRIDE walk на login flow. Идём по 4-question framework: что мы строим (DFD), что может пойти не так (STRIDE по каждой boundary), что делаем (конкретный mitigation), хорошо ли (review). На каждом из 6 шагов рассматриваем одну букву применительно к login: S = атакующий выдаёт себя за user (mitigation: MFA + WebAuthn); T = меняет request body (TLS integrity + HMAC); R = user потом отрицает что логинился (signed audit log с IP+timestamp); I = bcrypt-хэши утекают из БД (encryption at rest + ACL); D = brute-force атака (rate limit + account lockout); E = JWT с подделанным role=admin (sign+verify, never trust client). Финал — review: pen-test, regression suite, table-top exercise.

STRIDE per-element для file upload feature. File upload — классический «привлекательный» компонент для атакующего: исполняемые файлы, path traversal, zip-бомбы, polyglot-форматы (валидный JPEG, который ещё и PHP). Проходим STRIDE: spoofing (требуем auth token), tampering (sanitize filename + UUID rename), information disclosure (per-user prefix в S3 + signed URLs, чтобы user1 не читал файлы user2), DoS (max-size + streaming + per-user quota), elevation (отдельный домен/субдомен для uploaded content, no execute permission — иначе .php = RCE). Audit log на каждый upload для forensics и compliance. Pen-test покрывает: zip bomb, polyglot, SSRF через SVG (<image href="http://internal">), EXIF leakage (GPS координаты в JPEG).

LINDDUN walk — privacy-focused threat model. Для GDPR-чувствительных систем STRIDE недостаточен — он про security, не про privacy. LINDDUN добавляет privacy-угрозы: Linkability (две сессии связываются в одного user через fingerprint), Identifiability (anonymous данные деанонимизируются: Latanya Sweeney показала что 87% американцев уникально идентифицируются по {zip, gender, dob}), Non-repudiation как privacy-проблема (право быть забытым: user должен мочь отозвать данные), Detectability (timing-attack на /forgot-password показывает, зарегистрирован ли email), Disclosure (error message «user not found in tenant Y» утекает metadata о существовании tenant'а), Unawareness (user не знает что мы собираем precise location и behavioural recording), Non-compliance (PII европейцев попадает в US-based S3 — Schrems II violation). Mitigations: granular consent UI, region pinning per tenant, generic error messages с constant time, soft-delete с tombstone + hard-delete через retention period, DSAR endpoint, DPIA для high-risk processing.

Trade-offs (ADR)

Главный design-trade-off threat modeling'а — как глубоко идти. Спектр: от 1-часового whiteboard'а на feature до 2-4 недель формального SDL-процесса с dedicated security architect и DFD-инструментами. Выбор зависит от трёх факторов: blast radius (формальный процесс обязателен для PII/PHI/payments/critical infra, потому что compliance-аудиторы требуют evidence, и whiteboard-фоткой их не убедить), частота изменений (microservices с 50 deploys/день не выдержат формальный процесс — модель устареет за неделю, нужен code-as-DFD типа PyTM/Threagile в CI), maturity команды (junior team тонет в формализме без понимания, лучше lightweight + pairing; senior выжимает из часа на доске больше insight-ов чем формальный процесс за неделю). Default — lightweight whiteboard на дизайн-стадии, эскалация к формальному процессу по триггерам (новая интеграция с external party, compliance audit, security incident).

Реальные системы

• Equifax 2017 (147M records) — Apache Struts CVE-2017-5638 был известен 2 месяца, патч существовал. Threat model не покрыл «outdated dependency» как класс угрозы. Lesson: SCA (Software Composition Analysis) и SBOM mandatory в SDLC, не «nice to have».
• Target 2013 (40M cards) — атакующие зашли через HVAC-вендора, у которого был network access к корпоративной сети, через которую дотянулись до POS-терминалов. Lesson: «trusted internal network» — миф. Microsegmentation, zero trust networking, vendor-аккаунты в отдельных сегментах.
• Capital One 2019 (100M) — SSRF на metadata endpoint + over-permissive IAM role на WAF-инстансе → доступ к S3 buckets. Threat model пропустил «что если WAF instance скомпрометирован». Lesson: least privilege per service, не per VM/cluster.
• SolarWinds 2020 — backdoor вставили в build pipeline, не в production-код. Подписанные обновления распространили на 18 000 клиентов. Lesson: supply chain — часть threat model, SLSA framework, reproducible builds, signed commits.
• Twitter 2020 Bitcoin scam — социнженерия → доступ к admin-панели → 130 verified-аккаунтов твитили scam. На admin tools не было MFA. Lesson: MFA на privileged operations обязательно, не опционально.
• Snowflake 2024 (AT&T, Ticketmaster) — customer-аккаунты без MFA были скомпрометированы через credential stuffing. Snowflake позиционировал MFA как «рекомендуемо». Lesson: для high-value platform-аккаунтов MFA = enforce, не recommend.
• Knight Capital 2012 ($440M) — старый код активирован случайно, нет audit log деплоев → не могли быстро понять что произошло. Lesson: R в STRIDE (non-repudiation) — это не только про user actions, но и про operator/admin actions.

Anti-patterns

• «Сделаем threat model после MVP» — на этом этапе rewrite уже невозможен, security становится набором patches поверх дырявой архитектуры. Threat model дешевле всего на whiteboard стадии.
• DFD без trust boundaries — без них непонятно, где attacker. Просто «нарисовали компоненты со стрелками» = архитектурная схема, не threat model.
• STRIDE по компонентам, а не по data flows — пропустишь interactions. Большинство уязвимостей живут не в одном компоненте, а на стыке.
• «Security team сделает за нас» — те, кто строит систему, знают её лучше. Security team модерирует процесс, добавляет pattern recognition, но owner threat model'a — команда фичи.
• Список угроз без mitigations и owner-ов — bookkeeping. Каждая угроза должна стать либо тикетом с assignee, либо «accepted risk» с подписью responsible party.
• DREAD scoring как primary метрика — Microsoft сами отказались, оценки субъективны (D=8 vs D=7 ничего не значит). Используй CVSS 3.1 для CVE и простую матрицу likelihood × impact для design threats.
• «Threat model сделан, идём дальше» — модель устаревает за 3-6 месяцев. Re-review при major change, новой external integration, security incident, как минимум раз в год.
• Шаблон ради шаблона — copy-paste 40-страничный template из интернета, заполненный «N/A» — бесполезно. Лучше одна страница с реальными threats, чем 40 пустых.

Когда НЕ использовать

Threat modeling — не silver bullet, и в нескольких ситуациях формальный процесс — overkill:

• Прототипы, hackathon-демки, throwaway-код — если код не доживёт до production и не обрабатывает реальных PII, формальная процедура не окупится. Sanity check на S и I достаточно.
• Внутренние tools на 5 пользователей без чувствительных данных — здесь threat model = code review с security mindset, не отдельная сессия.
• Замена кода без изменения trust boundaries — refactor сервиса, который не меняет data flows и granted permissions, не требует нового threat model. Re-use existing model.
• Compliance theater — если threat model делается «для галочки» перед SOC 2 audit и потом не используется командой, это пустые часы. Лучше один работающий процесс чем два галочных.
• Реактивный mode — threat modeling до инцидента дешёвый и эффективный; во время инцидента — отвлекает от reaction. После — обязательно делай post-mortem с update threat model.

Threat modeling также не заменяет: SAST/DAST (находят bugs в коде), pen-test (валидируют гипотезы), SIEM/detection (ловят атаку в runtime), bug bounty (находят то, что пропустили все остальные). Это дополнительный layer на дизайн-стадии.

Дальше читать

• [CONCEPT]owasp-top-10 — 10 классов уязвимостей, дополняет STRIDE конкретными CWE
• [CONCEPT]defense-in-depth — multi-layered security, каждый layer mitigation для разных STRIDE-категорий
• [CONCEPT]zero-trust-networking — «never trust, always verify», подход к trust boundaries
• [CASE]auth-system-design — threat model реального auth-сервиса (login, MFA, session)
• [CASE]payment-system-design — threat model платёжного пайплайна (PCI DSS scope)

Канон:

• Adam Shostack, «Threat Modeling: Designing for Security» (Wiley, 2014) — библия темы, 4-question framework впервые сформулирован тут
• OWASP Threat Modeling Cheat Sheet — практичный one-pager
• Microsoft SDL — оригинальный методологический gold standard
• NIST SP 800-154 (Data-Centric Threat Modeling), NIST SSDF SP 800-218 — для compliance evidence
• MITRE ATT&CK — knowledge base реальных TTPs, дополняет STRIDE конкретными техниками