Большие языковые модели (БЯМ) пришли в сферу безопасности сразу в трех обличьях: как инструменты повышения производительности, работающие наряду с аналитиками, как компоненты, встроенные в продукты и рабочие процессы, и как цели, которые злоумышленники могут исследовать, манипулировать ими и похищать.
Именно это слияние делает обсуждение запутанным. Та же возможность, которая может обобщить инцидент за секунды, может также сгенерировать правдоподобный предлог для целенаправленного фишинга. Того же помощника, который может составить логику обнаружения, можно побудить к утечке конфиденциального контекста, если он интегрирован во внутренние базы знаний без защитных механизмов.
Я отношусь к БЯМ как к еще одной системе с высоким уровнем воздействия: определяю результаты, моделирую угрозы и создаю средства контроля, которые предполагают, что модель может ошибаться или быть скомпрометированной.
Как БЯМ меняют работу команд безопасности
Когда люди говорят «БЯМ в SOC», они часто представляют себе чат-интерфейс. Более значимый сдвиг является архитектурным: БЯМ удешевляют перевод неструктурированных данных безопасности в структурированные гипотезы, повествования и следующие шаги. Это важно, поскольку большая часть работы в сфере безопасности не является технически сложной. Это сшивание контекста.
Если бы я внедрял функциональность БЯМ в программу безопасности, я бы начал с узкого набора рабочих процессов, где результат носит рекомендательный характер и легко проверяется. Затем я бы расширял возможности только после того, как команда сможет измерить качество и управлять режимами сбоев.
Вот примеры использования с высокой ценностью, которые хорошо подходят для раннего внедрения:
- Сводки по сортировке оповещений, которые преобразуют необработанную телеметрию в краткое повествование «что произошло, почему это важно и что мне следует проверить дальше»
- Копилоты для расследований, которые генерируют хронологию из логов, тикетов и чатов, а затем выделяют пробелы и рекомендуемые точки перехода
- Помощь в разработке систем обнаружения для составления фрагментов кода на языках Sigma, YARA или языках запросов, которые инженер может просмотреть и протестировать
- Копилоты для управления уязвимостями, которые группируют похожие находки, объясняют возможность эксплуатации с точки зрения бизнеса и предлагают окна для установки исправлений
- Вопросы и ответы по политикам и стандартам, где помощник отвечает на вопросы, ссылаясь на точную формулировку внутреннего контроля, на которую он опирался
Даже в этих безопасных сценариях операционное правило, которое я использую, простое: относиться к выводу БЯМ как к недоверенному. Если модели разрешено писать код, рекомендовать действия по сдерживанию или ссылаться на внутренние данные, следует предполагать, что она может галлюцинировать, стать жертвой социальной инженерии или быть спровоцированной на небезопасное поведение.
Сообщество OWASP каталогизировало распространенные режимы сбоев для приложений с поддержкой БЯМ, включая внедрение запросов (prompt injection), небезопасную обработку вывода, раскрытие конфиденциальной информации, чрезмерную автономность и чрезмерную зависимость. Это не академические понятия. Они напрямую соотносятся с тем, как БЯМ терпят неудачу в рабочих процессах безопасности. См. OWASP Top 10 для приложений больших языковых моделей.
На практике я рассматриваю развертывание БЯМ в сфере безопасности как три уровня: модель, данные, к которым она имеет доступ, и действия, которые она может предпринять. Вы можете получить значительную пользу, расширяя первый уровень (например, используя лучшие модели или запросы), сохраняя при этом два других уровня ограниченными.
Три проектных решения последовательно снижают риск, не убивая ценность:
- Сделать источники явными: Используйте генерацию с дополненным поиском (retrieval-augmented generation), чтобы помощник отвечал на основе отобранных документов, тикетов или плейбуков, и показывайте проанализированные фрагменты аналитику.
- Держать модель вне зоны поражения: Модель не должна хранить секреты. Используйте краткосрочные учетные данные, ограниченные по области действия токены и опосредованный доступ к инструментам.
- Ограничивать действия: Все, что изменяет состояние системы (блокировка, карантин, удаление, отправка электронной почты), должно требовать одобрения человека или отдельного механизма политики.
Руководство по-прежнему должно быть проницательным в отношении измерений. Если вы не можете количественно оценить, снижает ли помощник время реагирования или улучшает ли он качество сигнала, вы берете на себя новый класс операционного риска при неопределенной выгоде.
Как злоумышленники используют ту же возможность для масштабирования и персонализации
Защитники — не единственные, кто автоматизирует сшивание контекста. Злоумышленники могут использовать БЯМ для проведения разведки, составления текстов и быстрой итерации. Результатом являются не столько новые атаки, сколько изменение экономики для злоумышленников: более дешевая персонализация, более быстрая итерация и меньше языковых барьеров.
Наиболее непосредственное влияние наблюдается в социальной инженерии. Хорошее фишинговое письмо — это не только правильная грамматика. Это ситуационная релевантность: правильный тон, правильный внутренний жаргон и правильный момент в бизнес-процессе. БЯМ делают такую настройку тривиальной в масштабе.
Исследование 2024 года, проведенное Хайдингом, Лерменом, Као, Шнайером и Вишванатом оценило полностью автоматизированные кампании целенаправленного фишинга, проверенные на людях-субъектах. В их эксперименте электронные письма, сгенерированные ИИ, показали результаты на уровне человеческих экспертов и значительно лучше, чем контрольная группа с общим фишингом. Статью стоит прочитать полностью, поскольку она количественно оценивает проблему и делает экономику злоумышленника осязаемой.
В то же время организации создают новый набор мягких целей, интегрируя БЯМ во внутренние базы знаний, системы тикетов и инструменты рабочих процессов. Если злоумышленник может вызвать внедрение запроса через управляемый пользователем ввод, документ в общем репозитории или скомпрометированную веб-страницу, которую помощник может читать, модель может стать каналом для утечки данных или небезопасных действий.
Именно поэтому я рассматриваю безопасность БЯМ как наступательную и оборонительную дисциплину. Вы защищаете свою организацию от угроз, основанных на БЯМ, и вы защищаете свои собственные системы, основанные на БЯМ, от обращения против вас. Министерство науки, инноваций и технологий Великобритании составило карту уязвимостей на протяжении всего жизненного цикла ИИ — от проектирования до обслуживания, что является полезной ментальной моделью для команд безопасности.
Чтобы сохранить практичность, я группирую возможности злоумышленников по трем категориям:
- БЯМ как механизмы убеждения: лучшие предлоги, лучшие многоязычные мошеннические схемы, лучшее подражание и лучший скриптинг мошенничества
- БЯМ как механизмы производительности: более быстрая итерация товарного вредоносного ПО, скриптов, отчетов о разведке и адаптации эксплойтов
- БЯМ как цели и точки опоры: кража запросов, извлечение системных инструкций, отравление источников данных или манипулирование агентами, использующими инструменты
Оборонительное следствие неудобно: некоторые из ваших существующих средств контроля становятся еще более важными, особенно проверка, подтверждение личности и ужесточение процессов. Если рабочий процесс одобрения руководителем может быть обойден с помощью убедительного сообщения, БЯМ поможет злоумышленникам быстрее найти и использовать эту слабость.
БЯМ также усложняют обнаружение на основе контента. Когда злоумышленники могут генерировать чистый язык, я придаю больший вес техническим сигналам и поведенческим сигналам (аутентификация отправителя, необычный вход в систему, аномальный шаблон запроса платежа), чем сигналам тона или грамматики.
Стек контроля, который позволяет использовать БЯМ, не теряя сути
Я не думаю, что организациям нужен совершенно новый режим управления для БЯМ. Им нужно применять существующие рычаги управления к новым режимам сбоев. Наиболее подходящим является управление рисками, а не поклонение моделям.
Полезной отправной точкой является Структура управления рисками искусственного интеллекта NIST, которая организует деятельность по управлению (govern), картированию (map), измерению (measure) и управлению (manage). Ценность заключается не столько в метках, сколько в дисциплине: определение подотчетности, понимание контекста и последствий, измерение риска, а затем операционализация смягчающих мер.
Если бы я консультировал комитет по безопасности и рискам по программе БЯМ, я бы предложил следующий стек контроля. Он намеренно прагматичен и предполагает смешанную среду сторонних моделей, внутренних данных и интеграций инструментов:
- Управление (Govern): Определите, что модели разрешено делать, кто за нее отвечает и что означает «небезопасно» в вашем контексте (классы данных, регулируемые рабочие процессы, критические решения)
- Картирование (Map): Документируйте сквозную систему, включая запросы, источники данных, конвейеры поиска, плагины и последующие действия; а не только конечную точку модели
- Защита данных: Проведите инвентаризацию обучающих данных, данных для тонкой настройки и поисковых корпусов, обеспечьте контроль доступа и отслеживайте отравление, утечки и несанкционированное повторное использование
- Моделирование угроз с использованием методов, специфичных для ИИ: Составляйте карту вероятного поведения противника с помощью MITRE ATLAS и включайте в свои сценарии внедрение запросов и злоупотребление инструментами
- Создание защитных барьеров на границах: Проверка ввода, фильтрация контента, ограничения вывода и синтаксический анализ на основе схемы для любого вывода, который подается в автоматизацию
- Ограничение действий с высоким уровнем воздействия: Требуйте явного одобрения, многофакторной аутентификации или проверок механизмом политики, прежде чем агент сможет изменить состояние в рабочей среде
- Тестирование всерьез: Проводите красное тестирование помощника, запускайте наборы для обхода блокировок (jailbreak) и внедрения запросов и измеряйте частоту ошибок при реалистичных нагрузках
- Инструментирование, мониторинг и реагирование: Регистрируйте запросы, вызовы инструментов и выводы, обнаруживайте аномальные шаблоны использования и поддерживайте аварийный выключатель для небезопасной автоматизации
Дальнейшие шаги
Два общедоступных руководства стоит прочитать, поскольку они переводят безопасный ИИ в операционные шаги. Во-первых, «Руководящие принципы безопасной разработки систем ИИ» — документ, опубликованный Национальным центром кибербезопасности Великобритании (NCSC) и Агентством по кибербезопасности и защите инфраструктуры США (CISA, CISA) — предоставляет рекомендации по жизненному циклу от безопасного проектирования до безопасной эксплуатации и обслуживания. Во-вторых, «Безопасное развертывание систем ИИ» — совместно опубликованный Центром безопасности искусственного интеллекта (AISC) Агентства национальной безопасности США и CISA, а также другими национальными и международными агентствами — фокусируется на лучших практиках развертывания и эксплуатации внешне разработанных систем ИИ.
Наконец, я рассматриваю чрезмерную автономность как черту, которую пересекают намеренно. Чем больше автономии вы предоставляете агенту на основе БЯМ, тем больше вы создаете новый класс привилегированного программного обеспечения. Если бы вы не предоставили младшему скрипту неограниченный доступ к API, вы не должны предоставлять его и вероятностной модели.
Слияние БЯМ и кибербезопасности не является выбором. Злоумышленники будут использовать эти инструменты, и сотрудники уже их используют. Преимущество заключается в получении выгоды от повышения производительности при сохранении контроля над данными, идентификацией и управлением изменениями.
Эта статья публикуется в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ankit Gupta
