Суть. Разбор системы на компоненты и потоки данных, после чего по каждому месту задаётся вопрос: как это можно сломать или использовать не по назначению. Делается на этапе проектирования, когда исправление стоит дёшево.
Четыре вопроса
- Что мы строим — схема потоков данных и границ доверия
- Что может пойти не так — перечисление угроз по категориям
- Что с этим делаем — устранить, снизить, передать, принять
- Хорошо ли справились — проверка и пересмотр
Категории угроз
| Категория | Пример | Чем закрывается |
|---|---|---|
| Подмена личности | Вход под чужой учётной записью | Надёжная проверка личности |
| Изменение данных | Правка суммы в запросе | Проверка целостности, подписи |
| Отрицание действия | «Я этого не делал» | Журналирование, неизменяемые записи |
| Утечка | Данные видны тому, кому не должны | Шифрование, разграничение доступа |
| Отказ в обслуживании | Система недоступна | Ограничение частоты, резервирование |
| Повышение прав | Обычный пользователь получает административные права | Минимальные права, разделение ролей |
Четыре вопроса, из которых состоит разбор
| Вопрос | Что делаем | Результат |
|---|---|---|
| Над чем работаем | Схема системы: компоненты, потоки данных, границы доверия | Одна картинка, понятная всем участникам |
| Что может пойти не так | Перебор типов угроз по каждому потоку | Список сценариев, а не страхов |
| Что с этим делаем | Решение по каждому: устраняем, снижаем, передаём, принимаем | Задачи с владельцами |
| Достаточно ли хорошо сделали | Повторный разбор после изменений | Практика, а не разовое мероприятие |
Когда проводить
- При проектировании нового сервиса — до написания кода, пока изменения бесплатны.
- При изменении границ доверия: новая интеграция, новый тип пользователей, вынос компонента наружу.
- После инцидента — но как отдельное упражнение, не вместо разбора инцидента.
- Раз в год для критичных систем, даже если ничего не менялось: меняется окружение.
Где ломается
Делают один раз перед запуском. Архитектура меняется, модель устаревает за квартал.
Только специалисты по безопасности. Без разработчиков схема потоков будет неточной, а значит и угрозы найдены не те.
Находят угрозы и не приоритизируют. Список на сто пунктов без оценки риска не превращается в задачи.
Разбор превращается в перечень уязвимостей. Это работа сканера. Ценность моделирования угроз в том, чтобы найти то, что сканер не увидит: логику, права, доверие между компонентами.
Проводят только специалисты по безопасности. Без разработчиков схема будет неточной, без бизнеса — неверно расставлены приоритеты.
Результат никуда не попадает. Найденное не превращается в задачи и теряется вместе с презентацией.
Хороший разбор занимает от часа до половины дня и заканчивается пятью-семью конкретными задачами. Многодневное упражнение с сотней пунктов обычно означает, что границы системы выбраны слишком широко.
Частые вопросы
Связанное
Моделирование угроз — это проектная работа, а не проверка. Оно ценно тем, что меняет архитектуру до запуска, когда изменение ещё ничего не стоит.