«У нас всё под защитой: есть межсетевой экран, антивирус и DLP» — примерно так отвечают на вопрос «как у вас с безопасностью?» в половине компаний. Это не ответ, это перечисление покупок. Проблема в том, что количество установленных средств защиты не связано с реальной устойчивостью: систему с полным комплектом сертифицированных СЗИ ломают за вечер из-за одного забытого VPN-аккаунта без второго фактора. Ниже — про то, как перейти от «у нас стоит» к измеримым величинам, которые можно сравнить с прошлым месяцем и защитить перед руководителем.
Что на самом деле значит «уровень защиты»
Прежде чем считать что-либо, полезно развести три разных вопроса, которые обычно смешивают в один:
- Соответствие. Выполняем ли мы требования регулятора (152-ФЗ, приказы ФСТЭК №17 и №21, приказ №117 для значимых объектов КИИ, ГОСТ Р 56939 для процессов разработки).
- Устойчивость. Насколько дорого и долго атакующему обходится путь до наших данных.
- Наблюдаемость. Увидим ли мы атаку, когда она начнётся, и успеем ли что-то сделать.
У каждого слоя свои метрики. Если измерять только первый, получится красивый отчёт и полная неожиданность в момент инцидента.
Метрики соответствия: нужны, но о защите почти ничего не говорят
Это база — процент выполненных контролей из перечня, доля АРМ с обязательным ПО, наличие утверждённых документов, доля систем, прошедших оценку эффективности. Считать их надо, хотя бы потому, что без них не пройти проверку и не подписать договор с крупным заказчиком.
Но держите в голове простую вещь: контроль, закрытый документом, и контроль, работающий в проде, — разные вещи. «Парольная политика утверждена» и «в домене реально включена блокировка после пяти попыток» — это одна строка в отчёте и два совершенно разных состояния инфраструктуры. Поэтому соответствие считаем, но решения о бюджете принимаем по следующей группе.
Технические метрики гигиены: то, что собирается за неделю
Хорошая метрика обладает тремя свойствами: её можно посчитать автоматически, у неё есть понятный знаменатель, и на неё можно повлиять инженерными действиями. Вот набор, который закрывает большую часть риска:
- Patch latency — медианное время от публикации обновления до установки. Считайте отдельно для систем, доступных из интернета, и для внутренних. Второй важный срез — сколько критичных обновлений старше 30 дней всё ещё не установлено.
- Покрытие инвентаризацией. Доля активов, которые видны сканеру и CMDB. Это знаменатель для всех остальных процентов: если 20% машин неизвестны, любые «95% пропатчено» — самообман.
- Доля систем с MFA для удалённого и привилегированного доступа. Здесь цель простая и достигаемая — 100%, без промежуточных «у нас 60%, но мы работаем».
- Количество постоянных привилегированных учётных записей и средний срок жизни привилегированной сессии. Метрика хорошо реагирует на внедрение PAM и JIT-доступа.
- Секреты в коде. Число находок на 1000 коммитов и, важнее, медианное время от находки до отзыва ключа. Найти секрет в репозитории легко, дорого — не отозвать его месяцами.
- Проверенные резервные копии. Доля систем, восстановление которых тестировали за последние 90 дней, и фактический RTO из последнего теста. Наличие бэкапа — не метрика, метрика — успешное восстановление.
- Доля уязвимостей с известным эксплойтом, закрытых за N дней. Вот это уже ближе к реальному риску, чем общее число «критичных» находок в сканере.
Приоритизация уязвимостей: почему CVSS 9.8 — не приговор
Классическая ошибка — строить приоритет по одной базовой оценке CVSS. Она описывает серьёзность последствий, но не вероятность того, что кто-то придёт эксплуатировать именно эту уязвимость в вашем контуре. Уязвимость с CVSS 9.8 в компоненте, до которого снаружи не дотянуться, месяцами ждёт патча, а «семёрка» в публичном VPN ломается в первые сутки после публикации PoC.
Что помогает принимать решения:
- EPSS (оценка вероятности эксплуатации в ближайшие 30 дней от FIRST) — полезный второй фильтр;
- каталог известных эксплуатируемых уязвимостей CISA KEV — если CVE там, срок реакции измеряется часами и сутками, а не неделями;
- БДУ ФСТЭК — для российской специфики и отчётности удобно сверяться с банком данных угроз, там же публикуются бюллетени по отечественному ПО;
- достижимость уязвимого компонента из сети и наличие публичного эксплойта.
Отсюда рабочая метрика: доля уязвимостей, для которых есть подтверждённая эксплуатация в дикой природе, закрытых в течение 72 часов. Она честнее, чем средний CVSS по парку систем.
Метрики обнаружения и реагирования
Это то, что отличает «у нас есть SIEM» от «мы видим атаку». Считайте:
- MTTD (время до обнаружения), MTTA (до взятия в работу) и MTTR (до локализации). Считайте по медиане, а не по среднему — один инцидент на две недели развалит любую среднюю.
- Покрытие логированием. Доля активов и сервисов, отправляющих события в SIEM, и наличие обязательного минимума источников: контроллер домена, EDR, VPN, прокси, облачные подписки, системы CI/CD.
- Доля алертов, разобранных в SLA. Если очередь не разбирается, детект не существует.
- Доля правил, которые не тюнили ни разу — косвенный, но очень говорящий индикатор качества детекта.
- Результаты учений. Purple team или хотя бы аккуратно проведённый внутренний сценарий: сколько шагов атаки зафиксировано, сколько осталось незамеченным. Здесь важны цифры, а не «в целом неплохо».
Базовая линия по MTTD у большинства средних компаний — сутки и больше, и это нормально как отправная точка. Ориентир, к которому имеет смысл идти, — часы для критичных сценариев; обещать минуты без круглосуточного SOC смысла нет.
Проверка на прочность: метрики, которые нельзя получить из дашборда
Часть оценок требует, чтобы кто-то пришёл и попробовал. Раз в год-полтора — внешний пентест, регулярно — внутренние учения. Из них вытаскивайте измеримое:
- Сколько независимых путей до критичных данных нашли (и сколько из них — повтор прошлогодних).
- Время от начала работ до первого обнаружения вашими силами.
- Сколько времени заняло восстановление после сценария с шифровальщиком — по факту, а не по плану.
- Уложились ли в целевые RTO/RPO на учениях по отказоустойчивости.
Три ловушки, в которые попадают все
- Метрика без знаменателя. «Обнаружили 300 угроз» ничего не значит без ответа на вопрос, сколько их было и сколько пропустили.
- Закон Гудхарта. Как только число становится целью, его начинают улучшать в обход смысла: закрывать тикеты «не уязвимость», переводить алерты в «информационные», сокращать MTTR удалением сложных правил.
- Метрики-декорации. «Уровень осведомлённости сотрудников — 92%» из теста, который все прошли с третьей попытки, — это не осведомлённость, это настойчивость.
Минимальный стартовый набор
Если начинать с нуля, я бы взял десять показателей и считал их ежемесячно:
- доля активов, известных инвентаризации;
- медианный patch latency для интернет-доступных систем;
- доля закрытых уязвимостей из KEV за 72 часа;
- доля систем с MFA на удалённом и привилегированном доступе;
- число постоянных привилегированных учётных записей;
- медианное время отзыва утёкшего секрета;
- доля систем с успешно проверенным восстановлением за 90 дней;
- покрытие ключевых источников логов в SIEM;
- MTTD и MTTR по критичным сценариям;
- число критичных повторных находок по итогам последнего пентеста.
Как показывать это руководству
Дашборд из сорока графиков не читает никто. Работает структура из трёх блоков: что улучшилось с прошлого месяца, что горит прямо сейчас, какое решение или бюджет нужны. И главное — динамика. Абсолютное значение метрики почти бесполезно без базовой линии: «MTTD 8 часов» звучит по-разному, если в январе было 40 часов, а если 2 часа — это провал.
Короткий вывод
Уровень защиты измеряется не количеством СЗИ, а временем: сколько живёт известная уязвимость, сколько проходит от атаки до обнаружения, сколько занимает восстановление. Эти три числа покрывают большую часть реального риска и, что важно, каждое из них инженер может сдвинуть своими руками — без новой волшебной кнопки из презентации вендора. Начните с инвентаризации и patch latency: без первого все проценты врут, без второго всё остальное просто не успевает сработать.
