SOC будущего: почему сигнатурный анализ устарел

Понедельник, 9:15 утра. SOC-аналитик L2 открывает дашборд после выходных - 847 новых алертов. Первый в очереди: сработка Sigma-правила на запуск certutil.exe с флагом -urlcache. Проверяет - скрипт обновления сертификатов, развёрнутый админами в пятницу. False positive. Второй алерт: тот же certutil, другой хост. Тоже FP. К седьмому однотипному алерту внимание притупляется. Тринадцатый - снова certutil, но на этот раз реальный lateral movement через скомпрометированную сервисную учётку. Аналитик доберётся до него через четыре часа. К этому моменту атакующий уже на контроллере домена.

Этот паттерн я наблюдал в трёх из пяти SOC, где настраивал правила корреляции за последний год. По данным CrowdStrike Global Threat Report 2025, 79% атак проходят вообще без malware, среднее время lateral movement - 62 минуты (рекорд - 51 секунда). Сигнатурный анализ в этих условиях - замок на двери без стен.

Почему сигнатурный анализ устарел в SOC 2026​

Сигнатурный подход строится на простой логике: «видим паттерн X - значит атака». Десять лет назад это работало: атакующие использовали известный malware с характерными хешами, C2-доменами, сетевыми сигнатурами. Сегодня модель разбивается о три стены.

LOTL-техники и обнаружение аномалий в сети​

По данным отраслевых исследований, около 49% ransomware-атак задействуют Living-Off-The-Land техники. Атакующие запускают не кастомный malware, а штатные утилиты Windows - PowerShell, WMI, Bitsadmin.exe, Certutil.exe. Каталог LOLBAS-project перечисляет десятки таких бинарников с маппингом на MITRE ATT&CK:

• Certutil.exe - загрузка файлов, кодирование/декодирование (T1027.013, T1105, T1140, T1564.004)
• Bitsadmin.exe - загрузка и выполнение через фоновые задачи (T1105, T1218, T1564.004)
• Wmic.exe - удалённое выполнение команд, разведка ПО безопасности (T1105, T1218, T1518.001, T1564.004)

Написать сигнатуру на certutil -encode - минута работы. Но та же команда используется легитимно в десятках скриптов автоматизации. Итог: или поток false positive, который аналитики начинают игнорировать, или настолько узкое правило, что атакующий обходит его минимальной модификацией синтаксиса.

Техники Masquerading (T1036) и Obfuscated Files or Information (T1027) позволяют переименовать бинарник, обфусцировать аргументы или использовать альтернативный синтаксис вызова. Сигнатура перестаёт срабатывать. А поведенческая модель, которая отслеживает нетипичные цепочки процессов на конкретном хосте, от переименования не зависит - ей важно что делает процесс, а не как он называется.

Атаки через валидные учётные данные​

IBM X-Force Threat Intelligence Index 2025: количество атак с использованием действительных credentials выросло на 71% за год. CrowdStrike: 75% вторжений проходят через valid credentials. Verizon DBIR 2025: 38% утечек данных связаны с кражей учётных данных. При этом 6000+ свежих учёток всплывают на dark web ежедневно (оценка IBM).

Техника Valid Accounts (T1078) - одновременно initial access, persistence, privilege escalation и stealth. Сигнатура на «вход с невалидными credentials» тут бесполезна: credentials валидные. Атакующий входит под реальной учётной записью, работает в рамках стандартных разрешений, постепенно наращивает привилегии. Для SIEM это выглядит как обычный рабочий день сотрудника. Попробуй отличи.

Скорость адаптации: tuning fatigue​

Sigma-правило от момента обнаружения новой техники до production проходит цикл: исследование → написание → тестирование → деплой → тюнинг FP. В лучшем случае - дни, часто - недели. По данным Mandiant M-Trends 2025, exploits остаются самым распространённым вектором initial access (38%), а медианное время нахождения злоумышленника в сети - 11 дней. Атакующий адаптирует тактику за часы, защитник обновляет сигнатуры за дни. Арифметика не в нашу пользу.

Каждое обновление ОС, каждое изменение инфраструктуры может сломать десятки правил или породить волну новых FP. Это и есть tuning fatigue: аналитики тратят больше времени на поддержку сигнатур, чем на расследование реальных инцидентов. По данным anti-malware.ru, команды получают в среднем более 4000 оповещений ежедневно, при этом до 90% времени уходит на разгребание ложных срабатываний. Девяносто процентов. Не опечатка.

UEBA: поведенческая аналитика как фундамент SOC будущего​

Поведенческая аналитика (UEBA - User and Entity Behavioral Analytics) работает принципиально иначе. Вместо сравнения с базой известных паттернов атак она строит baseline нормального поведения каждого пользователя, хоста, сервиса и детектирует отклонения. Это напрямую реализует требование NIST CSF v2.0, подкатегория DE.AE-01: «базовый уровень сетевых операций и ожидаемых потоков данных для пользователей и систем устанавливается и поддерживается».

Как это работает на практике​

Система собирает данные об активности: время входа, источник, объём обращений к ресурсам, типичные приложения, сетевые соединения. За 2-4 недели формируется поведенческий профиль. Аномалии оцениваются по risk score.

Конкретный пример. Сервисная учётная запись svc_backup ежедневно в 02:00 обращается к 15 файловым серверам, передаёт 200-400 ГБ данных, завершает сессию. Это baseline. Если svc_backup внезапно обращается к контроллеру домена в 14:30 и выполняет LDAP-запросы на перечисление групп - это аномалия, даже если каждое отдельное действие выглядит легитимно. Сигнатурное правило такое не поймает: нет ни вредоносного хеша, ни подозрительного домена, ни запрещённой команды. Всё «чисто» - и всё не так.

По данным SANS Institute (через Swimlane): «эффективный мониторинг кибербезопасности требует контекстного понимания для различения нормальной и вредоносной активности». Именно этот контекст и даёт UEBA.

Что UEBA ловит, а сигнатуры - нет​

Detection-чеклист: baseline для UEBA​

Минимальный набор телеметрии для поведенческих профилей:

1. Authentication events - источник (IP, гео), время, результат, тип аутентификации
2. Process execution - родительский процесс, аргументы командной строки, хеш
3. Network connections - source/destination, порт, объём, продолжительность
4. File access - кто, к чему, когда, тип операции (read/write/delete)
5. Privilege changes - эскалация прав, добавление в группы, изменение ролей

Период обучения baseline: минимум 14 дней для пользователей, 7 дней для серверов и сервисов. Учитывайте сезонность: отчётные периоды и праздники могут потребовать 30-60 дней. (На практике я закладываю месяц - первые две недели baseline ещё слишком «сырой» и шумит не хуже старых сигнатур.)

ИИ в SOC: что реально работает для детектирования угроз без сигнатур​

«ИИ в SOC» - фраза, после которой у практикующего detection engineer срабатывает внутренний BS-детектор. Слишком много маркетинга, слишком мало конкретики. Разберём, что даёт результат, а что остаётся слайдами для руководства.

ML-модели для аномалий в SIEM​

Isolation Forest, autoencoders, кластеризация (DBSCAN) - вот рабочие лошадки для обнаружения аномалий в сетевом трафике и поведении пользователей. Типичный сценарий: модель Isolation Forest обучается на 30-дневном baseline сетевых сессий, затем присваивает anomaly score каждой новой сессии. Сессии выше порога попадают в очередь аналитика.

Никакой магии. Вместо 847 алертов аналитик видит 30-50 сессий с высоким anomaly score. False positive остаются, но их природа другая: не «PowerShell - подозрительно», а «эта сессия статистически отличается от всех остальных сессий этого пользователя за месяц». По данным NIST, «методы машинного обучения могут улучшить обнаружение вторжений путём идентификации паттернов и аномалий в больших наборах данных». Звучит очевидно - но в 2026 году это всё ещё не стандарт в большинстве SOC.

Что работает прямо сейчас​

ML-триаж алертов - приоритизация по risk score вместо severity. Алерт с severity=high на workstation интерна и тот же алерт на сервере с PCI DSS-данными - разные приоритеты. ML учитывает контекст актива, и это реально разгружает L1.

Корреляция через графы атак - связывание разрозненных событий в цепочку. По отдельности: подозрительный login, нехарактерный PowerShell, DNS-запросы к новому домену. Вместе: потенциальный kill chain. Ни один из трёх алертов сам по себе не вызвал бы эскалацию - а граф показывает картину целиком.

Detection-as-Code - CI/CD-пайплайн для Sigma-правил: правило пишется, автоматически тестируется на исторических данных, оценивается FP rate, деплоится в production. Не ML, но автоматизация, которая реально снижает tuning fatigue. Мы внедряли такой пайплайн на одном проекте - FP rate новых правил упал с ~40% до 12% за квартал.

Что не работает (пока)​

Полностью автономный SOC без людей. По данным Simbian, AI SOC agents показывают 95% analyst approval rate. Но 5% - это 50 неверных решений на 1000 алертов. Для инфраструктуры с критическими активами один неверный automated response может стоить дороже всех 999 правильных. Пока рано убирать людей из контура.

SOAR без адаптивности. Simbian отмечает, что Gartner deprecated SOAR в 2025 - playbook-based автоматизация не адаптируется к атакам, отклоняющимся от прописанного сценария. LLM-агенты как ассистенты аналитиков полезны для суммаризации инцидентов и генерации запросов к SIEM, но финальное решение о реагировании - за человеком. И это правильно.

Практика: поведенческое детектирование для конкретных TTP​

Правило грубое - в production без фильтра по конкретным destination и процессам-родителям зашумит. Но как отправная точка работает.

Indicator Removal: очистка логов (T1070.001) и Impair Defenses (T1562)​

Продвинутые атакующие не очищают лог целиком (Event ID 1102 - слишком заметно, это как поджечь дом, чтобы скрыть кражу). Они удаляют конкретные записи или отключают аудит через Impair Defenses (T1562).

Поведенческий подход: baseline объёма логов. Если на хосте обычно 500 событий/час, а за последний час - 3, это аномалия: сбой аудита или целенаправленное отключение. Сигнатура на Event ID 1102 этот сценарий не покроет - лог не очищался, он просто перестал наполняться.

Valid Accounts + Lateral Movement (T1078)​

Атакующий получает credentials через phishing, входит легитимно, перемещается по сети через RDP/SMB. Ни одного IOC.

Поведенческий подход: граф взаимодействий. Если user_finance за три года ни разу не подключался к srv-dev-01, а сегодня выполнил RDP-сессию в 23:47 - UEBA-модель присваивает высокий risk score. Объяснение: первое взаимодействие этих сущностей, нетипичное время, нетипичный destination. Три слабых сигнала, которые по отдельности ничего не значат, а вместе - повод для эскалации.

Переход от сигнатур к гибридной модели: пошаговый план​

По данным Swimlane и Abnormal, сигнатурный подход по-прежнему эффективен для known commodity threats с высокой confidence и минимальным FP rate. Цель - не отказ от сигнатур, а гибридная модель: сигнатуры закрывают commodity threats, поведенческая аналитика - advanced threats.

Практический план:

1. Аудит текущих правил - выгрузить все активные Sigma/SIEM-правила, оценить FP rate за 90 дней. Правила с FP >80% - кандидаты на замену поведенческой моделью
2. Определить baseline-источники - какая телеметрия уже собирается, чего не хватает. Минимум: authentication logs, process creation (Sysmon Event ID 1), network connections (Event ID 3)
3. Один use case в production - начать с insider threat или lateral movement detection. Один поведенческий use case, доведённый до production, ценнее десяти в «пилоте»
4. Метрики с бизнес-привязкой - не «аномалий обнаружено 500», а «инцидентов найдено поведенческой аналитикой, которые сигнатуры пропустили». С учётом оборотных штрафов за утечки персональных данных (до 3% выручки по российскому законодательству) один пойманный insider threat может окупить весь проект
5. Detection-as-Code pipeline - для сигнатурных правил, которые остаются: CI/CD с автотестированием на исторических данных, автооценка FP rate перед деплоем

Последний год я перевожу SOC-команды с чисто сигнатурной модели на гибридную. Результат неоднозначный, и врать не буду: baseline тюнится долго, первые месяцы UEBA генерирует шум не хуже старых сигнатур, команда сомневается. Перелом наступает на третьем-четвёртом месяце, когда модель стабилизируется и ловит то, что сигнатуры в принципе не могли - lateral movement через valid credentials, аномальную активность сервисных учёток, insider threat. Первый реальный инцидент, пойманный исключительно поведенческой аналитикой, меняет отношение команды навсегда.

Но вот что я вижу регулярно: команды, которые «внедрили UEBA», на деле включили модуль в SIEM и оставили дефолтные пороги. Без тюнинга baseline, без кастомизации под инфраструктуру, без обратной связи от аналитиков - это как поставить IDS в режиме tap и считать, что сеть защищена.

Сигнатурный анализ устарел не потому, что сигнатуры плохи сами по себе. Он устарел потому, что атакующие изменились. 79% атак без malware, 75% через valid credentials - цифры CrowdStrike не оставляют пространства для интерпретаций. Но поведенческая аналитика без инвестиций в тюнинг станет таким же разочарованием, как SIEM без правил корреляции десять лет назад. Если интересно, как другие команды выстраивают поведенческий detection на практике - на codeby.net ведётся живой тред с разбором UEBA-кейсов и примерами Sigma-правил под поведенческие паттерны.