Метрики безопасности: что измерять
«Как мы поймём, что программа безопасности работает?» — этот вопрос задаёт руководство, и он заслуживает честного ответа. «Мы стали безопаснее» — не ответ. Нужны конкретные показатели: они демонстрируют прогресс, сигнализируют о проблемах и обосновывают инвестиции.
В этой главе — какие метрики стоит собирать, чем полезная метрика отличается от красивой и как собрать из них дашборд.
Лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности. Далее по тексту — «лидер б езопасности».
Почему измерение важно
Без метрик вы летите вслепую.
Для лидера безопасности:
- Нет понимания, работают ли инициативы
- Нет понимания, на чём сосредоточить усилия
- Нет возможности расставлять приоритеты
- Нет способа показать прогресс
Для руководства:
- Нет обоснования затрат на безопасность
- Нет сравнения с отраслевыми ориентирами
- Нет видимости реального риска
- Безопасность воспринимается как чёрный ящик
Для команды:
- Нет целей для работы
- Нет признания за улучшения
- Нет понимания, что важно
- Безопасность ощущается как неблагодарный труд
Правильные метрики делают безопасность видимой, измеримой и управляемой.
Что отличает хорошую метрику
| Характеристика | Почему важна | Пример |
|---|---|---|
| Влечёт действие | С ней можно что-то сделать | «% систем с актуальными патчами» (можно улучшить) vs. «количество попыток атак» (не контролируется) |
| Измерима | Можно посчитать | «Среднее время устранения критических уязвимостей» vs. «уровень зрелости» (размыто) |
| Релевантна реальному риску | Связана с реальными угрозами | «% учётных записей с МФА» vs. «часов обучения по ИБ» (активность, не результат) |
| Сопоставима во времени | Можно отслеживать тренд | Одинаковое определение квартал от квартала |
| Понятна руководству | CEO понимает с первого взгляда | «3 критические уязвимости в продакшне» vs. «совокупный CVSS-балл 7,2» |
Метрики тщеславия vs. реальные метрики
Метрики тщеславия выглядят хорошо, но не влекут решений:
- Количество развёрнутых инструментов безопасности
- Суммарное число заблокированных фишинговых писем
- Часы проведённых тренингов
- Количество написанных политик
Реальные метрики показывают фактическое состояние защиты:
- Доля критических уязвимостей, закрытых в установленные сроки
- Кликабельность в симуляциях фишинга (и тренд)
- Время обнаружения и реагирования на инциденты
- Доля систем с актуальными обновлениями
Опережающие и запаздывающие индикаторы
Запаздывающие индикаторы говорят о том, что уже случилось:
- Количество инцидентов безопасности
- Обнаруженные утечки
- Уязвимости, найденные в продакшне
- Нарушения при аудите
Опер ежающие индикаторы предсказывают будущие проблемы:
- Доля проектов с моделированием угроз
- Покрытие тестами безопасности в CI/CD
- Разработчики, обученные по ИБ
- Завершённые проверки безопасности сторонних поставщиков
- Требования безопасности в спецификациях новых проектов
| Тип | Пример | Почему важен |
|---|---|---|
| Запаздывающий | 5 инцидентов за квартал | Показывает прошлые проблемы, но слишком поздно предотвращать |
| Опережающий | 80% PR-запросов с ревью безопасности | Предсказывает меньше инцидентов в следующем квартале |
| Запаздывающий | 12 уязвимостей найдено в продакшне | Ущерб уже возможен |
| Опережающий | 95% уязвимостей остановлено в CI/CD | Проблемы блокируются до продакшна |
Большинство компаний измеряют только запаздывающие показатели: их просто считать, но они говорят о вчерашнем дне. Опережающие требуют больше усилий для определения и отслеживания, но именно они двигают улучшения.
Сбалансированная система включает оба типа:
- Запаздывающие — для измерения результатов и до казательства ценности
- Опережающие — для предсказания трендов и своевременной корректировки курса
Основные метрики для лидера безопасности
Начните с этих базовых показателей. Они измеримы, влекут действие и значимы для руководства.
1. Метрики управления уязвимостями
| Метрика | Что измеряет | Целевое значение | Как собирать |
|---|---|---|---|
| Открытые критические/высокие уязвимости | Текущий уровень риска | 0 критических, менее 10 высоких | Сканер уязвимостей, система задач |
| Среднее время устранения (MTTR) | Скорость закрытия проблем | Менее 7 дней для критических, менее 30 — для высоких | Дата обнаружения → дата закрытия |
| Доля систем с обновлениями в срок | Актуальность патчей | Более 95% в рамках SLA | Инструмент управления обновлениями |
| Плотность уязвимостей | Проблемы на объём кодовой базы | Снижающийся тренд | SAST-инструменты (находки на KLOC) |
| Возраст старейшей уязвимости | Забытые проблемы | Менее 30 дней для критических | Запрос к системе задач |
Как рассчитать MTTR:
MTTR = Сумма (Дата закрытия − Дата обнаружения) для всех уязвимостей / Количество уязвимостей
Пример:
- Уязвимость А: обнаружена 1 января, закрыта 5 января = 4 дня
- Уязвимость Б: обнаружена 3 января, закрыта 10 января = 7 дней
- Уязвимость В: обнаружена 5 января, закрыта 8 января = 3 дня
MTTR = (4 + 7 + 3) / 3 = 4,67 дня
2. Метрики доступа и аутентификации
| Метрика | Что измеряет | Целевое значение | Как собирать |
|---|---|---|---|
| Охват МФА | Защита учётных записей | 100% для критических систем | Консоль администратора IdP |
| Учётные записи с МФА | Общее покрытие МФА | Более 95% всех учётных записей | Консоль администратора |
| Количество привилегированных учётных записей | «Разрастание» прав администратора | Минимально необходимое | Аудит IAM |
| Осиротевшие учётные за писи | Чистота доступа | 0 | Регулярные проверки доступа |
| Неудавшиеся попытки входа | Возможные атаки | Базовый уровень + оповещения при всплеске | Журналы аутентификации |
Пример дашборда охвата МФА:
Охват МФА по сервисам — март 2025
Сервис Пользователей С МФА Охват
──────────────────────────────────────────────────────
Яндекс 360 (почта) 45 45 100%
GitFlic / GitVerse 32 32 100%
Yandex Cloud (консоль) 12 12 100%
VK Teams (мессенджер) 45 43 96%
Битрикс24 / CRM 18 15 83% ← Нужны действия
Яндекс Трекер 38 38 100%
──────────────────────────────────────────────────────
Итого 190 185 97%
3. Метрики инцидентов
| Метрика | Что измеряет | Целевое значение | Как собирать |
|---|---|---|---|
| Количество инцидентов | Объём проблем | Снижение тренда | Трекер инцидентов |
| Среднее время обнаружения (MTTD) | Скорость обнаружения | Менее 1 часа для критических | Журналы инцидентов |
| Среднее время реагирования (MTTR) | Скорость действий | Менее 4 часов для критических | Журналы инцидентов |
| Среднее время устранения | Полное разрешение | Менее 24 часов для критических | Журналы инцидентов |
| Инциденты по уровням критичности | Распределение риска | Меньше критических со временем | Трекер инцидентов |
| Инциденты по категориям | Выявление паттернов | Определяет направления фокуса | Трекер инцидентов |
Пример тренда инцидентов:
Инциденты по уровням — 2024
I кв. II кв. III кв. IV кв. Тренд
───── ────── ─────── ────── ─────
Критические 2 1 1 0 ↓
Высокие 5 4 3 2 ↓
Средние 8 10 7 5 ↓
Низкие 12 15 11 8 ↓
───── ────── ─────── ──────
Итого 27 30 22 15 ↓
Примечания:
- Рост во II квартале связан с эксплуатацией уязвимостей
в популярной библиотеке
- Снижение в IV квартале — результат автоматизации патчинга
4. Метрики осведомлённости и обучения
| Метрика | Что измеряет | Целевое значение | Как собирать |
|---|---|---|---|
| Доля прошедших обучение | Охват обязательного обучения | 100% для обязательного | LMS или таблица учёта |
| Кликабельность при симуляции фишинга | Эффективность осведомлённости | Менее 5%, снижение тренда | Система симуляции (Phishman, Антифишинг, Kaspersky ASAP) |
| Доля сообщивших о фишинге | Бдительность сотрудников | Более 50% от симуляций | Система симуляции |
| Вопросы по безопасности | Вовлечённость | Рост тренда | Аналитика мессенджера |
| Доля ознакомленных с политиками | Осведомлённость о политиках | 100% | HR-система или форма |
Отслеживание симуляций фишинга:
Результаты симуляций фишинга — 2024
К ампания Отпр. Кликнули % Сообщили % сообщений
───────────────────────────────────────────────────────────────────────
Янв: Поддельный ЭДО 45 8 18% 12 27%
Мар: Сброс пароля ИТ 45 5 11% 18 40%
Май: Уведомление доставки 45 4 9% 22 49%
Июл: Соцсети 45 3 7% 25 56%
Сен: Счёт к оплате 45 2 4% 28 62%
Ноя: Конец года 45 2 4% 30 67%
───────────────────────────────────────────────────────────────────────
Тренд ↓ 14 п.п. ↑ 40 п.п.
Цель: кликабельность менее 5%, сообщаемость более 50% ✓
5. Метрики базовой гигиены безопасности
| Метрика | Что измеряет | Целевое значение | Как собирать |
|---|---|---|---|
| Охват защитой конечных точек | Безопасность устройств | 100% | Дашборд EDR/антивируса |
| Шифрование данных в покое | Защита данных | 100% для чувствительных данных | Аудит облачной консоли |
| Успешность резервного копирования | Возможность восстановления | Более 99% | Журналы системы резервного копирования |
| Охват менеджером паролей | Централизованное хранение реквизитов | 100% сотрудников | Отчёт из Пассворка или аналога |
| Оповещения об утечке секретов | Открытые реквизиты | 0 необработанных | CodeScoring, Solar appScreener |
| Уязвимости в зависимостях | Риск цепочки поставок | 0 критических, менее 10 высоких | CodeScoring, OWASP Dependency-Check |
Построение дашборда безопасности
Дашборд превращает сырые метрики в историю. Правильный дашборд отвечает на вопрос «как у нас дела?» с первого взгляда.
Принципы дизайна дашборда
1. Адаптируйте к аудитории:
- Дашборд для руководства: 5–7 ключевых метрик высокого уровня
- Операционный дашборд для команды ИБ: детальные метрики
- Дашборд для разработчиков: метрики кода и зависимостей
2. Показывайте тренды, а не только текущее со стояние:
- Стрелки, цвета или мини-графики для трендов
- Сравнение с предыдущим периодом
3. Связывайте с действиями:
- Ссылки на детали для расследования
- Выделяйте то, что требует внимания
- Делайте следующие шаги очевидными
4. Будьте честны:
- Не скрывайте плохие новости
- Объясняйте аномалии в контексте
- Не выбирайте «удобные» метрики
Шаблон дашборда для руководства
Краткий одностраничный дашборд со статусом ключевых метрик, трендами и фокусом на следующий квартал.
Все шаблоны — в библиотеке шаблонов.
Инструменты для дашборда
| Инструмент | Лучше всего для | Стоимость | Усилия |
|---|---|---|---|
| Таблицы (МойОфис, Яндекс Таблицы, Excel) | Быстрый старт, простые метрики | Бесплатно / в рамках лицензии | Низкие |
| Корпорати вная вики (Confluence self-hosted, Bookstack) | Наглядность, общий доступ | Бесплатно / СПО | Низкие |
| Grafana (open-source) | Технические метрики, временны́е ряды | Бесплатно (self-hosted) | Средние |
| OpenSearch / Kibana | Анализ журналов, SIEM-функции | Бесплатно (self-hosted) | Средние |
| MaxPatrol SIEM / KUMA | Корреляция событий, комплексный мониторинг | Коммерческий | Высокие |
| R-Vision / Security Vision | GRC, комплаенс, управление рисками | Коммерческий | Высокие |
Для малого бизнеса: начните с таблицы. Серьёзно. Хорошо ведущаяся таблица в Яндекс Таблицах эффективнее Grafana, за которой никто не следит.
Автоматизация сбора данных
Ручной сбор данных не масштабируется. Автоматизируйте, где возможно.
Для каждой метрики определите:
- Источник данных (консоль IdP, облачный аудит, SIEM, трекер задач)
- Ответственного за регулярно е обновление
- Периодичность обновления (еженедельно, ежемесячно)
Большинство источников (Яндекс 360, Yandex Cloud, VK Cloud, GitFlic) позволяют экспортировать данные через API или консоль администратора. Настройте регулярное извлечение данных или назначьте дежурного для еженедельного ручного сбора — на начальном этапе это лучше, чем сложная автоматизация.
См. также
- Отчётность и ROI — как доложить эти метрики руководству
- Получение поддержки руководства — зачем это нужно для поддержки
Что дальше
Вы знаете, что измерять и как собрать дашборд. Следующая глава — отчётность перед руководством: как докладывать о безопасности, ставить цели и переводить риск в деньги.