Метрики команды кибербезопасности: SOC за пределами MTTR
SOC, который ездит только на MTTR, измеряет пожар, а не пожарную команду. В отчёте IBM Cost of a Data Breach 2024 среднее время выявления и сдерживания утечки — 258 дней, и команды, которые пробили планку в 200 дней, сделали это не за счёт скорости реакции. Они детектили раньше и тратили меньше времени на toil. MTTR был побочным эффектом, а не целью.
Инженерия кибербезопасности требует своего стека метрик. Стандартные engineering KPI недооценивают асимметричную цену пропуска, а чисто InfoSec-дэшборды не замечают, выгорает ли команда или сжигает ли она бюджет.
{/* truncate */}
Почему security engineering — отдельный зверь
Команда security engineering не шипает фичи — она шипает coverage, детекты и response-возможности. Feedback loop'ы жестокие: пропущенная угроза может всплыть через месяцы, так что вы не можете ждать lagging-сигнал, чтобы понять, работает ли команда.
Три асимметрии делают стандартные инженерные метрики вводящими в заблуждение:
| Обычная инженерная команда | Команда security engineering |
|---|---|
| Сбой = баг в фиче, чинится в следующем спринте | Сбой = непойманная утечка, копится неделями |
| Обратная связь от клиента — часы | Обратная связь от атакующего — месяцы (или никогда) |
| Deploy frequency — цель | Deploy frequency — поверхность риска |
Вывод: нужно мерить опережающие индикаторы (coverage, throughput detection engineering, patch lag), а не только запаздывающие (инциденты, MTTR).
Фреймворки, на которые стоит ссылаться:
| Фреймворк | Что даёт | Чего не хватает |
|---|---|---|
| MITRE ATT&CK | Таксономия покрытия детектами | Нет модели продуктивности |
| NIST CSF 2.0 | Governance + Identify/Protect/Detect/Respond/Recover | Слишком абстрактен для командного уровня |
| SANS SOC Survey (ежегодный) | Бенчмарки по штату и toil | Self-reported, survey-based |
SOC, который меряет только MITRE coverage и MTTR — это как команда разработки, которая меряет только test coverage и uptime. Обе метрики полезны, но ни одна не говорит, выгорит ли команда в следующем квартале.
7 метрик, которые реально важны в security engineering
1. Mean Time to Detect (MTTD) — опережающая половина MTTR
Что меряет: время от появления угрозы в сети до первого алерта, на который реагирует человек или автоматический playbook.
Таргет: менее 60 минут для high-severity. Бенчмарки Gartner SOC 2024: медианный MTTD в финансовых SOC — 43 минуты для tier-1 угроз.
Почему «to restore» вводит в заблуждение: команда может иметь быстрый MTTR и двухнедельный MTTD. К моменту, когда вы нажали секундомер, утечка уже катастрофична.
2. Mean Time to Contain (MTTC)
Что меряет: время от детекта до изоляции угрозы — не починка, не устранение, просто невозможность дальше наносить ущерб.
Таргет: менее 2 часов для tier-1 инцидентов.
IBM 2024 приписывает $1.76M среднего снижения стоимости утечки именно скорости containment'а. Containment компаундится: каждый сэкономленный час убирает час lateral movement.
3. Throughput detection engineering
Что меряет: число качественных детектов, написанных и задеплоенных инженером за квартал, с quality gate — детекты, которые сработали хотя бы раз за 90 дней, не будучи затьюнены до полной немоты.
Почему это самая сложная метрика: команды оптимизируют под количество детектов, выкатывают 400 правил, половина отключена через месяц из-за шума false-positive. Quality gate убивает закон Гудхарта.
4. Patch lag
Что меряет: медианные дни между публикацией CVE, релевантной вашему стеку, и её деплоем в прод.
Таргет: менее 14 дней для CVSS 9+. Менее 30 дней для CVSS 7–8.
Данные Verizon DBIR 2024: 60% успешных эксплойтов бьют по уязвимостям, патч к которым был доступен 60+ дней. Patch lag — это не проблема security-команды, это проблема на стыке security engineering и DevOps. Поэтому большинство компаний не могут её починить. Нужна cross-team телеметрия.
5. Alert-to-action ratio
Что меряет: % алертов, приводящих к действию человека (расследование, эскалация, тюнинг). Инверсия — шум алертов — главный предиктор выгорания аналитика.
Таргет: выше 15%. Ниже 5% — SOC завален шумом, аналитики перестают расследовать вообще.
SANS SOC Survey 2024: выгорание аналитиков — причина №1 текучки в SOC, впереди зарплаты. Гонит её не объём, а шум.
6. Toil ratio
Что меряет: % времени аналитика на повторяющихся, автоматизируемых задачах (триаж false positive, сбор логов для compliance, ручное обогащение).
Таргет: менее 30%. Google SRE book ставил потолок toil у SRE на 50%; у security-аналитиков нужно жёстче (ближе к 30%), потому что работа более когнитивно нагружена, а налог на выгорание выше.
7. Coding time security-инженера
Что меряет: реальное время, которое detection-инженеры и tooling-инженеры проводят в IDE — пишут правила, пайплайны, SOAR-плейбуки, а не сидят в триаже.
Если ваши detection-инженеры кодят меньше часа в день, они не detection-инженеры — это аналитики с красивым тайтлом. PanDev Metrics трекает IDE heartbeat именно для того, чтобы отделить engineering-time от toil-time — разрез, который большинство SOC-лидов не видят из своих SIEM-дэшбордов.
SOC-телеметрия, а не только SIEM-телеметрия. Security engineering метрикам нужны сигналы из IDE, Git и трекера, помимо security-стека.
Как compliance и масштаб меняют измерение
Финансовые и healthcare SOC живут под режимом доказательств. PCI-DSS 4.0 (в силе с марта 2025) явно требует документированного покрытия детектами и time-bound записей о remediation — то есть ваши MTTD и patch lag больше не внутренние KPI, это audit-артефакты.
Три регуляторных нюанса:
| Регуляция | Что добавляет к метрикам | Практическое изменение |
|---|---|---|
| PCI-DSS 4.0 | Доказательство детекции для каждого критического контроля | MTTD по каждой тактике ATT&CK, а не только глобальный |
| NIS2 (EU) | Первичное уведомление в 24 часа для значимых инцидентов | MTTD + MTTC по regulator-reportable событиям отдельно |
| SOX IT (US public) | Change control на production-детектах | Audit trail на каждое изменение детекта — Git, а не Excel |
Вывод: SOC в регулируемой вертикали не может трекать метрики только в Splunk или Sentinel. Нужны Git-бэкапнутые записи изменений детектов, IDE-бэкапнутые записи, кто что написал, и трекер-бэкапнутые записи жизненного цикла инцидента. Здесь модель «один SIEM-дэшборд» ломается.
Типичный профиль команды security engineering
| Параметр | Типичный диапазон |
|---|---|
| Размер | 6–30 |
| Структура | Tier-1 аналитики, Tier-2/3 респондеры, detection-инженеры, tooling-инженеры, SOC-менеджер |
| Основной стек | SIEM (Splunk / Sentinel / Chronicle), EDR (CrowdStrike / SentinelOne), SOAR, тикет-система |
| Доля кодинга | Detection-инженеры 40–60%, аналитики 5–15% |
| Главное давление | Регуляторный аудит + текучка аналитиков |
Разрыв между ролями внутри security-команды резкий. У detection-инженеров и SOAR/tooling-инженеров профиль coding-time должен быть ближе к backend-инженерам, чем к helpdesk. Если это не так — аналитическая работа маркируется как инженерная, и output SOC на человека падает без видимой причины на дэшборде.
Что трекать иначе, чем в обычной SaaS-команде
- Coverage, а не velocity. Покрытие тактик MITRE ATT&CK важнее закрытых тикетов. Команда, закрывшая на 40% больше тикетов, но потерявшая 3 тактики — регрессирует.
- Throughput с quality gate. Каждая инженерная метрика должна иметь «всё-ещё-полезен-через-90-дней» фильтр. Отключённые детекты не считаются.
- Ранние сигналы выгорания. Security-аналитики демонстрируют паттерны выгорания за 6–8 недель до увольнения — weekend-алерт-аки, прерывания отпуска, after-hours логины. Наша статья про burnout signals описывает пять паттернов, применимых здесь с ещё большим запасом.
- Cross-team patch lag. Security-команда не владеет деплоем, так что patch lag — joint-метрика с платформенной инженерией. Мерьте вместе или будете показывать пальцем.
Типичные pitfalls
- MTTR как единственный KPI — запаздывающий, реактивный, легко геймится сужением определения инцидента.
- Alert count как KPI — аналитики оптимизируют закрытие алертов, то есть закрывают без расследования.
- Coverage без quality — 1200 детектов, 800 молчащих, 400 шумных, ноль полезных.
- Путать время аналитика и время инженера — ваша «detection engineering команда» скорее всего делает 70% триажа. IDE-данные вам это покажут. Таймшит — нет.
- Мерить в Excel — ручной сбор метрик раз в месяц = 20 часов toil у SOC-менеджера, цифры протухли на 3 недели, половину аудита надо собирать заново.
Где вписывается PanDev Metrics
Для security engineering-команд релевантный срез — измерение инженерной половины SOC: detection-инженеры, SOAR-инженеры, tooling-инженеры. IDE heartbeat показывает разрыв между engineering-time и triage-time, детекция паттернов выгорания ловит ранний weekend-ack сигнал, а on-prem Docker/K8s деплой работает в air-gapped security-окружениях, где облачный SaaS просто не проходит.
Честный лимит
У нашего IDE-датасета разумная глубина по detection-инженерам и DevSecOps-ролям. Мы не имеем сильного сигнала по чисто аналитическим workflow — они живут в SIEM-консоли, а не в IDE. Для аналитической половины SOC вам всё ещё нужен SIEM-нативный productivity-инструмент. Кто говорит, что одна платформа закрывает и то, и другое — продаёт, а не измеряет.