Threat modeling для веб-приложений: моделирование угроз до написания кода

Четыре вопроса

1. Что мы строим? Схема: участники, компоненты, хранилища данных, потоки между ними.
2. Что может пойти не так? Перебор угроз по каждому потоку и каждой границе доверия.
3. Что с этим делаем? По каждой угрозе одно из решений: снизить, передать, принять или избежать, с владельцем и сроком.
4. Достаточно ли сделали? Проверка: меры попали в задачи, а сценарии атаки стали тестами.

Чем отличается от аудита и ревью

Аудит и ревью читают то, что уже написано, и отвечают, какие ошибки в нём есть. Модель угроз работает со схемой замысла и отвечает, какие защиты должны быть и где их нет. Поэтому её делают до разработки или перед крупным изменением, а не вместо проверки готового кода. Проверка готовой системы описана на странице «Аудит безопасности веб-приложения», ревью кода — на странице «Secure code review».

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

Кто участвует

Нужны люди, которые знают, как система устроена на самом деле: разработчик или архитектор, аналитик, владелец продукта, администратор, который её эксплуатирует. Достаточно двух-трёх сессий по паре часов: мы ведём и записываем, вы отвечаете на вопросы.

Что рисуем

Сначала активы: что в системе ценно (персональные данные, договорные цены, права на платёж, ключи доступа). Затем потоки данных и границы доверия: там, где данные переходят от менее доверенного участника к более доверенному, чаще всего и живут угрозы. Схема остаётся в формате, который вы редактируете сами.

Условный пример: кабинет клиента с загрузкой документов

На схеме клиент в браузере, сервер приложения, база, хранилище файлов и обмен с 1С. Перебор по границам даёт, например, такие угрозы: ссылка на загруженный документ не имеет срока жизни (раскрытие), сотрудник поддержки входит «от имени клиента» без записи в журнале (отказ от действия), в окне загрузки принимается любой тип файла (подмена и повышение привилегий через содержимое). По каждой записывается решение, и это сразу превращается в три задачи.

• Кто может это сделать. Аноним из интернета, зарегистрированный пользователь, сотрудник партнёра, ваш сотрудник. Чем шире круг, тем выше приоритет.
• Что он получит. Чужие данные, деньги, управление системой или только неудобство. Утечка договорных цен и потеря журнала весят по-разному для разных бизнесов, поэтому вес задаёт владелец продукта.
• Насколько это трудно. Достаточно изменить число в адресе или нужна цепочка из нескольких условий. Если число в адресе, угроза почти всегда идёт первой.

Затем по каждой угрозе записывается решение. Снизить: добавить меру. Передать: платёж принимает провайдер, и данные карт не попадают к вам. Принять: оставить, как есть, с подписью владельца и сроком пересмотра. Избежать: убрать функцию, которая создаёт угрозу. Принятый риск без подписи мы считаем недоделанной работой.

Модель угроз стоит в начале цепочки. Её результат — список мер и сценариев, которые затем проверяются разными способами. Автоматически: SAST, DAST и SCA ловят типовые ошибки реализации. Человеком: ревью кода на безопасность проверяет права и логику, которые сканер не понимает.

Если нужно встроить безопасность во весь цикл разработки, от требований до эксплуатации, это безопасная разработка, а моделирование угроз в ней первый шаг. Для приложения с публичным API угрозы на границе обмена разбирает страница «Защита API от несанкционированного доступа», а выбор способа входа — SSO и MFA.

Как пройти сессию самим, если пока не нужен подрядчик, описано в статье «Как провести моделирование угроз веб-приложения».