Эта глава темы 12 фокусируется на threat modeling методах STRIDE/LINDDUN и приоритизации рисков.
В реальном проектировании систем материал помогает закладывать security-by-design: заранее фиксировать boundaries доверия, требования к контролям и эксплуатационные процедуры реакции на угрозы.
Для System Design interview глава полезна тем, что дает структурированный security reasoning: как выявляются угрозы, почему выбраны конкретные контроли и как оценивается остаточный риск.
Практическая польза главы
Практика проектирования
Используйте материал по threat modeling методах STRIDE/LINDDUN и приоритизации рисков, чтобы формировать архитектурные security-требования до этапа реализации.
Качество решений
Проверяйте решения через модель угроз, security invariants и управляемость контролей в production, а не только через чеклист соответствия.
Interview articulation
Стройте ответ в формате threat -> control -> residual risk, показывая связь между бизнес-сценарием и техническими мерами защиты.
Trade-off framing
Явно описывайте компромиссы по threat modeling методах STRIDE/LINDDUN и приоритизации рисков: UX friction, latency overhead, стоимость сопровождения и требования compliance.
Контекст
OWASP Top 10 в контексте System Design
OWASP отвечает на вопрос «что защищать», а STRIDE/LINDDUN - «как системно находить угрозы».
Threat Modeling - это инженерная практика, которая переводит разговор о безопасности и приватности из абстракции в конкретные архитектурные решения. В этой главе мы используем STRIDE для security-рисков и LINDDUN для privacy-рисков, чтобы получить проверяемый backlog контролей.
Когда выбирать STRIDE, LINDDUN или оба подхода
STRIDE - для security угроз
Подходит для анализа угроз целостности и доступности: spoofing, tampering, privilege escalation, DoS и подделки операций.
LINDDUN - для privacy угроз
Фокус на рисках приватности: связуемость действий пользователя, deanonymization, утечки чувствительных данных и policy non-compliance.
STRIDE + LINDDUN - для цифровых продуктов с PII
Комбинируйте оба подхода, если в системе одновременно важны бизнес-риски безопасности и риски обработки персональных данных.
STRIDE: категории угроз и архитектурные контроли
SSpoofing
Ключевой вопрос: Кто может выдать себя за доверенный субъект?
Пример угрозы: Подмена service account для доступа к внутреннему API.
Контроли: MFA, mTLS, signed tokens, device/workload identity.
TTampering
Ключевой вопрос: Где данные могут быть изменены без авторизации?
Пример угрозы: Подмена payload между BFF и backend сервисом.
Контроли: Подписи сообщений, checksums, immutable logs, strict authz.
RRepudiation
Ключевой вопрос: Кто может отрицать совершённое действие?
Пример угрозы: Пользователь отрицает операцию оплаты без доказуемого audit trail.
Контроли: Коррелируемые audit logs, timestamping, request IDs, non-repudiation proofs.
IInformation Disclosure
Ключевой вопрос: Какие данные могут утечь?
Пример угрозы: PII попадает в логи и трассировки с открытым доступом.
Контроли: Data classification, masking, encryption, policy-based access control.
DDenial of Service
Ключевой вопрос: Что может вывести сервис из строя?
Пример угрозы: Перегрузка публичного API бот-трафиком без rate limit.
Контроли: Rate limits, queueing, autoscaling bounds, circuit breakers, WAF.
EElevation of Privilege
Ключевой вопрос: Как атакующий может получить более высокие права?
Пример угрозы: IDOR и эскалация с user role на admin role.
Контроли: Least privilege, policy checks on every hop, permission boundaries, periodic reviews.
LINDDUN: privacy-угрозы и меры защиты
LLinkability
Ключевой вопрос: Можно ли связать разные действия одного пользователя?
Пример риска: Единый device identifier связывает поведение в разных контекстах.
Контроли: Pseudonymization, rotating identifiers, separation of datasets.
IIdentifiability
Ключевой вопрос: Можно ли восстановить личность из данных?
Пример риска: Комбинация ZIP + дата рождения + пол раскрывает личность.
Контроли: k-anonymity подходы, minimization, aggregation, differential privacy where relevant.
NNon-repudiation
Ключевой вопрос: Не нарушает ли неизбежная доказуемость право на приватность?
Пример риска: Логи операций позволяют однозначно восстановить действия пользователя.
Контроли: Policy-driven retention, scoped audit access, purpose limitation.
DDetectability
Ключевой вопрос: Можно ли обнаружить наличие пользователя или его состояния?
Пример риска: По времени ответа можно определить существование аккаунта.
Контроли: Constant-time responses, generic errors, traffic padding for sensitive flows.
DDisclosure of Information
Ключевой вопрос: Где возможна утечка персональных данных?
Пример риска: Экспорт данных без фильтрации чувствительных полей.
Контроли: Encryption, redaction, DLP controls, least-privilege data access.
UUnawareness
Ключевой вопрос: Понимает ли пользователь, какие данные и зачем собираются?
Пример риска: Скрытая телеметрия без прозрачного consent UX.
Контроли: Consent UX, just-in-time notices, data usage transparency.
NNon-compliance
Ключевой вопрос: Соответствуют ли процессы требованиям закона и политики?
Пример риска: Хранение данных дольше разрешённого срока по регуляторике.
Контроли: Data retention policies, legal basis tracking, automated compliance checks.
Пошаговый workflow threat modeling
1. Зафиксировать scope и архитектурный контекст
Определите границы системы, типы пользователей, доверенные/недоверенные зоны и бизнес-активы с наибольшим риском.
Результат: Список активов и trust boundaries.
2. Построить DFD и точки пересечения доверия
Отрисуйте data flow между клиентом, API gateway, сервисами, очередями и хранилищами. Отдельно выделите external dependencies.
Результат: Data Flow Diagram с явными trust boundaries.
3. Прогнать STRIDE по каждому элементу схемы
Для процесса, data store, data flow и external entity задайте вопросы из STRIDE и зафиксируйте наблюдаемые угрозы.
Результат: Черновой реестр security threats.
4. Прогнать LINDDUN по потокам PII/персональных данных
Для пользовательских идентификаторов, профилей, аналитики и событий оцените privacy-риски и требования по прозрачности.
Результат: Реестр privacy threats и compliance gaps.
5. Приоритизировать угрозы и назначить owners
Оцените likelihood x impact, определите mitigation strategy и назначьте владельца для каждого threat item.
Результат: Приоритизированный backlog мер защиты.
6. Встроить контроли в delivery lifecycle
Добавьте security/privacy controls в ADR, CI/CD gates, observability и план инцидентного реагирования.
Результат: План внедрения + критерии приёмки.
Практический пример: checkout + профиль пользователя
Checkout API
STRIDE: Spoofing: подмена токена клиента; Tampering: изменение суммы заказа; DoS: перегрузка endpoint.
LINDDUN: Detectability: утечка существования аккаунта по различию ошибок; Disclosure: PII в логах оплаты.
Контроли: mTLS + signed JWT, idempotency keys, rate limits, masked logs, consistent error responses.
User Profile Service
STRIDE: Elevation of Privilege: чтение чужого профиля; Repudiation: отсутствие доказуемого аудита изменений.
LINDDUN: Linkability: объединение поведенческих событий; Non-compliance: нарушение сроков хранения профилей.
Контроли: ABAC/ReBAC checks, immutable audit trail, pseudonymous analytics IDs, retention automation.
Какие артефакты должны остаться после сессии
- DFD с явными trust boundaries и перечнем внешних зависимостей.
- Threat register (STRIDE + LINDDUN) с severity, owner и сроком remediation.
- Список обязательных controls для архитектуры и CI/CD.
- Набор security/privacy тестов, связанных с конкретными угрозами.
- План регулярного пересмотра threat model при изменениях архитектуры.
Типичные антипаттерны и рекомендации
Типичные антипаттерны
Проводить threat modeling один раз «для галочки» перед релизом.
Ограничиваться только STRIDE и игнорировать privacy-риски для продуктов с PII.
Не фиксировать владельцев и сроки закрытия угроз, оставляя список без исполнения.
Не обновлять модель угроз после появления новых интеграций и data flows.
Рекомендации
Включайте threat modeling в Definition of Ready для крупных архитектурных изменений.
Начинайте с простого DFD и коротких сессий, а не с попытки сразу покрыть всю систему.
Связывайте каждую high-risk угрозу с конкретным контролем и тестом в CI/CD.
Комбинируйте STRIDE и LINDDUN для систем, где важны и security, и privacy outcomes.
Связанные материалы
Связанные главы
- OWASP Top 10 в контексте System Design - помогает связать выявленные угрозы с архитектурными controls и приоритизацией security backlog.
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - закрывает важную часть STRIDE-рисков (spoofing/elevation of privilege) через корректные identity-потоки.
- API Security Patterns - переводит threat model в прикладные API-контроли: валидация, anti-abuse и управление ключами/токенами.
- Zero Trust: современный подход к безопасности архитектуры - усиливает модель угроз практиками непрерывной верификации и сегментацией trust boundaries.
- Data Governance & Compliance - добавляет governance и regulatory perspective для LINDDUN-рисков в работе с персональными данными.