Что можно выжать из базовых метрик SOC, если у тебя лапки

Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах.
Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

Привет, Хабр! Меня зовут Анатолий Антипов, я руковожу группой аналитиков L1 в небольшом in-house SOC. В этой статье расскажу, почему классический тайм-трекинг (как единственная система оценки) сказывается не только на безопасности, но и на выгорании аналитиков, чем его дополнить для качественной оценки и как мы перестроили еженедельную отчетность, добавили прозрачную матрицу вердиктов, контроль качества и фокус на результате, а не на количестве кликов.

Эта тема не нова: есть масса исследований про обоснование бизнес-потребности SOC, про финансовую составляющую, про гибридные и коммерческие SOC. Поэтому сразу зафиксирую рамки этой статьи, чтобы не было ложных ожиданий:

  • Во‑первых, это взгляд на малочисленный in-house SOC – команда до 8 человек.

  • Во‑вторых, здесь в первую очередь оценивается работа аналитиков SOC.

  • В‑третьих, метрики выбираются не для топ-менеджмента и не для бизнеса, а для технических руководителей – чтобы управлять командой и процессами.

  • В‑четвёртых, это взгляд не «сверху» от признанных лидеров в области кибербезопасности, а со стороны практиков – тех, кто каждый день разбирает алерты и чинит процесс.

  • И, наконец, так как большинство сработок детектирующего контента не подтверждаются как инциденты, дальше я в основном буду говорить именно про рутину алертов, а не про реальные инциденты.

В обсуждениях эффективности SOC, в том числе в вебинаре Алексея Лукацкого «Как измерить эффективность SOC: подходы и лучшие практики», хорошо звучит базовая мысль: начинать нужно не с метрики, а с цели. Если цель сформулирована как «быстрее закрывать алерты», система почти неизбежно начнет оптимизировать скорость вместо качества.

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

Какие метрики обычно используют

По классике SOC любят мерить «Mean Time» метриками. Но есть нюанс: названия похожи, а смысл и границы у них часто плавают.

  • MTTD (Среднее время обнаружения) - показывает скорость работы автоматики, детектирующих правил и систем, но не учитывает качество. Мгновенная генерация тысяч ложных алертов даст идеальный MTTD, но перегрузит команду;

  • MTTA (Среднее время подтверждения) - оценивает оперативность дежурной смены и и загруженность людей, но его легко накрутить. Аналитики могут механически переключать статус алерта «в работу» ради KPI, не приступая к разбору;

  • MTTI (Среднее время расследования) - подсвечивает квалификацию аналитиков и их способность быстро отличить реальную атаку от легитимных действий, но скорость может расти за счет поверхностного анализа и пропуска деталей;

  • MTTC (Среднее время локализации) - отражает способность SOC быстро остановить развитие атаки и минимизировать ущерб для бизнеса, но не гарантирует полноту. Можно быстро изолировать один хост, но упустить из виду, что злоумышленники уже закрепились на других серверах;

  • MTTR (Среднее время решения/устранения) - комплексная метрика, которая показывает слаженность и оперативность работы всех (ИБ и ИТ) команд, но не отражает полноту решения. Быстрое восстановление системы из бэкапа улучшит метрику, но без устранения корневой причины атака может повториться.

Смысл простой: время показывает, насколько быстро SOC двигается по процессу. Но не показывает, правильным ли было решение.

В погоне за MTTA: когда автоматизация пошла не туда

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

Из личного опыта:  в прошлом у меня был опыт, когда  руководство настолько закрутило гайки вокруг MTTA, что дежурная смена пошла на радикальные меры. Один из аналитиков написал простейший скрипт, который мониторил почту и при поступлении оповещения о новом алерте автоматически переводил карточку в статус «В работе». На бумаге всё выглядело прекрасно: MTTA падал, метрики зеленели, руководство довольно смотрело на «бублики». Но реальные кейсы могли часами висеть без внимания.

Это классический пример того, как метрики в отрыве от контроля качества порождают симуляцию безопасности.

Что говорит индустрия?

Свежий глобальный отчет 2026 SANS SOC Survey показывает важный тренд: современный SOC живет в условиях жесткого дисбаланса. В реальной жизни SOC живет в шуме, разрозненных данных и вечной нехватке контекста. И если аналитик вынужден выбирать между глубоким разбором и сохранением красивого SLA, выбор часто делается не в пользу безопасности.

А лидеры индустрии в свою очередь сходятся во мнениях, что для обоснования финансирования используют метрики «количество обработанных инцидентов» (70% респондентов) и время от обнаружения до локализации и устранения инцидента (48%). И после формирования SOC продолжают смотреть именно на эти метрики.

Что ломается, когда важны только скорость и количество и что это означает для L1 на практике?
Если весь фокус только на времени реакции и количестве, SOC начинает жить в очень странной логике:

  • чем быстрее взяли кейс, тем лучше, даже если дальше его не начали разбирать;

  • чем быстрее закрыли, тем «эффективнее», даже если вердикт натянут и непрозрачен;

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

В итоге появляются знакомые симптомы:

  • поверхностный анализ вместо качественного разбора;

  • закрытие алертов «чтобы не висели»;

  • эскалация без сбора контекста;

  • игра со статусами «ожидаем ответа сотрудника»;

  • имитация активности под названием «сделать цифру».

И вот уже SOC выглядит бодро только на дашбордах. В жизни же он начинает напоминать очень дорогой автокликер с хорошими отчётами.

Что мы поменяли?

Шаг 1. Наводим порядок в вердиктах (Убираем серую зону)

Важнее не просто считать алерты и минуты, а разделять, что именно происходит с потоком, чтобы аналитики L1 не тонули в нем. Это ровно та логика, о которой часто говорят в разговорах про эффективность SOC: сначала нужно понять, какую полезную работу SOC вообще должен делать, а уже потом подбирать метрики под эту задачу.
Мы полностью отказались от размытых формулировок вроде «Легитимно» при закрытии карточек алертов в SOAR. Мы внедрили пятиуровневую матрицу вердиктов и провели границу между типами ложных сработок.

Мы ввели пять основных категорий:

  • TP.Ext (True Positive External) - подтвержденный инцидент, связанный с внешней атакой;

  • TP.Int (True Positive Internal) - подтвержденное нарушение со стороны внутреннего нарушителя;

  • BP (Benign Positive) - легитимная активность аудиторов, пентестеров, учений или тестов правил;

  • FP (False Positive) - сработка на легитимное действие бизнеса или ИТ;

  • FP.SOC (False Positive SOC) - проблема внутри контента SOC: правило, парсинг, фильтрация, логика.

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

Для наглядности приведу пример BPMN-схемы из внутреннего регламента.

Шаг 2. Пересобираем еженедельный отчет

Вот здесь, на мой взгляд, и начинается самое полезное.

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

Мы переработали отчет так, чтобы он отвечал на три вопроса:

  • Что происходило в SOC на самом деле?

  • Что именно нужно чинить: людей, правила или процессы?

  • На что ушли реальные трудозатраты команды?

В итоге отчет стал состоять из трех блоков:

Блок

Что показывает

Зачем нужен

Общая картина недели

Сколько алертов зарегистрировано, сколько закрыто, какой остаток, как распределилась нагрузка по сменам и источникам логов

Чтобы видеть масштаб и динамику

Разбор по вердиктам

Распределение TP/ FP /BP, и FP.SOC

Чтобы понимать, что происходит в потоке и где болит

Подтвержденные нарушения и реагирование

Реальные кейсы, выводы, реакция, трудозатраты

Чтобы показывать ценность SOC и реальную загрузку

Блок 1. Общая картина недели

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

Здесь важен не только объем, но и динамика или девиация. Если поток алертов значительно вырос, то не всегда нужно паниковать. Важно понять, за счет чего именно он растет: новый источник, новая активность бизнеса, обновление контента SIEM или реальный всплеск вредоносной активности?

Блок 2. Разбор по вердиктам

Этот блок наглядно показывает, где у SOC здоровье, а где температура. Если растет FP – смотрим на взаимодействие с ИТ и бизнес-подразделениями. Если растет FP.SOC – это не просто «очередная фолза». Это уже сигнал, что проблема сидит внутри самого SOC: в правилах, логике, парсинге, фильтрации. То есть это не внешний шум, а наш собственный техдолг, который обычно очень любит маскироваться под «особенности инфраструктуры».

Как это работает: мы не просто копим тикеты FP.SOC. Еженедельно мы берем этот топ-10 и проводим рефакторинг правил корреляции.

Пример из жизни: в SOAR приходит сработка «Запуск подозрительного PowerShell». В карточке алерта поле «Путь» пустое – не подтянулся FilePath из события 4104, ошибка маппинга. Аналитик проваливается в консоль SIEM и видит, что путь на штатный скрипт инвентаризации ИТ. Но из-за того, что инженер SIEM некорректно экранировал слеши в логике правила, KUMA считает эту активность аномальной. Аналитик также тратит еще минут 10 на выгрузку и анализ файла скрипта через консоль EDR, чтобы убедиться, что скрипт действительно не вредоносный. Это чистый FP.SOC, который сжигает ресурсы.

Это ключевой блок для демонстрации динамики повышения качества детектирования.

Блок 3. Подтвержденные нарушения и реагирование
Здесь мы показываем руководству "выхлоп" бизнес-ценность от работы SOC и реальные трудозатраты.

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

Для подсчета трудозатрат и загрузки аналитиков также важна сводная статистика:
(об этом я более подробно планирую рассказать в последующей статье)

  • Количество алертов, потребовавших почтовых взаимодействий (запросы, уточнения).

  • Количество алертов с запуском антивирусной проверки.

  • Количество запусков сбора триажа (хостовая криминалистика).

  • Количество заблокированных индикаторов компрометации (IP, FQDN).

Чтобы цифры были сопоставимыми, мы добавили показатели эффективности дежурной смены:

  • среднее время решения ;

  • количество алертов с нарушенным SLA;

  • количество переоткрытых алертов - хороший индикатор некорректной отработки алерта;

  • таблицу статистики по аналитикам: кто сколько обработал и эскалировал.

Шаг 3. Постоянный контроль качества

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

Каждая карточка алерта оценивается по следующим критериям:

  • корректен ли вердикт (действительно ли FP/TP);

  • описаны ли все действия (можно ли по карточке восстановить ход мысли и действий аналитика);

  • приложены ли артефакты (и достаточны ли они);

  • корректно ли решение (прозрачно ли транслирован комментарий к закрытию)

  • для FP.SOC - описана ли потребность в доработке

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

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

Резюме

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

И да, самая неприятная часть этой истории в том, что рутина никуда не девается сама. Ее все равно приходится разбирать, автоматизировать, упрощать и вычищать.
Именно поэтому в следующих статьях я планирую рассказать про математическую многофакторную систему оценки качества работы аналитиков и про калькулятор трудозатрат SOC.
Потому что, если не заняться рутиной системно, она очень быстро начнет управлять и людьми, и метриками, и самим SOC. А это уже совсем не тот SOC, который хочется строить.

В этой статье я сознательно затронул только две вехи из триады SOC – людей и процессы.
Есть ещё огромный и немаловажный пласт – технологии, а под ними я для себя выделяю не только сам технологический стек SOC, но и технические реализации: SIEM-контент, интеграции, автоматизации, покрытие источников телеметрии, покрытие TTP (тактик, техник и процедур нарушителей) – это уже тема для отдельной дискуссии.

Вопросы к аудитории:

  • Чем ваша команда дополняет метрики «Mean Time» при построении отчетов?

  • Используете ли вы практику регулярного кросс-ревью карточек алертов внутри смены?

  • Поделитесь своим опытом построения качественных метрик в комментариях!