Модель угроз: как разработчику анализировать угрозы без бюрократии

Прямой ответ

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

Базовый процесс:

1. Декомпозиция. Нарисуйте диаграмму: компоненты, хранилища данных, внешние сущности и потоки между ними.
2. Границы доверия. Отметьте, где данные пересекают границу между зонами с разным уровнем доверия: интернет — приложение, приложение — база данных, сервис — внешний API.
3. Применение STRIDE к каждому элементу:
   • Spoofing (подмена личности) — можно ли выдать себя за другого пользователя или сервис?
   • Tampering (несанкционированное изменение) — можно ли изменить данные на пути или в хранилище?
   • Repudiation (отказ от авторства) — можно ли выполнить действие и не оставить следов?
   • Information disclosure (раскрытие информации) — куда данные могут утечь?
   • Denial of service (отказ в обслуживании) — можно ли вывести компонент из строя?
   • Elevation of privilege (повышение привилегий) — можно ли получить больше прав, чем положено?
4. Приоритизация. Оценивается вероятность и последствия; сначала исправляется то, что легко эксплуатируется и дорого обходится.
5. Меры. Для каждой угрозы — контрмера или осознанное принятие риска с фиксацией решения.
6. Проверка. Тесты и проверки, подтверждающие, что контрмера работает.

Практический формат — таблица, а не документ на сто страниц:

Практика: разбор реального сервиса

Шаг 1. Диаграмма. Для сервиса «личный кабинет» достаточно пяти элементов: браузер, веб-приложение, база данных, очередь задач, платёжный провайдер. Потоки: запросы пользователя, записи в БД, постановка задач в очередь, вызовы внешнего API.

Шаг 2. Границы доверия. Первая — между браузером и приложением (данные недоверенные). Вторая — между приложением и базой (приложение доверенное, но его учётная запись не должна иметь лишних прав). Третья — между приложением и платёжным провайдером (внешняя сторона, требуется подпись и проверка ответа).

Шаг 3. Прогон STRIDE по потокам. Каждый поток проверяется по шести категориям. Практика показывает: для одного потока обычно находится одна-две значимые угрозы, а не шесть.

Шаг 4. Приоритизация. Оценка «вероятность × последствия» без точных формул: высокий/средний/низкий. Цель — не посчитать риск, а договориться о порядке работ.

Шаг 5. Контрмеры. Большинство мер уже известны из стандартных практик: проверка входных данных, параметризованные запросы, контроль доступа по ролям — см. RBAC, защита от межсайтовых атак — см. CSRF и XSS, общий список классов уязвимостей — OWASP Top 10. Ценность threat modeling в том, что меры привязываются к конкретным элементам вашей системы, а не применяются «вообще».

Шаг 6. Проверка. Каждая контрмера получает проверку: тест, правило статического анализа, правило мониторинга или пункт чек-листа развёртывания.

Рекомендации:

1. Начинайте с изменения, а не с системы целиком. Модель угроз для нового функционала за час полезнее идеальной модели всего продукта, которую никто не доделает.
2. Делайте это вдвоём. Разработчик и человек с другим контекстом (тестировщик, другой разработчик, оператор) находят разные вещи.
3. Фиксируйте принятые риски. Запись «риск принят, потому что вероятность низкая, а mitigation стоит месяц работы» — легитимный результат.
4. Обновляйте модель при архитектурных изменениях. Новый внешний сервис или новый поток данных — повод вернуться к таблице.
5. Не стремитесь к полноте. Пропущенная угроза в живой модели дешевле идеальной модели, которая устарела через месяц после создания.

Практический сценарий: разбор перед запуском нового интеграционного потока

Контекст: команда добавляла приём вебхуков от партнёра и планировала запуск за две недели. Threat modeling занял полтора часа.

1. Диаграмма. Партнёр — внешний сервис, наш приёмник — публичный HTTP-эндпоинт, дальше очередь и обработчик, который пишет в базу и инициирует возврат средств.
2. Находка 1: подмена отправителя (Spoofing). Подпись проверялась, но сравнение выполнялось обычной оператором сравнения строк, что уязвимо к атаке по времени. Заменили на сравнение с постоянным временем.
3. Находка 2: повторная доставка (Tampering / Elevation). Повторная отправка того же вебхука приводила к повторному возврату средств. Добавили идемпотентность по идентификатору события: уникальный индекс и проверка перед обработкой.
4. Находка 3: раскрытие информации. Ответ приёмника возвращал текст внутренней ошибки с деталями запроса к базе. Заменили на стандартный ответ, детали — только в журнал.
5. Находка 4: отказ в обслуживании. Ограничений на частоту запросов с одного источника не было. Добавили лимит по частоте и размеру тела.
6. Проверка. Каждая находка получила тест; интеграционный тест отправляет дубликат вебхука и проверяет, что второй возврат не создаётся.

Итог: четыре исправления до запуска вместо разбора инцидента после. Стоимость — полтора часа обсуждения и день работы.

FAQ

Нужен ли специальный инструмент для threat modeling? Для начала достаточно доски и таблицы. Инструменты помогают вести модели в актуальном состоянии и совместно их редактировать, но ценность создаёт сам разбор, а не диаграмма.

Кто должен это делать? Разработчик, который строит функционал, вместе с человеком с другим контекстом. Отдельная «служба безопасности», которая делает модель угроз вместо команды, обычно производит документ, который никто не читает.

Чем threat modeling отличается от проверки по чек-листу OWASP? Чек-лист перечисляет типовые классы уязвимостей и помогает не забыть очевидное. Threat modeling привязывает их к конкретной архитектуре и находит проблемы, специфичные для ваших потоков данных и границ доверия. Используются вместе.

Как часто обновлять модель? При каждом значимом архитектурном изменении: новый внешний сервис, новый поток персональных данных, изменение модели доступа, выход за пределы исходного периметра. Полный пересмотр раз в год — разумный минимум для стабильной системы.

Источники: OWASP Threat Modeling, OWASP Threat Dragon, Microsoft Threat Modeling Tool — ссылки в шапке.