Figma: LLM-агенти автоматизують розслідування інцидентів

Команда інженерів безпеки Figma постійно стикається зі змінними загрозами, пов'язаними зі змінами хмарної інфраструктури, новими інструментами розробників та різноманітним програмним забезпеченням на ноутбуках. Історично, реагування на інциденти вимагало значної ручної роботи, особливо для збору контексту.

Від SIEM до агентних систем

Для моніторингу загроз Figma використовує SIEM-систему Panther, яка перевіряє хмарну інфраструктуру, кінцеві точки, SaaS-додатки та системи ідентифікації. При виявленні потенційної проблеми Panther надсилає сповіщення в Slack та створює тікет в Asana для чергових інженерів. Раніше збір контексту для цих сповіщень був основним викликом.

Спостерігаючи за швидким розвитком можливостей LLM-моделей, Figma вирішила розширити використання агентів за межі кодової бази, де вони вже допомагали виявляти вразливості в конфігураціях Okta та AWS. Метою стало створення нової системи для зменшення рутинної роботи та покращення захисту внутрішніх систем.

Рівень RAG: пам'ять для сповіщень

Першим кроком було створення системи класифікації з доповненою генерацією (RAG) на базі AWS Bedrock Knowledge Bases та Amazon Kendra. Початкова мета полягала в тому, щоб надавати історичний контекст про попередні спрацьовування аналогічних сповіщень та, можливо, пригнічувати дублікати.

Коли спрацьовує сповіщення Panther, обробник Lambda перетворює його на стандартизований документ та індексує в Kendra. Зі сповіщення витягуються структуровані поля (IP-адреси, імена користувачів, ідентифікатори облікових записів AWS), які стають атрибутами документа Kendra разом із назвою сповіщення, серйозністю, тегами та часовими мітками. Система запитує Bedrock для семантичних збігів, використовуючи назву сповіщення як основний вектор, та надає перевагу новішим результатам, а також сповіщенням з investigation_context — коментарями чергових інженерів у Slack про їхні висновки. Ці коментарі індексуються без зміни існуючих робочих процесів інженерів, що робить кожне майбутнє схоже сповіщення дешевшим для обробки.

Система RAG генерує та публікує резюме для людей у Slack/Asana. Це призвело до зменшення навантаження на чергових інженерів та дозволило програмно знижувати серйозність сповіщень, які з високою ймовірністю були доброякісними або дублікатами. Це призвело до 20% скорочення кількості викликів чергових.

Додавання агентного рівня

Наступним кроком стало створення агентного рівня поверх RAG, використовуючи Tines для автоматизації робочих процесів. Tines дозволяє запускати цикли агентів LLM з явними інтерфейсами інструментів, такими як читання потоку Slack, пошук користувача Okta, запит даних Panther або відкриття PR.

Коли Panther виявляє подію, обробник Lambda публікує сповіщення в Slack з LLM-резюме та посиланнями на схожі сповіщення від RAG, а потім автоматично позначає @Tines Security Slackbot. Інженери можуть також вручну позначати бота для подальших запитань.

При позначенні бота спрацьовує вебхук у Tines, який запускає маршрутизацію намірів. Легша модель (наприклад, Claude Sonnet) класифікує запит (обробка сповіщення, питання безпеки платформи, запит на затвердження програми тощо). Кожна класифікація направляється до спеціалізованого агента з власним набором інструментів, рівнем авторизації та системним промптом. Це дозволяє кожному агенту мати сфокусований набір інструментів без ризику надмірного доступу.

Інструментарій агента з обробки сповіщень

Агент з обробки сповіщень (використовуючи модель на кшталт Claude Opus) виконує більшу частину розслідування. Він отримує повну історію потоку Slack як контекст, власну пам'ять керування та набір інструментів, необхідних черговому інженеру безпеки:

Okta: отримання профілю користувача, списку груп, історії входів.
North Pole Security Workshop: пошук правил, подій, перевірка статусу синхронізації хостів, застосування правил.
Wiz: отримання журналів аудиту, інвентаризації хмарних ресурсів, виявлення вразливостей.
Slack: читання відповідей у потоці, пошук профілів користувачів, надсилання оновлень.
Panther: отримання деталей сповіщення, вихідних подій, пов'язаних сповіщень.
Зміна коду: відкриття PR у репозиторіях Panther або монорепозиторії.
Під-агент розслідування Panther: LLM-агент, який може писати та виконувати Snowflake SQL для озера даних безпеки.

Запити до озера даних безпеки

Для глибших розслідувань агент з обробки сповіщень делегує завдання під-агенту розслідування. Цей під-агент (також модель на кшталт Claude Opus) перетворює запит природною мовою в Snowflake SQL. Він працює з сховищем даних Panther, яке збирає журнали аудиту з різних джерел (AWS CloudTrail, Okta, GitHub, GCP, osquery, Workshop/Santa, Wiz та інші). Під-агент визначає, які таблиці використовувати, які стовпці та як фільтрувати за часом.

Розвиток та сегментація пам'яті агента

Пам'ять виявилася ключовим фактором корисності системи. Figma використовує кілька типів пам'яті:

Пам'ять випадків (RAG corpus): Історичні сповіщення та контекст розслідувань зі Slack та Asana.
Пам'ять керування: Поведінкові вказівки для агента, що завантажуються як Markdown-документ. Вона містить правила, які агент може оновлювати після виправлень інженерами безпеки.
Записи в базі даних (Tines): Для об'єктів зі станом, таких як відкриті PR або стан розслідування Panther.
Процедурна пам'ять: Найбільш значущий шар пам'яті для під-агента розслідування, організований за тегами. Перед запитом агент завантажує відповідні спогади для джерел даних. Після завершення розслідування, що вимагало виявлення схеми, він зберігає отримані знання. Це дозволило значно скоротити кількість запитів для виявлення схем.

Приклади розслідувань агента

Несанкціонований додаток macOS: Агент виявив, що сповіщення про встановлення несанкціонованого додатка було викликано інженером, який тестував власне правило виявлення. Дії не знадобилися.
Повторювані сповіщення Snowflake: Агент описав поточний стан, делегував запит до під-агента, ідентифікував причину повторення, знайшов чернетку PR для пригнічення та пояснив довгострокове рішення.
Сповіщення, пов'язані зі шкідливим ПЗ: Агент може перевірити підпис бінарного файлу, визначити спосіб встановлення та автоматично створити зміни коду для пригнічення сповіщення в безпечних умовах без втручання людини.

Від розслідування до змін коду

Агент може відкривати PR для виправлення проблем. Для змін у правилах виявлення, білих списках та пригніченнях сповіщень PR відкриваються в репозиторії Panther. Для інфраструктурних змін, конфігурацій сервісів, Terraform або RBAC/IdP агент працює з монорепозиторієм. Для забезпечення контексту в PR, створених ботом, в опис включається ім'я інженера безпеки, який зробив запит, та посилання на початковий потік Slack. Агент також може реагувати на коментарі рецензентів та перебазовувати застарілі гілки.

Захисні механізми

Для всіх викликів інструментів застосовуються детерміновані захисні механізми. Наприклад, кожен PR, створений агентом, автоматично встановлюється як чернетка. Це реалізується як детермінований пост-крок у робочому процесі Tines, а не як інструкція в промпті. Також існують контракти на виклик інструментів, що забезпечують контроль, наприклад, запобігання обробці конфіденційної інформації співробітників або модифікації PR, які агент не створював. Інструменти агента мають обмежену область дії, авторизовані та моніторяться. Агент не має повного доступу до каналів Slack і читає потоки лише тоді, коли його явно позначають.

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

Уроки та майбутнє

З огляду на досвід, Figma відзначає, що процедурна пам'ять мала бути впроваджена з самого початку через її значний вплив. Конфігурація як код є важливою для запобігання фрагментації агентного рівня. Також необхідно заздалегідь продумати модель довіри для публічних каналів Slack, щоб уникнути витоку конфіденційних даних.

Наразі система обробляє всю початкову роботу з реагування на інциденти безпеки. Робота чергового інженера змінилася з "розслідування з нуля" на "перегляд знайденого агентом, підтвердження або виправлення, а також обробку випадків, що потребують людського судження".

Результати включають близько 70% скорочення часу вирішення складних сповіщень, 20% зменшення кількості викликів чергових та 25% менше запитів на затвердження програмного забезпечення для кінцевих точок. Figma оптимістично дивиться на те, що система з часом інтегрує тисячі рішень, відображень схем та поведінкових корекцій, роблячи кожен наступний запуск ефективнішим та точнішим.

Наступний етап передбачає створення кращої площини управління навколо моделі, чіткіше розмежування шарів пам'яті (прецедент, політика, стан) та покращення механізмів прийняття рішень щодо автоматичного закриття або ескалації сповіщень. Figma вважає, що це не вибір "люди або ШІ", а пошук оптимальних рішень між цими крайнощами для зменшення ризиків та підвищення ефективності.

Що це означає для розробників

Ця система змінює роль інженерів безпеки, перетворюючи їхню роботу з "розслідування з нуля" на "перегляд знайденого агентом, підтвердження або виправлення, а також обробку випадків, що потребують людського судження". Агенти також створюють запити на зміни коду (PRs), які інженери переглядають та затверджують, що вимагає розуміння їхньої логіки та контексту.

Ключові факти

Figma розробила агентну систему на базі LLM для автоматизації внутрішньої безпеки.
Система використовує RAG (Retrieval-Augmented Generation) для надання історичного контексту та зменшення навантаження на чергових інженерів.
Вона включає агентний рівень на базі Tines, який класифікує запити та використовує спеціалізовані інструменти для розслідування.
Агент може запитувати сховище даних безпеки, писати зміни коду та відкривати запити на злиття (PRs).
Система має різні типи пам'яті, включаючи процедурну пам'ять для самостійного вивчення схем баз даних.