Стежити Операції з виявлення для кількох орендарів — це практика управління однією джерелом незалежної від постачальника логіки виявлення, перекладеної та налаштованої для кожного орендаря, що забезпечує узгодженість, налаштованість і можливість звітності для обсягу клієнтів, які використовують різні платформи SIEM з одного керованого джерела.
MSSP, який виконує виявлення для десятків орендарів, стикається з одним структурним питанням: кожен клієнт отримує власну версію кожного правила виявлення, чи одне кероване джерело перекладається та налаштовується для кожного орендаря? Відповідь визначає операційні витрати, точність звітності про покриття, а також чи поширюються зміни у спільній логіці відразу, чи залишаються в черзі ручних виправлень.
Ця сторінка охоплює шар з вмістом виявлення в цій моделі: одне джерело незалежної від постачальника логіки виявлення, централізовано керованої, перекладеної та налаштованої для кожного орендаря. Hunters працює на аналітичному та операційному рівні, платформі для SOC і MSSP, альтернативі SIEM Соц. пакету ContraForce, орієнтована на стек безпеки Microsoft (Microsoft Sentinel та Defender XDR). Джерело з вмістом виявлення, описане тут, знаходиться на попередньому етапі, забезпечуючи незалежну від постачальника логіку виявлення, яку споживають шари виконання, дослідження та звітності.
Обсяг: платформи SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike). EDR як цільове розгортання не входить в обсяг, доки не буде перевірено підтримку для кожної платформи.
MSSP є також регульованою організацією сама по собі. Виконавчий регламент Комісії (ЄС) 2024/2690, що діє з 7 листопада 2024 року, встановлює вимоги до моніторингу та ведення журналів (Додаток розділ 3.2) для постачальників керованих послуг безпеки згідно з NIS2. Власне зобов’язання MSSP щодо доказів, а не лише його орендарів, визначає, як управляється та звітується про вміст виявлення.
Як SOC для кількох орендарів може зберігати логіку виявлення узгодженою в різних середовищах клієнтів, що працюють на різних платформах SIEM?
Написати логіку виявлення один раз у форматі, незалежному від постачальника (Sigma). Перекласти її для SIEM кожного орендаря. Управляти джерелом централізовано.
Спільний основний артефакт
Основою є один артефакт логіки виявлення. Логічна умова оцінюється проти загальної, нормалізованої схеми, а не проти будь-яких сирих полів журналу орендаря. Це робить те саме правило портативним на Splunk, Microsoft Sentinel, Google SecOps, Elastic і CrowdStrike без переписування логіки виявлення.
Нормалізація відображає поля, специфічні для джерела, на цю загальну схему, зберігаючи їх семантику. Правило, написане проти нормалізованого поля auth.result, означає те ж саме, незалежно від того, який постачальник ідентичності створив подію: auth.result розв’язується до {успіх, помилка, виклик} за іменованим семантичним контрактом, а не за тим, як клієнт називає поле.
Накладання для кожного орендаря
Кожен орендар отримує накладання. Накладання переносить відображення полів, яке перекладає сирі поля джерела орендаря в загальну нормалізовану схему, а також параметри налаштування (пороги, часові вікна, виключення шуму), пристосовані до середовища орендаря. Основа і накладання версіонуються окремо.
Оновлення логіки бази поширюється на кожного орендаря, накладання якого відображає потрібні поля. Зміна налаштування вкладеності торкається лише цього орендаря.
Спільне проти специфічного для орендаря
Що залишається спільним: умова логіки виявлення, визначення семантичних контрактів, на які спирається логіка, мітка техніки MITRE ATT&CK , а також історія версій та змін.
Що є специфічним для орендаря: відображення поля сирого до нормалізованого, статус перевірки контракту під час виконання (успіх чи провал оцінюються за фактичним потоком подій орендаря, а не за статичною властивістю правила), переклад платформи-цілі та параметри налаштування.
Як ви керуєте контентом виявлення в десятках клієнтських середовищ без відгалуження для кожного клієнта?
Один керований артефакт на кожне виявлення, а не відгалуження для кожного клієнта.
Відгалуження файлу правил для кожного клієнта означає підтримку незалежних копій того, що має бути одним керованим артефактом. Виправлення логіки або нове оновлення техніки ухилення повинні застосовуватися вручну до кожного відгалуження. Відгалуження розходяться, і єдина історія змін зникає.
Коли аудитор або клієнт питає, хто змінив це правило, коли і чому, відповідь має переглянути однією хронологією. Різні копії, які можуть чи не можуть відображати те саме виправлення, залишають це питання без відповіді. Це невдача в управлінні та контролі змін, і вона безпосередньо підриває слід доказів, на який спираються аудитори.
Модель з основою та накладанням тримає один артефакт під керуванням:
| Шар | Містить | Обсяг |
|---|---|---|
| Основа (спільна) | Умова логіки виявлення, визначення семантичного/часового/кореляційного контракту, мітка техніки MITRE ATT&CK, версія та історія змін | Всі орендарі |
| Накладання (для кожного орендаря) | Відображення полів сирого до нормалізованого, переклад платформи-ціли, пороги, часові вікна, виключення шуму | Один орендар |
Одна зміна базової логіки розповсюджується за рахунок конструкції. Тільки відображення і налаштування залишаються локальними. Це дисципліна Виявлення як код , застосована до операцій з декількома орендарями: зміни правил версіонуються, переглядаються і відстежуються як артефакти коду. Автоматизація розгортання переносить оновлену базу до кожного орендаря, накладання якого її підтримує.
Версіонування контракту забезпечує базу. Зміни необхідно версіонувати, а для критичних змін вимагається новий ідентифікатор контракту, щоб кожен орендар отримав шляхи оновлення, які можна узгодити, а не беззвучне порушення.
SOC Prime працює з MDR, щоб спроектувати операції інженерії виявлення починаючи з виявлення SIEM до зниження обсягу SIEM з Prime Detect.
Зв’язатися з відділом продажів
Як налаштувати кожного клієнта, не порушуючи спільне правило?
Налаштування в накладанні. Основне правило залишається незмінним.
Накладання переносить конфігурацію, специфічну для орендаря, у двох частинах.
Відображення полів. Джерела продуктів кожного орендаря по-різному називають той же факт у сирому журналі, тому накладання перекладає ці сирі поля в загальну нормалізовану схему. Відображення повинно незалежно відповідати тому ж семантичному контракту, який мають інші орендарі.
Конкретна невдача показує, чому це важливо. Накладання орендаря відображає результат «MFA pending» свого постачальника ідентичностей до нормалізованого значення «failure», замість «challenge». Спільна логіка виявлення обходу MFA, яка шукає успішний вхід без попередньої події виклику, ніколи не бачить значення «challenge» для цього орендаря. Кожний успішний вхід відмічається як обхід: масова помилкова позитивна для цього одного орендаря, тоді як те саме правило є правильним для кожного іншого орендаря, чиє накладання правильно відображає enum.
Правило ніколи не змінювалось. Невдача повністю в накладанні, помилка накладання, яка маскується як помилка правила.
Параметри налаштування. Часові толерантності на кореляцію для зв’язування пов’язаних подій, вікна часу очікування сеансу та періоду доброзичливості для аутентифікаційних послідовностей і виключення шуму. Замалий набір толеранцій пропускає реальні кореляції. Занадто вільний набір об’єднує непов’язані події. Ці вікна можуть потребувати налаштувань для конкретного орендаря з урахуванням його синхронізації годинника та характеристик затримки.
Умова логіки виявлення базового правила, оцінена проти нормалізованих полів, ніколи не змінюється для одного орендаря. Статус перевірки контракту має оцінюватися для кожного орендаря під час виконання, а не виходячи з правила чи типу джерела.
Як я можу звітувати про покриття виявлення MITRE ATT&CK перед кожним клієнтом, коли кожен клієнт надсилає нам різні джерела журналів?
Вичислити покриття на орендаря відповідно до власного пріоритетного набору технік ATT&CK кожного орендаря. Ніколи не звітувати однією бібліотечною цифрою для всіх орендарів. Повний метод вимірювання описано на супроводжуючій сторінці про вимірювання покриття виявлення MITRE ATT&CK.
Шаблон покриття:
Покриття (орендаря) = техніки, де [телеметрія дійсна і правило розгорнуте і правило доведено активним] поділене на кількість пріоритетних технік цього орендаря.
Коли техніка вважається покритою
Техніка вважається покритою, лише коли все це тримається разом:
- Телеметрія дійсна для цього орендаря. Потрібне джерело даних зібрано, активно завантажується, відповідає семантичним, часовим і кореляційним контрактам і задовольняє якісні SLO (рівень відсутності, свіжість). Все це оцінюється проти фактичного потоку подій цього орендаря, а не за умовчанням для типу джерела.
- Правило розгорнуте і відображене на техніку. Факт інвентаризації як Виявлення як код: яке правило існує, яку мітку MITRE ATT&CK воно має, його версія.
- Правило має доказ активності. Базування частоти спрацьовування, канаркові події або перевірка атомних тестів, що показують, що правило генерує оповіщення на реальну чи емульовану активність. Мітка техніки без запису спрацьовування — це ярлик, а не доказ.
Знаменник — це власний названий, пріоритетний підмножина технік ATT&CKцього орендаря. Ніколи не повна матриця ATT&CK. Ніколи не розмір бібліотеки правил постачальника.
Звітування про стани розриву
Звітувати про стани розриву окремо, ніколи не як одне об’єднане число:
| Статус | Значення | Виправлення |
|---|---|---|
| VALID | Усі перехоплювачі пройдені, правило розгорнуте, докази активності у файлі | Покрито на дату звіту |
| INVALID | Не зібрано потрібне джерело або не завантажується | Увімкнення джерела або ремонт завантаження |
| DEGRADED | Джерело зібрано, але контракт або якісні SLO не виконуються | Виправлення відображення, парсера або схеми |
| Розрив вмісту | Телеметрія дійсна, правило не відображено на техніку | Розробка вмісту |
Не включайте статуси INVALID і DEGRADED в одне число «розриву». Різні режими відмов вимагають різного усунення і призводять до різних розмов з клієнтами.
Звітувати з датою. Покриття є точковим у часі.
Що робить повторне використання вмісту з маржею та навантаженням на навчання аналітиків?
Повторне використання вмісту для кількох орендарів перетворює вартість інженерії виявлення для кожного клієнта в спільну, амортизовану вартість. Коли основна логіка виявлення створюється один раз і перекладається для кожного орендаря, вартість інженерії розподіляється по всьому об’єму клієнтів.
Маржа. Кожен орендар, що використовує спільну базу, уникає додаткових годин інженерії виявлення. Покращення маржі є структурним. Партнерська програма SOC Prime MDR оцінює збереження в 4000 годин на рік на дослідження загроз та кодування вмісту виявлення. Навантаження на навчання.
Одна методологія Виявлення як код. Одна нормалізована схема. Один набір семантики контракту. Аналітики інтегруються в спільну модель, а не в бібліотеки правил для кожного клієнта, що мають розбіжності в назвах, структурі та намірах. Коли аналітик переходить з черги одного орендаря в іншу, логіка виявлення, схема та контракти вже знайомі. One Detection-as-Code methodology. One normalized schema. One set of contract semantics. Analysts onboard against the shared model rather than against per-customer rule libraries with divergent naming, structure, and intent. When an analyst moves from one tenant’s queue to another, the detection logic, the schema, and the contracts are already familiar.
Чесне заперечення. Спільний вміст виявлення не стерває диференціацію MSSP. Диференціація переходить до налаштування, реагування та звітності. Специфічні для орендаря накладання, планувальники реагування та звіти для клієнтів — ось де показується цінність MSSP. Потенційний клієнт, який чує “спільний вміст” і думає “товар” повинен побачити, де саме знаходиться індивідуальна робота.
Регуляторний рушій. Власне зобов’язання MSSP щодо доказів згідно з NIS2, через Виконавчий регламент Комісії (ЄС) 2024/2690, вимагає моніторингу та ведення журналів доказів від власне MSSP, а не лише від орендарів. Спільна модель амортизує виробництво цих доказів.
Де це не діє
Модель з основою і накладанням передбачає, що базове правило написано проти нормалізованої схеми, яку може задовольнити кожен продукт джерела орендаря. Модель ламається за наступних умов.
- Продукти джерела, які не видають потрібні дані. Різні продукти джерела або різні версії одного продукту можуть взагалі не видавати потрібний компонент даних. Жодне накладання не виправляє структурно відсутнє поле. Це є INVALID розрив, який виправляється включенням джерела або оновленням.
- Доступність джерела. Орендар не підключив потрібне джерело журналу, або його завантаження ставьться. Правило, відображення та налаштування можуть бути правильними, але стратегії, що їх впливають, залишаться непокритими, доки джерело не почне знову постачати дані.
- Невідповідність кореляційної толерантності. Спільна перехідна часові толеранції можуть пропустити дійсні кореляції для орендаря із незвичайною синхронізацією годинника або затримкою. Потрібно, не є необов’язковим, налаштування кореляційних вікон на орендаря.
- Унікальні загрозові моделі або обмеження зберігання даних. Орендар із дійсно унікальним профілем загрози може потребувати кастомної логіки виявлення, якої не містить спільна база. Обмеження, яке забороняє ділитися артефактами логіки виявлення через організаційні кордони, має такий самий ефект.
- Ізоляція орендарів не підлягає переговорам. Модель ділиться логікою виявлення між орендарями (текст правил, визначення контрактів). Вона ніколи не ділиться даними орендарів, кешем збагачення, станом оповіщення або результатами перевірки через кордони орендарів. Будь-яка архітектура, де пошук збагачення одного орендаря або черга оповіщення протікають до іншого, на заздалегідь задуманий режим є пріоритетно першоплановою подією. Спільна логіка і спільні дані – це різні вимоги.
Контрольний список моделі операцій з декількома орендарями
Автор і управляйте основним правилом
- Логіка виявлення, створена у форматі, незалежному від постачальника (Sigma), по відношенню до нормалізованої, визначеної контрактом схеми
- Базове правило відокремлене від накладання орендаря: логіка виявлення, визначення контракту, мітка техніки MITRE ATT&CK та історія версій залишаються спільними
- Накладання для кожного орендаря переносить відображення поля, переклад платформи та лише параметри налаштування, версіоновані окремо від бази
- Зміни базового правила поширюються до кожного орендаря за рахунок конструкції
- Історія змін простежується до однієї керованої часової лінії для кожного базового правила, з відстеженням змін накладання для кожного орендаря
- Версіонування контракту здійснюється: критичні зміни супроводжуються новим ідентифікатором контракту
Перевірте відображення та переклад платформи
- Відображення поля задовольняють той самий семантичний контракт для кожного орендаря, з перевіркою контракту під час виконання проти фактичного потоку подій кожного орендаря
- Переклад платформи перевіряється для цільової SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic Security, CrowdStrike)
Вичислити покриття для кожного орендаря
- Покриття обчислюється для кожного орендаря відповідно до власного пріоритетного набору технік ATT&CK цього орендаря
- Чисельник покриття вимагає, щоб телеметрія була дійсною, правило розгорнуте і правило доведено активним, все це є разом
- Стани розриву розрізняються: VALID, INVALID (відсутнє джерело), DEGRADED (джерело наявне, перевірка не вдалася), і Розрив у вмісті (телеметрія дійсна, правило не відображено)
Налаштуйте, ізолюйте та звітуйте
- Часові толерантності кореляцій перевіряються для кожного орендаря для відповідності синхронізації годинника і затримки
- Налаштування змінюється в накладанні, ніколи не шляхом відгалуження базового правила
- Ізоляція орендарів забезпечується: жодних спільних даних, кешів збагачення, стану оповіщення або результатів перевірок через кордони орендарів
- Покриття звітується з датою, для кожного орендаря, ніколи як одне бібліотечне число по всьому обсягу
- Власне регуляторне зобов’язання MSSP щодо доказів (Виконавчий регламент NIS2 2024/2690) вирішується поруч з зобов’язаннями орендарів
- Навчання аналітиків вирівнюється з спільною методологією Виявлення як код, нормалізованою схемою та семантикою контракту
FAQ
Як SOC для кількох орендарів може зберігати логіку виявлення узгодженою в різних середовищах клієнтів, що працюють на різних платформах SIEM?
Написати логіку виявлення один раз в Sigma, у форматі без врахування постачальника, та перекласти її для SIEM кожного орендаря. Модель з основою та накладанням зберігає спільну логіку виявлення та мітку техніки MITRE ATT&CK в одному регульованому артефакті, в той час як накладання кожного орендаря переносить відображення полів, переклад платформи та параметри налаштування для цього середовища. Це поширюється на платформи SIEM (Splunk, Microsoft Sentinel, Google SecOps, Elastic, CrowdStrike). EDR як цільове розгортання не входить до обсягу, доки не буде перевірено підтримку для кожної платформи.
Як я можу звітувати про покриття виявлення MITRE ATT&CK перед кожним клієнтом, коли кожен клієнт надсилає нам різні джерела журналів?
Вичислити покриття на орендаря відповідно до власного пріоритетного набору технік ATT&CK кожного орендаря, ніколи не як одне бібліотечне число по всьому обсягу. Техніка вважається покритою, лише коли телеметрія є дійсною для цього орендаря, правило розгорнуто та відображено на техніку, а правило має доказ активності. Повідомляйте про чотири окремі стани розриву: VALID, INVALID (відсутнє джерело), DEGRADED (зібрано джерело, але перевірка не вдалася), та Розрив вмісту (телеметрія дійсна, правило не відображено). Кожен звіт про покриття містить дату.
Чи стирає спільний вміст виявлення диференціацію MSSP?
Спільний вміст виявлення змінює місце диференціації. Власна індивідуальна цінність MSSP доходить до налаштування, відповідних інструкцій і звітності для клієнтів. Накладання для кожного орендаря, плани відповідей і аналіз покриття для окремих орендарів – ось де проявляється експертиза MSSP для кожного клієнта.
Зв’язатися з відділом продажів
