Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, как из-за ошибок в триаже алертов настоящая атака спокойно проходит мимо дежурного аналитика — и что с этим делают зрелые команды в 2026 году.

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E-commerce и преподаю на курсах разработки и архитектуры. SOC — не «мой» мир в смысле ежедневной дежурной смены, но я много лет живу рядом с ним: мы поднимали интеграции продуктовых сервисов с SIEM, я читал постмортемы, где «алерт-то был, его просто закрыли», и сидел на разборах, где главный вопрос звучал не «почему сработала защита», а «почему её сигнал утонул». Об этом и поговорим.

Сразу про формат: это статья про ошибки, и я не буду давать ровную методичку «как надо» с первого абзаца. Я возьму одну рабочую область — повседневный триаж алертов — и разберу пять ситуаций, в которых аналитик и команда делают что-то понятное, логичное, по-человечески объяснимое. И именно поэтому пропускают атаку.

Сбой, который видел почти каждый

Картина, знакомая до боли. Три часа ночи. Дежурный аналитик заходит на смену, в очереди — несколько тысяч алертов. Он методично закрывает их пачками: вот опять GuardDuty сработал на перебор SSH от известного сканера, вот CloudTrail ругается на нарушение IAM-политики, которое подождёт до следующего спринта. К утру закрыто две сотни. И ровно один из них — не шум.

Это не страшилка из методички вендора, а статистически ожидаемое поведение. По данным State of the SOC 2026 от Microsoft/Omdia, 46% всех алертов оказываются ложными срабатываниями — почти половина работы аналитика не даёт ценности для безопасности. В крупных SOC цифры жёстче: центры получают по 10–15 тысяч алертов в день и успевают разобрать меньше половины, а по опросу Vectra AI 62% алертов вообще не триажат — просто игнорируют.

И вот что важно про современного атакующего. Он это знает. Промежуток между проникновением и началом бокового перемещения по сети в 2025 году сократился до 29 минут — на 65% быстрее, чем годом ранее, по данным CrowdStrike Global Threat Report 2026; в одном из задокументированных случаев эксфильтрация началась через четыре минуты после входа.

И атакующий специально подгадывает активность под окна высокого трафика, когда аномальный объём логов прячет его действия, либо под нерабочие часы с сокращённой сменой. Он не обходит детекторы в лоб — он делает так, чтобы его алерт был похож на те 200, которые вы уже закрыли не глядя.

Разберём пять ошибок, из-за которых этот один настоящий алерт остаётся незамеченным. Для каждой — симптом, почему она возникает, чем оборачивается и как её чинят сильные команды.

Ошибка 1. Глушить алерт вместо того, чтобы чинить правило

Симптом. В очереди раз за разом всплывает один и тот же тип срабатывания, который оказывается ложным. Аналитик устал — он добавляет правило в mute, отключает уведомление или просто заводит привычку закрывать его не открывая.

Почему так происходит. Это путь наименьшего сопротивления. Заглушить шумный детектор — две минуты. Разобраться, почему он шумит, переписать логику, добавить исключение для конкретного сервисного аккаунта — полдня, а ещё надо доказать, что ты ничего не сломаешь. Когда над тобой висит счётчик в три тысячи алертов, выбор очевиден.

Чем оборачивается. Глушение — это не настройка, это создание слепой зоны. Между «правило слишком чувствительное» и «правило выключено» есть огромная разница, и в первом случае вы хотя бы видите сигнал. Классика жанра — кейс Target 2013 года, который до сих пор разбирают на каждом курсе по ИБ.

Сигналы там были зафиксированы средствами защиты: FireEye генерировал срочные алерты на каждой установке вредоноса. Но опция автоматического удаления была отключена, а замеченные алерты не привели к своевременной эскалации — и это дало атакующим время украсть данные более 40 миллионов карт. Сигнал был. На него не отреагировали.

Как чинят. Здесь работает простое правило, которое я для себя сформулировал ещё на продуктовой разработке, разгребая шумные алерты мониторинга: шумный сигнал нельзя гасить, его можно только чинить или осознанно понижать с записью причины. Если детектор фонит — это задача в трекер на тюнинг, а не кнопка mute.

Зрелые команды ведут это как инженерный процесс: со временем паттерны ложных срабатываний выявляются, правило уточняется порогами и исключениями, и каждое ложное срабатывание становится материалом для улучшения, а не поводом отключить детектор. Разница в одном: заглушка убирает симптом, тюнинг убирает причину.

Ошибка 2. Триажить вслепую, без обогащения контекстом

Симптом. Аналитик открывает алерт, а там — голый факт: «подозрительный AssumeRole», IP, время. Чтобы понять, угроза это или нет, ему надо вручную сходить в пять разных консолей: проверить IP по репутации, поднять историю этого пользователя, посмотреть, что за актив, свериться с тикетами на деплой.

Почему так происходит. Потому что обогащение не настроено заранее. Алерт прилетает как уведомление, а не как готовое к решению дело. И тогда вся работа по сбору контекста ложится на человека в момент разбора — самое дорогое время.

Чем оборачивается. Аналитик тратит на сборку картины больше, чем на сам анализ. В средах, где обогащение не автоматизировано, аналитики проводят бóльшую часть времени триажа, собирая контекст, а не анализируя его. А дальше самое опасное: решения принимаются на неполных данных. Один из разборов 2026 года формулирует это жёстко — большинство SOC-команд триажат в темноте, работая с 60–70% доказательств, и эскалируют осторожно, потому что обогащение возвращает неполный результат.

Как чинят. Обогащение должно случаться до того, как человек откроет алерт. Скрипт проверяет подозрительный IP по репутационным спискам и прикрепляет результат к тикету ещё до открытия. К каждому событию заранее подтягивается исторический контекст (видели ли мы этот IP раньше?), критичность актива и, если в организации есть UEBA, риск-скор пользователя (например, UEBA risk score) — оценка того, насколько поведение этого аккаунта отклоняется от его обычной нормы.

Тогда аналитик открывает не загадку, а дело с уликами. Мой вариант, который я обычно отстаиваю на проектировании интеграций: обогащение — часть пайплайна доставки алерта, а не ручной шаг. Если контекст собирается руками, вы уже проиграли по времени.

Ошибка 3. Закрывать пачками без разбора: «по памяти» и «всё low — оптом»

Симптом. Два сросшихся паттерна. Первый: аналитик распознаёт тип алерта за полсекунды и закрывает на автопилоте, потому что «этот всегда ложный» — решение принимается не по содержанию события, а по тому, как оно выглядит. Второй: всё, что прилетело с severity low или informational, закрывается оптом — критичных и так не успеваем, до мелочи руки не дойдут. Вот как выглядит такой «безобидный» low, который закрыли не глядя:

14:02:11  severity=LOW  GetCallerIdentity  user=svc-deploy  src=10.0.4.7   -> closed: FP
14:02:48  severity=LOW  ListBuckets        user=svc-deploy  src=185.* (new) -> closed: FP
14:03:30  severity=LOW  AssumeRole         user=svc-deploy  role=admin-ro    -> closed: FP

По отдельности каждая строка — рутина. Вместе — разведка с нового IP за полторы минуты: кто я, что вижу, во что могу повыситься. Но три low, закрытые как FP, не сложились в одну картину.

Почему так происходит. Первое — прямое следствие усталости от алертов: после сотен ложных срабатываний из одного правила мозг переучивается, и реакция по умолчанию становится «скорее всего, ерунда». Это не вопрос дисциплины, это свойство психики под нагрузкой. Второе — рациональная реакция на перегрузку: когда очередь больше пропускной способности, приоритизация по severity кажется единственным способом не утонуть.

Чем оборачивается. Настоящий positive, спрятанный внутри потока однотипных ложных срабатываний из того же правила, — это ровно тот алерт, который с наибольшей вероятностью закроют без разбора. И атакующие поняли это раньше нас: когда команда автоматически отметает 80% алертов без расследования, нападающему достаточно сделать активность похожей на эти 80%. А с severity ещё хуже: атака почти никогда не начинается с high.

Ранние фазы kill chain — разведка, первичный доступ, аккуратное закрепление — это тихие, низкоприоритетные сигналы. Когда низкие severity массово закрываются без расследования, SOC систематически слеп к ранним фазам kill chain: атакующий становится виден только там, где активность уже достаточно серьёзна для high-severity алерта, — а это часто точка, где варианты сдерживания уже сузились. К моменту, когда загорается «красный», красть уже поздно — украли на «жёлтых».

Как чинят. Не лозунгом «будьте внимательнее» — на усталого человека он не действует, — и не «успевать всё руками», что невозможно. Убирают зависимость глубины проверки от состояния аналитика и от severity. Здесь важно не смешивать три разные вещи: обогащение (enrichment), корреляцию событий и AI-assisted triage — это разные слои, и многие зрелые SOC закрывают первые два вообще без LLM, на correlation searches, Sigma-правилах и движках детекта.

Подход, который становится стандартом: автоматизированные системы корреляции, всё чаще с AI-assisted triage, обеспечивают одинаковый минимальный объём автоматизированной проверки для каждого алерта — независимо от давления очереди, усталости аналитика и severity. Ресурсы всегда ограничены, поэтому речь не о «бесконечно глубоком расследовании всего», а о гарантированном минимуме первичной проверки, ниже которого не падает ни один алерт. Человек подключается не ко всем, а туда, где система подняла флаг.

Ошибка 4. Закрывать дело одной строчкой «FP» без обоснования

Симптом. Алерт закрыт. В комментарии — «false positive» или «benign», и всё. Ни почему ложное, ни что именно проверили, ни какого контекста не хватило.

Почему так происходит. Времени нет, очередь давит, а написать «FP» быстрее, чем зафиксировать ход мысли. К тому же кажется, что это и так очевидно — зачем расписывать.

Чем оборачивается. Так умирает обратная связь в детектирование. Закрытие алерта — это не конец работы, это данные для улучшения правил. Но только если в закрытии есть рассуждение. Результаты триажа с зафиксированным ходом расследования питают тюнинг детектов, обучение аналитиков и улучшение процессов; результаты, закрытые однострочной пометкой, в этот цикл обратной связи не попадают.

Без петли обратной связи происходит то, о чём я писал в ошибке 1: одни и те же ложные срабатывания повторяются и снижают эффективность SOC. Команда бегает по кругу: шумит правило — закрыли «FP» — правило шумит дальше.

Как чинят. Вводят detection feedback rate как метрику. Названия могут различаться между командами, но смысл один: измерять, какая доля результатов триажа приводит к изменениям в правилах и логике детектирования. Эта скорость и частота — один из главных способов, которыми SOC со временем улучшает качество детекта.

На практике это значит: закрытие алерта обязано отвечать на вопрос «что мы из этого поняли про правило». Помню, как однажды на разборе инцидента мы вытащили всю историю закрытий по одному шумному детектору — сто раз «FP» без единого слова. А внутри этой сотни сидел пропущенный настоящий. Узнать его было невозможно: он выглядел ровно как предыдущие девяносто девять закрытий.

Ошибка 5. Бороться с перегрузкой числом людей и хрупкими плейбуками

Симптом. Алертов больше, чем команда вывозит. Решение на уровне руководства: нанять ещё аналитиков и/или написать побольше SOAR-плейбуков «если X, то Y».

Почему так происходит. Это интуитивно правильные ходы. Не хватает рук — добавь руки. Много рутины — автоматизируй жёсткими сценариями. Оба решения легко защитить перед бизнесом, оба выглядят как движение вперёд.

Чем оборачивается. Добавление людей просто распределяет страдание на большее число человек — корень в архитектуре потока алертов, а не в нехватке рук. С жёсткими плейбуками своя беда: легаси-SOAR обещал автоматизацию, но выдал хрупкие плейбуки, которые постоянно ломаются, потому что угрозы не следуют предсказуемым паттернам «если X — делай Y».

Отдельная ловушка с AI-детектами: в отличие от обычного правила, которое остаётся читаемым, точность модели может молча деградировать по мере изменения среды, и тюнинг требует переобучения, а не правки одной строки. То есть можно заменить ручной шум на автоматический и какое-то время этого не замечать.

Как чинят. Не людьми и не жёсткими ветвлениями, а перестройкой самого пайплайна — и здесь критично одно архитектурное правило. Автономный триаж хорош ровно до момента, пока не начинает сам выполнять необратимые действия. Зрелый подход — многоуровневое исполнение: авто-выполнение для обратимых действий с высокой уверенностью вроде изоляции хоста, отзыва сессии или блокировки индикатора; рекомендовать-и-подтвердить для среднего уровня вроде блокировки аккаунта; полное человеческое решение для чувствительных действий.

И обязательный этап после любого действия — проверка результата: применилась ли блокировка, не офлайн ли агент, не откатилось ли изменение. Возможность отката не обсуждается: автоматический ответ без кнопки undo — это самоинициированная авария, ждущая своего часа. Wiz в своей методичке по SOC-автоматизации проводит ту же границу: процессы с необратимыми изменениями — деактивация продакшен-идентичностей, остановка критичных нагрузок — должны требовать явного человеческого подтверждения.

Как эта граница выглядит на схеме принятия решения — см. Рис. 2: он показывает маршрут алерта от поступления до действия и где проходит линия между «машина решает сама» и «зовём человека».

Главная мысль этой схемы простая. Автоматизация забирает на себя не право казнить, а право расследовать. Обогащение и корреляция идут для каждого алерта одинаково и без участия человека, обратимые действия с высокой уверенностью выполняются сами — но после каждого действия идёт проверка результата, и если блокировка не применилась или агент офлайн, дело уходит человеку, а не закрывается «успешно».

Всё необратимое и всё сомнительное обязательно проходит через человека — и всегда с возможностью отката. Человек не исчезает из контура, он перемещается из позиции «разгребаю всё подряд» в позицию «принимаю решения там, где цена ошибки высока».

Что реально работает: практики команд в 2026 году

Соберу в одном месте то, что делают зрелые SOC прямо сейчас — обратную сторону всех пяти антипаттернов.

Главное — detection-as-code: правила детектирования описываются как код или декларативные правила (Sigma, KQL, YARA-L, SPL и другие), хранятся в Git и проходят тот же жизненный цикл, что и обычный код, — ревью, версионирование, тесты, выкатку через CI/CD. Правило нельзя по-тихому заглушить мимо ревью, у каждого изменения есть история, каждое исправленное ложное срабатывание уменьшает шум завтра. Рядом — петля обратной связи как часть архитектуры: результаты триажа используются для обновления правил и плейбуков и, при наличии ML-компонентов, для последующего переобучения моделей, а сам пайплайн замкнут в контур от телеметрии до обратной связи в детектирующий слой.

И правильные метрики: не «сколько закрыли», а конверсия алертов в кейсы и доля benign. Много алертов не ведут ни к какому действию — детекты надо тюнить; алертов почти нет, но инциденты случаются — провалы в покрытии. Отдельно — MTTD/MTTR: в 2025 году глобальный медианный dwell time вырос до 14 дней против 11 годом ранее, по данным M-Trends 2026. Одной из причин может быть то, что ранние слабые сигналы теряются на этапе триажа.

Теперь живой пример. Показательны не сами проценты, а направление изменений. Независимо от масштаба компании и используемого стека результаты похожи: сокращается объём ручного триажа, уменьшается число ложных срабатываний, снижается время расследования. Конкретные цифры различаются, но закономерность повторяется почти во всех опубликованных кейсах.

Из конкретики: Grammarly сократила время расследования на 90%, уменьшив tier-1 триаж с 45 минут до 4 минут на тикет; по другим командам похоже — Docker сообщает о снижении ложных срабатываний на 85%, Snyk о сокращении объёма алертов на 70%, Tealium на 85%. Что мне здесь важно: ни одна из них не «наняла больше людей» и не «написала больше плейбуков». Все сделали обратное этим пяти ошибкам — автоматизировали обогащение и расследование, оставили человеку решения, замкнули обратную связь в детект, так что объём алертов со временем уменьшается, а не просто триажится быстрее.

Оговорюсь про ограничение, чтобы не выглядело рекламой. Все эти цифры — от вендоров, и к ним стоит относиться с поправкой на источник; я бы не воспринимал «90%» как обещание лично вам. Но направление важнее процента: проблема триажа не решается ни наймом, ни ужесточением правил по отдельности — лечится связка из трёх вещей сразу. Кто чинит только объём или только signal-to-noise, остаётся с дырой.

Сводная таблица: ошибка → признак → что проверить

Чек-лист: пройдитесь по своему триажу

Отметьте, что из этого настроено у вас. Каждый невыполненный пункт — это место, где настоящий алерт может утонуть.

• Шумные детекторы уходят в задачу на тюнинг, а не в mute; выключенных «чтобы не фонило» правил нет.

• Обогащение (репутация IP, история, критичность актива, риск пользователя) подтягивается до того, как аналитик открыл алерт.

• Минимальный объём автоматической проверки одинаков для всех алертов и не зависит от severity и усталости дежурного.

• Низкие severity и однотипные срабатывания коррелируются между собой, а не закрываются поштучно.

• Закрытие алерта фиксирует, что мы поняли про правило; вы измеряете detection feedback rate.

• У автоматических действий есть граница по обратимости и кнопка отката; необратимое проходит через человека.

Если хотя бы половина пунктов не отмечена — у вас не проблема «ленивых аналитиков», у вас дырявый процесс триажа.

Какой навык на самом деле проверяет эта группа ошибок

Если посмотреть на все пять ошибок сверху, видно: ни одна не про «плохого аналитика» и не про «слабый инструмент». Каждая — про то, что под нагрузкой судьба алерта начинает зависеть от усталости человека, от его памяти, от номера алерта в очереди и от того, сколько консолей не лень открыть. А атакующий 2026 года строит атаку именно на этом: подгадывает активность под шум и под нерабочие часы, чтобы его сигнал был неотличим от того, что вы привыкли закрывать не глядя.

Поэтому настоящий навык, который проверяет эта группа ошибок, — не «быстро разгребать очередь». Это умение построить триаж так, чтобы базовая проверка каждого алерта не зависела от состояния дежурного: обогащение случается до человека, гарантированный минимум автоматической проверки одинаков для всех алертов, человек принимает решения там, где цена ошибки и необратимость высоки, а каждое закрытие возвращается в детект как урок.

Аналитик, который это понимает, экономит команде не часы, а тот самый единственный пропущенный алерт, который иначе станет заголовком новостей.

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

22 июня в 20:00 на открытом уроке курса «Аналитик SOC» разберут журналы событий Windows, настройку аудита, Sysmon и инструменты анализа событий — тот слой доказательств, без которого расследование быстро превращается в догадки. Это хороший способ сверить свой подход к журналированию с тем, как события реально используют в работе SOC. Записаться на урок