У компании может быть зелёный dashboard ИБ и при этом совершенно красный бизнес-риск.

Это не парадокс. Это результат того, что мы часто измеряем активность подразделения вместо защищённости бизнеса.

Закрыто 97% критических уязвимостей. Звучит хорошо.

Но что находится в оставшихся 3%?

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

Та же проблема возникает с другими популярными показателями:

— доля активов под EDR; — охват MFA; — соблюдение SLA по устранению уязвимостей; — среднее время обнаружения; — процент успешных резервных копий; — количество сотрудников, прошедших обучение.

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

Средние значения особенно опасны.

97% охвата MFA могут скрывать нескольких администраторов без устойчивой аутентификации.

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

Успешные резервные копии — отсутствие проверенного восстановления ключевого сервиса.

Формальное согласование AI-проектов — неподконтрольные GenAI-сервисы, shadow AI и агенты с избыточными полномочиями.

На мой взгляд, одна из главных ошибок при построении отчётности ИБ — попытка сделать её максимально зелёной.

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

Это незрелая модель.

Задача CISO не в том, чтобы доказать, что команда выполнила максимальное количество мероприятий. Задача — своевременно показать руководству, где риск превышает допустимый уровень и какое решение требуется.

Я бы разделял метрики на четыре уровня.

Operational metrics показывают, выполняются ли процессы.

Control effectiveness metrics — работают ли меры защиты не на бумаге, а против реальных сценариев.

Risk metrics связывают угрозы с критическими сервисами, последствиями и риск-аппетитом.

Resilience metrics показывают, способен ли бизнес выдержать инцидент и восстановиться.

На board-level стоит выносить три измерения:

Exposure: какие критические сценарии остаются открытыми.

Readiness: способны ли мы обнаружить атаку, локализовать её и продолжить работу.

Residual risk: какой риск останется после внедрения мер и кто принимает его от имени бизнеса.

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

Например, не просто: «94% серверов защищены EDR».

А:

«Пять из семи серверов без EDR поддерживают критический производственный сервис. Отклонение сохраняется 74 дня. Необходимо выбрать: модернизировать платформу, внедрить компенсирующие меры или формально принять риск».

Второй вариант выглядит менее комфортно. Но именно он позволяет управлять.

Моя позиция проста:

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

А какую метрику ИБ, по вашему опыту, руководство чаще всего понимает неправильно: количество уязвимостей, SLA, охват средствами защиты, число инцидентов или что-то другое?