AppGuard зменшує поверхню атаки та зупиняє загрози в режимі реального часу
AppGuard зменшує поверхню атаки та зупиняє загрози в режимі реального часу
Команди забезпечення безпеки підприємств все частіше покладаються на платформи EDR, XDR та SIEM з підтримкою ІІ для більш швидкого виявлення загроз, обробки оповіщень, відновлення хронології дій зловмисників та планування заходів у відповідь. Постачальники позиціонують ці можливості як революційні. Однак задокументований інцидент у виробничому середовищі показує, як обмеження безпеки та конфіденційності, закладені в комерційні моделі ІІ, можуть призвести до збоїв або низької ефективності цих рівнів саме тоді, коли потрібен новий, критично важливий аналіз.
Приклад реального життя: злом системи автономного ІІ в Hugging Face.
У липні 2026 року компанія Hugging Face повідомила про те, що автономна система ІІ-агентів здійснила наскрізне вторгнення до частини її виробничої інфраструктури. Шкідливий набір даних використовував два шляхи виконання коду в конвеєрі обробки даних. Потім агент підвищив свої привілеї, отримав облікові дані хмари та кластера та перемістився внутрішніми кластерами. Він виконав тисячі дій (понад 17 000 зареєстрованих подій) у роях пісочниць, що короткочасно працюють, із самопереміщуваним управлінням і контролем, і все це за одні вихідні.
Hugging Face виявила активність за допомогою власної системи виявлення та аналізу аномалій із використанням штучного інтелекту. Коли група безпеки спробувала провести поглиблений криміналістичний аналіз реальних журналів атак, експлойтів та артефактів управління з використанням комерційних моделей, доступних через стандартні API, запити було заблоковано. Системи безпеки постачальників не змогли відрізнити легітимних фахівців із реагування на інциденти від зловмисників.
Судово-криміналістичний аналіз вдався тільки після того, як команда перейшла на саморозміщувальну модель з відкритим вихідним кодом (без обмежень щодо безпеки та конфіденційності роботи моделі), що працює на власній інфраструктурі Hugging Face. Такий підхід також дозволив зберегти конфіденційні дані та облікові дані всередині організації.
Чому комерційні моделі ІІ обмежують аналіз реальних атак
Комерційні моделі ІІ, що використовуються в інструментах безпеки, вводять обмеження з двох взаємопов'язаних, але різних причин.
Обмеження безпеки призначені для запобігання створенню моделями шкідливих дій або сприяння їм. Коли моделі надається реальний експлойт-код, послідовність команд зловмисника або нові корисні навантаження, її класифікатори часто розглядають вхідні дані як потенційне неправомірне використання та відхиляють або жорстко фільтрують запит. Мета полягає в тому, щоб запобігти допомозі моделі у створенні чи вдосконаленні атак.
Обмеження конфіденційності спрямовані на захист особистих та корпоративних конфіденційних даних. Моделі та сервіси, що їх використовують, налаштовуються таким чином, щоб обмежувати зберігання, навчання або розкриття ідентифікаторів, таких як IP-адреси, імена користувачів, імена співробітників або інші дані, які можуть розкрити особи чи внутрішні системи. На практиці це може означати редагування, відмову або обмеження обробки саме тих контекстних даних (підозрілих IP-адрес, облікових записів або імен хостів), які необхідні аналітикам безпеки для кореляції та отримання достовірної інформації.
Обидва набори обмежень існують із поважних причин: зниження ризику неправомірного використання, відповідність вимогам законодавства та захист даних клієнтів. Однак при застосуванні до реальних телеметричних даних інцидентів вони можуть погіршити можливості виявлення, сортування, реагування та аналізу інцидентів, які команди безпеки очікують від систем EDR, XDR та SIEM на основі штучного інтелекту.
Обмеження у сфері безпеки та конфіденційності ІІ дають противникам перевагу перед захисниками.
Зловмисники, які використовують необмежені або самостійно розміщені необмежені моделі (з відкритим вихідним кодом), не стикаються з аналогічними перешкодами. Їхні агенти можуть обробляти, генерувати та адаптуватися до будь-яких даних без фільтрів безпеки або приховування конфіденційної інформації. Захисники, що використовують комерційні сервіси ІІ, навпаки, можуть зіткнутися з блокуванням або неповним аналізом у момент появи нових артефактів.
Ця асиметрія особливо помітна у протистоянні загрозам із боку автономних агентів. Автономні агенти генерують великий обсяг мінливої, адаптивної активності, що саме собою створює проблеми для традиційного зіставлення образів. Коли рівень ІІ, призначений для прийняття рішень із високим ступенем достовірності, сам обмежений, захисники втрачають швидкість та контекст. Противники виграють час.
Розширення «вікна завдання шкоди»: більше часу для успіху зловмисників.
Період, протягом якого шкідливе програмне забезпечення може завдати шкоди, починається з моменту його запуску і закінчується після того, як засоби кіберзахисту припиняють його роботу. Чим більше заходів необхідно контролювати і чим більша залежність від зовнішніх ресурсів, тим довше зберігається період, протягом якого шкідливе програмне забезпечення може завдати шкоди і поширитися.
Атаки з використанням агентів по суті розширюють вікно можливостей. Вони швидко адаптуються та створюють нові артефакти, що вимагають більш ретельного спостереження. Коли обмеження безпеки чи конфіденційності ще більше уповільнюють або погіршують роботу систем аналізу та криміналістики з використанням ІІ, вікно можливостей для заподіяння шкоди стає ще ширшим. В результаті відбувається більше крадіжок даних, їх поширення стає більш масштабним, і у зловмисника з'являється більше можливостей для того, щоб заблокувати або вивести інструменти виявлення загроз на кінцевих пристроях до того, як вони зможуть забезпечити значну інформацію.
Моделі самостійного розміщення виявилися ефективними для одного постачальника, але наскільки вони є практичними для більшості підприємств?
Компанія Hugging Face досягла успіху, запустивши модель з відкритим вихідним кодом (з відкритим вихідним кодом) на власній інфраструктурі, уникнувши як блокувань, так і витоку даних ззовні. Таке рішення вимагає наявності фахівців, які мають досвід вибору, розгортання, обслуговування та захисту подібних моделей, а також інфраструктури для їх запуску в масштабі, необхідному для швидкого аналізу інцидентів. Крайнім прикладом є спроба запустити модель розміром із Kimi K3, яка потребує значних обчислювальних ресурсів та пам'яті, яких у багатьох підприємств просто немає для виділеного внутрішнього використання з метою реагування на інциденти.
Чи є у вашої організації готові та перевірені до інциденту фахівці та ресурси? Для більшості підприємств відповідь – ні. Створення та експлуатація власних аналітичних можливостей на основі ІІ - це значні інвестиції, які сьогодні недоступні більшості команд безпеки.
Постачальники розвиватимуться, але компроміси ще довгий час зберігатимуться.
Згодом постачальники рішень у сфері кібербезпеки будуть прагнути збалансувати більш потужні можливості виявлення та реагування з вимогами безпеки та конфіденційності. Деякі доповнюватимуть комерційні моделі альтернативними рішеннями з відкритим вихідним кодом. Інші розроблятимуть методи, що дозволяють уникнути передачі найбільш конфіденційних даних до інструментів ІІ, прагнучи при цьому зберегти ефективність. Також може виникнути тісніша взаємодія між рівнями кібербезпеки, оскільки постачальники прагнуть більш повного контексту.
Кожен із цих шляхів пов'язаний зі своїми ризиками та складнощами — потенційний витік даних клієнтів у разі компрометації компонентів, які забезпечують зважування відкритих даних, зниження аналітичної цінності при прихованні конфіденційних ідентифікаторів та нові проблеми інтеграції. Для досягнення правильного балансу потрібен час. Штучний інтелект продовжуватиме надавати нові можливості, але, як і більшість потужних інструментів, він нестиме постійні компроміси.
Як AppGuard знижує ризики, пов'язані зі штучним інтелектом, без цих обмежень.
Як мінімум, AppGuard скорочує обсяг роботи, що виконується рівнями виявлення та реагування, обмежуючи дії шкідливого ПЗ та несанкціонованих процесів на кінцевій точці. Це досягається за рахунок локальних, орієнтованих на конкретні методи контролю - авторизації запуску, ізоляції процесів та ізоляції критично важливих ресурсів - які працюють без комерційних моделей ІІ, зовнішніх API або пов'язаних з ними обмежень безпеки та конфіденційності. У більшості випадків AppGuard взагалі запобігає відкриттю «вікна ризику».
Якщо ваші існуючі інструменти виявлення та реагування не можуть вчасно виявити або зупинити будь-що, AppGuard може зупинити це в режимі реального часу. Оскільки управління здійснюється локально і фокусується на тому, що дозволено робити процесам, а не намагається класифікувати кожну нову поведінку постфактум, вона залишається ефективною навіть у випадках затримки, обмеження чи неповноти аналізу за допомогою ІІ. AppGuard розроблений як додатковий шар, який закриває прогалини у виконанні, залишені інструментами виявлення, а не як їхня повна заміна.
AppGuard, будучи рішенням, орієнтованим на контроль, а не виявлення загроз, не вимагає збору потенційно конфіденційних даних клієнтів і прагне цього уникати. У той час як інструменти виявлення повинні спостерігати та фіксувати великі дані про активність (включаючи ідентифікатори та контекст, які можуть бути конфіденційними) для формування шаблонів, AppGuard функціонує швидше як стіна, яка просто запобігає несанкціонованим діям, не вимагаючи збору або аналізу цих даних.
Практичні кроки для керівників служб безпеки.
- Провести інвентаризацію областей застосування комерційних можливостей ІІ у процесах виявлення, сортування, реагування та криміналістичної експертизи, а також оцінити наслідки обмеження цих можливостей під час інциденту з новим агентом чи агентом.
- Зміцніть механізми контролю, що обмежують те, що може запускатися і що може робити програма, що запускається, тим самим скоротивши кількість етапів, які зловмисник може пройти до виявлення або аналізу.
- Оцінюйте вимоги до суверенітету даних на ранніх етапах; для багатьох організацій забезпечення прямого контролю за конфіденційними матеріалами зловмисників стає практичною необхідністю.
Існуючі рекомендації AppGuard щодо стримування ризиків, пов'язаних з автономними агентами, являють собою конкретну відправну точку, яка поширюється на ширший клас загроз, проілюстрований інцидентом з особою, що «обіймається».
Висновок – Превентивний захист
Обмеження безпеки та конфіденційності в комерційних моделях ІІ виконують важливі захисні функції, однак вони можуть призвести до того, що рівні виявлення та реагування, засновані на ІІ, будуть давати збої або працювати неефективно проти реальних нових атак. В результаті розширюється «вікно можливостей для заподіяння шкоди», що сприяє противникам.
Система запобігання, що блокує виконання шкідливих дій на ранній стадії без опори на обмежений аналіз за допомогою ІІ безпосередньо закриває або звужує це вікно можливостей. AppGuard забезпечує цю можливість локально, без недоліків у сфері безпеки та конфіденційності, які притаманні рівням, що залежать від ІІ. Вона зупиняє в режимі реального часу те, що втрачають інші інструменти, одночасно підвищуючи стійкість усієї кіберсистеми.
