Безопасность ИИ не нарушена, мы просто защищаем не те вещи.

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

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

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

Реальная поверхность атаки, за которой никто не следит

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

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

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

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

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

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

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

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

Атака не начинается и не заканчивается на модели ИИ. Модель — это всего лишь точка входа.

Пути атаки не соответствуют границам продукта.

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

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

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

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

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

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

Именно поэтому необходимо сместить акцент с «безопасности ИИ» на непрерывное управление угрозами в средах, интегрированных с ИИ.

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

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

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

Как на самом деле выглядит безопасность с учетом пути атаки

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

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

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

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

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

Предупреждение, которое нельзя игнорировать

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

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

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

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