Проблема, которую никто не хочет признавать

Ваша модель угроз находится на странице Confluence, красиво оформленная в виде диаграмм, тщательно документированная. Это шедевр «театра безопасности». Ваши разработчики мельком смотрят на неё во время знакомства с проектом, служба безопасности отмечает её как выполненное требование соответствия, и затем все делают вид, что она действительно отражает реальность. Звучит знакомо? Вот неудобная правда: большинство моделей угроз — это сложная выдумка — тщательно продуманные истории о том, как системы должны подвергаться атакам, оторванные от того, как они фактически развиваются в процессе эксплуатации. Это фанфикшн по безопасности, написанный с лучшими намерениями, но обречённый устареть быстрее, чем уязвимость npm вчерашнего дня.

Великий самообман моделирования угроз

Позвольте мне описать, как традиционное моделирование угроз работает в большинстве организаций. Вы собираете комнату, полную людей: разработчики, которые предпочли бы выпускать функции, эксперты по безопасности, у которых есть сорок три других критически важных проекта, архитекторы, которые только что вернулись с совещаний, и менеджеры продуктов, задающиеся вопросом, зачем они здесь. Каждый приносит своё собственное представление о том, что такое «угроза». Кто-то рисует блоки на доске. Кто-то спорит о границах доверия. Возникает ожесточённый спор о том, действительно ли стороннему API нужен доступ к данным клиентов. Четыре часа спустя вы завершили упражнение по STRIDE или PASTA. Поздравляю — вы создали снимок состояния безопасности вашей системы трёхдневной давности. Это фундаментальная трагедия традиционного моделирования угроз: это момент времени, выдаваемый за стратегию. Но вот что на самом деле происходит, как только сессия моделирования угроз заканчивается:

  • Ваша команда инфраструктуры добавляет две новые микросервисы.
  • Разработчик интегрирует бета-версию API, которую вы никогда не оценивали.
  • Ваш облачный провайдер запускает новый регион, который не учтён в вашей модели.
  • Кто-то неправильно реализует OAuth, потому что модель угроз была слишком абстрактной, чтобы служить им руководством.
  • Устаревший код, развёрнутый два года назад, не соответствует никакой документации. Ваша красивая модель угроз уже устаревает.

Почему традиционное моделирование угроз не работает в масштабах

Математика не работает. Позвольте мне показать вам почему. Согласно опросу BSIMM за 2021 год, организации поддерживают соотношение примерно один эксперт по безопасности на каждые 140 разработчиков, которые коллективно поддерживают более 50 приложений. Теперь представьте, что этот единственный специалист по безопасности проводит комплексные упражнения по моделированию угроз для каждого приложения — многодневные семинары по каждому проекту с участием высшего руководства. Неизбежный результат? Моделируются только наиболее критические приложения. Всё остальное — это театр безопасности. Ваша организация становится похожа на больницу, где один врач проводит операцию исключительно для генерального директора, пока все остальные ждут в общем отделении. Критическим системам уделяется внимание; большинство вашего портфеля приложений остаётся уязвимым, игнорируемым, устаревшим.

Проблема устаревания: когда ваша модель угроз умирает

Позвольте мне привести вам реалистичный сценарий. Вы заканчиваете свою модель угроз для приложения X в марте 2024 года. Она подробна. Ваша команда отнеслась к этому серьёзно. Вы выявили двенадцать критических угроз и разработали стратегии смягчения. Затем:

  • Апрель 2024: Архитектура меняется с монолитной на микросервисную. Ваша модель угроз частично устарела.
  • Май 2024: Вы переносите данные с локальной инфраструктуры в AWS. Появляются новые векторы угроз, которые ваша модель никогда не рассматривала.
  • Июнь 2024: Вы интегрируете стороннего платёжного процессора. Новые границы доверия. Новые поверхности атак.
  • Июль 2024: Вы переходите на бессерверную архитектуру для вычислений. Ваши диаграммы потоков данных теперь выглядят устаревшими. К августу 2024 года ваша тщательно разработанная модель угроз за март 2024 года становится историческим документом, а не артефактом безопасности. Проблема экспоненциально усугубляется на сотнях или тысячах приложений. Ручные модели угроз, отражающие первоначальное намерение проектирования проекта, невозможно поддерживать в больших масштабах.

Опыт разработчиков: пример трения

Вот где метафора фанфикшена действительно кусается. Традиционные инструменты моделирования угроз созданы для команд безопасности, а не для разработчиков. Они заставляют инженеров следовать жёстким рабочим процессам, которые не соответствуют тому, как на самом деле происходит современная разработка. Они требуют ручного ввода данных, бесконечных диаграмм и дополнительных шагов, которые всё замедляют. Когда что-то замедляет работу инженеров, они это игнорируют. Ваша модель угроз становится домашним заданием по безопасности — работой, которую разработчики resent, skip whenever possible, and fulfill only when forced by process gates (перевод: ненавидят, пропускают при любой возможности и выполняют только когда вынуждает процесс). Реальная ценность моделирования угроз — глубокое размышление о безопасности системы — заменяется театром видимости моделирования угроз.

Как оценка рисков превращается в театральный спектакль

Вот где я высказываю своё мнение: большинство моделей угроз определяют неправильные риски. Команды тратят недели на анализ крайних случаев — obscure attack vectors that might affect 0.01% of users (перевод: маловероятных векторов атак, которые могут затронуть 0,01% пользователей) — в то время как очевидные уязвимости остаются открытыми. Это происходит потому, что упражнения по моделированию угроз часто становятся академическими упражнениями: «Какая самая интересная угроза, которую мы могли бы выявить?» вместо «Какие угрозы на самом деле нарушают работу нашего бизнеса?» Распространённая ошибка — применять моделирование угроз ко всему одновременно. Это создаёт подавляющую сложность. Ваша команда тратит две недели на анализ сценариев обхода аутентификации, пока базовая реализация входа в систему подвергает опасности пользовательские сеансы. Более узкий охват — сосредоточение на приложениях, ориентированных на клиентов, платёжных системах и всём, что содержит конфиденциальные данные — на самом деле приводит к лучшим результатам в области безопасности, чем всеобъемлющее моделирование угроз для каждой системы.

Прорыв в коммуникации

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

Что отрасль сделала не так: одержимость визуализацией

Модели угроз стали визуальными, потому что люди якобы думают картинками. Поэтому мы создали диаграммы угроз, диаграммы потоков данных, деревья атак и матрицы угроз. Результат? Красивая документация, которая устаревает до запуска проекта. Визуальные модели угроз служат своей цели — они помогают командам изначально понять систему. Но они также являются кошмарами обслуживания. Каждое изменение архитектуры требует обновления диаграмм. Каждая новая интеграция требует перерисовки потоков. Когнитивная нагрузка на поддержание визуальных артефактов превышает пользу.

Императив автоматизации: что нужно изменить

Вот что на самом деле работает: автоматизированное, непрерывное моделирование угроз. Вместо упражнений, привязанных к определённому моменту времени, представьте себе непрерывное выявление угроз по мере изменения вашего кода. Автоматический анализ вашей кодовой базы, архитектуры и зависимостей в режиме реального времени. Контекстно-зависимые сведения о безопасности, адаптированные к каждой конкретной системе, а не общие шаблоны рисков. Это не научная фантастика. Это то, что сейчас создают зрелые программы безопасности. Автоматизированное моделирование угроз:

  • Сокращает ручные усилия и устраняет ограничения масштабируемости.
  • Ускоряет обнаружение рисков.
  • Обеспечивает актуальность моделей угроз по мере развития приложений.
  • Интегрируется непосредственно в CI/CD конвейеры и рабочие процессы разработчиков.
  • Предоставляет контекстно-специфичные сведения вместо общих фреймворков.

Текущее состояние моделирования угроз: визуальная реальность

Вот как на самом деле выглядит ландшафт моделирования угроз:

graph TD A["Традиционный подход к моделированию угроз"] --> B["Ручное выполнение"] A --> C["Анализ на определённый момент"] A --> D["Зависимость от экспертов"] B --> E["Медленное выполнение"] C --> F["Быстрое устаревание"] D --> G["Плохая масштабируемость"] E --> H["Ограниченное покрытие"] F --> H G --> H H --> I["Неполная картина безопасности"] J["Современный автоматизированный подход"] --> K["Непрерывный анализ"] J --> L["Обновления в реальном времени"] J --> M["Управление инструментами"] K --> N["Быстрое выполнение"] L --> O["Текущая актуальность"] M --> P["Масштабирование по всему миру"] N --> Q["Комплексное покрытие"] O --> Q P --> Q Q --> R["Точная картина безопасности"] style I fill:#ffcccc style R fill:#ccffcc

Практический пример: где фанфикшн терпит неудачу

Позвольте мне привести вам конкретный пример из реальной ситуации (детали скрыты, но шаблон универсален): Финтех-компания провела комплексное моделирование угроз для своего приложения для обработки платежей. Отличная работа: сорок три выявленные угрозы, подробные меры по смягчению последствий, прекрасная документация. Затем они перешли с AWS на гибридную облачную среду с локальными базами данных. Никто не обновил модель угроз, потому что команда безопасности уже была перегружена. Восемнадцать месяцев спустя тест на проникновение выявил уязвимость в процессе синхронизации на локальном уровне — то, что было бы немедленно выявлено, если бы модель угроз учитывала гибридную архитектуру. Модель угроз была фикцией безопасности