Модели угроз — STRIDE, PASTA, LINDDUN и их вариации — отлично дисциплинируют мышление. Они помогают системно искать уязвимости, расставлять приоритеты и говорить с бизнесом на одном языке. Но у любой модели есть тень. В этой статье — о рисках, которые часто остаются за кадром формальных threat model’ов, хотя именно они регулярно «стреляют» в реальных инцидентах.
1. Человеческий фактор вне сценариев
В моделях угроз человек обычно фигурирует как абстрактный «пользователь», «администратор» или «злоумышленник». В жизни же люди:
устают и совершают рутинные ошибки;
обходят правила ради скорости;
интерпретируют инструкции по-своему;
действуют эмоционально под давлением.
Классический пример — временные исключения в безопасности, которые «поживут пару дней», а затем становятся постоянными. Формально угрозы нет, но фактически система живёт в состоянии ослабленного контроля.
Почему выпадает: сложно формализовать и почти невозможно оценить количественно.
2. Организационные и политические риски
Модель угроз редко учитывает внутреннюю политику компании:
конфликты между командами;
KPI, стимулирующие рискованное поведение;
давление сроков и маркетинга;
смену руководства.
В итоге появляются решения «временно в прод», отключённые проверки и доступы «на всякий случай». Это не баги в коде — это баги в управлении.
Слепая зона: модель смотрит на систему, а не на организацию вокруг неё.
3. Риски цепочек доверия
Threat modeling хорошо работает с прямыми зависимостями, но хуже — с косвенными:
зависимости зависимостей (transitive dependencies);
доверие к CI/CD, артефактам, контейнерам;
компрометация инфраструктуры поставщика.
Инциденты уровня SolarWinds показали: система может быть «безопасной», пока не скомпрометирован тот, кому она доверяет.
Проблема: граница модели угроз часто совпадает с границей ответственности команды.
4. Экономические и мотивационные перекосы
Модель угроз предполагает рационального атакующего. Но в реальности мотивации бывают странными:
атака ради репутации или хайпа;
саботаж изнутри без финансовой выгоды;
демонстративные взломы «из принципа»;
атаки, убыточные для атакующего, но разрушительные для жертвы.
То, что кажется «нерациональным» в модели, может быть вполне логичным в социальной или политической плоскости.
5. Риски устаревших допущений
Любая модель угроз строится на предположениях:
кто атакующий;
какие у него ресурсы;
какие активы наиболее ценны.
Со временем эти допущения устаревают, но модель продолжает жить. В итоге защищают не то и не от тех.
Типичный симптом: модель угроз не обновлялась годами, но используется как аргумент в архитектурных решениях.
6. Эффект «бумажной безопасности»
Иногда модель угроз существует только как документ:
её сделали ради галочки;
выводы не дошли до разработки;
mitigations не были внедрены;
риски «приняли», не осознав последствий.
Формально всё сделано правильно, фактически — безопасность не изменилась.
Опасность: ложное чувство защищённости.
7. Неучтённые сценарии деградации
Модели угроз фокусируются на атаках, но редко рассматривают:
частичные отказы;
деградацию сервисов;
ручные операции в аварийном режиме;
работу системы «на костылях».
А именно в таких состояниях чаще всего отключаются логи, проверки и контроль доступа.
8. Социальный и регуляторный контекст
Риски могут возникать не из технических уязвимостей, а из:
изменений законодательства;
общественного внимания к продукту;
утечек, не нарушающих формально безопасность, но подрывающих доверие.
Модель угроз может считать риск низким, а репутационный ущерб — критическим.
Как с этим жить
Полностью покрыть все риски невозможно. Но можно:
Регулярно пересматривать допущения модели угроз.
Включать в обсуждение не только инженеров, но и продукт, поддержку, безопасность, юристов.
Добавлять «анти-сценарии»: что пойдёт не по плану при стрессе и аварии.
Фиксировать организационные риски явно, даже если они «не технические».
Относиться к модели угроз как к процессу, а не документу.
Вместо вывода
Модели угроз — мощный инструмент, но не магический щит. Самые опасные риски часто живут между строк: в людях, мотивациях, процессах и устаревших предположениях. Видеть их — значит выходить за рамки схем и чеклистов и смотреть на систему как на живой организм.
Именно там чаще всего и начинаются настоящие инциденты.