Детекцію не декларують – її доводять: що насправді виявляє ваш SOC
Виступ Романа Сологуба, CEO ISSP, на SOC Day 2026 почався із запитання, яке звучить майже наївно: якщо ваша SIEM бачить атаку, чи означає це, що вона про неї повідомить? Подія в журналі, правило з тегом MITRE ATT&CK і підтверджене виявлення дії противника – три різні речі. Між ними стоять джерела, парсери, схеми даних, умови правил, винятки й конфігурація середовища. Саме в цьому проміжку, як показують і дослідження індустрії, і власні вимірювання ISSP, губиться більшість атак. Звідси теза, навколо якої побудована вся доповідь: детекцію не декларують – її доводять. І доводять регулярно.
Противник без шкідливого ПЗ і з секундоміром
Почати варто з того, що саме сьогодні має ловити SOC. За даними CrowdStrike Global Threat Report 2026, 82% виявлень у 2025 році обійшлися без шкідливого ПЗ. Зловмисник заходить під легітимним обліковим записом, користується вбудованими засобами адміністрування і діє руками оператора. Класичних індикаторів у такій атаці просто немає.
Чому так, давно пояснила піраміда болю Девіда Б’янко. Хеш, IP-адресу чи домен противник змінює миттєво й безкоштовно. Змінити інструмент уже складніше. А змінити тактики, техніки й процедури, тобто сам спосіб досягати мети, – найболючіше. Тому моніторити треба поведінку.
І моніторити швидко. Від первинного проникнення до бокового переміщення в середньому минає 29 хвилин, а найшвидший зафіксований випадок тривав 27 секунд. Mandiant у M-Trends 2026 наводить ще промовистішу цифру: медіанний час між отриманням первинного доступу і його передачею іншому угрупованню скоротився до 22 секунд. Індикатори компрометації лишаються корисними, але за такого темпу вони захищають переважно від учорашньої інфраструктури.
Парадокс: правил тисячі, детектів мало
Здавалося б, поведінкову детекцію давно вирішено. У відкритому доступі, без жодних підписок, лежать тисячі готових правил: SigmaHQ, Wazuh, Microsoft Sentinel, Splunk Security Content, Elastic. Бери й розгортай.
А ось що відбувається насправді. За даними CardinalOps, у середній продуктивній SIEM працює 163 правила, і це на 25% менше, ніж у 2022 році. Ще тоді компанія зафіксувала, що клієнти деактивують 75% готових правил від виробника. Правил у світі щороку більшає, а в роботі їх стає менше.
Може, бракує даних? Ні. CardinalOps оцінює, що вже наявні в SIEM джерела дозволили б покрити близько 90% технік ATT&CK. Фактично покрито 22%, а кожне десяте правило працює некоректно. Picus Blue Report дивиться на те саме з боку атакувальника: за чотири роки частка дій, що потрапили в журнали, зросла з 37% до 58%, а частка тих, що дали сповіщення, весь час тримається між 12% і 16%. Організації навчилися бачити більше. Виявляти більше вони не стали.
Два незалежні дослідження вказують в одне місце: розрив не в даних, а в контенті детекції. Picus показує і де саме він ламається: половина причин – збір журналів, чверть – продуктивність правил. У 2026 році продуктивність стала найбільшою окремою категорією проблем контенту детекції – 49%. Правило формально коректне, але шукає по сирому тексту чи розбирає дані під час запуску, і під навантаженням частина подій просто не перевіряється. На рев’ю коду цього не видно. Видно лише тоді, коли простежуєш увесь тракт від дії до сповіщення.
Три діагнози однієї системи
У доповіді ці симптоми зібрано в три «хвороби» системи детекції, і кожен, хто супроводжував SIEM довше року, впізнає принаймні одну.
Перша – ожиріння. Після кожного бюлетеня бібліотека росте: індикатори записують у правила й забувають, а на карті ATT&CK з’являються нові зелені клітинки. Ефекту від них немає. Класичний приклад: експлуатацію віддалених сервісів «покриває» правило на мережеві порти, написане колись під мережевого хробака.
Друга – гіперчутливість. Загальні правила, які нічого не знають про середовище, реагують на звичайну роботу бізнесу. Команда лікує шум винятками і не знає, яку частину атаки виключила разом із ним. За дослідженням SANS × Anvilogic State of Detection Engineering 2026, 66% хибних спрацювань дають саме правила постачальників.
Третя – некроз, і вона найнебезпечніша, бо безсимптомна. Змінилася схема чи синтаксис джерела, або засіб захисту почав блокувати дію раніше, а правило лишається «активним». У консолі все зелене. В одному з публічно розібраних кейсів команда два роки довіряла правилу EDR, яке взагалі не компілювалося.
Detection as Code: фундамент
Індустрія має на ці хвороби зрілу відповідь, успадковану з розробки програмного забезпечення, – Detection as Code. Правило живе як код: версії в Git, зміни через pull request, рев’ю, статичні перевірки, тести, поетапне розгортання і моніторинг здоров’я правил. Це чудовий підхід, і він лишається фундаментом: саме він визначає, як створювати й супроводжувати код детекції.
Фундамент цей недешевий: потрібні кваліфіковані інженери, і не один, а команда. За тим самим дослідженням SANS × Anvilogic, version control мають 62% команд, рев’ю – 58%, CI/CD – 42%, а 72% називають головним бар’єром брак часу.
І є дві речі, яких Detection as Code не каже. Перша: від чого захищатися першочергово, коли технік сотні, а способів виконати кожну ще більше. Друга: чи спрацює правильно побудоване правило на реальну атаку саме у вашому середовищі. На ці запитання відповідають два наступні рівні.
Threat-aware detection engineering: фокус
Threat-aware detection engineering додає до фундаменту пріоритети й фокус. Він дозволяє впоратися з великою масою різноманітних технік, зосередившись на ймовірному. Саме це робить Detection as Code осмисленим: команда пише й супроводжує не все підряд, а те, що потрібне проти її противників.
У 2024–2025 роках ISSP застосовувала цей підхід як сервіс. Фокус змістився з контенту на кіберрозвідку. Для кожного клієнта будується профіль зловмисника з огляду на сектор, регіон і активи. Його техніки накладаються на наявне покриття SIEM, і стає видно, проти кого організація вже захищена, а де прогалини. Із тисяч правил і hunting-запитів у тенант їде лише те, що ці прогалини закриває, разом із runbooks для тріажу й розслідування.
Противники діють послідовно, ланцюгом атаки, і це теж стало частиною підходу. Коли спрацьовує правило, система за CTI-базою кампаній прогнозує суміжні кроки. Ретро-запит шукає пропущене в архіві подій, а список спостереження бере під контроль те, що ймовірно станеться далі. Це гіпотеза для аналітика, а не доказ, але разом із risk-based alerting вона скоротила кількість сповіщень на 72%.
Два роки такої практики дали промовистий результат. Із понад 14 000 одиниць контенту реально ефективними виявилися близько 9%. Натомість дистильоване ядро з 1 300 правил під пріоритетні загрози працює повністю. За оцінкою ISSP, стандартний підхід дає детект приблизно для 16% атак, Detection as Code – для 75%, а threat-aware detection engineering – для 91%. Решта 9% – це сліпі зони обмеженої видимості.
Threat-proven detection engineering: еволюція threat-aware
91% – добра цифра. Але й вона спирається на аналіз, а на кілька запитань аналіз відповісти не може. Чи спрацює правило саме на ту поведінку, під яку його писали? Чи не змінив тюнінг від хибних спрацювань цільову логіку? Чи надійде телеметрія вчасно і що зміниться після оновлення агента чи парсера?
З’ясувати це можна лише одним способом: виконати зловмисну процедуру й подивитися.
Так з’являється наступний крок еволюції – threat-proven detection engineering. Threat-aware каже, на чому зосередитися. Threat-proven дозволяє впевнитися, що код детекції справді працює. І не в лабораторних умовах, а у власному середовищі: з його політиками домену, контролями, системами безпеки й конфігурацією.
Ключовий елемент підходу – генерація і валідація правил через автоматизований purple teaming. Процедура виконується; перевіряється, чи надійшла телеметрія і чи спрацювала детекція з потрібними параметрами; а саме правило створюється з реального виконання. Раніше такий рівень перевірки давав лише дорогий purple teaming, здебільшого в лабораторії вендора. Тепер він виконується в інфраструктурі клієнта, регулярно, як сервіс.
Ці три рівні не замінюють один одного, а надбудовуються. Detection as Code відповідає, як писати й супроводжувати правила. Threat-aware – які правила потрібні першими. Threat-proven – чи вони справді працюють там, де мають працювати.
Одна зелена клітинка, три шляхи повз неї
Тут виникає спокуса спростити. За даними Red Canary, топ-30 технік трапляються у трьох чвертях атак. Чому б не написати правила на ці тридцять і не закрити питання?
Бо техніка – це не одна дія, а від кількох до кількох десятків процедур. Наприклад, закріплення через планувальник завдань можна виконати утилітою schtasks.exe, через PowerShell або напряму через API. Правило на командний рядок schtasks.exe бачить лише один шлях із трьох. А на карті ATT&CK у багатьох ця клітинка вже зелена.
Тож правильне запитання – не «чи є правило на техніку», а «що має змінити противник, щоб його обійти». Відповідь дає модель Summiting the Pyramid від MITRE CTID. Вона розгортає вершину піраміди болю на п’ять рівнів стійкості: від імені файлу, яке змінюється миттєво, до конкретної поведінки, без якої виконання техніки неможливе. ISSP оцінює за цією шкалою кожне правило і для кожної техніки визначає досяжну стелю – найвищий рівень, який дозволяє телеметрія клієнта.
Бібліотека, яка вміє атакувати
На цій основі бібліотека правил ISSP перестала бути статичною. Тепер це дві колекції, пов’язані механізмом запуску.
Колекція blue описує 701 техніку: логіку детекції, потрібну телеметрію і стелю стійкості. Для 342 технік можливе правило рівня L3 і вище. Колекція red – це майже 2 000 дій і 307 ланцюжків атак, зібраних із CTI, звітів про реальні інциденти та бібліотек емуляції на кшталт популярних Atomic Red Team, MITRE Caldera і MITRE Attack Flow. Атаки не вигадуються, а їхні елементи повторюються. Механізм запуску виконує ці дії в середовищі клієнта й створює правило з тієї телеметрії, яка там справді є.
Що це дає на практиці, показав лабораторний приклад із системою Wazuh та її 4 511 правилами на борту. Із 515 підготовлених технік і субтехнік виконали 285. Стандартний контент виявив 52 з них, тобто 18%. Ще 212, або 74%, дали телеметрію, але жодне правило не спрацювало коректно. І 21 техніка лишилася сліпою зоною.
Картина знайома: та сама, що й у дослідженнях галузі. Більшість активності видно, а виявляється мало. Далі починається найцікавіше. В одному з прогонів на тестовому стенді стандартний контент не виявив жодного з чотирьох виконаних кроків ланцюжка. Після генерації нових правил виявлено три з чотирьох, і без жодного хибного спрацювання.
Показово й інше. Із десяти кроків того ланцюжка виконалися лише чотири: шість заблокували наявні засоби захисту. Результат залежить не тільки від правил, а й від політик домену, контролів і конфігурації. Тому стенд показує лише механізм, а справжню відповідь дає перевірка у власному середовищі.
Детекція в SOC: процес, а не проєкт
У цих цифр є термін придатності: з появою нових процедур будь-яке покриття знижується. Тому threat-proven detection engineering – не разовий аудит, а кілька циклів, що обертаються постійно. Цикл CTI оновлює профіль противника. Цикл телеметрії перевіряє, чи бачать джерела відтворені техніки. Цикл детекції виправляє й валідує правила. Detection as Code проводить кожну зміну через рев’ю і тести. Infrastructure hardening закриває ті прогалини, де допомагає не правило, а налаштування інфраструктури. Спільна точка всіх циклів – дистиляція TTP: вона визначає, що саме відтворювати, що вимірювати й під що писати контент.
Такий процес складний і ресурсоємний. Він потребує системної, data- і process-інженерії, спільної роботи blue, red і DevOps-команд, а також використання Git, XDR, SIEM, CTI та BAS. Але інакше SOC не може знати, що він справді виявляє. Покриття має вимірюватися виконанням, а не декларуватися мапінгом.
Головна думка доповіді вміщується в одне речення: правило детекції – лише гіпотеза виявлення, а відтворення атаки – її перевірка.
Повний виступ Романа Сологуба на SOC Day 2026 дивіться у відеозаписі: https://youtu.be/Uc8vaCdMBfU
Коментарі