Системы оценки критичности уязвимостей в AI Security. ai safety.. ai safety. AI Security.. ai safety. AI Security. cvss.. ai safety. AI Security. cvss. llm.. ai safety. AI Security. cvss. llm. Информационная безопасность.. ai safety. AI Security. cvss. llm. Информационная безопасность. искусственный интеллект.. ai safety. AI Security. cvss. llm. Информационная безопасность. искусственный интеллект. оценка критичности.. ai safety. AI Security. cvss. llm. Информационная безопасность. искусственный интеллект. оценка критичности. скоринг.. ai safety. AI Security. cvss. llm. Информационная безопасность. искусственный интеллект. оценка критичности. скоринг. уязвимости.
Системы оценки критичности уязвимостей в AI Security - 1

В практике информационной безопасности отдельное место занимает вопрос критичности результатов оценки защищенности систем. Эта информация необходима как для приоритизации задач внутри команды/отдела безопасности, так и для предоставления результатов другим бизнес-функциям. Например, чтобы требовать закрыть одну найденную уязвимость в кратчайшие сроки, а другую – с чуть меньшим приоритетом, не так срочно, надо это обосновать. Для этого существуют оценки критичности уязвимостей.
В ИБ их множество, несколько десятков можно назвать точно. Полезный обзор систем скоринга уязвимостей есть на портале Резбез, рекомендую.

Классика – оценка приложений

Можно ли с их помощью оценивать уязвимости из области AI Security? Что это вообще за уязвимости? В реальной практике такие существуют. Рассмотрим примеры.

  1. CVE-2024-12366 – уязвимость в PandasAI 2.4.3. Заключается в отсутствии проверки генерируемого ллм кода, что могло привести к исполнению опасных вызовов. CVSSv3 = 9.8, посчитан CISA-ADP.

  2. CVE-2024-8309 уязвимость в LangChain 0.2.5, позволяющая также ввиду отсутствия проверки ответов модели произвести sql-инъекцию в БД Neo4J. Заключается в отсутствии санитизации ввода пользователя. CVSSv3 = 9.8, посчитанный NIST, или 4.9 по версии ProtectAI.

  3. CVE-2024-5184 – уязвимость в EmailGPT. Это расширение Google Chrome, позволяющее через Gmail работать c моделями OpenAI. Дело также в отсутствии санитизации пользовательского ввода, что может привести к различным последствиям, от DoS до утечки системного промпта. Оценена по CVSSv4 авторами (Synopsys) на 8.5, по CVSSv3 ими же на 6.5 и NIST’ом на 9.1.

  4. Другие промпт-инъекции: CVE-2024-5565 (CVSSv3=8.1 by JFrog), CVE-2024-48140 (CVSSv3=7.5 by CISA-ADP), CVE-2024-4099 (CVSSv3=5.3 by NIST, CVSSv3=3.1 by GitLab)

Вывод – оценка проводится для приложений, использующих LLM, с точки зрения классических векторов атак. И это заложено в основной цели таких систем. не только CVSS, но и других, как строго алгоритмических (CVSS, SSVC, VISS), так и на основе ML (EPSS, Vulners AI Score).

Классика – оценка промпт-атак

Однако вопрос можно рассмотреть с другой стороны. Все эти CVE’шки описывают промпт-атаки на GenAI-модели. А как измерить, насколько критична для реализации нежелательных генераций та или иная промпт-атака по отношению к определенной модели? Моделей ведь не так много, и однозначно можно заключить, что различные промпт-атаки совершенно разные по сложности эксплуатации (хотя на самом деле атака тем критичнее. чем легче, а не сложнее), у них разный Attack Success Rate (ASR), разная заметность.
Можно ли применять стандартные системы для оценки промпт-атак (инъекций, джейлбрейков)? Этим же вопросом задались авторы статьи On the Validity of Traditional Vulnerability Scoring Systems for Adversarial Attacksag ainst LLMs, в которой разбираются 5 различных систем скоринга для атак на GenAI. С помощью DREAD, CVSS v3.1, SSVC, OWASP Risk Rating были оценены 56 различных атак на LLM следующих видов:

  1. Jailbreaks (White-box и Black-box)

  2. Prompt Injections

  3. Evasion attacks

  4. Model-Inference (Membership Inference) attacks

  5. Model-Extraction attacks

  6. Poisoning/Trojan/Backdoor

Оценка производилась путем усреднения ответов GPT-4o, LLAMA3.2-90b, и Perplexity AI. Вывод – эти системы оценки не подходят, так как во многом характеристики систем имеют низкодисперсные значения в совокупности по всем атакам. Недостатки рассмотренных систем оценки следующие: чрезмерный акцент на триаде CIA, и недостаток контекста по AI, выражающийся в субъективности численных оценок и ограниченности качественных.

Авторы предлагают несколько перспективных направлений исследований в области оценки критичности атак:

  • возможные последствия

    • подрыв доверия

    • распространение дезинформации

    • получение вредных и предвзятых результатов

  • учет архитектуры и цели LLM

    • большая восприимчивость крупных моделей к атакам из-за более сложных границ принятия решений

    • отражение критичности безопасности данных обучения в критичности безопасности самой LLM – если модель обучена на конфиденциальных даннных, так как это важнее, нежели если на данных из открытых источников

    • потенциальная повышенная восприимчивость мультимодальных LLM к кросс-модальным атакам (звук+изображение, например)

  • более многоступенчатые качественные метрики оценки.

Специальные системы для AI

Поехали дальше. Существуют системы для скоринга уязвимостей, специализированные под AI. Мне известны три такие.

  1. Microsoft Evaluation and monitoring metrics for generative AI. Механизм предоставляется в рамках платформы Azure AI Foundry для разработки приложений с GenAI. Его работа делится на 4 этапа:

    1. Подготовка заготовок атакующих промптов с помощью шаблонов

    2. Создание атакующих промптов на основе заготовок с помощью LLM и получение ответов на них от тестируемого приложения с GenAI

    3. Добавление (опционально) дополнительных данных от команды Red Team, если пользователь платформы обладает ими

    4. Проводится оценка ответа на содержание контента, разжигающего ненависть и неравенство, насильственного, сексуального, связанного с членовредительством, защищенного авторским правом, а также с прямыми и непрямыми джейлбрейками. Под прямыми джейлбрейками понимают атакующие запросы, содержащиеся в тексте с ролью “пользователь”, а непрямые – вне роли “пользователь”, в частности, в прилагаемых к запросу документах. Реализуется оценка в перечисленных плоскостях с помощью отдельных LLM-as-a-judge, сопровождаемых специальными для каждой плоскости инструкциями.

    Системы оценки критичности уязвимостей в AI Security - 2

    Всего платформа предлагает 20 различных evaluator’ов, при чем все они, кроме SimilarityEvaluator, предоставляют численную оценку и текстовое объяснение своего решения.

    Минус этой системы – основной фокус лежит в области AI Safety, то есть отслеживаются нарушения этики, моральный ущерб и прочее. Помимо этого, метод не формализован, и будет давать на одних и тех же входных данных не идентичные оценки. И главное – оценка нацелена на проверямое приложение с интеграцией с GenAI, а не на сами атаки.

  2. OWASP AIVSS draft (от 29.12.2024). Оценка общего уровня уязвимости AI-системы к AI-рискам, в том числе атаки, деградация модели, недостатки ЖЦ системы, социальный и этический ущерб, статистическая ненадежность ИИ. Идейно наследует концепцию CVSS: предлагает провести расчет base metrics, impact metrics и ai specific metrics. Все метрики и подметрики распределены от 0 до 1.

    1. Base metrics полностью идентичны exploitability metrics, входящих в состав base metrics group CVSSv3.1.

    2. Impac metrics также взяты из base metrics group CVSSv3.1.

    3. AI specific metrics оценивает 10 аспектов безопасности модели, и по security, и по safety:

      • MR (Model Robustness, Устойчивость модели): Оценивает устойчивость системы к атакам на модель и её деградации.

      • DS (Data Sensitivity, Чувствительность данных): Показывает риски, связанные с конфиденциальностью, целостностью и происхождением данных, используемых AI-системой.

      • EI (Ethical Implications, Этические последствия): Рассматривает возможные проявления предвзятости, проблемы прозрачности, вопросы ответственности и влияние на общество.

      • DC (Decision Criticality, Критичность решений): Измеряет потенциальные последствия неправильных или злонамеренных решений, принимаемых AI-системой.

      • AD (Adaptability, Адаптивность): Оценивает способность системы адаптироваться к новым угрозам и поддерживать безопасность на протяжении времени.

      • AA (Adversarial Attack Surface, Поверхность атак): Оценивает степень подверженности системы различным методам атак злоумышленников.

      • LL (Lifecycle Vulnerabilities, Уязвимости на этапах жизненного цикла): Анализирует риски безопасности на различных этапах жизненного цикла AI-системы.

      • GV (Governance and Validation,Управление и валидация): Оценивает наличие и эффективность механизмов управления и процессов проверки.

      • CS (Cloud Security Alliance LLM Taxonomy, Таксономия Cloud Security Alliance для больших языковых моделей): Учитывает конкретные угрозы для больших языковых моделей в облачных средах, определённые в таксономии CSA LLM Threat Taxonomy (которые во многом повторяются с теми подметриками, что указаны выше; зачем это, непонятно).

      • ModelComplexityMultiplier (Множитель сложности модели): Фактор, корректирующий итоговую оценку AI-specific metrics в зависимости от сложности AI-модели (от 1.0 для простых моделей до 1.5 для высоко сложных моделей). Однако на вопрос, что такое “сложные модели”, авторы предлагают отвечать экспертам-пользователям самостоятельно…

    Минус – также не позволяет оценить критичность отдельного метода атаки, потому что направлен на всю систему в целом. Более того, на данный момент формула в данной системе – перемножение всех параметров друг на друга (за исключением CIA – из их значений берется среднее). Такой способ агрегации параметров дает сильную неравномерность – 2-3 параметра получили низкие значения, и вся метрика ушла вниз.

  3. Статья Security Vulnerability Analyses of Large Language Models (LLMs) through Extension of the Common Vulnerability Scoring System (CVSS) Framework (Biju et al.) посвящена расширению системы оценки уязвимостей CVSS для анализа рисков безопасности больших языковых моделей (LLM), таких как GPT и DALL-E. Авторы вводят новые метрики (происхождение атаки, сложность доступа, взаимодействие атакующего и организационное влияние), позволяющие более точно оценивать угрозы, связанные с инъекцией промптов и отравлением обучающих данных. Цель работы — устранить пробелы в текущей системе CVSS и дать организациям инструмент для эффективного управления рисками LLM-приложений.
    Авторы ввели следующие три метрики:

    • AttackOrigin (источник атаки):

      • Поясняет, является ли атакующий внешним злоумышленником или внутренним сотрудником. Внутренний нарушитель обычно имеет больше возможностей и знаний о модели, что повышает критичность атаки.

    • AccessComplexity (сложность доступа):

      • Оценивает уровень предварительных знаний атакующего о внутреннем устройстве модели.

      • Black-box означает, что у атакующего нет доступа к параметрам и структуре модели, он видит только выходные данные и может отправлять ей запросы.

      • White-box подразумевает полный доступ к архитектуре, параметрам и данным обучения модели, что упрощает проведение успешной атаки и увеличивает её потенциальный вред.

    • AttackerInteraction (степень вовлечённости атакующего):

      • Определяет, насколько атака автоматизирована.

      • Низкий уровень вовлечённости означает, что для успешной атаки нужно постоянное участие человека (например, постоянная адаптация промпта). Это усложняет проведение масштабных атак.

      • Высокий уровень автоматизации позволяет атакующему легко масштабировать атаку, например, запуская автоматизированные скрипты, отправляющие множество промптов с минимальным вмешательством человека.

    При этом авторы не учитывают такие параметры, как:

    • Бюджет атакующего — затраты, необходимые для атаки.

    • Заметность атаки — насколько легко атаку обнаружить.

    • Эффективность атаки (например, Attack Success Rate, измеренный на каких-то референсных моделях).

    Хотя это единственная система, которая оценивает именно отдельные атаки/уязвимости с GenAI-спецификой.

Итого

В этот раз сказка с открытым концом. Систем, эффективно оценивающих промпт-атаки на конкретную модель, нет. Хотя интересно видеть проникновение определенных идей в разные системы. Например, авторы статьи On The Validity… предполагают только на перспективу, что надо бы учитывать масштаб модели при ее оценке, а разработчики AIVSS непосредственно учитывают это отдельным множителем (хоть и неконкретным по своей сути).
Имея такую оценку по критичности промпт-атаки для конкретной LLM, используемой в конкретном приложении, можно использовать ее в многосоставном процессе оценки защищенности. Например, учесть ее при подсчете оценки критичности уязвимости, реализованной с помощью данной промпт-атаки. Поживем, увидим, появится ли что-то подобное.

Автор: ivolake

Источник

Rambler's Top100