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