Контекст

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

• Моделирование угроз позволяет команде заранее договориться о том, что защищаем, от кого и насколько серьёзно воспринимаем каждый риск.
• QA не создаёт угрозы — QA верифицирует, что существующие защиты от этих угроз работают корректно.
• Популярная методология STRIDE делит угрозы на шесть категорий: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
• Моделирование угроз выполняется на разрешённом тестовом стенде или специально созданном окружении, а не на боевых системах.
• Результатом моделирования является список угроз с оценкой риска и перечнем проверок для QA.

Рабочий алгоритм

Чтобы применить моделирование угроз в работе QA-инженера, используйте следующий пошаговый подход:

• Получите или составьте диаграмму потоков данных (DFD): что и куда передаётся, через какие компоненты проходит.
• Для каждого компонента и каждого потока данных пройдитесь по категориям STRIDE и задайте вопрос: 'Что может пойти не так здесь?'
• Запишите каждую угрозу в виде: 'Злоумышленник может [действие], если [условие], что приводит к [последствию]'.
• Уточните у разработчиков или security-инженера, какие защитные механизмы уже реализованы для каждой угрозы.
• Для каждого защитного механизма напишите один или несколько тест-кейсов, проверяющих его наличие и корректность в тестовой среде.
• Свяжите тест-кейсы с требованиями или user stories — это позволит отслеживать покрытие.

Пример из практики

Команда разрабатывает API для мобильного банка. QA-инженер участвует в сессии моделирования угроз на этапе проектирования. DFD показывает, что мобильное приложение передаёт токен авторизации в заголовке каждого запроса. Применяя STRIDE, команда выявляет угрозу типа Tampering: клиент мог бы изменить идентификатор пользователя в теле запроса и попытаться получить чужие данные. QA-инженер фиксирует эту угрозу и пишет тест-кейс: в авторизованном запросе к /api/v1/account/{id} подставить id другого пользователя и проверить, что сервер возвращает 403 Forbidden, а не данные чужого аккаунта. Тест выполняется на тестовом стенде с тестовыми учётными записями. Результат проверки подтверждает, что серверная валидация работает корректно, и закрывается как Pass.

Частые ошибки

QA-инженеры, начинающие работу с моделированием угроз, часто допускают следующие ошибки:

• Путают моделирование угроз с написанием эксплойтов — задача QA не атаковать систему, а верифицировать защиты.
• Пропускают этап выяснения реализованных механизмов защиты и пишут тесты для несуществующих контролей.
• Не фиксируют угрозы документально, полагаясь на устную договорённость — это ведёт к потере контекста при следующей итерации.
• Проводят проверки на production-среде вместо разрешённого тестового стенда.
• Ограничиваются только одной категорией STRIDE (чаще всего Information Disclosure), не проходя по всем шести.