Моделирование угроз

Материал проходит ревью.

MiddleФундамент ~48 мин

Границы темы

Scope: повторяемый инженерный процесс для backend-сервиса: ограничить объект анализа, показать потоки и доверие, сформулировать угрозы, выбрать response и получить доказательства.

Не рассматриваем: threat intelligence конкретного противника, red team exercise, полный penetration test и обещание перечислить «все возможные атаки».

Что нужно знать заранее

Нужно уметь различать конфиденциальность, целостность и доступность из статьи «Триада CIA», читать простую архитектурную схему и понимать путь HTTP-запроса через API к хранилищу.

Результаты обучения

После статьи читатель сможет:

определить границы конкретного моделирования;
построить data-flow diagram с внешними сущностями и trust boundaries;
записать угрозу как причинно-следственный сценарий;
найти пропуски с помощью STRIDE;
выбрать response и проверяемую mitigation;
назвать событие, после которого модель нужно обновить.

Основная модель

— не диаграмма и не таблица сама по

себе. Это связка модель системы → сценарии угроз → решения → доказательства.

OWASP рекомендует начинать с этих четырёх вопросов и не объявляет единственную обязательную методологию. NIST SP 800-154 рассматривает threat modeling как форму risk assessment и подчёркивает ограниченность ресурсов: модель нужна, чтобы тратить их на значимые сценарии, а не на абстрактную «максимальную безопасность».

Основные термины

Термин	Определение	Не путать с
Актив	Данные, функция или способность системы, потеря которой имеет влияние	Только таблица базы данных
Actor	Человек, сервис, процесс или внешняя система, способные действовать	Только злонамеренный хакер
Граница доверия	Место, где меняются гарантии об identity, данных, среде или полномочиях	Сетевой firewall как единственный вариант
Угроза	Возможный нежелательный сценарий, способный причинить влияние	Уже подтверждённая уязвимость
Уязвимость	Слабость, которую можно использовать в сценарии	Любая угроза
Mitigation	Изменение дизайна, control или процесса, снижающее риск	Название купленного продукта
Допущение	Утверждение, истинность которого требуется для модели	Неизменный факт
Остаточный риск	Риск, остающийся после выбранных решений	Риск, о котором забыли

Контекст: webhook оплаты

Сервис принимает уведомление платёжного провайдера и переводит заказ из pending в paid. Нельзя начать с «какие атаки бывают на webhook». Сначала нужно описать систему.

Границы здесь означают изменение гарантий:

входящий запрос контролируется внешней стороной;
proxy может подтвердить TLS-соединение, но не бизнес-полномочия события;
сообщение в очереди уже внутреннее, но может быть повторено или подменено при компрометации producer;
запись в БД меняет денежное состояние и требует более сильных инвариантов.

End-to-end процесс

1. Что моделируем

Зафиксируйте:

изменение или сценарий: «приём webhook оплаты», а не «весь fintech»;
версии диаграммы и контракта;
активы: статус заказа, сумма, provider event ID, ключ проверки подписи;
внешние зависимости и владельцев;
допущения: например, provider гарантирует уникальный event ID;
non-goals и срок следующего пересмотра.

2. Что может пойти не так

Формула полезного сценария:

text

actor + предусловие + действие/путь + актив + нарушенное свойство + влияние

Пример:

text

Внешний отправитель повторяет ранее перехваченный подписанный webhook.
Handler не хранит provider event ID и создаёт вторую операцию.
Нарушается целостность заказа: клиенту повторно начисляется платёж.

Это лучше записи «replay attack», потому что показывает точку изменения и ожидаемое влияние.

3. Что делаем

Для каждой приоритетной угрозы выберите явный response:

Response	Смысл	Пример
Устранить	Убрать опасную возможность или поток	Не принимать сумму из webhook, читать её у provider API
Снизить	Уменьшить вероятность или влияние	Проверять подпись, timestamp и уникальность event ID
Принять	Документированно оставить остаточный риск	Принять задержку reconciliation с владельцем и сроком
Передать	Перераспределить финансовые последствия	Страхование; техническая ответственность всё равно остаётся

4. Достаточно ли хорошо

Mitigation считается завершённой не после merge, а когда есть доказательство:

негативный test повторного event ID;
constraint или idempotency record в хранилище;
metric повторов и alert на аномалию;
owner и дата проверки;
решение об остаточном риске.

STRIDE как эвристика

STRIDE помогает пройти по компонентам и потокам и спросить, не пропущен ли класс сценариев.

Категория	Вопрос	Типичное свойство
Spoofing	Может ли actor выдать себя за другого?	Аутентичность, конфиденциальность
Tampering	Можно ли неправомерно изменить данные или код?	Целостность
Repudiation	Можно ли убедительно отрицать действие из-за нехватки доказательств?	Accountability
Information Disclosure	Может ли информация раскрыться без разрешения?	Конфиденциальность
Denial of Service	Можно ли лишить уполномоченного субъекта услуги?	Доступность
Elevation of Privilege	Может ли actor получить более сильные полномочия?	Авторизация, целостность

Что происходит под капотом

Threat model соединяет несколько видов доказательств:

Если связь оборвана, появляется типичная фикция:

диаграмма без угроз — обычная документация архитектуры;
угроза без влияния — неприоритизированный страх;
control без сценария — checkbox;
mitigation без теста и сигнала — недоказанное обещание.

Минимальный воспроизводимый пример

Создайте запись угрозы для webhook в следующем формате:

yaml

id: PAY-WH-01
scope: payment webhook v2
asset: order payment state
actor: external sender
preconditions:
  - valid event captured earlier
path: repeated webhook -> handler -> queue -> worker
violates: integrity
impact: duplicate financial operation
existing_controls:
  - signature verification
decision: mitigate
mitigations:
  - unique provider event id in durable storage
  - transactional state transition
verification:
  - replay the same event twice; one transition must occur
detection:
  - metric webhook_duplicate_total
owner: payments-team
review_trigger:
  - provider contract or event schema changes

Ожидаемый результат

Другой инженер без устного контекста может:

воспроизвести сценарий;
назвать нарушенное свойство и влияние;
проверить mitigation;
найти владельца и условие пересмотра.

Как диагностировать слабую запись

Признак	Что отсутствует
«Возможен replay»	Путь, предусловие и impact
«Использовать Redis»	Сценарий, semantics хранения и отказ Redis
`risk: high`	Обоснование приоритета
`fixed`	Test, telemetry и остаточный риск

Приоритизация без ложной точности

Для первой модели достаточно сравнимой качественной оценки:

Фактор	Вопрос
Влияние	Что произойдёт с пользователем, деньгами, данными и операциями?
Достижимость	Какие предусловия нужны и доступны ли они actor?
Масштаб	Один заказ, tenant, регион или вся система?
Обнаруживаемость	Узнаем ли мы о сценарии и за какое время?
Обратимость	Можно ли безопасно восстановить состояние?
Уверенность	Какие утверждения подтверждены, а какие являются допущениями?

Число с двумя знаками после запятой не повышает качество модели, если исходные вероятности придуманы. Важнее единые критерии, evidence и владелец решения.

Failure modes и типичные ошибки

Моделировать всю систему сразу. Scope становится неподъёмным, а решения — общими. Начните с изменения или критичного потока.
Рисовать deployment diagram без trust boundaries. Сетевое соседство не объясняет, где меняются гарантии.
Считать внутреннюю сеть доверенной. Внутренний producer тоже может быть скомпрометирован или ошибаться.
Путать угрозу и уязвимость. Угроза может существовать до обнаружения конкретной слабости; уязвимость становится значимой в контексте сценария и влияния.
Закрывать угрозу названием control. Нужны конфигурация, failure mode, test и наблюдаемость.
Проводить сессию один раз. Новый data flow, dependency, privilege или assumption требует пересмотра.

Практическое задание

Задача: смоделируйте восстановление пароля или загрузку файла.

Подготовьте:

scope и три non-goals;
DFD с минимум одной trust boundary;
активы и допущения;
пять сценариев угроз, включая CIA и abuse availability;
response, owner и verification для двух приоритетных сценариев;
trigger для следующего пересмотра.

Критерии готовности: каждый сценарий содержит actor, путь, предусловие, актив и impact; mitigation проверяется негативным тестом или операционной процедурой.

Подсказка

Для password reset проверьте enumeration аккаунтов, кражу и повтор токена, подмену адреса доставки, массовую отправку писем и отказ identity/email provider.

Проверка знаний

01Команда начинает threat modeling нового webhook endpoint. Что сделать первым?

Зафиксировать scope, поток данных, зависимости и довериеСразу выбрать WAFПрисвоить CVSS ещё не найденным угрозам

02Какая запись лучше всего описывает угрозу?

JWT небезопасенВнешний отправитель повторяет подписанный webhook; сервис повторно списывает деньги из-за отсутствия replay-защитыНужно поставить сканер

03Что делает mitigation проверяемой?

Назначенный владелецНегативный тест или процедура проверкиСигнал обнаружения и ожидаемая телеметрияТолько название продукта безопасности

04Восстановите рабочий цикл моделирования угроз.

Проверить модель и выполненные меры
Описать систему и границы
Выбрать response и владельца
Найти и приоритизировать сценарии

Самопроверка

Почему DFD ещё не является threat model?
Когда внутренняя очередь образует trust boundary?
Почему risk: high недостаточно для решения?
Какие изменения требуют пересмотра модели?

Ответы и критерии

DFD описывает систему, но не содержит сценариев, решений и доказательств.
Когда при переходе меняются гарантии об отправителе, формате, целостности, полномочиях или владении данными.
Нужны влияние, предусловия, масштаб, обнаруживаемость, уверенность и владелец.
Новые компоненты, data flows, privileges, зависимости, контракты, типы данных, сценарии использования и опровергнутые assumptions.

Краткое резюме

Threat modeling — непрерывный цикл, а не разовый документ.
Сначала моделируется система и доверие, затем угрозы и controls.
Полезная угроза — причинно-следственный, воспроизводимый сценарий.
STRIDE помогает искать пропуски, но не заменяет инженерное суждение.
Завершённая mitigation имеет owner, test, telemetry и остаточный риск.

Следующие шаги

В статье «Эшелонированная защита» выбранные mitigations раскладываются по независимым слоям предотвращения, обнаружения, ограничения ущерба и восстановления.

Источники

OWASP Threat Modeling Project — поддерживаемая точка входа и четыре методологически нейтральных вопроса.
OWASP Threat Modeling Cheat Sheet — практический цикл: system modeling, threat identification, response и review.
NIST SP 800-154, Initial Public Draft — data-centric threat modeling как форма risk assessment; источник явно остаётся draft.
FIPS 199 — свойства и потенциальное влияние, используемые для формулировки impact.

Моделирование угроз ​

Границы темы ​

Что нужно знать заранее ​

Результаты обучения ​

Основная модель ​

Основные термины ​

Контекст: webhook оплаты ​

End-to-end процесс ​

1. Что моделируем ​

2. Что может пойти не так ​

3. Что делаем ​

4. Достаточно ли хорошо ​

STRIDE как эвристика ​

Что происходит под капотом ​

Минимальный воспроизводимый пример ​

Ожидаемый результат ​

Как диагностировать слабую запись ​

Приоритизация без ложной точности ​

Failure modes и типичные ошибки ​

Практическое задание ​

Проверка знаний ​

Самопроверка ​

Краткое резюме ​

Следующие шаги ​

Источники ​