Поєднайте доставку із SOC та SIRT

Визначте функції за назвами

Центр операцій безпеки, або SOC, зазвичай відстежує сигнали безпеки, досліджує сповіщення та ескалує підозрювані інциденти. Команда реагування на інциденти безпеки, або SIRT, координує реагування на інциденти безпеки. CSIRT — інша поширена назва цієї функції реагування.

Організації розподіляють ці функції по-різному. Ті самі люди можуть виконувати обидві. Зовнішній постачальник може надавати частину сервісу. Не виводьте охоплення чи повноваження з абревіатури. Записуйте години моніторингу, шляхи ескалації, права ухвалення рішень і зобов’язання реагування.

Фреймворк CSIRT від FIRST описує сервіси, які може надавати команда реагування. NIST поєднує реагування на інциденти з ширшим керуванням ризиками кібербезпеки. Використовуйте ці джерела для визначення своїх обов’язків та інтерфейсів. Фреймворк FIRST, реагування на інциденти NIST.

Включіть розробку з ШІ до сфери виявлення

Система доставки програмного забезпечення має ідентичності, репозиторії, runners, registries, інтеграції та облікові дані розгортання. Агенти додають виклики інструментів і потоки даних до постачальника моделі. Включіть ці межі до проєктування безпеки.

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

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

Підготуйте передачу до інциденту

Визначте, хто може відкликати токен, ізолювати runner, призупинити розгортання або відновити сервіс. Відповідальні за сервіси пояснюють операційні наслідки. Учасники реагування на інциденти безпеки координують розслідування та стримування. Відповідні представники з питань приватності, права та бізнесу оцінюють обов’язки повідомлення для фактичної ситуації.

Вимоги до повідомлення залежать від інциденту та застосовних зобов’язань. Завчасно залучіть належного відповідального за рішення. Не дозволяйте підсумку ШІ ухвалювати це рішення або затримувати встановлену ескалацію.

Розгляньте вигаданий інцидент із токеном

О 14:05 UTC SOC виявляє, що ідентичність збірки читає неочікуваний репозиторій. О 14:08 відповідальний за репозиторій підтверджує, що жодне схвалене завдання не пояснює цієї активності. Чи залишив вихідний код середовище, поки невідомо.

Команда реагування зберігає записи аудиту та відповідні докази runner. Уповноважений відповідальний відкликає уражені облікові дані та зупиняє підозрілий шлях виконання. Ці дії відповідають процедурі реагування організації та враховують вплив на сервіс.

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

Перед відновленням доставки перевірте ідентичність, runner, походження артефакту та потрібні межі доступу. Запишіть, що залишається невідомим. Сама успішна збірка не встановлює довіри до середовища доставки.

Поверніть результати до інженерної роботи

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

Записи аудиту та доставки Taiga можуть надати докази у своїй задокументованій сфері. Інтегруйте їх у процес реагування організації. Перевіряйте межу спільної відповідальності замість припущення, що увімкнення Taiga передає відповідальність за SOC або SIRT. Audit log, спільна відповідальність.