Зелёный дашборд, красный риск: почему метрики ИБ могут обманывать руководство

На заседании руководства CISO показывает отчёт: критические уязвимости закрываются в срок, охват MFA растёт, резервные копии создаются, сотрудники проходят обучение, большинство показателей подсвечено зелёным.

Выглядит убедительно.

Но за этим dashboard может скрываться привилегированная учётная запись без достаточной защиты, не протестированное восстановление критического сервиса, доступный из интернета legacy-компонент или единственный attack path, ведущий к остановке бизнеса.

Проблема не в том, что цифры неверны. Проблема в том, что они отвечают не на тот вопрос.

Большинство метрик ИБ показывают операционную активность подразделения. Руководству же нужно понимать состояние бизнес-риска.

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

Объём данных о безопасности растёт быстрее, чем способность организации интерпретировать их.

Сканеры находят тысячи уязвимостей. SIEM обрабатывает миллионы событий. IAM формирует отчёты по учётным записям. AppSec считает дефекты, SOC — инциденты и время реакции, GRC — выполнение контролей и статус корректирующих мероприятий.

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

В результате dashboard становится всё подробнее, но не обязательно полезнее.

Это особенно опасно сейчас, когда внешние ориентиры всё сильнее смещаются от подсчёта мер защиты к управлению результатами и риском. NIST CSF 2.0 рассматривает кибербезопасность через высокоуровневые outcomes и подчёркивает её связь с корпоративным управлением рисками. AI RMF использует логику Govern, Map, Measure и Manage, то есть измерение должно быть встроено в контекст, ответственность и принятие решений, а не существовать отдельно. (NIST Publications⁠)

При этом реальные атаки продолжают использовать уязвимости, украденные учётные данные, внешние сервисы и цепочки поставок. В отчёте Verizon DBIR за 2026 год эксплуатация уязвимостей названа ведущей точкой входа в подтверждённые компрометации. CISA, в свою очередь, рекомендует использовать каталог реально эксплуатируемых уязвимостей KEV как фактор приоритизации, а не устранять дефекты только по формальной критичности CVSS. (cisa.gov⁠)

Главный вывод прост: считать выполненные действия недостаточно. Нужно измерять, какой риск этими действиями действительно изменён.

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

Например:

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

Для операционного руководителя это полезная информация. Она показывает дисциплину процесса, загрузку команд и соблюдение правил.

Но для CEO или совета директоров этот процент почти ничего не говорит без контекста.

Какие 4% остались?

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

И наоборот: среди закрытых 96% могут преобладать уязвимости в изолированных тестовых средах, на низкокритичных рабочих местах или в системах, не связанных с ключевыми бизнес-процессами.

Зрелая метрика должна учитывать не только количество и CVSS, но и:

Правильный вопрос звучит не так:

Сколько критических уязвимостей мы закрыли?

А так:

Какие реалистичные пути атаки к критическим бизнес-сервисам остаются открытыми и что необходимо сделать, чтобы их разорвать?

Среднее значение удобно для презентации и опасно для управления риском.

Средний уровень покрытия MFA может составлять 97%. Но среди оставшихся 3% могут оказаться сервисные учётные записи, администраторы legacy-систем или внешние подрядчики с удалённым доступом.

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

Средний результат восстановления может выглядеть приемлемо. Но восстановление наиболее критичного бизнес-сервиса могло никогда не проверяться в условиях полной недоступности основной инфраструктуры.

Среднее время обнаружения инцидента может снижаться. Но организация может быстро обнаруживать массовый malware и по-прежнему не видеть использование легитимных токенов, session cookies или привилегированных идентичностей.

Риск редко распределяется равномерно. Он концентрируется в исключениях, зависимостях и точках, где одновременно сходятся высокая критичность, доступность для атаки и недостаточная устойчивость.

Поэтому зрелый dashboard обязан показывать не только среднее значение, но и:

SLA нужен. Без него процессы быстро превращаются в бесконечные согласования и необязательные рекомендации.

Но SLA — это характеристика процесса, а не доказательство защищённости.

Можно устранять уязвимости в установленный срок, но при этом неправильно определять приоритеты.

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

Можно вовремя пересматривать доступы, но не видеть неуправляемые machine identities.

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

Можно считать долю AI-систем, прошедших оценку, но не измерять:

SLA отвечает на вопрос: выполнили ли мы действие вовремя?

Риск-метрика должна отвечать на другой вопрос: достаточно ли этого действия, чтобы изменить вероятность или последствия значимого сценария?

Фраза «охват EDR составляет 94%» выглядит конкретно, но без дополнительных данных может вводить в заблуждение.

Нужно понимать:

Сам по себе процент не создаёт управленческого смысла.

Смысл появляется, когда метрика содержит:

текущее значение → допустимый порог → динамику → бизнес-контекст → владельца → решение.

Например, вместо:

94% серверов защищены EDR.

Полезнее показать:

Пять из семи серверов без EDR поддерживают критический производственный сервис. Отклонение сохраняется 74 дня из-за несовместимости legacy-ОС. Риск превышает утверждённый порог. Варианты решения: модернизация платформы, сегментация с дополнительным мониторингом либо формальное принятие риска владельцем сервиса.

Вторая формулировка не такая красивая. Зато она позволяет управлять.

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

Это показатели ежедневной деятельности:

Эти данные нужны руководителям функций и операционным командам. Но выносить их на board-level без интерпретации не стоит.

Здесь измеряется не наличие контроля, а его фактическая эффективность:

Контроль может быть внедрён формально, но не обеспечивать ожидаемый результат. Этот уровень помогает увидеть разрыв между compliance и реальной защищённостью.

На этом уровне технические отклонения связываются с бизнес-сценариями:

Именно здесь ИБ начинает говорить на языке руководства.

Предотвратить все атаки невозможно. Поэтому верхний уровень должен показывать способность компании продолжать работу и восстанавливаться:

Резервная копия — ещё не устойчивость. Установленный контроль — ещё не эффективность. Закрытая уязвимость — ещё не устранённый путь атаки.

Для руководства я бы ограничил dashboard тремя основными измерениями.

При этом dashboard не должен превращаться в светофор без пояснений. Красный цвет — не обвинение подразделения. Это сигнал о необходимости решения.

Зелёный цвет тоже не должен означать «риск отсутствует». Он должен означать: риск находится в пределах согласованного аппетита, меры проверены, а остаток осознанно принят владельцем.

Начать стоит не с выбора визуализации и не с обсуждения набора KPI.

Для каждого показателя нужно спросить:

Какое решение изменится в зависимости от его значения?

Типовые решения:

Если показатель не влияет ни на одно решение, возможно, он нужен операционной команде, но не руководству.

Не «у нас 18 тысяч уязвимостей», а:

Нужно понимать, какие системы, данные, идентичности, модели, интеграции и поставщики участвуют в сценарии и какие меры реально снижают его вероятность или последствия.

У каждой значимой метрики должны быть:

Руководству важна не только текущая точка, но и траектория:

SOC, AppSec, инфраструктура, GRC, CISO, risk committee и совет директоров не должны получать один и тот же dashboard.

Едиными должны быть модель риска и источники данных. Уровень детализации и язык решений — разными.

Я не считаю количество закрытых уязвимостей, выполненных проверок или внедрённых контролей достаточным доказательством зрелости ИБ.

Зрелость начинается там, где компания способна показать связь:

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

Хорошая метрика не обязана быть удобной и успокаивающей.

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

Опасность зелёного dashboard не в цвете. Она возникает, когда организация принимает отсутствие красных индикаторов за отсутствие риска.

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

У руководства должно оставаться не ощущение контроля, а понимание экспозиции, готовности и остаточного риска.

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

Подписывайтесь на мой ТГ канал: @ib_decisions