Всем привет, меня зовут Сергей Прощаев, и в этой статье расскажу про то, как из-за ошибок в триаже алертов настоящая атака спокойно проходит мимо дежурного аналитика — и что с этим делают зрелые команды в 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, который закрыли не глядя:
По отдельности каждая строка — рутина. Вместе — разведка с нового 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, остаётся с дырой.
Сводная таблица: ошибка → признак → что проверить
Признак в вашем SOC
Что проверить прямо сейчас
Глушить вместо чинить
У детекторов есть mute/выключенные правила «чтобы не фонили»
Сколько правил в mute и почему; заведены ли задачи на тюнинг вместо заглушки
Триаж без обогащения
Аналитик ходит по 5 консолям, чтобы понять один алерт
Подтягивается ли контекст (репутация, история, критичность) до открытия алерта
Закрывать пачками без разбора
Алерты закрываются по виду «всегда ложный»; всё low/informational — оптом
Есть ли категории с автопилотом закрытий; получают ли низкие severity хоть какую-то проверку; видите ли вы ранние фазы kill chain
«FP» без обоснования
В закрытиях — однострочные «benign/FP» без рассуждения
Питают ли результаты триажа тюнинг правил; измеряете ли detection feedback rate
Люди и хрупкие плейбуки
На перегрузку отвечаете наймом и новыми «если X — Y»
Есть ли граница авто-действий по обратимости; есть ли откат у автоматических действий
Чек-лист: пройдитесь по своему триажу
Отметьте, что из этого настроено у вас. Каждый невыполненный пункт — это место, где настоящий алерт может утонуть.
Шумные детекторы уходят в задачу на тюнинг, а не в mute; выключенных «чтобы не фонило» правил нет.
Шумные детекторы уходят в задачу на тюнинг, а не в mute; выключенных «чтобы не фонило» правил нет.
Обогащение (репутация IP, история, критичность актива, риск пользователя) подтягивается до того, как аналитик открыл алерт.
Обогащение (репутация IP, история, критичность актива, риск пользователя) подтягивается до того, как аналитик открыл алерт.
Минимальный объём автоматической проверки одинаков для всех алертов и не зависит от severity и усталости дежурного.
Минимальный объём автоматической проверки одинаков для всех алертов и не зависит от severity и усталости дежурного.
Низкие severity и однотипные срабатывания коррелируются между собой, а не закрываются поштучно.
Низкие severity и однотипные срабатывания коррелируются между собой, а не закрываются поштучно.
Закрытие алерта фиксирует, что мы поняли про правило; вы измеряете detection feedback rate.
Закрытие алерта фиксирует, что мы поняли про правило; вы измеряете detection feedback rate.
У автоматических действий есть граница по обратимости и кнопка отката; необратимое проходит через человека.
У автоматических действий есть граница по обратимости и кнопка отката; необратимое проходит через человека.
Если хотя бы половина пунктов не отмечена — у вас не проблема «ленивых аналитиков», у вас дырявый процесс триажа.
Какой навык на самом деле проверяет эта группа ошибок
Если посмотреть на все пять ошибок сверху, видно: ни одна не про «плохого аналитика» и не про «слабый инструмент». Каждая — про то, что под нагрузкой судьба алерта начинает зависеть от усталости человека, от его памяти, от номера алерта в очереди и от того, сколько консолей не лень открыть. А атакующий 2026 года строит атаку именно на этом: подгадывает активность под шум и под нерабочие часы, чтобы его сигнал был неотличим от того, что вы привыкли закрывать не глядя.
Поэтому настоящий навык, который проверяет эта группа ошибок, — не «быстро разгребать очередь». Это умение построить триаж так, чтобы базовая проверка каждого алерта не зависела от состояния дежурного: обогащение случается до человека, гарантированный минимум автоматической проверки одинаков для всех алертов, человек принимает решения там, где цена ошибки и необратимость высоки, а каждое закрытие возвращается в детект как урок.
Аналитик, который это понимает, экономит команде не часы, а тот самый единственный пропущенный алерт, который иначе станет заголовком новостей.
Разбор триажа почти всегда упирается в один практический вопрос: хватает ли команде данных, чтобы отличить шум от раннего признака атаки.
22 июня в 20:00 на открытом уроке курса «Аналитик SOC» разберут журналы событий Windows, настройку аудита, Sysmon и инструменты анализа событий — тот слой доказательств, без которого расследование быстро превращается в догадки. Это хороший способ сверить свой подход к журналированию с тем, как события реально используют в работе SOC. Записаться на урок