Работа с уязвимостями редко страдает от отсутствия сканирующих инструментов. Гораздо чаще процесс разваливается из-за неверных показателей, которыми служба ИБ отчитывается перед руководством. Пока сотрудники спорят о приоритетах, исправляют дефекты и стремятся к красивым графикам, киберпреступник ищет кратчайшую дорогу к критически важному активу. В таких условиях мониторинговая панель не обеспечивает защиту. Она создает лишь иллюзию безопасности.
В этом заключается основной парадокс работы с уязвимостями. Процедуры могут быть формально отлажены, автоматизированы и дорогостоящи, но при этом не отвечать на ключевой вопрос: насколько сложно злоумышленнику прямо сейчас получить доступ к жизненно важным системам. Когда метрики подменяют оценку реальных угроз, деятельность службы безопасности превращается в отчетную рутину.
Где кроются основные проблемы управления уязвимостями
Классическая схема кажется логичной: компания выявляет активы, сканирует инфраструктуру, анализирует найденные уязвимости, определяет приоритеты, исправляет проблемы и проверяет результаты. На бумаге всё выглядит правильно. Реально же процесс почти сразу сталкивается с давлением управленческой логики. Руководству требуются понятные цифры, ИТ-командам нужны четкие сроки и критерии успешности. Именно в этот момент появляются показатели, призванные упростить общую картину.
Упрощение само по себе не вредно – без него невозможно управлять сложной инфраструктурой. Проблемы начинаются, когда показатель превращается из инструмента в самоцель. Стоит сделать главным критерием количество исправленных уязвимостей, соблюдение сроков или снижение числа критических инцидентов, как команда быстро перестраивается под эти параметры. Люди начинают делать не то, что действительно снижает риски, а то, за что их оценивают.
Почему компании предпочитают неверные метрики
Ответ прост: неправильные показатели удобны и наглядны. Общее количество уязвимостей легко вписать в презентацию. Процент решенных за квартал вопросов приятно выделить зеленым цветом. Соблюдение сроков хорошо смотрится в ежемесячных отчетах. Такие данные не требуют сложных объяснений, не заставляют углубляться в архитектуру и не поднимают неудобные вопросы о непроверенных активах.
Настоящие риск-ориентированные показатели устроены сложнее. Они требуют учета многих факторов: доступность ресурса извне, его значимость для бизнеса, наличие работающих эксплойтов, признаки атак в реальных условиях, связи между системами и учетными записями. Обсуждение таких данных плохо умещается на один слайд и часто приводит к неприятному выводу: даже после большой работы реальная угроза могла снизиться незначительно.
Поэтому руководители часто выбирают не самые точные, а самые удобные для управления показатели. В краткосрочной перспективе такое решение выглядит разумным. В долгосрочной – организация получает опасную ситуацию: метрики показывают успех именно тогда, когда защита фактически ослабевает.
Ложный ориентир: общее количество уязвимостей
Панель с цифрами «всего найдено», «критических», «высоких», «средних» знакома всем, кто занимался этой темой. Такой экран создает иллюзию контроля. Виден объем работы, заметно движение к цели – значит можно демонстрировать прогресс. Однако сама сумма выявленных проблем мало говорит об уровне защиты. Она измеряет лишь масштаб проблем, а не вероятность успешной атаки.
Когда компания делает общее число уязвимостей ключевым показателем, команды начинают избегать сложных и ресурсоемких задач. Исправляются однотипные и простые проблемы, а реально опасные остаются без внимания. В результате сотни легких исправлений дают красивый отчет, хотя одна уязвимость у внешнего сервиса может принести атакующему больше пользы, чем десятки критических проблем в изолированном окружении.
Опасность стандартных сроков по CVSS
Идея кажется разумной: критические проблемы устранять за сутки, высокие – за три дня, средние – в течение месяца. Появляется дисциплина, понятны рамки, видно отставание. Однако шкала CVSS оценивает саму уязвимость, а не ее роль в конкретной инфраструктуре. Она не учитывает доступность сервиса из интернета, его связь с ключевыми процессами, наличие компенсирующих мер и реальную активность злоумышленников.
Поведение команды начинает искажаться: спорят о баллах на этапе разбора, переносят находки в исключения, ищут быстрые исправления, подгоняют риски под сроки. Формально компания соблюдает регламент, фактически лишь упорядочивает очередь задач. Между формальным и реальным состоянием – огромная разница, где часто и кроются успешные атаки.
Погрешность метода: процент закрытых уязвимостей
Когда в квартальных оценках появляется цифра типа «исправить 95% находок», уязвимости становятся бухгалтерскими единицами. Часть задач закрывают формально, часть маскируют временными мерами, часть переводят в исключения. Отчет выглядит хорошо, но инфраструктура не становится надежнее.
Здесь работает принцип Гудхарта: когда показатель становится целью, он перестает быть полезным. Для управления уязвимостями это особенно актуально. Если команда честно расширяет проверку, выявляет новые активы и старые проблемы, процент исправлений может ухудшиться. Если гонится за формальным закрытием задач – цифра растет. Получается парадокс, когда реальная работа выглядит хуже отчетной.
Главный критерий зрелости процесса
Сильный подход оценивают не по количеству исправленных записей, а по снижению реальных угроз. Вопрос должен звучать иначе: какие сценарии атак стали невозможны, какие узлы лишились быстрого пути компрометации, какие системные причины перестали порождать одни и те же проблемы. Именно такие показатели сегодня рассматривают как основу профессионального риск-менеджмента.
Автор: Игорь Панарин, руководитель направления анализа защищенности инфраструктуры ДИБ РАНХиГС
