Как измерить кибербезопасность: KPI, KRI и ключевые метрики эффективности защиты

Можно ли измерить кибербезопасность одной цифрой? Разбираемся, какие KPI, KRI и метрики помогают оценить уровень защищённости, почему количество найденных уязвимостей ещё не говорит о безопасности и как построить систему измерения, которая отражает реальные киберриски.

 

 

 

 

 

 

1. 1. Введение
2. 2. Можно ли измерить кибербезопасность?
3. 3. KPI, KRI и метрики: в чём разница
4. 4. Какие метрики работают
   
   1. 4.1. Метрики обнаружения
   2. 4.2. Метрики реагирования
   3. 4.3. Управление уязвимостями
   4. 4.4. Метрики управления доступом
   5. 4.5. Метрики устойчивости
5. 5. Метрики по методике ФСТЭК России
6. 6. Почему хорошие цифры могут вводить в заблуждение
7. 7. Что меняет искусственный интеллект
8. 8. Как построить систему измерения безопасности
9. 9. Выводы

Введение

Бизнес всё чаще говорит об информационной безопасности на языке цифр. В 2025 году 56 % крупных российских организаций увеличили бюджеты на киберзащиту в среднем на 20–40 %, а интерес генеральных директоров к вопросам ИБ заметно вырос. При этом 75 % компаний уже собирают метрики ИБ.

 

Рисунок 1. Рост рынка информационной безопасности России, млрд рублей (Источник: TAdviser)

 

Однако во многих компаниях эффективность защиты до сих пор оценивают по количеству найденных уязвимостей, срабатываний SIEM или закрытых заявок. Эти метрики характеризуют работу лишь ИБ-подразделения, но не показывают общий уровень защиты.

Проблема хорошо видна по отраслевой статистике. Средняя оценка уровня кибербезопасности российских компаний по индексу F6 составляет 5,7 балла из 10, а почти у половины субъектов КИИ (47 %) защита информационных систем находится на критическом уровне. Получается, что большие вложения в информационную безопасность не гарантируют высокий уровень защищённости.

Возникает закономерный вопрос: можно ли вообще измерить кибербезопасность и какие показатели действительно помогают оценить уровень защиты?

Можно ли измерить кибербезопасность?

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

Вместо одной цифры международные стандарты предлагают оценивать три взаимосвязанные характеристики:

1. Уровень защищённости — способность организации противостоять актуальным угрозам с учётом архитектуры, настроек и действий персонала.
2. Зрелость процессов ИБ — насколько системно выстроены процессы управления безопасностью: есть ли регламенты, автоматизация, регулярная оценка рисков и контроль выполнения требований.
3. Эффективность работы службы ИБ — насколько быстро команда обнаруживает инциденты, реагирует на них и достигает установленных целевых показателей.

Эти характеристики не равнозначны. Большое количество обнаруженных инцидентов может говорить как об эффективном мониторинге, так и о высокой активности злоумышленников. Быстрое устранение уязвимостей не гарантирует высокую защищённость, если критически важные системы остаются без контроля.

В стандарте NIST SP 800-55 показатели разделяют на группы: внедрение мер защиты (Implementation), эффективность процессов (Effectiveness) и влияние на бизнес (Impact).

ISO/IEC 27004 описывает, как связать метрики с целями информационной безопасности, организовать сбор данных и использовать результаты для улучшения процессов.

CIS Controls Assessment Specification предлагает оценивать степень внедрения конкретных мер защиты, например многофакторной аутентификации, инвентаризации активов, контроля привилегированных учётных записей и управления обновлениями.

KPI, KRI и метрики: в чём разница

При обсуждении информационной безопасности термины KPI и KRI часто путают, хотя они решают разные задачи. Основные различия — в таблице.

 

Таблица 1. Основные типы показателей информационной безопасности

 

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

Аналитики Gartner рекомендуют использовать подход Outcome-Driven Metrics (ODM), который предлагает оценивать не объём работы, а её результат. Вместо вопроса «Сколько инцидентов мы обработали?» стоит спрашивать:

• снизилась ли вероятность успешной атаки;
• уменьшилось ли количество критических рисков;
• сократилось ли время восстановления после инцидентов;
• повысилась ли защищённость наиболее ценных информационных ресурсов.

Такой подход помогает оценивать не объём выполненной работы, а то, насколько информационная безопасность действительно снижает киберриски и поддерживает устойчивость бизнеса.

Какие метрики работают

По данным исследования State of DevOps Russia 2025, самыми популярными метриками информационной безопасности в российских компаниях стали время восстановления после инцидентов (40 %), количество нарушений политик безопасности (38 %), число уязвимостей высокого уровня опасности (37 %) и скорость реагирования на угрозы (37 %).

На практике показатели информационной безопасности объединяют в группы. Их выбор зависит от масштаба организации, отрасли, регуляторных требований и зрелости процессов. Ниже рассмотрим основные из них.

Метрики обнаружения

Эти метрики показывают, как долго злоумышленник может оставаться в сети незамеченным, и насколько эффективно система мониторинга выявляет атаки.

MTTD (Mean Time to Detect) — среднее время обнаружения инцидента. MTTD рассчитывают как среднее время между появлением первых признаков инцидента, которые могли быть обнаружены средствами мониторинга, и его фактическим обнаружением. Для расчёта используют все инциденты за выбранный период (месяц, квартал или год). Чем ниже MTTD, тем быстрее организация выявляет угрозы.

MTTD = Σ (Время обнаружения инцидента − Время появления первых признаков инцидента) / Количество инцидентов

По данным Mandiant, медианное время пребывания злоумышленника в инфраструктуре (Dwell Time) составляет 14 дней. Этот показатель отражает период от компрометации до обнаружения злоумышленника и не является MTTD, однако показывает, сколько времени атакующий может оставаться незамеченным.

Для наиболее важных информационных систем компании обычно устанавливают собственные целевые значения MTTD в зависимости от типа инцидента и требований бизнеса.

False Positive Rate (FPR) — доля ложноположительных срабатываний системы мониторинга.

FPR = (Количество ложноположительных срабатываний / Общее количество срабатываний) × 100 %

Высокий FPR увеличивает нагрузку на аналитиков SOC, приводит к усталости от оповещений (alert fatigue) и повышает риск пропустить реальную атаку.

В хорошо настроенных средах с качественными правилами корреляции стремятся удерживать FPR на уровне 5 % и ниже. Однако допустимое значение зависит от типа средств защиты и сценариев обнаружения. Например, для поисковых запросов (hunt queries) и проактивного поиска высокий процент шума может быть оправдан, тогда как для автоматических алертов порог должен быть строже.

Detection Coverage — метрика, показывающая, какую долю актуальных сценариев атак способны выявить средства мониторинга. Чаще всего её оценивают по покрытию матрицы MITRE ATT&CK — количеству техник, для которых настроены правила обнаружения или сценарии детектирования.

Стремиться к 100 % покрытию любой ценой нецелесообразно. Приоритетом должно быть выявление техник, наиболее вероятных для конкретной отрасли и инфраструктуры.

Метрики реагирования

После обнаружения инцидента задача службы ИБ — как можно быстрее остановить развитие атаки, а затем полностью устранить её последствия. Поэтому сначала оценивают скорость локализации, а затем — скорость полного реагирования.

MTTC (Mean Time to Contain) — среднее время локализации атаки.

MTTC = Σ (Время локализации всех инцидентов) / Количество инцидентов

Метрика показывает, насколько быстро команда изолирует скомпрометированные системы и предотвращает дальнейшее развитие атаки. В высокорегулируемых отраслях (финансы, КИИ, телеком) или при компрометации важных систем, критичных данных, внешнего периметра целевое MTTC — 15–60 минут. Для событий с минимальным риском — до 24 часов.

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

MTTR (Mean Time to Respond) — среднее время реагирования на инцидент, то есть промежуток времени от момента обнаружения проблемы (или получения оповещения) до первого подтверждённого действия команды (например, взятия тикета в работу или начала диагностики).

MTTR = Σ (Время устранения − Время обнаружения) / Количество инцидентов

MTTR не учитывает период, когда проблема уже существовала, но о ней ещё не было известно — это среднее время обнаружения инцидента (MTTD).

Целевые значения задают с учётом критичности инцидента. Логично, что на серьёзный сбой нужно реагировать быстрее, чем на мелкую неполадку. Для сервисов, влияющих на бизнес или взаимодействие с клиентами, целевое время — 30–60 минут. Для важных сервисов, где есть частичные обходные пути, ориентир — 1–4 часа.

Также на целевые значения влияет отрасль. В финансовых услугах из‑за прямых финансовых и регуляторных рисков стремятся к MTTR менее 30 минут для критических инцидентов. В здравоохранении для систем жизнеобеспечения требования ещё строже — реакция должна быть в течение считанных минут. В производстве допустимые сроки обычно составляют 1–6 часов, так как простой оборудования не всегда ведёт к мгновенному финансовому ущербу.

SLA выполнения — доля инцидентов, обработанных в установленный срок.

SLA = (Количество инцидентов, обработанных в срок / Общее количество инцидентов) × 100 %

Показатель помогает количественно оценить соблюдение регламентов и дисциплину исполнения задач. В идеале для критичных инцидентов целевой уровень соблюдения SLA должен быть не ниже 95 %.

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

 

Рисунок 2. Модель жизненного цикла реагирования на инциденты (Источник: Nist)

 

Управление уязвимостями

Большинство успешных атак используют уже известные уязвимости, поэтому управление ими остаётся одним из главных направлений оценки безопасности.

Patch SLA — доля уязвимостей, устранённых в установленный срок.

Patch SLA = (Количество уязвимостей, устранённых в срок / Общее количество уязвимостей) × 100 %

Метрика показывает эффективность процесса управления обновлениями. Обычно её рассчитывают отдельно по категориям уязвимостей, поскольку сроки их устранения различаются. Например, для уязвимостей с максимальным приоритетом SLA может составлять 24 часа, а для уязвимостей средней степени опасности — до 30 дней.

Patch SLA нужно считать не только в целом по компании, но и по сегментам инфраструктуры (периметр, критичные системы, тестовые среды), так как риски и допустимые сроки там разные.

Для определения приоритетов уязвимостей используют сразу две оценки: CVSS и EPSS.

CVSS (Common Vulnerability Scoring System) — международная система оценки серьёзности уязвимостей. Она учитывает технические характеристики уязвимости и её потенциальное влияние на конфиденциальность, целостность и доступность информации.

EPSS (Exploit Prediction Scoring System) — разработанная организацией FIRST модель машинного обучения, которая ежедневно оценивает вероятность эксплуатации конкретной уязвимости в течение ближайших 30 дней. Значение EPSS изменяется от 0 до 1 (или от 0 до 100 %): чем выше показатель, тем выше вероятность использования уязвимости в реальных атаках. О применении EPSS мы писали ранее.

Сочетая CVSS и EPSS, можно избежать слепой гонки за закрытием всех уязвимостей с высоким CVSS и сосредоточиться на тех, которые с наибольшей вероятностью будут эксплуатироваться. Например, уязвимость с CVSS 9.8 и EPSS 0.01 может быть менее срочной, чем уязвимость с CVSS 7.5 и EPSS 0.45 — именно её стоит закрыть в первую очередь.

 

Рисунок 3. Топ угроз за июль 2026 года (Источник: First)

 

Метрики управления доступом

Компрометация учётных записей остаётся одним из самых распространённых способов проникновения в инфраструктуру.

Метрика MFA Coverage — это доля учётных записей, защищённых многофакторной аутентификацией.

MFA Coverage = (Количество учётных записей, защищённых MFA / Общее количество учётных записей) × 100 %

Показатель обычно рассчитывают отдельно для всех пользователей и для привилегированных учётных записей (администраторы, сервисные аккаунты, DevOps). Для расчёта используют общее количество активных учётных записей и число тех, для которых многофакторная аутентификация включена.

Для привилегированных учётных записей целевое значение — 100 %. Для обычных пользователей целевой уровень — не менее 95–98 %. Оставшиеся 2–5 % могут приходиться на обоснованные исключения (технические учётные записи, где MFA неприменим), но они должны быть задокументированы.

Дополнительно оценивают, насколько инфраструктура находится под контролем службы ИБ. Для этого анализируют долю устройств с установленными EDR-агентами, процент учтённых активов и количество неуправляемых устройств.

Метрики устойчивости

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

Backup Success Rate — процент успешно выполненных заданий резервного копирования.

Backup Success Rate = (Количество успешно выполненных заданий резервного копирования / Общее количество заданий резервного копирования) × 100 %

Для наиболее важных систем целевое значение — не менее 99%. Допускаются лишь единичные сбои, которые оперативно устраняются. При этом высокий процент успешных резервных копирований сам по себе не гарантирует возможность восстановления. Нужно регулярно проводить тестовые восстановления, чтобы убедиться, что резервные копии пригодны для использования.

Recovery Time — среднее время восстановления систем из резервных копий.

Recovery Time = Σ (Время завершения восстановления − Время начала восстановления) / Количество восстановлений

Отдельно считают время для разных типов систем (БД, приложения, виртуальные машины) и сценариев (полное восстановление, восстановление отдельных файлов).

Целевое значение определяется RTO (Recovery Time Objective) — максимально допустимым временем простоя, установленным для каждой системы. Фактическое Recovery Time должно быть меньше или равно RTO. Если оно регулярно превышает RTO — компания не выполняет собственные требования и должна пересмотреть архитектуру или процессы.

Метрики по методике ФСТЭК России

В 2024 году ФСТЭК утвердила «Методику оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов КИИ». На тот момент документ носил рекомендательный характер. Однако с 1 марта 2026 года вступил в силу Приказ ФСТЭК №117, который ввёл обязательный расчёт КЗИ для государственных информационных систем (ГИС), государственных и муниципальных предприятий и учреждений, а также для субъектов КИИ. В ноябре 2025 года ФСТЭК утвердила обновлённую методику, которая заменила документ от мая 2024 года.

Оценку КЗИ проводят не реже одного раза в шесть месяцев. Внеплановую оценку выполняют после существенных изменений архитектуры информационной системы, при инцидентах с негативными последствиями либо по требованию регулятора.

Для коммерческих организаций, не относящихся к ГИС или КИИ, методика ФСТЭК по‑прежнему носит рекомендательный характер. При этом многие компании используют её как внутренний инструмент самооценки.

КЗИ — числовой показатель от 0 до 1. Он отражает, насколько организация соответствует минимально необходимому уровню защиты от актуальных угроз. Для расчёта оценивают 16 частных показателей, сгруппированных в четыре блока: организационные меры, технические меры, контроль и реагирование.

Результат интерпретируется так:

• КЗИ = 1 — минимально необходимый уровень защищённости обеспечен;
• 0,75 < КЗИ < 1 — имеются недостатки, повышающие риск реализации угроз;
• КЗИ ≤ 0,75 — уровень защищённости считается критическим.

Если показатель ниже 1, необходимо разработать план повышения защищённости и выполнить его до следующей плановой оценки.

Важно учитывать, что КЗИ оценивает выполнение мер защиты, но не показывает, насколько быстро организация обнаруживает атаки, реагирует на инциденты или устраняет уязвимости. Поэтому КЗИ обычно используют вместе с операционными метриками: MTTD, MTTR, Patch SLA.

Почему хорошие цифры могут вводить в заблуждение

Любую метрику необходимо рассматривать в контексте. Один и тот же показатель может свидетельствовать как об улучшении защиты, так и о проблемах в процессах. Например:

• большое количество обнаруженных уязвимостей может говорить не о слабой защите, а о хорошо организованном процессе поиска;
• небольшое число зарегистрированных инцидентов не означает отсутствия атак — возможно, организация обнаруживает лишь часть из них;
• низкое время реагирования не гарантирует высокий уровень защищённости, если инциденты обнаруживаются слишком поздно;
• большой поток событий в SIEM может быть следствием высокого уровня шума, а не качественного мониторинга;
• высокое покрытие инфраструктуры средствами защиты не означает, что они настроены корректно и действительно снижают риск.

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

• снижение MTTR может быть результатом поверхностного реагирования: инцидент формально закрыт, но его причина не устранена, поэтому атака может повториться;
• сокращение числа зарегистрированных инцидентов может означать не повышение безопасности, а ухудшение обнаружения — система мониторинга или специалисты SOC просто перестали выявлять часть атак;
• высокий процент устранённых уязвимостей может быть достигнут за счёт исправления менее опасных проблем, тогда как наиболее рискованные остаются без внимания.

Поэтому метрики следует анализировать в совокупности. Например, MTTD имеет смысл рассматривать вместе с MTTC и MTTR, а Patch SLA — одновременно с оценками CVSS и EPSS, а также с данными о фактической эксплуатации уязвимостей.

Что меняет искусственный интеллект

Искусственный интеллект смещает акцент с реагирования на уже произошедшие инциденты к их прогнозированию и предотвращению. Для этого используют предиктивные модели оценки защищённости (Predictive Security Metrics), которые анализируют большие объёмы данных и помогают выявлять потенциальные угрозы ещё до реализации атаки. В контролируемых условиях точность достигает 90 %, однако на практике она зависит от качества входных данных и динамики угроз.

ИИ помогает решать несколько практических задач:

1. Система анализирует инциденты в реальном времени, оценивает потенциальный ущерб и ранжирует события по критичности. Аналитик получает готовый список задач с расставленными приоритетами.
2. ИИ выявляет отклонения в поведении пользователей, сетевом трафике и работе систем, которые незаметны для традиционных правил корреляции. Можно обнаруживать атаки на ранних стадиях, ещё до того, как сработают сигнатуры.
3. Модели оценивают вероятность атаки с учётом известных уязвимостей, настроек защиты и актуальных данных о киберугрозах. Вместо статического рейтинга рисков появляется динамическая оценка, которая автоматически пересчитывается по мере изменения исходных данных.
4. Некоторые платформы используют генеративный ИИ, чтобы показать, почему изменились показатели. Например, рост MTTD может быть связан с увеличением числа ложноположительных срабатываний, а снижение количества критических уязвимостей — с установкой обновлений.
5. ИИ помогает отличать реальные угрозы от фонового шума, уменьшая False Positive Rate и снижая нагрузку на аналитиков SOC.

Attack Path Analysis (APA) моделирует возможные пути развития атаки в инфраструктуре. В отличие от традиционного сканирования, которое показывает отдельные уязвимости, APA позволяет увидеть взаимосвязи между ними и определить наиболее вероятные сценарии компрометации. Похожий подход использует проект MITRE ATT&CK Attack Flow, который формализует последовательность действий злоумышленника при реализации атаки.

Continuous Security Controls Validation (CSCV) — это подход к непрерывной проверке эффективности средств защиты. Вместо периодических аудитов организация постоянно контролирует, насколько эффективно работают EDR, межсетевые экраны, DLP и другие средства защиты. Для этого часто используют BAS-платформы (Breach and Attack Simulation), которые безопасно моделируют действия злоумышленников и проверяют, способны ли существующие механизмы защиты обнаружить и остановить атаку. Симуляции часто привязывают к MITRE ATT&CK для объективности.

Одним из примеров подобных решений на российском рынке является Индекс кибербезопасности F6. Он собирает сигналы по внешнему периметру, цифровым рискам и угрозам и показывает инфраструктуру глазами злоумышленника. Индекс анализирует почтовые системы, DNS, SSL, публичные IP и внешние упоминания, а затем формирует отчёт с конкретными зонами риска. Подробнее о том, как формируется Индекс кибербезопасности F6, мы рассказывали в отдельном материале.

Несмотря на широкие возможности ИИ, окончательные решения по реагированию на инциденты и оценке рисков по-прежнему принимают люди. ИИ помогает быстрее анализировать большие объёмы данных и расставлять приоритеты, но не заменяет экспертную оценку.

Как построить систему измерения безопасности

Процесс можно разбить на семь шагов.

1. Определите бизнес-цели

Сначала необходимо понять, что именно должна защищать служба ИБ. Для одной организации критична непрерывность сервисов, для другой — защита персональных данных, для третьей — соответствие требованиям регуляторов. Метрики должны быть связаны с этими задачами.

2. Определите ценные активы и основные риски

Не все информационные системы одинаково важны для бизнеса. На этом этапе определяют наиболее важные информационные ресурсы, возможные сценарии атак и риски, которые способны привести к максимальному ущербу. Для них в дальнейшем выбираются ключевые показатели.

3. Сформулируйте цели по SMART

Цели должны быть конкретными, измеримыми, достижимыми, релевантными и ограниченными по времени. Например: сократить среднее время обнаружения инцидентов на 30 % к концу года. Такие цели необходимо увязать со стратегией организации и внутренними документами по информационной безопасности.

4. Выберите KPI и KRI

После определения целей можно подобрать показатели эффективности и риска. KPI позволяют оценивать работу процессов и подразделения ИБ, KRI — отслеживать изменение уровня риска и своевременно выявлять негативные тенденции. Важно, чтобы каждая метрика была связана с конкретной управленческой задачей. Для каждой метрики желательно определить владельца, целевое значение и периодичность контроля.

5. Определите источники данных и автоматизируйте сбор

Метрики должны формироваться автоматически, а не вручную. Источниками данных обычно становятся SIEM, EDR, системы управления уязвимостями, CMDB, IAM, журналы событий, средства резервного копирования и другие инструменты защиты.

6. Настройте отчётность для разных уровней управления

Разным руководителям нужны разные показатели. Специалистам SOC важны MTTD и MTTR, руководителю службы ИБ — динамика рисков и выполнение KPI, а топ-менеджменту — влияние киберрисков на бизнес, выполнение требований регуляторов и эффективность инвестиций. Поэтому отчётность должна различаться по уровню детализации и периодичности.

7. Регулярно пересматривайте систему метрик

По мере изменения инфраструктуры, угроз и бизнес-задач показатели также должны меняться. Если метрика перестала помогать принимать решения, её следует пересмотреть или заменить.

Набор ключевых метрик зависит от бизнес-модели и основных рисков. Интернет-магазин в первую очередь контролирует доступность сайта, MTTD, MTTR, защиту платёжных данных и долю пользователей с MFA. Простой сайта или компрометация учётных записей напрямую влияют на продажи.

Промышленное предприятие делает ставку на непрерывность технологических процессов, своевременное обнаружение атак на АСУ ТП, выполнение требований регуляторов, Patch SLA и показатель текущего состояния защищённости (КЗИ).

Финансовая организация уделяет особое внимание скорости обнаружения и реагирования на инциденты, защите платёжной инфраструктуры, управлению уязвимостями и соблюдению требований Банка России.

Для SaaS-провайдера важны доступность сервиса, MTTD, MTTR, своевременное устранение уязвимостей, защита клиентских данных и контроль безопасности процесса разработки.

Выводы

Эффективная система измерения кибербезопасности сочетает KPI, KRI и технические метрики, связывая их с бизнес-целями, уровнем риска и требованиями регуляторов. Показатели должны регулярно пересматриваться по мере изменения инфраструктуры, угроз и задач организации.

Информационная безопасность уходит от оценки количества выполненных действий к оценке их результата. Всё большее значение приобретают метрики, которые показывают, насколько компания способна предотвращать атаки, снижать киберриски и быстро восстанавливать работу после инцидентов. Такие показатели помогают принимать обоснованные управленческие решения и объективно оценивать эффективность инвестиций.

Начните с малого: выберите три — пять ключевых метрик, свяжите их с бизнес-целями и настройте автоматический сбор. Остальное добавится по мере роста зрелости процессов.