Безпека штучного інтелекту не зламана, ми просто захищаємо неправильні речі

Індустрія кібербезпеки має певний шаблон, коли з’являється нова технологія, ми одразу починаємо будувати стіни навколо неї. Ми зробили це з хмарними технологіями, ми зробили це з контейнерами, і тепер ми робимо це зі штучним інтелектом, тільки цього разу стіни, які ми будуємо, знаходяться зовсім не в тих місцях.

Виходьте в будь-який огляд безпеки підприємства сьогодні, і ви почуєте ті самі пріоритети: захист моделей штучного інтелекту, захист даних навчання, перевірка виходів та розгортання штучного інтелекту. Виробники спішать продавати інструменти “безпеки штучного інтелекту”, які фокусуються виключно на контролях рівня моделі, таких як поручні, захист від вставки запитів та платформи моніторингу моделей.

Але атакувальники використовують ваші інтеграції штучного інтелекту як шосе до всього іншого.

Дійсна поверхня атаки, яку ніхто не спостерігає

Одним із шаблонів, який ми постійно спостерігаємо в середовищах підприємств, є історія про те, як команди безпеки інвестують великі кошти в захист своїх середовищ розробки штучного інтелекту: контроль доступу до моделей, кадри управління даними, інструменти безпеки 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 разів швидше, ніж ми їх захищаємо.

Якщо ви захищаєте штучний інтелект окремо, захищаючи модель, одночасно ігноруючи екосистему, в якій він діє, ви вже відстали. Атакувальники не думають у інструментах, вони думають у шляхах. Вони не експлуатують окремі уразливості. Вони ланцюжаться помилкові конфігурації через все ваше середовище.

Підприємства, які успішно захистять штучний інтелект, не будуть тими, у кого найбільше інструментів безпеки штучного інтелекту. Це будуть ті, хто розуміє, що безпека штучного інтелекту нерозривно пов’язана з управлінням експозицією по всій поверхні атаки.

Безпека моделі є мінімальним вимогам. Що важливіше, це розуміння того, що атакувальник може досягти, коли скомпрометує інтеграцію штучного інтелекту. До тих пір, поки команди безпеки не зможуть відповісти на це питання безперервно, в реальному часі, по всьому середовищу, вони не будуть захищати штучний інтелект. Вони просто сподіваються, що стіни, які вони збудували, знаходяться в правильних місцях.