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

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

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

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

Наступальна поверхня, яку ніхто не спостерігає

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

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

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

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