За підтримки Google Cloud
Зловмисники використовують автономних агентів для пошуку вразливостей та здійснення атак з мінімальним втручанням людини. Це означає, що час від виявлення до експлуатації став занадто коротким для традиційних методів, таких як виявлення на основі сигнатур та виправлення, які самі по собі вже не справляються. Командам безпеки необхідно виявляти аномальну поведінку зі швидкістю машини.
Ці події роблять шар даних ще критичнішим, ніж будь-коли. Командам безпеки потрібно обробляти величезні обсяги активності, включно з діями внутрішніх агентів, та в реальному часі пов’язувати їх з контекстом підприємства. Більшість архітектур даних не були створені для такого типу роботи.
Новий вид даних для безпеки
Сучасна розвідка загроз повинна глибше аналізувати те, що насправді роблять додатки та агенти. Агентні системи додають нові дані, які потребують моніторингу, такі як дії та траєкторії самих агентів. Оскільки агенти працюють зі швидкістю машини, ці дані зростають швидше, ніж будь-що, з чим команди безпеки мали справу раніше.
Кожна дія, яку виконує агент, генерує запис у журналі або трасування, але проста агрегація журналів сама по собі мало що розповість. Командам безпеки необхідно пов’язувати ці записи з траєкторією кожного агента, щоб вони могли відновити послідовність подій і зрозуміти, що сталося та які системи були зачеплені.
Це надає розвідці загроз схожий профіль навантаження, як і засобам спостереження (observability), з журналами величезного масштабу, безперервним збором даних, обробкою потоків та тріажем. Журнали, трасування та метрики, які команди з надійності сайтів (site reliability teams) використовують для забезпечення роботи сервісів, також можуть виявляти ознаки компрометації або зловмисного наміру.
Основні вимоги до шару даних безпеки
Оцінка ризику вимагає обґрунтування необробленої телеметрії бізнес-контекстом. Аномалія, яка впливає на тестове середовище, менш термінова, ніж та, що торкається виробничої бази даних, і команди безпеки повинні мати можливість розрізняти їх майже в реальному часі.
Прийняття цих рішень вимагає доступу до всіх даних, де б вони не знаходилися, і доступ до них не може залежати від тривалого проєкту міграції. Це одна з причин появи концепції «безмежного озерохаусу» (borderless lakehouse), яка надає командам безпеки та агентам прямий доступ до даних у багатьох хмарах, базах даних та SaaS-інструментах без необхідності їх переміщення.
Відкриті формати, такі як Apache Iceberg, є важливою частиною цієї зміни. Коли дані безпеки знаходяться у відкритих форматах, на них можуть працювати різні движки, чи то SQL, що масштабується, чи то програма на Python, яку агент пише на льоту. SIEM-системи також розвиваються. Щоб надати командам безпеки максимальну інтероперабельність та доступ до їхніх даних, SIEM-системи повинні підтримувати відкриті платформи даних та працювати з федеративними даними на місці, без їх попереднього імпорту.
Ця гнучкість створює власну проблему безпеки. Коли дані залишаються на своєму місці, там же залишаються і дозволи, що керують ними, і ці дозволи неможливо керувати з центрального місця. Дублювання та синхронізація правил у кожному джерелі не масштабується до тисяч агентів, а передача авторизації кінцевим користувачам створює нові ризики, такі як ін’єкції підказок (prompt injection) або витік облікових даних. Рішенням є деталізовані засоби контролю, аж до рядків і стовпців, визначені один раз і застосовані під час запиту, в тому числі до таблиць у відкритих форматах. Кожен запит повинен передавати фактичну ідентичність користувача за допомогою короткочасних, обмежених облікових даних, щоб агенти не могли перевищити повноваження особи, яка ними керує.
Коли з’являється сигнал про загрозу, завдання переходить від пошуку правильних журналів до аналізу впливу. Обробка графів може відобразити ізольовану подію на навколишні активи та допомогти командам безпеки відстежити будь-яке горизонтальне переміщення. Каталог знань додає ще один рівень контексту, надаючи агентам та людським слідчим карту активів даних організації, щоб вони знали, де шукати.
Контроль витрат у масштабі машини
Великі мовні моделі добре аналізують записи журналів, але їхнє використання для петабайтів телеметрії безпеки швидко стає дорогим. Шар даних повинен звужувати обсяг даних, що обробляються, перш ніж моделі почнуть свою роботу.
Це може відбуватися поетапно. Потокові запити відстежують події під час їх надходження та позначають підозрілі. Другий прохід перевіряє їх на основі історичних даних, щоб звузити список. Тільки після цього агент проводить розслідування.
Деякі базові моделі попередньо навчені на мільярдах часових рядів, таких як мережевий трафік або активність входу з часом, тому вони вже знають, як виглядають нормальні патерни. Це дозволяє їм виявляти незвичайну активність на ранніх стадіях без спеціального навчання. Для простіших завдань, як-от сортування записів журналів на «небезпечні» та «нешкідливі», платформа даних може створювати невелику, спеціалізовану модель на льоту, що дешевше, ніж обробляти кожен запис через велику модель.
Розслідування, керовані агентами, також роблять попит непередбачуваним. Коли агенти починають шукати в історичних журналах, обсяг запитів може різко зрости, а потім так само швидко впасти. Апаратні пристрої та заздалегідь підготовлена хмарна потужність не були створені для такого патерну. Платформа даних потребує безсерверного масштабування, яке розширюється та стискається за потреби, щоб команди безпеки платили лише за те, що вони використовують, до секунди.
Спостереження за власними агентами
Агенти також створюють нові ризики безпеки всередині підприємства. Коли компанія доручає роботу агенту, вона повинна вирішити, до чого цей агент матиме доступ, так само, як і для нового співробітника.
Традиційне програмне забезпечення працює передбачувано, але агенти — ні. Їхня поведінка є ймовірнісною, тому їм потрібні власні ідентичності з обмеженнями на доступ до даних, документів та систем, навіть якщо особа, яка ними керує, має ширші дозволи.
Ін’єкції підказок роблять ці обмеження ще важливішими. Якщо раніше зловмисники використовували SQL-ін’єкції проти баз даних, то тепер вони можуть приховувати інструкції в даних, які читає агент. Все, що потрапляє в контекст агента, може вплинути на його подальші дії, тому команди безпеки повинні контролювати, що кожен агент може читати, записувати та надсилати. Кожне зовнішнє з’єднання є потенційним шляхом для витоку даних.
Навіть авторизований агент може виконати послідовність індивідуально дозволених дій, які в комбінації стають небезпечними. Але за власними агентами легше стежити. Агенти зловмисника з’являються лише як аномалії, тоді як ваші залишають повний запис їхніх дій. Аналіз цього запису в масштабі машини — це те, як команди безпеки виявляють агента, який відхилився від курсу.
Від пасивного архіву до активної оборони
Оскільки агенти беруть на себе все більше роботи, завдання аналітика безпеки змінюється. Замість ручного виконання запитів та тріажу сповіщень, аналітики витрачатимуть більше часу на визначення того, що є важливим, і на перегляд результатів роботи агентів, подібно до того, як розробники зараз переглядають плани для коду, написаного агентами, замість того, щоб читати кожен рядок. Це можливо лише за умови, що агенти можуть демонструвати свою роботу. Аналітикам потрібно бачити, які дані вивчав агент, які кроки він зробив і як він дійшов свого висновку.
Це змінює роль шару даних у безпеці. Раніше він був місцем для зберігання та запитів до подій після їхнього фактичного відбуття. Зараз він є частиною того, як команди безпеки розуміють ці події в процесі їхнього виникнення. Ваша архітектура даних повинна надавати вашим агентам і командам безпеки швидкість, контекст та масштабованість для зупинки атаки до того, як вона зможе завдати шкоди.
Щоб дізнатися більше, приєднайтеся до нашої майбутньої віртуальної події Trusted Agents, Real Outcomes. Завантажте це керівництво зі забезпечення безпеки автономних середовищ за допомогою Agentic Data Cloud від Google та створення основи платформи даних для безпеки за допомогою BigQuery.
Томас Таліус — віце-президент з інженерії BigQuery у Google Cloud.
Спонсоровані статті – це контент, створений компанією, яка або платить за публікацію, або має ділові стосунки з VentureBeat, і вони завжди чітко позначені. Для отримання додаткової інформації звертайтеся за адресою [email protected].
Подробиці можна знайти на сайті: venturebeat.com