📊 Временные метрики SOC не отвечают на главный вопрос Аналитик написал скрипт, который при поступлении предупреждения автоматически переводил карточку в «В работе». MTTA снижался, панели мониторинга зеленели. Реальные случаи часами висели без разбора. Это не анекдот — случай из практики руководителя L1 во внутреннем SOC численностью до 8 человек, описанный в статье на habr_infosec. Метрики Mean Time измеряют скорость, но не решение. MTTD легко исказить потоком ложных срабатываний, MTTA — скриптами, MTTR — восстановлением из резервной копии без устранения причины. В отчёте SANS SOC Survey 2026 те же перекосы: 70% респондентов обосновывают финансирование количеством обработанных инцидентов, 48% — временем до локализации. Так SOC превращается в дорогой автоматический кликер. Команда автора заменила размытые заключения на пятиуровневую матрицу: TP.Ext, TP.Int, BP, FP и FP.SOC. Последний — отдельная категория: срабатывание из-за проблем в собственном содержимом SIEM. Пример: правило «Запуск подозрительного PowerShell» срабатывало на штатный скрипт инвентаризации, потому что инженер некорректно экранировал слеши в логике KUMA. FilePath из события 4104 не подгрузился, аналитик тратил ещё 10 минут на проверку файла в EDR. Такие FP.SOC еженедельно выносят в топ-10 и перерабатывают правила. Раз в неделю автор берёт выборку закрытых карточек каждого аналитика и проверяет заключение, описанные действия, артефакты и логику решения. Это снимает ловушку «быстрый — значит хороший». В маленьком SOC плохая метрика обходится дороже: один перекос быстро становится рутиной, техническим долгом и выгоранием. Я бы начал не с новой панели мониторинга, а с проверки закрытых карточек за прошлую неделю. Если в выборке больше 20% заключений нельзя восстановить по карточке — у вас не SOC, а конвейер по производству зелёных цифр. #SOC #метрики #FalsePositive #техдолг