Ложные срабатывания SIEM: тюнинг правил корреляции за первую неделю в SOC

За первую неделю стажировки в SOC (Security Operations Center — центр мониторинга безопасности) я обработал больше 400 алертов. Подтверждённых инцидентов среди них — два. Оба информационного уровня. Остальное — ложные срабатывания: корпоративный сканер уязвимостей, который никто не внёс в исключения; тестовый стенд разработчиков, стучащий на внешний API каждые 30 секунд; сервисная учётка с просроченным паролем. По данным anti-malware.ru, от 60% до 85% всех алертов в типичном SOC — ложные срабатывания. Мой опыт оказался ближе к верхней границе. Эта статья — записки стажёра о том, почему тюнинг одного правила корреляции ценнее подключения десяти новых.

Что такое ложные срабатывания SIEM и как они выглядят в очереди SOC

SIEM (Security Information and Event Management) — система, которая собирает логи со всей инфраструктуры, приводит их к единому формату и прогоняет через правила корреляции. Совпали условия правила — аналитик SOC получает алерт, уведомление о потенциальном инциденте.

Ложное срабатывание (false positive, FP) — алерт, который выглядит как угроза, но описывает легитимную активность. Три примера из первой недели, которые я запомнил навсегда:

Сканер в роли атакующего. Правило ловило множественные подключения к разным портам одного хоста за короткий промежуток — по сути, детектировало сканирование портов (техника Network Service Discovery, T1046 в MITRE ATT&CK). MITRE ATT&CK — открытая база тактик и техник злоумышленников; T-коды вроде T1046 — стандартные идентификаторы, на которые ссылаются правила детектирования. Правило честно срабатывало каждый раз, когда корпоративный Nessus запускал плановую проверку: 50+ алертов за смену, и каждый — мусор.

Сервисная учётка с просроченным паролем. Правило на «множественные неуспешные авторизации» реагировало на учётку svc_backup, у которой истёк пароль. Она пыталась аутентифицироваться каждые 10 секунд, генерируя десятки событий в минуту. Brute-force? Нет — забытая ротация пароля.

Тестовый стенд. Правило фиксировало подозрительные HTTP-запросы к внешним ресурсам. Разработчики гоняли интеграционные тесты, каждый прогон — 20-30 алертов.

Каждый FP требует времени: открыть тикет, проверить контекст, убедиться что легитимно, закрыть с комментарием. В первые дни на один алерт уходило 5-10 минут. Умножаем на 300+ ложных срабатываний за смену — и становится понятно, откуда берётся alert fatigue (усталость от алертов). Это не метафора. Это состояние, когда аналитик физически не может просмотреть все уведомления и начинает закрывать их на автомате, не вчитываясь.

False positive vs false negative SIEM: что опаснее на деле

False positive — SIEM кричит «пожар», а ничего нет. False negative (FN, пропуск) — реальная атака происходит, SIEM молчит. На первый взгляд, false negative страшнее: пропущенная атака = ущерб. Но связь между FP и FN гораздо теснее, чем кажется на старте.

Механизм простой: аналитик тонет в сотнях ложных срабатываний, перестаёт внимательно читать алерты. Появляется привычка «опять сканер» — и среди двухсот FP теряется одно настоящее срабатывание. По данным CardinalOps (2025), которые приводит anti-malware.ru, корпоративные SIEM детектируют лишь около 21% техник MITRE ATT&CK — даже при наличии нужных источников логов. А по результатам Picus Blue Report 2025 — только 1 из 7 многоэтапных атак приводит к генерации алерта.

Избыточные false positive напрямую провоцируют false negative. Правило, которое стабильно выдаёт 100 FP в день, не просто бесполезно — оно активно вредит, маскируя реальные срабатывания.

На третий день стажировки я уже автоматически закрывал определённые типы алертов, почти не читая. Наставник поймал этот момент и показал случай: среди «привычных» срабатываний правила на сканирование портов оказался один от внешнего IP — не из нашей инфраструктуры. Не сканер. Разведка извне. Урок усвоен: FP и FN — не противоположности, а звенья одной цепи.

Тюнинг правил корреляции SIEM: почему качество важнее количества

До стажировки я читал материалы с логикой «подключите больше источников, добавьте больше правил — получите лучшее покрытие». На практике это не работает.

Ошибка №5 из списка критических проблем SIEM (anti-malware.ru) — использование типовых правил корреляции без адаптации к среде. Вендорские SIEM поставляются с сотнями готовых правил (out-of-the-box rules). Каждое написано под «среднюю» инфраструктуру — то есть ни под какую конкретную. Включить все и ждать результата — утонуть в false positive.

Показательный пример: компания UnderDefense (кейс на cybersierra.co) увеличила покрытие MITRE ATT&CK с 20% до 90% — не добавлением новых правил, а пересмотром 500 дефолтных и созданием 275 кастомных. Они не нарастили количество, а заменили типовые правила на те, которые работают в их среде.

Правило корреляции — не датчик дыма (одинаковый для всех), а калиброванный термометр. Его нужно настроить под конкретную инфраструктуру: где норма — 5 неуспешных входов в минуту (AD с lockout-политикой), а где — 0.

Три категории FP для ежедневного отслеживания

После первой недели наставник предложил вести таблицу причин ложных срабатываний. Через месяц в ней выделились три устойчивые категории:

Каждая категория решается тюнингом существующего правила, а не написанием нового. Это главный вывод первых недель: одно вычищенное правило ценнее десяти непроверенных.

Снижение false positive в SOC: делай раз, делай два, делай три

Подход, который показал мне наставник, совпадает с рекомендациями из EN-источников (cybersierra.co, manageengine.com). Привожу в том виде, в каком применял сам.

Шаг 1. Найти правила-шумники

Прежде чем менять правила, нужно понять, какие из них генерируют больше всего ложных срабатываний. Цель — определить 3-5 правил, дающих 80% мусора, и начать именно с них.

В Splunk ES (Enterprise Security — надстройка для SOC-аналитиков) это делается запросом по индексу notable, где хранятся все алерты:

index=notable status=closed disposition="False Positive"
| stats count by rule_name
| sort -count
| head 10

Предусловие: нужен доступ к Splunk ES с правами на чтение индекса notable. В другой SIEM (QRadar, MaxPatrol, ELK) логика та же, синтаксис будет другим.

На выходе — таблица из двух столбцов: имя правила и количество FP. Первые 2-3 строки покажут, откуда идёт основной шум. В моём случае это были «Port Scan Detected» (сканер Nessus), «Multiple Failed Authentication» (сервисные учётки) и «Suspicious Outbound Connection» (тестовые стенды).

Шаг 2. Разобрать логику и найти «широкий» параметр

Каждое правило корреляции — набор условий: «если событие X произошло N раз за T минут с хоста Y — создай алерт». Ложное срабатывание означает, что одно из условий слишком широкое. Прежде чем менять правило, нужно понять, какой именно параметр «щедрый».

Что проверять (по рекомендациям cybersierra.co и manageengine.com):

• Временное окно — 5 минут vs 30 минут. Широкое окно захватывает больше шума.
• Пороговое значение (threshold) — 3 неуспешных входа vs 10. Низкий порог даёт много FP.
• Списки исключений — IP-адреса сканеров, сервисные учётки, тестовые подсети. Нет списка — правило реагирует на всё.
• Контекст актива — правило одинаково реагирует на продуктивный контроллер домена и на виртуалку стажёра.

ManageEngine описывает подход layered detection (многослойное детектирование): вместо срабатывания на одно событие правило требует комбинации нескольких условий. Не просто «вход с незнакомого IP», а «вход с незнакомого IP + доступ к критичным файлам в течение 10 минут». Такая логика резко снижает FP.

Шаг 3. Проверить изменения на исторических данных

После корректировки параметра нужно убедиться, что правило не стало слишком тихим. Иначе вместо FP получишь FN — а это хуже.

Прогон по историческим данным покажет, не «сломает» ли изменение детектирование подтверждённых инцидентов:

index=notable rule_name="Brute Force Access Behavior Detected"
| eval was_fp=if(disposition="False Positive",1,0)
| eval was_tp=if(disposition="True Positive",1,0)
| stats sum(was_fp) as FP sum(was_tp) as TP
| eval FP_rate=round(FP/(FP+TP)*100,1)."%"

На выходе — процент FP для конкретного правила. Выше 90% — правило требует серьёзной переработки. 50-70% — аккуратная корректировка порогов. Менее 30% — работает приемлемо.

После каждого изменения фиксируй в комментарии к правилу, что именно поменял и почему. Через месяц ты не вспомнишь, зачем поднял порог с 5 до 15. Коллега по смене — тем более.

Настройка правил корреляции SIEM: полный цикл на кейсе brute-force

Весь цикл тюнинга на одном примере — самый частый сценарий первой недели.

Исходное правило: «Более 5 неуспешных авторизаций с одного IP за 10 минут».

Проблема: сервисная учётка svc_backup с истёкшим паролем генерировала 200+ событий в час. Правило создавало новый алерт каждые 10 минут.

Анализ: все попытки — с одного внутреннего IP, одна учётка, один и тот же error code (KDC_ERR_PREAUTH_FAILED в Kerberos). При настоящей brute-force атаке перебираются разные учётные записи или пароли. Здесь одна пара «логин-пароль» повторяется в цикле — сломанный автоматический процесс, не атака.

Решение в три уровня:

1. Добавил svc_backup в exclusion list правила — убрал конкретный источник шума.
2. Изменил логику: вместо «5 неуспешных попыток с одного IP» — «5 неуспешных попыток с одного IP по 3 и более разным учётным записям за 10 минут». Это тот самый layered detection: одно условие не создаёт алерт, нужна комбинация.
3. Отправил заявку администраторам на ротацию пароля svc_backup — устранение корневой причины вместо маскировки симптома.

Результат: количество FP по этому правилу упало с 30+ за смену до 1-2. При этом правило стало точнее — теперь оно ловит именно перебор по разным учёткам, реальный паттерн brute-force.

Как зашумлённые правила пропускают реальные атаки

Чтобы связать тюнинг с последствиями — пример из каталога CISA KEV (Known Exploited Vulnerabilities, список уязвимостей, которые УЖЕ эксплуатируются в реальных атаках; если CVE попала в этот каталог — патчить нужно было вчера).

CVE-2023-20887 — command injection (внедрение команд, CWE-77) в VMware Aria Operations for Networks. CVSS: 9.8/10 (CRITICAL). Разберём вектор: AV:N — атака по сети, AC:L — низкая сложность, PR:N — привилегии не нужны, UI:N — без участия пользователя. Любой с сетевым доступом может выполнить произвольные команды на сервере без аутентификации. EPSS (оценка вероятности эксплуатации в ближайшие 30 дней) — 0.98, это top 1% среди всех CVE. Уязвимость активно эксплуатируется с июня 2023 года.

Атака через CVE-2023-20887 проходит несколько этапов. Каждый может быть задетектирован — или пропущен из-за шума:

1. Exploit Public-Facing Application (T1190, тактика Initial Access): аномальные HTTP-запросы к API VMware Aria. Правило на подозрительные веб-запросы — классический генератор FP, потому что каждый crawler и каждый легитимный API-клиент тоже создаёт «аномальные» запросы.
2. Command and Scripting Interpreter (T1059, тактика Execution): выполнение внедрённых команд на сервере.
3. Network Service Discovery (T1046, тактика Discovery): сканирование внутренней сети с захваченного хоста — тот самый паттерн, который у меня забивал очередь из-за Nessus.

Если правила для T1190 генерируют 200 FP в день, аналитик перестаёт на них смотреть. Настоящий exploit проходит незамеченным. В репозитории Sigma (открытая библиотека правил детектирования в формате YAML) по тегу T1190 опубликовано 152 правила, по T1046 — 22, по T1059 — 453. Для сканера Nuclei есть готовый шаблон CVE-2023-20887.yaml. Правила существуют. Вопрос — настроены ли они под конкретную инфраструктуру или шумят вхолостую.

NIST CSF 2.0 (фреймворк кибербезопасности от NIST) описывает этот процесс как две связанные функции: DE.AE-01 — создание и поддержание baseline (эталон нормального поведения сети) и RS.AN-01 — расследование уведомлений от систем детектирования. Без первого второе тонет в мусоре.

Метрики качества правил детектирования vs количество: что отслеживать

После первого месяца я завёл таблицу для оценки каждого правила. Метрики — из рекомендаций ManageEngine по rule evaluation:

Если у правила FP Rate выше 90% на протяжении двух недель — кандидат на серьёзный тюнинг или отключение. Если правило ни разу не сработало за месяц — проверь, получает ли оно нужные логи: возможно, источник отключён или нормализация сломана.

Отключение правила — не поражение. Это осознанное решение. По данным исследования RuleGenie (2025), избыточные и перекрывающиеся правила снижают производительность аналитиков, увеличивают вычислительную нагрузку и задерживают реагирование на реальные угрозы. Иногда лучшее, что можно сделать, — удалить правило и написать новое точно под свою инфраструктуру.

Отдельный подход — rule prioritization (ManageEngine): каждому правилу присваивается приоритет на основе severity угрозы, критичности актива и compliance-требований. Правила с высоким TPR и низким FPR получают приоритет в обработке. Правила с хронически высоким FPR — либо перерабатываются, либо подавляются в пользу более точных.

Вот что я вынес из первых месяцев работы с алертами. SOC-аналитика первого уровня часто оценивают по количеству обработанных тикетов за смену. Реальная ценность L1 — не в скорости закрытия, а в качестве обратной связи. Каждый ложный алерт, который ты разобрал и задокументировал с причиной FP, — входные данные для детект-инженера (специалист, который пишет и поддерживает правила корреляции). Каждый непомеченный FP — упущенная возможность сделать SIEM тише и точнее.

Команды, где L1 «просто закрывает алерты», живут в цикле: 300 FP за смену → усталость → пропущенный инцидент → паника → добавление новых правил → 400 FP. Команды, где L1 ведёт feedback loop для детект-инженера, выходят из этого цикла за 2-3 месяца.

Половина проблем с SIEM — не проблемы технологии. Это проблемы процесса: нет регулярного тюнинга, нет обратной связи от L1 к инженерам, нет метрик качества правил. Пока KPI аналитика — «закрыть 50 тикетов за смену», SIEM будет дорогим архивом логов с шумной сиреной. На IB Basics в codeby.school эту механику разбирают на практике: не «что такое CIA-triad», а как выглядят первые задачи в SOC и blue team — та база, с которой начинается осмысленная работа с алертами.