Моделирование угроз отвечает на вопрос «что может пойти не так» до того, как код написан. Это самая дешёвая практика безопасности: ошибку в архитектуре исправить на схеме в сотни раз проще, чем после релиза. На собесе AppSec почти всегда есть кейс «смоделируйте угрозы для системы X».
Четыре вопроса
Адам Шостак сводит моделирование к четырём вопросам:
- Над чем мы работаем? Схема системы.
- Что может пойти не так? Угрозы.
- Что мы с этим сделаем? Меры.
- Хорошо ли мы справились? Проверка и пересмотр.
Шаг 1. Диаграмма потоков данных
DFD (data flow diagram) из пяти элементов:
- Внешняя сущность: пользователь, партнёр, внешний API (прямоугольник).
- Процесс: ваш сервис, функция (круг).
- Хранилище: база, очередь, бакет, кеш (две линии).
- Поток данных: стрелка с подписью, что передаётся и по какому протоколу.
- Граница доверия: пунктир там, где меняется уровень доверия: интернет и DMZ, сервис и база, ваш код и сторонний SaaS, пользователь и администратор.
Угрозы концентрируются на пересечениях границ доверия: там данные приходят от менее доверенной стороны.
Шаг 2. STRIDE
Шесть категорий угроз, каждая нарушает одно свойство безопасности:
| Угроза | Нарушаемое свойство | Пример | Типичная мера |
|---|---|---|---|
| Spoofing (подмена) | Аутентичность | Вход под чужим аккаунтом, поддельный вебхук | Аутентификация, MFA, подпись, mTLS |
| Tampering (изменение) | Целостность | Изменение суммы в запросе, подмена файла | Подпись, HMAC, проверки на сервере, контроль доступа на запись |
| Repudiation (отказ) | Неотказуемость | «Я не делал этот перевод» | Аудит-логи, защищённые от изменения, подписи |
| Information disclosure (раскрытие) | Конфиденциальность | Утечка ПДн, подробные ошибки | Шифрование, авторизация, минимизация данных |
| Denial of service (отказ в обслуживании) | Доступность | Флуд, тяжёлые запросы | Лимиты, квоты, масштабирование |
| Elevation of privilege (повышение привилегий) | Авторизация | Обычный пользователь стал админом | Проверка прав, минимальные привилегии, изоляция |
STRIDE по элементам помогает не забыть: внешней сущности угрожают в основном S и R; процессу все шесть; потоку данных T, I, D; хранилищу T, I, D, а если это журнал, то и R.
Другие подходы: LINDDUN для приватности, PASTA как риск-ориентированный процесс, деревья атак для разбора конкретной цели, MITRE ATT&CK как каталог техник атакующих.
Шаг 3. Оценка и меры
Для каждой угрозы: вероятность и ущерб (риск), затем решение:
- Снизить: мера безопасности (основной вариант).
- Устранить: убрать функцию или данные.
- Передать: страховка, провайдер.
- Принять: осознанно, с владельцем риска.
Угрозы превращаются в задачи бэклога и требования с критериями приёмки, иначе модель останется документом в вики. Шкалы риска могут быть простыми: высокий, средний, низкий.
Шаг 4. Проверка
- Меры реализованы и проверены тестами или пентестом.
- Модель обновляется при изменении архитектуры: новая интеграция, новый тип данных, выход в интернет.
- Разбор инцидентов возвращается в модель: почему угрозу не увидели.
Как вести сессию
- Участники: разработчики системы, архитектор, AppSec, иногда продакт. Модель строит команда, AppSec фасилитирует.
- Время: 1-2 часа на фичу. Лучше маленькие частые модели, чем большая раз в год.
- Начинать с ценного: деньги, ПДн, учётные данные, административные функции.
- Результат: схема, список угроз, решения и задачи.
Частые ошибки
- Моделировать после релиза.
- Список угроз без мер и владельцев.
- Только технические угрозы, без злоупотребления бизнес-логикой.
- Забыть администраторов, поддержку, CI и сторонние сервисы.
Что спросят на собесе
- Расскажите, как вы проводите моделирование угроз.
- Что такое граница доверия, где их рисовать.
- Разберите по STRIDE систему: вход, платежи, загрузку файлов.
- Как превратить модель угроз в работу для команды.
- Когда модель нужно пересматривать.