В очереди SIEM - 2 847 алертов за выходные. Из них ~2 300 - false positives от трёх правил корреляции, которые стабильно срабатывают на каждом плановом бэкапе, обновлении антивирусных баз и scheduled task от IT-отдела. Оставшийся бэклог разгребают три дня. Среди закрытых «как FP» алертов - lateral movement через скомпрометированный сервисный аккаунт. Его нашли постфактум. Снижение false positives в SOC - не абстрактная метрика для красивого дашборда. Это вопрос, успеет ли аналитик добраться до настоящего инцидента до того, как данные утекут.
Почему статические правила корреляции проигрывают шуму
Классическая схема детектирования строится на правилах корреляции: если событие X произошло N раз за T минут - создать алерт. Проблема не в логике, а в том, что порог N и окно T одинаковы для всей инфраструктуры. Правило «более 5 неудачных логинов за 10 минут» срабатывает и на brute-force, и на сотрудника после отпуска, и на сервисный аккаунт при плановой ротации паролей. Три разных ситуации - один алерт.По данным Prophet Security «State of AI in Security Operations 2025» (цитируется в обзоре Authentic8), около 40% алертов в среднестатистическом SOC вообще не расследуются. При этом порядка 60% команд столкнулись с инцидентами, ставшими прямым следствием проигнорированных алертов. Отчёт Tines рисует ту же картину: 71% SOC-аналитиков испытывают выгорание, 69% команд работают в условиях нехватки кадров (конкретные цифры зависят от методологии и выборки).
Ситуация становится хуже, когда злоумышленник целенаправленно эксплуатирует шум. Техника Disable or Modify Tools: Modify or Spoof Tool UI (T1685.003) - генерация ложных алертов для перегрузки SOC и маскировки реальной активности. Indicator Removal (T1070) и Disable or Modify Tools (T1685) дополняют схему: атакующий зачищает следы и отключает мониторинг, пока аналитики разбирают очередной шквал ложных срабатываний. По сути, SOC превращается в прикрытие для атаки.
Антипаттерн, который я встречаю регулярно: порог аномальности по z-score и порог 3o (sigma) для DNS-трафика. В теории три стандартных отклонения ловят аномалии. На практике DNS-трафик имеет тяжёлые хвосты распределения - обновления CDN, синхронизация облачных сервисов, bulk-резолвинг при деплое контейнеров генерируют всплески, которые модель без контекста маркирует как аномалии. Десятки FP ежедневно от одного правила.
Связка простая: больше шума в очереди -> меньше расследованных алертов -> длиннее dwell time -> дороже инцидент. В российском контексте добавляются оборотные штрафы за утечку персональных данных: SOC, который «утонул» в false positive алертах безопасности и пропустил эксфильтрацию ПДн, создаёт организации не только технический, но и юридический риск.
Машинное обучение в SOC: архитектура пайплайна от телеметрии до скоринга
ML-модель в SOC - не замена правилам корреляции, а дополнительный слой, который работает после первичной фильтрации. Архитектура, показавшая результат в реальных проектах, выстроена как трёхстадийный пайплайн:- Pre-filter - статические правила и whitelist отсекают заведомо легитимную активность: scheduled tasks из утверждённого списка, сервисные аккаунты с известным паттерном, IP-адреса из доверенных подсетей
- ML scoring - модель обрабатывает оставшийся поток и присваивает каждому алерту risk score на основе поведенческих признаков
- Contextual enrichment - алерт обогащается данными об активе (критичность, владелец, роль пользователя в AD), историей аномалий и результатами проверки IOC в TI-фидах
Три модели anomaly detection для SOC
Выбор модели зависит от типа данных и зрелости SOC. Ниже - сравнение подходов с ограничениями, которые на практике определяют, взлетит решение или нет:| Модель | Тип обучения | Где применять | Ограничения |
|---|---|---|---|
| Isolation Forest | Unsupervised | Первичный скоринг по числовым признакам: объём трафика, частота запросов, количество уникальных destination | Не учитывает последовательность событий; чувствителен к параметру contamination; требует ручной калибровки порогов |
| UEBA (поведенческая аналитика) | Semi-supervised | Профилирование пользователей и entity: отклонение от персонального baseline | 2-4 недели «прогрева» для baseline; ложные срабатывания при смене роли сотрудника или переводе в другой отдел |
| Supervised classifier (Random Forest, XGBoost) | Supervised | Классификация алертов TP/FP на основе исторических маркировок аналитиков | Требует размеченный датасет с достаточным количеством TP-примеров; деградирует при concept drift |
Каждая модель хороша в своей нише, но ни одна не работает «из коробки» без боли. Isolation Forest - быстрый старт, но без контекста последовательности событий он слеп к цепочкам атак. UEBA - мощная штука, но первый месяц после запуска вы будете разгребать FP от сотрудников, которые просто вышли из отпуска. Supervised-классификатор даёт лучшую точность, но попробуйте собрать достаточно TP-примеров в SOC, где 95% алертов - шум.
Подход DeepCASE (van Ede et al., ACM CCS 2022) использует контекст последовательности событий и cost-sensitive функцию потерь - минимизирует пропуск реальных угроз (false negatives) при агрессивной фильтрации FP.
Базовый скоринг через Isolation Forest на Python - для демонстрации концепции:
Python:
from sklearn.ensemble import IsolationForest
# пример для демонстрации концепции
model = IsolationForest(contamination=0.05, n_estimators=200)
model.fit(baseline_features) # dns_query_len, req_per_min, dst_count
scores = model.decision_function(new_alerts)
# score < -0.3 → подозрительный → передать на обогащение контекстомcontamination=0.05 задаёт ожидаемую долю аномалий (~5%). В среде с высоким базовым шумом (dev-окружения, CI/CD-кластеры) начинайте с 0.1 и снижайте по мере тюнинга. Порог -0.3 - отправная точка; реальный порог калибруется по FP/TP-соотношению на исторических данных конкретной инфраструктуры. Без калибровки под ваш стек - это просто число.Интеграция ML в SIEM: Elastic, Splunk, Sentinel
Способ встраивания ML-детектора зависит от SIEM-платформы. Универсальных рецептов нет - каждый вендор предлагает свой механизм, со своими граблями.
Elastic SIEM (8.x+). Встроенные ML jobs через anomaly detection в Kibana: population analysis (отклонение конкретного пользователя от группы) и rare analysis. ML-ноды требуют выделенных ресурсов - минимум 8 ГБ RAM на ML-ноду. Результаты аномалий приходят как отдельные findings, не привязанные к detection rules «из коробки»: нужно создавать custom rules, которые коррелируют ML-аномалию с исходным алертом по entity (user, host). Без этой связки ML-findings остаются «сиротами» вне общей очереди. Я видел инсталляции, где ML-ноды крутились месяцами, а findings никто не смотрел - потому что не прикрутили к пайплайну.
Splunk ES + MLTK. Machine Learning Toolkit позволяет обучать модели внутри Splunk через SPL-команды
fit и apply. Типовой подход: обучить модель на исторических notable events с маркировкой аналитиков, затем применять score к новым алертам. MLTK работает на search heads и может создавать нагрузку при больших объёмах - для продакшена рекомендуется вынести inference в отдельный сервис и передавать результаты обратно через HTTP Event Collector.Microsoft Sentinel. Встроенный UEBA с автоматической корреляцией по identity. Таблица
BehaviorAnalytics содержит оценки аномальности для каждого пользователя. Fusion rules объединяют алерты из разных source provider в одну цепочку. Для приоритизации тюнинга - запрос на поиск правил с наибольшим FP-rate за 30 дней:
Код:
SecurityIncident
| where TimeGenerated >= ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| summarize Total=count(), FP=countif(Classification=="FalsePositive"),
TP=countif(Classification=="TruePositive") by Title
| extend FPRate=round((FP*1.0/(FP+TP)),2)*100
| sort by FPRate desc | take 5Автоматизация триажа алертов через SOAR
ML-скоринг без автоматизации downstream-процессов - полумера. Модель выдала score, но если аналитик всё равно вручную открывает каждый тикет, читает контекст и принимает решение - выигрыш минимален. Оркестрация алертов SOAR превращает score в действие.
Playbook для автоматического триажа
Логика playbook строится на score-тирах. Каждый тир - конкретное автоматическое действие, без ручного вмешательства на нижних уровнях:| Risk score | Действие | Пример сценария |
|---|---|---|
| 0-20 | Auto-close, маркировка «low confidence, auto-resolved» | Failed login сервисного аккаунта из whitelist-подсети |
| 21-60 | Автоматическое обогащение контекстом + пересчёт score | Нетипичный логин - добавить: asset criticality, 24-часовая история, проверка IP в TI |
| 61-85 | Создание тикета L1 с pre-populated context | Тикет содержит: timeline, MITRE ATT&CK mapping, связанные алерты |
| 86-100 | Немедленная эскалация L2/L3 + pre-containment | Автоизоляция хоста через EDR API, уведомление в SOC-чат |
На Palo Alto XSOAR playbook реализуется через входной trigger на новый incident: вызов ML-scoring API -> ветвление по score -> набор обогащающих действий (запросы в VirusTotal, GeoIP, AD-атрибуты пользователя) -> создание или закрытие тикета. Для open-source стека аналогичную логику реализует Shuffle: webhooks от SIEM -> workflow -> вызов Python-скрипта с ML-моделью -> действие в ticketing-системе.
Mean Time to Conclusion (MTTC) - метрика, которая честнее классического MTTR. MTTC покрывает весь цикл от детекции до финального решения по всем алертам, включая закрытые как FP. По оценке Dropzone AI, ручное расследование одного алерта занимает от 20 до 40 минут в зависимости от типа. Автоматизированный триаж через ML сокращает это до секунд-минут и даёт 100% coverage - ни один алерт не уходит в бэклог нерассмотренным. Именно coverage здесь критичен: не скорость ради скорости, а гарантия, что ничего не провалится в щель.
Feedback loop: как замкнуть цикл и дообучить модель
Модель без обратной связи деградирует. Concept drift - изменение характера данных со временем - приводит к тому, что модель, обученная на данных полугодовой давности, начинает систематически ошибаться на текущем трафике. Через полгода ваша модель не узнает собственную инфраструктуру.
Четыре компонента работающего feedback loop:
За два года интеграции ML-пайплайнов в SOC разного масштаба (от 500 до 15 000 endpoint'ов) вывод один: 80% снижения FP-rate даёт не модель, а инженерная работа вокруг неё - whitelist'ы, baseline'ы, feedback loop. SOC, которые внедряют ML «сверху» - покупают UEBA-платформу и ждут магии - проигрывают тем, кто начинает снизу, с тюнинга пяти самых шумных правил и построения цикла обратной связи. По данным Verizon DBIR 2025, 68% утечек включают человеческий фактор (ошибки, misuse, социальная инженерия); Tines фиксирует выгорание у 71% SOC-аналитиков - усталость повышает риск того, что реальные алерты будут закрыты как FP. Автоматизация SOC ML - не про замену людей, а про то, чтобы люди оставались эффективными вместо того, чтобы перемалывать тысячи тикетов вхолостую. Формула понятна, но настоящая калибровка - это боль конкретного стека, конкретных данных и конкретной команды. Если настраиваете ML-обогащение алертов и хотите сверить пороги - на codeby.net коллеги разбирают калибровку ML-score и Sigma-правил для типовых SOC-сценариев, с привязкой к конкретным SIEM.
Последнее редактирование модератором:
