Несколько недель назад в напряженный день эксперт по моделированию угроз Адам Шостак открыл письмо от клиента. Кто-то в этой организации «навайбкодил» приложение и запустил его в работу с данными клиентов. Теперь клиент хотел узнать, какие риски несет этот инструмент и что с ними делать.
Ответы требовались быстро, поэтому Шостак выделил себе 15 минут на анализ системы.
Вскоре у него был «список значимых угроз», включая галлюцинации и предвзятость — проблемы, которые не показал бы STRIDE, широко используемая платформа моделирования угроз безопасности приложений.
«Я нашел кое-что интересное, что не было очевидным для меня в начале», — говорит Шостак.
За эти 15 минут он использовал PHANTOM-B — разработанную им платформу моделирования угроз. Она начинается со стандартного вопроса «Что может пойти не так?», но применяет его конкретно к LLM-компонентам системы.
Каждая буква в названии обозначает конкретную угрозу: Prompt injection (инъекция промптов), Hallucination (галлюцинация), Anthropomorphization (антропоморфизация), Non-explainability (необъяснимость), Training issues (проблемы обучения), Overreliance (чрезмерная зависимость, включая качество данных или «отравление»), Missing security engineering (отсутствие инженерии безопасности) и Bias (предвзятость).
Новая платформа призвана дополнять STRIDE, а не заменять его. В то время как STRIDE применяется ко всему приложению, PHANTOM-B можно использовать для компонентов, взаимодействующих с LLM.
Платформа разработана для быстрого получения полезных результатов, что делает моделирование угроз менее пугающим и менее затратным. И, следовательно, более вероятным к применению.
«Я большой сторонник того, чтобы сделать эту работу недорогой», — говорит Шостак, который представил PHANTOM-B на Black Hat USA 2026.
Шостак добавляет, что директора по информационной безопасности и их организации оказались между двух задач: давлением необходимости быстро обеспечить безопасность ИИ и сложностью применения существующих инструментов безопасности к нему.
«Бизнесу нужна точка входа — то, что можно уместить в часовую встречу или 10-минутный разговор с руководителем», — говорит он.
Необходимость использования таких инструментов, как PHANTOM-B, становится все более насущной по мере того, как компании все больше полагаются на ИИ. «Моделирование угроз сейчас важнее, чем когда-либо, потому что ИИ внедряет действительно новые архитектуры приложений и новые риски», — говорит Джефф Уильямс, основатель OWASP, а также основатель и технический директор Contrast Security.
Почему традиционное моделирование угроз не справляется
Моделирование угроз всегда было непростой задачей. Организации любого размера изо всех сил стараются делать это последовательно, потому что это требует времени и часто не поспевает за количеством создаваемых и обновляемых приложений. В результате многие компании оставляют его только для самых критических систем, оставляя большую часть своего программного обеспечения без такого же контроля.
«ИИ не сломал моделирование угроз. Он выявил слабые места, которые уже существовали», — говорит Уильямс. Неудобная реальность, утверждает он, заключается в том, что моделирование угроз никогда не было достаточно стандартизировано или автоматизировано для масштабирования.
Самая сложная часть — не назвать угрозы, а выяснить, какие приложения работают. «Традиционно мы пытались сделать это с помощью опросов, анкет, интервью, устаревших диаграмм Visio и электронных таблиц», — говорит Уильямс. «Полученная модель часто бывает неполной еще до начала упражнения и устаревает, как только приложение меняется».
Генеративный и агентный ИИ усиливают эти слабые места, потому что их поведение трудно предсказать. Обычное программное обеспечение следует правилам, которые инженеры могут проследить от ввода до вывода. Системы ИИ интерпретируют инструкции на естественном языке и генерируют вероятностные ответы, поэтому один и тот же запрос может давать разные результаты. А когда агенты могут получать доступ к данным или вызывать инструменты, эти результаты могут запускать действия в других местах.
«Традиционное моделирование угроз применялось к системам, которые в целом были детерминированными. Современные генеративные и агентные системы ИИ являются недетерминированными, поэтому требуется модификация того, как мы рассматриваем их профили рисков», — говорит Брайан Глас, вице-президент по консультационным услугам CODIFIC и один из руководителей проекта OWASP Top 10.
Это различие также отражено в руководстве Microsoft по моделированию угроз для ИИ, где отмечается, что граница между данными и командами может стираться, создавая новые поверхности атак и позволяя сбоям распространяться на инструменты, память и агентов.
В то же время более быстрые циклы разработки оставляют командам меньше времени на обдумывание того, как должны быть спроектированы и защищены системы. А сложность также затрудняет изучение угроз изолированно. Например, уязвимость в документе может изменить ответ модели и заставить агента или инструмент предпринять небезопасное действие в другой системе. OWASP предупреждает, что эти риски могут распространяться по всему конвейеру генерации с дополненной выборкой.
«Цепочка угроз или уязвимостей приводит к эксплуатации приложения», — говорит Глас.
Ответом на это является превращение моделирования угроз в непрерывную практику — рекомендация, которая содержится в Рамке управления рисками искусственного интеллекта NIST.
Но, несмотря на растущий объем руководств — включая PHANTOM-B Шостака, рекомендации Microsoft по моделированию угроз для ИИ, Профиль генеративного ИИ NIST и Топ-10 OWASP для LLM-приложений — до сих пор не существует окончательного руководства по моделированию угроз для систем ИИ.
«Моделирование угроз — это незрелая практика», — говорит Глас. «Я считаю, что мы все еще пытаемся в этом разобраться».
Совершенствование моделирования угроз в эпоху ИИ
15- или 30-минутное упражнение по моделированию угроз звучит обманчиво выполнимо. Но какую полезную работу по безопасности команды могут реально выполнить за такое короткое время?
Шостак говорит, что короткая сессия не должна быть исчерпывающей. Однако она должна выявить достаточно значимых рисков, чтобы направить следующее решение: приемлем ли риск, нужно ли изменить систему или требуется более глубокий анализ.
«Одна из вещей, которые мы усвоили из мира agile, заключается в том, что когда вы делаете период работы коротким, вы итерируете чаще и быстрее», — говорит он. Если первая сессия не попадает в цель, команда может стереть доску и попробовать снова, не теряя дни или недели работы. «Вы делаете эксперименты дешевыми, а когда эксперимент дешев, вы можете проводить его многократно».
Результатом должен быть набор конкретных сценариев того, как система может выйти из строя. Эти сценарии могут помочь директорам по информационной безопасности понять риски, которые они принимают, и помочь техническим командам выбрать соответствующие средства контроля, которые могут означать ограничение доступа к данным, сужение разрешений инструментов, добавление точек утверждения человеком или даже пересмотр необходимости использования LLM в принципе.
PHANTOM-B направлен на заполнение пробелов, оставленных другими платформами. Он затрагивает актуальные, но иногда необычные концепции, такие как антропоморфизация, задаваясь вопросом, не относятся ли пользователи или разработчики к модели так, как будто она понимает намерения, рассуждает как человек или будет надежно следовать инструкции вроде «Не делай X». Это misplaced доверие может формировать то, как система спроектирована и сколько полномочий она получает.
Необъяснимость поднимает другую проблему. Если LLM отбирает резюме, оценивает медицинские изображения или принимает бизнес-решения, организации может потребоваться обосновать его выводы. Но просьба к модели объяснить себя может дать правдоподобно звучащий ответ, а не точную запись того, как она пришла к первоначальному результату. Поскольку LLM являются вероятностными, повторный запуск того же запроса может не воспроизвести тот же результат, что затрудняет расследование и отладку.
Подсказка «отсутствие инженерии безопасности» напоминает, что добавление LLM не устраняет обычные риски программного обеспечения. Согласно документу Шостака, это может их усилить, особенно когда организации спешат развернуть «навайбкоденное» программное обеспечение, которое никто полностью не понимает.
Этот инструмент, наряду с работой OWASP, NIST, CISA и других, может помочь командам понять emerging ландшафт рисков. «Моделирование угроз — это творческий процесс», — говорит Уильямс.
Ошибки, которых следует избегать при моделировании угроз для систем ИИ
Инструменты на базе LLM могут быть относительно новыми, но они все еще являются приложениями. Они используют сторонние библиотеки, обрабатывают недоверенные входные данные, работают с конфиденциальными данными, предоставляют API и зависят от средств контроля идентификации и авторизации.
Сосредоточение в основном на новых угрозах ИИ при игнорировании основ может оставить организации уязвимыми для предотвратимых уязвимостей. «Самая большая ошибка — забывать, что все существующие риски все еще применимы», — говорит Уильямс.
Он советует директорам по информационной безопасности не переходить сразу к инъекции промптов или манипуляции моделью, пропуская основы. «Это неправильно», — говорит Уильямс. «Традиционная безопасность приложений должна быть фундаментом. Новые риски ИИ — это дополнительный слой поверх него, а не замена ему».
Глас согласен. «Детали изменились; основы риска — нет», — говорит он. «Не выбрасывайте уроки безопасности, полученные за последние 25 лет, в погоне за скоростью».
Глас также указывает на другую распространенную проблему: отсутствие контекста. Команды могут не до конца понимать, как LLM вписывается в более широкое приложение, включая его контроль доступа, границы доверия, входные данные и потоки данных. Без такого представления важные риски могут легко ускользнуть.
Попытка каталогизировать каждую мыслимую атаку — тоже не ответ. «Вы не можете отследить их все», — говорит Глас. «Количество возможных атак почти безгранично». Вместо этого он рекомендует начинать с активов, которые нуждаются в защите, и уже существующих превентивных и детективных средств контроля. Оттуда команды могут моделировать различные типы атак, чтобы выявить слабые или отсутствующие средства контроля и определить, что необходимо для снижения риска до приемлемого уровня.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Andrada Fiscutean
