Стежити Кожна команда з виявлення знає цей момент. Правило написане або завантажене, перевірене, перекладене на мову запитів SIEM і розгорнуте. Статус говорить, що увімкнено, кількість правил зростає, і звіт про покриття трохи зеленішає.
Жодне з цього не говорить вам, чи правило дійсно виявить атаку, під яку було написане. Правило може бути добре написане, але все одно нічого не знаходити, тому що його логіка, дані або переклад тихо не узгоджуються з реальністю. І оскільки правило, яке ніколи не спрацьовує, виглядає так само, як правило без чого ловити, проблема може залишатися прихованою довго.
Ця стаття пояснює, що відрізняє робоче правило від неробочого, де зазвичай правила йдуть неправильно і що ви можете зробити за допомогою SOC Prime, щоб довести, що правило працює до його доставки та забезпечити його роботу пізніше.
Що означає “робочий” насправді
Робоче правило виявлення виконує три речі. Воно висловлює правильну логіку для цільової поведінки. Воно працює на даних, які дійсно містять цю поведінку. І воно написане правильно для платформи, на якій працює. Якщо хоч одна з цих частин не спрацьовує, правило є невірним, навіть якщо воно ввімкнене і не викликає помилок.
Це формулювання допомагає, тому що кожна невдача має різну причину і різне вирішення:
- Проблеми з логікою живуть у самому правилі. Воно занадто вузьке, щоб ловити варіації поведінки, або настільки широке, що відповідає нормальній активності.
- Проблеми з даними живуть у середовищі. Події, які потрібно правилу, не записуються, не збираються або не містять полів, на які залежить правило.
- Проблеми з перекладом живуть у переході між мовами. Значення правила змінюється, коли воно перетворено у синтаксис запиту платформи.
Більшість команд ретельно перевіряють перше, коли пишуть правило. Друге і третє — де правила зазвичай ламаються без будь-якого помітування.
Де робочі правила йдуть неправильно
Логіка, яка не відповідає поведінці. Правило, яке базується тільки на імені файлу інструменту, легко обійти, перейменувавши файл. Правило, яке базується на загальному шаблоні командного рядка без фільтрації, може відповідати адміністраторам цілий день. Жодна помилка не є помітною при розгортанні. Перше виявляється, коли хтось через нього проходить, друге — як шум від сповіщень.
Дані, яких немає. Правило створення процесу, яке залежить від аргументів командного рядка, є даремним, якщо журналювання командного рядка не ввімкнено, тому що подія надходить без поля. Те ж саме стосується журналуе джерела, яке ніколи не було підключено, або агента, який перестав передавати. Правило працює за розкладом, нічого не знаходить і виглядає здоровим.
Поля, які мають різне значення у різних місцях. Одна й та ж концепція може мати різні імена у різних продуктах, і навіть моделі даних від різних постачальників є окремими контрактами. Splunk CIM та Microsoft Sentinel ASIM є гарним прикладом: поле, яке існує в одному, може не існувати в іншому. Переклад символ за символом створює правило, яке звертається до полів, які призначення ніколи не заповнює.
Переклад, який змінює значення. Автоматичні перекладачі добре справляються з простою логікою вибору, але кореляційні правила та пропрієтарні функції зазвичай потребують людського перегляду. Платформи також різняться у тому, як вони ставляться до деталей, як чутливість до регістру, підстановки та регулярні вирази. Правило може бути перекладене “успішно” і все ще поводитись по-різному від оригіналу.
Обмеження платформи, які списують хороші правила. SIEM накладає обмеження на те, скільки правил може працювати. Команди часто вимикають працюючі правила, щоб зробити місце для нових, що скорочує покриття, без жодного рішення про це.
Чому це має значення
Кожна з цих проблем залишає кількість правил і панель приладів незмінними. Цифри покриття, які рахують розгорнуті правила, через це перебільшують захист, і цей розрив зазвичай виникає під час інциденту, коли хтось виявляє, що правило, котре мало б спрацювати, ніколи не могло.
Є ще одна вартість: тихе правило є неоднозначним. Якщо нічого не спрацьовує, чи чисте середовище, чи відсутня теле метрика, чи неправильно логіка? Розібратися в цьому після факту означає перевірку логіки, даних і перекладу один за одним. Набагато дешевше зібрати докази заздалегідь і тримати їх актуальними.
Як SOC Prime допомагає довести, що правило працює
Перевірка виявлень насправді є ланцюгом питань: що потрібно цьому правилу, чи надає його моє середовище, чи поводить себе правило, як очікувалося, на моїх даних, і якщо ні, що варто змінити? SOC Prime підтримує кожний крок.
Зрозумійте вимоги до виявлень
Перевірка починається до будь-якого тестування. SOC Prime надає контекстну інформацію про вміст виявлення, включаючи цільову поведінку, телеметричні вимоги, відповідність MITRE ATT&CK, потенційні хибно-позитивні, та інші метадані. Це дає інженерам з виявлення точку відліку, щоб вирішити чи є виявлення актуальним для їх середовища та які умови повинні бути виконані до його тестування. Наприклад, правило, яке потребує журналювання командного рядка, скаже вам про це заздалегідь, замість того, щоб залишити вас виявити це пізніше.
Оцінка доступної телеметрії
Після того, як ви знаєте, що потрібно правилу, наступне питання – чи маєте ви його. Prime Hunt може допомогти командам оцінити відношення між їхніми доступними даними і потенційним покриттям виявлення. Data Audit аналізує доступні журнальні дані та співвідносить їх з MITRE ATT&CK, щоб визначити потенційні прогалини у видимості. Це допомагає визначити, чи є брак покриття виявлення з причини відсутності телеметрії, а не відсутності вмісту виявлення, які є двома дуже різними проблемами з двома дуже різними виправленнями.
Тестування виявлень за допомогою організаційних даних
Prime Hunt також може запускати сканування виявлень проти даних із підключених середовищ. Тестування виявлень на реальних даних дає вам докази того, як вміст себе поводить у вашому середовищі, замість того, щоб покладатися тільки на теоретичну перевірку. Результати сканування допомагають виявити виявлення, які продукують відповідні збіги, та виділяють ті, які потребують додаткового розслідування або налаштування.
Розслідування та поліпшення логіки виявлення
Коли виявленню потрібна модифікація, SOC Prime надає можливості з інженерії виявлень через Prime Core і Prime Architect. Вміст виявлень може бути переглянутий, налаштований, перекладений і оптимізований для цільового середовища. Це адресує різниці у схемах, відповідності полів, мовах запитів, та специфічних вимогах для середовища без того, щоб кожне проблемне виявлення вважати новим завданням розробки.
На практиці це означає:
- Переклад для платформи, на якій ви працюєте. Всі правила Sigma на платформі вже перекладені на всі підтримувані мови та формати SIEM, тому ви можете взяти запит для вашої стеки і негайно розгорнути його. Для чого-небудь користувацького або для ваших власних правил Sigma, використовуйте робочий простір перекладу в Prime Architect, щоб перетворити їх на рідну мову запитів вашого SIEM, EDR, XDR або озера даних. Sigma залишається джерелом, тому зміна, зроблена один раз, може бути знову перекладена замість того, щоб редагувати вручну на кожній платформі.
- Картування таблиць, полів і значень до вашої схеми. Користувацьке картування полів дозволяє вам визначати профілі, що відображають ваші нестандартні таблиці, поля та значення до стандартних. Створіть один профіль, а потім застосовуйте його кожного разу, коли розгортаєте правило або надсилаєте запит.
- Додавати фільтри, що відповідають вашому середовищу. Фільтри додають умови до логіки виявлення до розгортання, щоб включати або виключати певних користувачів, хостів або інші набори елементів. Вони запобігають тому, щоб відома-добра активність перетворила гарне правило на шумне, без переписування самого правила.
- Зберігати параметри розгортання як пресети. Пресети зберігають такі параметри, як період запиту, серйозність і статус правила, щоб розгортання залишалося постійним.
- Перевірка, оптимізація та налаштування. Робочий простір перекладу також перевіряє та оптимізує вміст виявлень. Це не замінює огляд: перевіряйте кожне поле по відношенню до схеми призначення та ретельно дивіться на все позначене, особливо кореляційну логіку та специфічні функції платформи. Коли зміна йде далі, ніж картування та фільтри, редагуйте код безпосередньо, перекладати його знову і зберігайте в своїй користувацькій репозиторії як оновлення або нове правило.
- Досліджуйте та корегуйте через робочий простір з підтримкою AI. Використовуйте його для дослідження цільової поведінки правила і пройдіть через зміну його логіки. Інженери залишаються контролювати та переглядати кожну зміну перед тим, як вона доставляється.
Визначення прогалин у покритті
Перевірка виявлень повинна також відповідати на питання, що не виявлено. Data Audit у Prime Hunt надає аналіз покриття на основі як доступної теле метрики, так і вмісту виявлення. Це допомагає командам відрізнити прогалини, викликані недостатньою видимістю, від прогалин, викликаних відсутністю або невідповідними правилами виявлення. Це розрізнення інформує наступну інженерну дію: зібрати більше даних, налаштувати існуюче виявлення, або ідентифікувати та розробити додатковий вміст виявлення.
Продовжувати перевірку з часом
Цифрова ефективність змінюється, як середовища та вміст виявлення розвиваються. Періодична перевірка з Prime Hunt дає командам змогу переоцінити виявлення на основі актуальних даних, а не покладатися на початковий результат перевірки нескінченно. Це особливо важливо в середовищах, де конфігурації журналювання, схеми даних, інфраструктура або вміст виявлення змінюються часто.
Доказ замість припущення
Розгорнуте правило — це заява. Правило, перевірене на реальних даних, — це доказ. Різницю легко пропустити, тому що обидва виглядають однаково у списку правил і обидва залишаються тихими, поки атака не надійде.
SOC Prime допомагає командам закрити цей розрив. Все починається з чітких вимог до виявлення та чесного погляду на доступну телеметрию, тестуючи виявлення на ваших власних даних та надаючи вам інструменти для виправлення того, що не підходить. Аналіз покриття потім показує, чи залишаються прогалини, що вимагають більше даних, кращого налаштування, або нового вмісту, та періодична перевірка дозволяє відповідь залишатися актуальною, як ваше середовище змінюється. Почніть з правил, які мають найбільше значення, і дізнайтеся, які з них дійсно спрацюють.
