AI-безопасность не сломана, мы просто защищаем не те вещи

Отрасль кибербезопасности имеет закономерность, когда появляется новая технология, мы сразу начинаем строить стены вокруг нее. Мы сделали это с облаком, мы сделали это с контейнерами, и теперь мы делаем это с ИИ, за исключением того, что стены, которые мы строим, находятся в совершенно неправильных местах.

Войдите в любую корпоративную безопасность сегодня, и вы услышите те же приоритеты: безопасность моделей ИИ, защита данных обучения, проверка выводов и развертывание ИИ-управляемых копилотов. Поставщики спешат продавать инструменты “безопасности ИИ”, которые фокусируются исключительно на контроле моделей, таких как ограничители, защиты от инъекции запросов и платформы мониторинга моделей.

Но атакующие используют ваши интеграции ИИ как шоссе во все остальное.

Настоящая поверхность атаки, которую никто не наблюдает

Одна закономерность, которую мы постоянно наблюдаем в корпоративных средах, рассказывает тревожную историю о командах безопасности, которые инвестируют значительные средства в обеспечение безопасности своих сред разработки ИИ: контролы доступа к моделям, кадры управления данными, инструменты безопасности MLOps. Это дает ложную уверенность в том, что их ИИ “заперт”.

Но когда вы картографируете фактическую поверхность атаки, вы видите, что чат-боты ИИ часто содержат токены OAuth для десятков платформ SaaS, ключи API с избыточными разрешениями в облаке и доверительные отношения идентификации, которые могут создать прямые пути от простой инъекции запроса к производственной инфраструктуре. Модели сами по себе могут быть безопасными, но экосистемы, в которых они существуют, часто открыты, и это не является исключением.

Корпорации теперь используют в среднем 130+ приложений SaaS, с интеграциями ИИ, охватывающими поставщиков идентификации, облачную инфраструктуру, базы данных и системы бизнес-критического уровня. Каждая интеграция является потенциальным путем атаки, и каждое подключение API является границей доверия, которую атакующие активно проверяют.

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

Почему модельно-ориентированная безопасность пропускает суть

Текущий подход к безопасности ИИ основан на фундаментальном недоразумении того, как работают современные атаки. Мы рассматриваем ИИ как самостоятельный актив, который нуждается в защите, подобно тому, как мы могли бы защитить базу данных или веб-приложение. Но ИИ в производстве не существует в изоляции. Это узел в сложном графе идентификаций, разрешений, API и потоков данных.

Рассмотрим типичное корпоративное развертывание ИИ. У вас есть агент ИИ с доступом к вашему Google Workspace. Он подключен к Salesforce через API. Он интегрирован со Slack для уведомлений. Он извлекает данные из бакетов AWS S3. Он аутентифицируется через Okta или Azure AD. Он запускает рабочие процессы в ServiceNow.

Традиционная безопасность ИИ фокусируется на самой модели: ее безопасности, проверке запросов, безопасности вывода. Но атакующие фокусируются на интеграциях: что они могут достичь через скомпрометированные учетные записи служб, где они могут переместиться через манипуляции API, какие границы доверия они могут пересечь через эксплуатируемые интеграции.

Атака не начинается и не заканчивается с моделью ИИ. Модель является только точкой входа.

Пути атаки не уважают границы продуктов

Вот где большинство организаций застревают. Они развернули инструменты безопасности, которые каждая обеспечивает видимость в отдельной области. Один инструмент отслеживает разрешения в облаке. Другой отслеживает конфигурации SaaS. Третий управляет управлением идентификацией. Четвертый занимается управлением уязвимостями.

Каждый инструмент показывает вам свою часть головоломки. Ни один из них не показывает вам, как части соединяются.

Согласно Gartner, организации теперь используют в среднем 45+ инструментов безопасности. Однако, несмотря на это огромное вложение, атакующие успешно объединяют неправильные конфигурации в этих областях, потому что ни один инструмент не может увидеть полный путь атаки.

Атакующему не нужно найти критическую уязвимость в вашей модели ИИ. Ему просто нужно найти цепочку. Может быть, это неправильно настроенная роль IAM, прикрепленная к вашей службе ИИ, которая имеет разрешения на бакет S3, который содержит учетные данные для приложения SaaS, которое имеет административный доступ к вашей производственной среде.

Каждая отдельная неправильная конфигурация может иметь оценку “средняя” или “низкая” в ваших инструментах безопасности. Но если их объединить? Это критическое воздействие. И оно полностью невидимо, если вы смотрите на каждую область безопасности изолированно.

Императив управления экспозицией

Это почему разговор должен перейти от “безопасности ИИ” к непрерывному управлению угрозами экспозиции для сред, интегрированных с ИИ.

Это не достаточно спросить, являются ли наши модели ИИ безопасными. Команды безопасности должны понимать, что атакующий может фактически достичь, если он скомпрометирует учетную запись службы ИИ. Им нужно иметь видимость того, как неправильные конфигурации в облаке, SaaS и системах идентификации могут быть объединены. Им нужно знать, как интеграции ИИ меняют их поверхность атаки в реальном времени. И им нужно расставлять приоритеты рисков на основе фактической возможности атаки, а не только оценок серьезности.

Большинство программ безопасности все еще расставляют приоритеты рисков изолированно, используя оценки CVSS и списки контроля соответствия, которые полностью игнорируют, является ли уязвимость фактически эксплуатируемой в вашей конкретной среде.

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

Что такое осведомленная о путях атаки безопасность

Обеспечение безопасности ИИ в производстве требует фундаментально другого подхода, и это сводится к четырем ключевым сдвигам в мышлении.

Во-первых, вам нужно объединенная видимость в области безопасности. Перестаньте просить каждый инструмент безопасности работать в своей отдельной области. Ваши инструменты безопасности в облаке, управление идентификацией, управление SaaS и сканирование уязвимостей все содержат части головоломки пути атаки. Им нужно делиться данными в реальном времени, чтобы вы могли увидеть, как неправильные конфигурации объединяются.

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

В-третьих, расставляйте приоритеты на основе контекста. Неправильно настроенный бакет S3 не является критическим только потому, что он общедоступен. Он критичен, если он общедоступен и содержит учетные данные, и эти учетные данные имеют привилегированный доступ, и они доступны из интернет-экспонированного актива. Контекст важнее любой отдельной оценки.

В-четвертых, переходите к предварительному исправлению. К тому времени, когда ваша команда SOC будет расследовать оповещение, вы уже потеряли ценное время реагирования. Современная защита требует возможности закрыть эксплуатируемые пути до того, как они будут использованы, а не после инцидента.

Предупреждение, которое мы не можем игнорировать

Когда ИИ становится встроенным во все слои корпоративной структуры, поверхность атаки расширяется быстрее, чем команды безопасности могут вручную рассуждать о ней. Мы добавляем интеграции ИИ в 10 раз быстрее, чем мы их защищаем.

Если вы защищаете ИИ в изоляции, защищая модель, игнорируя экосистему, в которой она работает, вы уже отстаете. Атакующие не думают в терминах инструментов, они думают в терминах путей. Они не эксплуатируют отдельные уязвимости. Они объединяют неправильные конфигурации в вашей整个 среде.

Корпорации, которые успешно обеспечат безопасность ИИ, не будут теми, у которых есть наиболее инструментов безопасности ИИ. Они будут теми, кто понимает, что безопасность ИИ неразрывно связана с управлением экспозицией на всей поверхности атаки.

Безопасность модели является базовой. Что важно, это понимание того, что атакующий может достичь, если он скомпрометирует интеграцию ИИ. До тех пор, пока команды безопасности не смогут ответить на это непрерывно, в реальном времени, на всей своей среде, они не обеспечивают безопасность ИИ. Они просто надеются, что стены, которые они построили, находятся в правильных местах.