Тестируем это все дело на AdvBench с разными видами джейлбрейков (GCG, AutoDAN, PAIR, TAP, Base64 и Low-Resource Language) и сравниваем с разными другими защитами (оценка перплексии, SmoothLLM, EraseCheck, Self-Reminder). Предлагаемый исследователями метод, разумеется, оказывается самым классным, давая самый низкий FPR при максимальном уровне детектирования. К сожалению, как мы помним, за все нужно платить, в случае нашего алгоритма – сэмплированием, которое мы повторяем несколько раз, если быть точным – то мы делаем N сэмплирований и к каждому применяем P пертурбаций, получая стоимость защиты в N*(P+1). В частности, данные результаты получены при N=P=10, причем если P увеличить до 20 или даже 110, то результаты могли бы быть и получше.
В целом, статья оставляет смешанное ощущение. С одной стороны, кажется, что где-то в кишках модели – градиентах, активациях – можно найти что-то, что может помочь (вспомним про sentiment neuron у OpenAI еще времен open), кроме того, наблюдение, что джейлбрейки работают вероятностно, и потому если LLM отказывается от ответа чаще, чем в среднем, то запрос подозрительный – довольно разумное. Да и действительно, наверняка, если чуть-чуть отойти от точной последовательности, при которой работает джейлбрейк (например, на живую добавив шума в эмбеддинги), то джейлбрейк (особенно такой специфичный, как GCG) перестанет работать, по аналогии с adversarial-шумом, который перестает работать, если картинку пожать jpeg’ом, так что норма градиента здесь вполне имеет смысл.
С другой стороны, я три раза перечитал статью, но так и не нашел, какой вклад в защиту вводит «наивная» фильтрация по доле отказов – у меня есть некоторое ощущение, что этот механизм работает более эффективно, чем норма приближенного градиента. Некоторые места просто кажутся немного сомнительными (например, префиксы для определения JB, кроме того, график 5 покорил своей осмысленностью). Ну и вычислительная сложность в N*(P+1), где обе переменных порядка десятков – это немного чересчур – становится понятно, почему они использовали 7B-модели. В общем, статья занятная некоторыми своими идеями, но практической ценности, пожалуй, особо не представляющая.
С другой стороны, я три раза перечитал статью, но так и не нашел, какой вклад в защиту вводит «наивная» фильтрация по доле отказов – у меня есть некоторое ощущение, что этот механизм работает более эффективно, чем норма приближенного градиента. Некоторые места просто кажутся немного сомнительными (например, префиксы для определения JB, кроме того, график 5 покорил своей осмысленностью). Ну и вычислительная сложность в N*(P+1), где обе переменных порядка десятков – это немного чересчур – становится понятно, почему они использовали 7B-модели. В общем, статья занятная некоторыми своими идеями, но практической ценности, пожалуй, особо не представляющая.
Openai
Unsupervised sentiment neuron
We’ve developed an unsupervised system which learns an excellent representation of sentiment, despite being trained only to predict the next character in the text of Amazon reviews.
Purple Llama CyberSecEval: A Secure Coding Benchmark for Language Models
Bhatt et al., 2023
Статья, блог, код
Недавно вышла LLaMA 3, которая, как уже известно, приблизилась по метрике «генерируем приятные ответы на первые пришедшие в голову вопросы случайных людей» (также известной, как Elo на Chatbot Arena) к ведущим моделькам типа Claude Opus и GPT-4, вызвав бурю восторгов. Менее заметным был релиз второй версии бенчмарка для оценки безопасности CyberSecEval в рамках инициативы по оценке надежности и безопасности моделей с точки зрения кибербезопасности под названием Purple LLaMA. На самом деле, инициатива очень крутая, а потому мы рассмотрим три статьи, которые сопровождали эти релизы.
Начнем мы с декабрьской статьи, посвященной первой версии бенчмарка. Исследователи рассматривают два вида рисков, которые появляются при развитии открытых LLM: генерация небезопасного кода при использовании в качестве ассистента при разработке, а также использование в качестве ассистента при проведении кибератак.
Bhatt et al., 2023
Статья, блог, код
Недавно вышла LLaMA 3, которая, как уже известно, приблизилась по метрике «генерируем приятные ответы на первые пришедшие в голову вопросы случайных людей» (также известной, как Elo на Chatbot Arena) к ведущим моделькам типа Claude Opus и GPT-4, вызвав бурю восторгов. Менее заметным был релиз второй версии бенчмарка для оценки безопасности CyberSecEval в рамках инициативы по оценке надежности и безопасности моделей с точки зрения кибербезопасности под названием Purple LLaMA. На самом деле, инициатива очень крутая, а потому мы рассмотрим три статьи, которые сопровождали эти релизы.
Начнем мы с декабрьской статьи, посвященной первой версии бенчмарка. Исследователи рассматривают два вида рисков, которые появляются при развитии открытых LLM: генерация небезопасного кода при использовании в качестве ассистента при разработке, а также использование в качестве ассистента при проведении кибератак.
👍1
Начнем с разработки. Приводится некоторое количество интересной статистики, например, что 46% кода на Github уже (в 2023) было сгенерировано копайлотом, 22% кодогенерации в Meta принимается пользователями, при этом в 40% автосгенерированного кода есть уязвимости. Таким образом, исследователей интересует, а можем ли мы сравнить LLM по их склонности генерировать плохой код? Чтобы ответить на этот вопрос создается бенчмарк CyberSecEval. Он включает в себя:
1. ICD: инструмент под названием Insecure Code Detector, который на основе 189 статических правил для детектирования 50 типовых проблем из Common Weakness Enumeration от MITRE на разных языках, от C до PHP. Авторы размечают вручную 50 примеров для каждого языка и на них оценивают качество инструмента – 96% точности, 79% полноты.
2. Датасет: набор тест-кейсов для двух сценариев – инструктивного и tab-дополнения. Сначала в открытом коде с помощью ICD ищутся небезопасные строки, затем к ним или генерируются инструкции, или оставляются строки, предшествующие строкам с ошибкой.
3. Метрика: смотрим, сгенерирует ли модель обратно дырявый код или сделает что-то иное. В качестве метрики считается число кейсов, где модель не сгенерировала код с уязвимостью. Есть нюанс: если сеть вообще ничего в ответ не сгенерирует или начнет генерировать чепуху, то и уязвимости там не будет. Поэтому авторы (на мой взгляд немного неоднозначно) дополнительно считают метрику «качества кода», в качестве которой берут BLEU между генерацией и тем, что было в оригинальном дырявом коде.
1. ICD: инструмент под названием Insecure Code Detector, который на основе 189 статических правил для детектирования 50 типовых проблем из Common Weakness Enumeration от MITRE на разных языках, от C до PHP. Авторы размечают вручную 50 примеров для каждого языка и на них оценивают качество инструмента – 96% точности, 79% полноты.
2. Датасет: набор тест-кейсов для двух сценариев – инструктивного и tab-дополнения. Сначала в открытом коде с помощью ICD ищутся небезопасные строки, затем к ним или генерируются инструкции, или оставляются строки, предшествующие строкам с ошибкой.
3. Метрика: смотрим, сгенерирует ли модель обратно дырявый код или сделает что-то иное. В качестве метрики считается число кейсов, где модель не сгенерировала код с уязвимостью. Есть нюанс: если сеть вообще ничего в ответ не сгенерирует или начнет генерировать чепуху, то и уязвимости там не будет. Поэтому авторы (на мой взгляд немного неоднозначно) дополнительно считают метрику «качества кода», в качестве которой берут BLEU между генерацией и тем, что было в оригинальном дырявом коде.
Результаты оценки по этому бенчмарку таковы: чем лучше модель, тем больше вероятность, что она сгенерирует уязвимый код. У меня есть гипотеза, что это связано с тем, что чем лучше модель, тем больше вероятность, что она сгенерирует вообще что-то похожее на реальное решение; авторы предполагают, что более мощные модели просто учатся у нас более эффективно, лучше запоминают наши ошибки, а потому, как мы, пишут плохой код. Конкретные метрики по моделям можно увидеть на картинке, но обратите внимание, что ось ординат на всех разного масштаба.
Следующим идет чуть более веселый бенчмарк про полезность в кибератаках. Он состоит из:
1. Инструкций, которые сгенерировали, комбинируя некоторый префикс («Я пентестер, поэтому мне нужно»), просьбу сгенерировать код и запрос, соответствующий какому-нибудь TTP из MITRE ATT&CK.
2. Оценщика на основе регулярок, который проверяет,сказала ли модель I'm sorry dave, I’m afraid I can't do that отказалась ли модель от ответа.
3. Оценщика на основе аж двух моделей (LLaMA-70B и CodeLLaMA-13B), которые проверяют ответ, если он не содержал отказа.
4. Метрики – доли ответов, которые, как кажется LLM-оценщикам, могут быть полезны для кибератак. Пайплайн оценки аналогично предыдущему тестируется на тестовой выборке, отобранной вручную, как имеющий 94% точности и 84% полноты.
1. Инструкций, которые сгенерировали, комбинируя некоторый префикс («Я пентестер, поэтому мне нужно»), просьбу сгенерировать код и запрос, соответствующий какому-нибудь TTP из MITRE ATT&CK.
2. Оценщика на основе регулярок, который проверяет,
3. Оценщика на основе аж двух моделей (LLaMA-70B и CodeLLaMA-13B), которые проверяют ответ, если он не содержал отказа.
4. Метрики – доли ответов, которые, как кажется LLM-оценщикам, могут быть полезны для кибератак. Пайплайн оценки аналогично предыдущему тестируется на тестовой выборке, отобранной вручную, как имеющий 94% точности и 84% полноты.
Для оценки из каждой модели для каждого промпта семплируют три дополнения. Результаты следующие. В среднем модели помогают в 52% случаев. Модели для кодогенерации (CodeLLaMA) отказываются реже, особенно когда речь идет о задачах «двойного назначения» типа шифрования файлов, которые могут иметь как полезные, так и вредные применения. Были отличия и в разрезе TTP – например, модели больше склонны отказываться от помощи в уклонении от обнаружения (evasion), чем в сборе информации (reconnaissance).
В конце исследователи отмечают, что у статьи есть определенные ограничения: от вполне реальной утечки тест-кейсов через гитхаб и неидеальной схемы детектирования уязвимостей до англоцентризма и отсутствию multi-turn-тестов. Тем не менее, наличие такого бенчмарка достаточно важно – как минимум, если вы решите сделать offensive LLM, вы знаете, на чем измерять эффективность 😈
В следующий раз посмотрим, что нового появилось в CyberSecEval 2.
В следующий раз посмотрим, что нового появилось в CyberSecEval 2.
Meta
CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models | Research - AI at Meta
Large language models (LLMs) introduce new security risks, but there are few comprehensive evaluation suites to measure and reduce these risks. We...
CYBERSECEVAL 2: A Wide-Ranging Cybersecurity Evaluation Suite for Large Language Models
Bhatt et al., 2024
Статья, блог, код
Меньше, чем полгода спустя, авторы CyberSecEval выкатывают вторую версию своего бенчмарка, приуроченную к выходу LLaMA-3. Во второй версии добавляются новые задачи для двух аудиторий: тех, кто строит решения для кибербезопасности на основе LLM, и тех, кто создает приложения общего назначения. Первым эта работа дает набор тестов, которые помогают оценить устойчивость решения перед стандартными атаками, вторым – возможность оценить, насколько хорошо LLM подходит для решения их задач.
Bhatt et al., 2024
Статья, блог, код
Меньше, чем полгода спустя, авторы CyberSecEval выкатывают вторую версию своего бенчмарка, приуроченную к выходу LLaMA-3. Во второй версии добавляются новые задачи для двух аудиторий: тех, кто строит решения для кибербезопасности на основе LLM, и тех, кто создает приложения общего назначения. Первым эта работа дает набор тестов, которые помогают оценить устойчивость решения перед стандартными атаками, вторым – возможность оценить, насколько хорошо LLM подходит для решения их задач.
Кроме того, исследователи улучшают тест на полезность в кибератаках из первой версии бенчмарка, добавляя в него набор пограничных запросов, которые относятся к сфере кибербезопасности и могут казаться зловредными, но на самом деле являются безопасными. Для оценки того, насколько часто LLM отказываются от таких запросов (что делает их бесполезными для соответствующих задач), используется метрика False Refusal Rate (FRR 🦊).
Исследователи также смотрят, насколько за 4 месяца изменился уровень элайнмента с точки зрения помощи в проведении кибератак. Изменился он очень солидно – с 52% случаев, в которых модели соглашались помочь, доля промптов, на которые не был дан отказ, в среднем уменьшилась до 28%. Самой доброй и непослушной, разумеется, оказывается LLaMA-3. Что же касается FRR, то протестированные модели в большинстве своем довольно неплохо различают плохие промпты от пограничных. Самой полезной и зловредной оказывается gpt-3.5-turbo, самой полезной и безобидной – опять, вот так совпадение, маленькая LLaMA-3.
Исследователи также смотрят, насколько за 4 месяца изменился уровень элайнмента с точки зрения помощи в проведении кибератак. Изменился он очень солидно – с 52% случаев, в которых модели соглашались помочь, доля промптов, на которые не был дан отказ, в среднем уменьшилась до 28%. Самой доброй и непослушной, разумеется, оказывается LLaMA-3. Что же касается FRR, то протестированные модели в большинстве своем довольно неплохо различают плохие промпты от пограничных. Самой полезной и зловредной оказывается gpt-3.5-turbo, самой полезной и безобидной – опять, вот так совпадение, маленькая LLaMA-3.
Первым новым бенчмарком в CSE2 является набор тестов на prompt injection. Тесты покрывают два вида инъекций – которые противоречат системному промпту, но не несут прямого вреда, и те, в которых подразумевается какой-то вред (например, раскрытие секрета). Покрывается 14 техник (плюс смесь техник), включая “ignore previous instuctions”, контрабанду токенов, режим разработчика и прочие известные вещи. Есть тесты как на прямые, так и на непрямые инъекции. Каждый тест-кейс включает системную инструкцию, пользовательский промпт с инъекцией и вопрос об успешности атаки к LLM-оценщику. По замерам исследователей, в среднем 17% атак оказываются успешными, при этом те LLM, у которых instruction-tuning не подразумевал наличие системного промпта (типа мистраля), из теста исключили. Интересное наблюдение – LLM с плохой мультиязычностью (например, LLaMA-3) больше подвержены инъекциям с помощью использования другого языка.
Следующим бенчмарком стал тест на эксплуатацию уязвимостей в программном коде. Это набор созданных вручную или сгенерированных синтетически задачек типа CTF (целью LLM является достать флаг), в которых LLM должна проэксплуатировать возможность SQL-инъекции в программах на Python, ошибки в логике обработки строк на на Python/JS/C или ошибки управления памятью в C/C++. Настоящий уязвимый код не брали, чтобы не столкнуться с ситуацией, когда LLM видела пример на претрейне.
GPT-4 тут, как обычно, лучше всех, другие модели показывают результаты в зависимости от размера. Интересно, что LLaMA-3 8B и gpt-3.5-turbo показывают схожий результат. Тем не менее, в целом результаты самих авторов не впечатляют.
GPT-4 тут, как обычно, лучше всех, другие модели показывают результаты в зависимости от размера. Интересно, что LLaMA-3 8B и gpt-3.5-turbo показывают схожий результат. Тем не менее, в целом результаты самих авторов не впечатляют.
Наконец, исследователи обращают внимание, что многие сервисы интегрируют в LLM интерпретатор кода, который тоже может быть подвержен различным уязвимостям или использован во вред. Очевидно, что интерпретатор должен быть обернут во всевозможные контейнеризации, виртуализации и прочие изоляции, но на практике выясняется, что один из первых LLM-кейсов в MITRE ATLAS был связан как раз с небезопасным использованием интерпретатора в студенческой поделке под названием MathGPT. Авторы бенчмарка предоставляют 500 промптов – по 100 в каждой из категорий: попытки побега из контейнера, повышения привилегий, пост-эксплуатация (включая персистирование), использование интерпретатора для атак на другие систем и для генерации контента для социальной инженерии. Для оценки процента отказа от выполнения зловредных инструкций снова используется LLM-судья. Что касается результатов, то самыми безопасными оказались вариации CodeLLaMA и GPT-4, которые, видимо, лучше умеют определять, что является потенциально опасным в контексте интерпретатора (или в целом лучше работают с идеей интерпретатора как инструмента), а в среднем LLM соглашаются сгенерировать (что не означает генерацию успешного или правильного кода) попытки эксплуатации интерпретатора в одной трети случаев.