Управление уязвимостями редко рушится из-за нехватки сканеров. Намного чаще процесс ломают показатели, по которым команда отчитывается перед руководством. Пока специалисты спорят о приоритетах, закрывают задачи и рисуют красивую динамику, злоумышленник ищет самый короткий путь к важной системе. В такой ситуации дашборд не защищает. Дашборд успокаивает.
В этом и состоит главный парадокс управления уязвимостями. Процесс может быть формально зрелым, хорошо автоматизированным и дорогим, но плохо отвечать на единственный действительно важный вопрос: насколько трудно атакующему добраться до критичных активов прямо сейчас. Когда метрики подменяют риск, безопасность начинает работать на отчетность.
Ниже речь пойдет о том, что можно назвать темными паттернами в управлении уязвимостями. Термин пришел из продуктового дизайна, где так называют приемы, подталкивающие человека к выгодному для системы поведению. В этой теме похожий механизм работает через целевые показатели, регламентные сроки, дашборды и отчетные формы. Они тоже задают поведение, только подталкивают уже не пользователя, а команду и руководителя.
Где на самом деле ломается управление уязвимостями
Классическая схема выглядит разумно. Компания находит активы, сканирует инфраструктуру, собирает сведения об уязвимостях, расставляет приоритеты, устраняет проблемы и проверяет результат. На бумаге все смотрится хорошо. На практике процесс почти сразу попадает под давление управленческой логики. Бизнесу нужны понятные цифры, руководству нужен наглядный прогресс, ИТ-командам нужны сроки и ясные критерии успеха. В этот момент и появляются метрики, которые должны упростить картину.
Упрощение само по себе не вредно. Без него нельзя управлять большой инфраструктурой. Проблема начинается там, где показатель перестает быть средством и становится целью. Стоит сделать главным ориентиром число закрытых уязвимостей, соблюдение сроков или снижение общего количества критичных находок, и команда быстро приспосабливается именно к этим метрикам. Люди начинают делать не то, что реально снижает риск, а то, за что их оценивают.
Поэтому зрелость процесса нельзя мерить только количеством сканеров, отчетов и регламентов. Зрелость видна в другом: умеет ли организация отличать удобную работу от полезной, понимает ли разницу между снижением шума и снижением риска, не путает ли безопасность с бухгалтерией по CVE.
Почему бизнесу так нравятся неправильные метрики
Ответ неприятно прост. Неправильные метрики понятны и удобны. Общее число уязвимостей легко вынести на слайд. Долю закрытия за квартал приятно покрасить в зеленый. Соблюдение сроков хорошо смотрится в ежемесячном отчете. Такие показатели не требуют длинных объяснений, не заставляют разбираться в архитектуре и не поднимают неудобный вопрос о том, какие активы вообще не попали в поле зрения.
Настоящие риск-метрики устроены сложнее. Они требуют контекста: внешняя доступность актива, его ценность для бизнеса, наличие рабочего эксплойта, признаки эксплуатации в реальных атаках, связи с другими сегментами, учетными записями и доверительными отношениями. Такой разговор хуже помещается в одну диаграмму и часто заканчивается неприятным выводом: даже после большого объема работы реальный путь атаки мог сократиться совсем немного.
Поэтому многие руководители тяготеют не к той системе показателей, которая точнее, а к той, которая удобнее для управления. На короткой дистанции решение выглядит разумным. На длинной дистанции организация получает опасную вещь: метрики, которые показывают успех именно тогда, когда защита начинает работать хуже.
Ловушка первая: общее количество уязвимостей
Дашборд с числами «всего найдено», «критические», «высокие», «средние» знаком каждому, кто работал с этой темой. Такой экран создает ощущение контроля. Видно объем работы, видно движение вниз, значит можно показать прогресс. Но сама по себе сумма находок почти ничего не говорит о защищенности. Она измеряет размер массива проблем, а не вероятность успешной атаки.
Как только организация делает общую численность уязвимостей главным индикатором, команды начинают убирать из очереди самые дорогие и трудоемкие задачи. Закрываются однотипные и удобные проблемы, а сложные и действительно опасные случаи остаются в хвосте. В итоге сотни простых исправлений дают прекрасный отчет, хотя один внешний сервис с уязвимостью среднего уровня по шкале CVSS приносит атакующему куда больше пользы, чем десятки высоких уязвимостей в изолированном тестовом контуре.
Общее число уязвимостей полезно как рабочий показатель загрузки. Но превращать его в главный признак безопасности нельзя. Такой счетчик не различает шум и короткий маршрут к критичной системе. Злоумышленнику не важно, сколько записей лежит в таблице. Злоумышленнику важно, существует ли достижимый путь к нужной цели.
Ловушка вторая: сроки по CVSS без контекста
Идея выглядит разумно: критические уязвимости закрываем за сутки, высокие за трое суток, средние за месяц. Появляется дисциплина, есть единая рамка, понятно, кто выбился из графика. Но шкала CVSS оценивает свойства самой уязвимости, а не ее роль в конкретной инфраструктуре. Шкала не знает, смотрит ли сервис в интернет, связан ли актив с ключевым бизнес-процессом, прикрыт ли сегмент компенсирующими мерами и используется ли проблема в реальных атаках.
Дальше поведение начинает искажаться. Команда спорит за баллы на этапе разбора, переносит часть находок в исключения, ищет самые быстрые исправления, подгоняет приоритет под срок, а не срок под реальный риск. Формально организация соблюдает регламент. По сути организация просто наводит порядок в очереди задач. Между этими состояниями огромная разница, и именно в этой разнице часто живут успешные атаки.
Хорошие сроки возможны только тогда, когда CVSS перестает быть единственной осью принятия решений. Минимальный набор контекста обязателен: внешний периметр, критичность актива для бизнеса, признаки эксплуатации, компенсирующие меры, достижимость из других сегментов и цена компрометации. Без такого слоя регламент превращается не в инструмент снижения риска, а в инструмент самоуспокоения.
Ловушка третья: доля закрытых уязвимостей как цель команды
Как только в квартальную оценку попадает цифра вроде «закрыть 95% находок», уязвимости превращаются в бухгалтерские единицы. Дальше процесс предсказуем. Часть карточек закрывают формально, часть маскируют временными мерами, часть переводят в исключения, а часть исправляют без устранения первопричины. Отчет выходит красивым, но инфраструктура не становится заметно труднее для атакующего.
Здесь работает закон Гудхарта: когда показатель становится целью, показатель перестает быть хорошим показателем. Для управления уязвимостями вывод особенно неприятный. Если команда честно расширяет покрытие, находит новые активы и вытаскивает из тени старые проблемы, доля закрытия может ухудшиться. Если команда гонится только за формальным закрытием уязвимостей, цифра улучшается. Получается перевернутый мир, где честная работа выглядит хуже удобной.
Поэтому сильный процесс оценивают не по доле исчезнувших записей, а по доле снятого риска. Вопрос должен звучать иначе: какие реальные сценарии атаки стали невозможны после работы команды, какие критичные узлы лишились короткого маршрута компрометации, какие повторяющиеся причины перестали воспроизводить одну и ту же проблему в разных местах.
Ловушка четвертая: статический дашборд без времени
Отчет, в котором уязвимости показаны только как срез на сегодня, легко вводит в заблуждение. Он не отвечает на важный вопрос: как долго проблема живет в системе. Между уязвимостью, найденной вчера, и уязвимостью, которая висит на внешнем сервисе полгода, колоссальная разница. Но в статичной витрине обе записи могут выглядеть одинаково.
Возраст уязвимости часто важнее ее бумажной критичности. Если проблема долго остается без движения, причина обычно лежит не в нехватке времени, а в системном дефекте процесса. Где-то размыта зона ответственности, где-то актив не привязан к владельцу, где-то бизнес не понимает цену откладывания, а где-то команда раз за разом обходит неудобный фронт работ. Без временного измерения такие сигналы теряются.
Управление уязвимостями вообще нельзя воспринимать как набор статичных карточек. Процесс живет во времени. Значение имеют не только количество и приоритет, но и срок жизни проблемы, скорость реакции, повторное появление, разница между временной мерой и корневым исправлением. Без этой динамики дашборд работает как витрина, а не как приборная панель.
Ловушка пятая: «критических уязвимостей не обнаружено»
Одна из самых опасных фраз в этой теме звучит почти безобидно: «критических уязвимостей не обнаружено». Формулировка отлично успокаивает руководство и плохо описывает реальность. В ней всегда скрыт невысказанный хвост: в каком покрытии, на каких активах, каким методом, с какими ограничениями и что осталось вне наблюдения.
Практика показывает, что большая часть сюрпризов живет не внутри известных и хорошо описанных активов, а на границе видимости. Теневой сервер, забытый поддомен, старый тестовый контур, неполный учет облачных ресурсов, исключение из лицензии на сканирование, подрядчик со своей частью инфраструктуры, сервис, который никто уже не считает важным, но который все еще доступен извне. Отсутствие находок в таких условиях означает не безопасность, а границы инструмента.
Поэтому зрелый процесс обязан считать не только найденные уязвимости, но и слепые зоны. Доля активов без покрытия, разрыв между инвентаризацией и сканированием, теневая инфраструктура, неизвестные интернет-доступные сервисы, исключения из политики и провалы в зоне ответственности значат не меньше, чем очередной список CVE. Иначе компания честно измеряет только освещенную часть комнаты.
Как искажаются решения внутри команды
Самое неприятное в темных паттернах даже не то, что они портят картину. Хуже другое: они меняют мотивацию людей. Инженер перестает думать о том, как убрать опасный маршрут атаки, и начинает думать о том, как не испортить квартальную отчетность. Руководитель перестает спрашивать, насколько трудно злоумышленнику добраться до ключевых систем, и начинает спрашивать, почему не выполнен план по «высоким» уязвимостям. Безопасность медленно превращается в спор между командами и таблицами.
Такой сдвиг особенно заметен там, где процесс живет отдельно от архитектуры, эксплуатации и бизнес-контекста. В этой модели находка становится абстрактной записью, а не свойством конкретного маршрута атаки. Служба безопасности давит на сроки, ИТ-команда спорит о приоритетах, владельцы систем защищают стабильность, менеджмент требует зеленый отчет. Все действуют рационально. Система в целом действует опасно.
Простой признак незрелости здесь выглядит так. Команда научилась быстро закрывать удобные проблемы, но после очередной проверки снова всплывают те же типы маршрутов атаки. Значит организация лечит симптомы. Формальная дисциплина есть, а снижения реальной площади атаки нет.
Что полезнее измерять вместо тщеславных метрик
Полностью отказаться от метрик нельзя и не нужно. Вопрос только в том, какие показатели помогают принимать правильные решения. Для зрелого процесса куда полезнее смотреть на долю действительно опасных уязвимостей на внешнем периметре, среднее время до устранения проблем на бизнес-критичных активах, долю активов без сканирования, число повторно возникающих дефектов и количество случаев, где команда устраняет первопричину, а не просто закрыла карточку.
Еще важнее attack path-метрики или те уязвимости и другие недостатки, комбинации которых ведут к критически важным активам. Не просто “уязвимость существует» или “у учетной записи есть привилегии”, а «уязвимость находится на узле, достижимом из интернета или из уже скомпрометированного сегмента, и дальше ведет к ценному активу». Такой взгляд быстро меняет приоритеты. Вместо десятков разрозненных находок команда видит несколько узлов, через которые проходит реальный путь атаки. Именно там и лежит лучший эффект от работы.
Отдельно полезно измерять разрыв между инвентаризацией и контролем, долю исключений из политик, возраст нерешенных проблем на критичных активах и число маршрутов, ведущих к недопустимым событиям: остановке сервиса, шифрованию, компрометации домена или утечке клиентских данных. Именно такие показатели сегодня все чаще рассматриваются как основа зрелых программ Exposure Management. В отличие от традиционных KPI они позволяют оценивать не количество выполненной работы, а то, насколько организация сократила реальные возможности злоумышленника для достижения критичных целей. Такие показатели сложнее объяснять на одном слайде, но они хотя бы связаны с тем, от чего компания действительно пытается защититься.
Почему одного классического подхода уже недостаточно
Даже хороший процесс управления уязвимостями решает только часть задачи. Он помогает работать с известными слабостями в программном обеспечении, но не отвечает на вопрос, как злоумышленник будет сочетать уязвимости, ошибки конфигурации, открытые сервисы, слабые пароли, избыточные привилегии и доверительные связи между системами. А именно так сегодня и выглядят многие реальные атаки.
Представим простой сценарий. В инфраструктуре есть забытый сервер в демилитаризованной зоне, на нем открыт сервис с известной уязвимостью удаленного выполнения кода. Дальше злоумышленник находит чрезмерные права у служебной учетной записи, использует доверие между сегментами, добирается до внутреннего узла администрирования и выходит к критичной системе. Если смотреть на компанию только через список CVE, виден набор разрозненных проблем. Если смотреть глазами атакующего, перед ним один вполне понятный маршрут. Именно поэтому в последние годы все чаще говорят не просто об управлении уязвимостями, а об управлении киберугрозами или экспозицией риска — Exposure Management. Логика здесь простая: считать нужно уже не отдельные находки, а вероятность того, что их сочетание позволит злоумышленнику достичь цели.
Поэтому зрелые команды все чаще двигаются от простого учета уязвимостей к учету реальной подверженности инфраструктуры к кибератакам. На практике такой сдвиг означает, что организация перестает спрашивать только «что найдено» и начинает спрашивать «что достижимо», «комбинация каких угроз позволит хакеру достичь цели» и «какие самые опасные и быстрые пути реализации атаки возможны прямо сейчас».
Новый уровень зрелости: смотреть не на список находок, а на путь атаки
Такой подход логично воспринимать не как модную замену классическому процессу, а как следующий уровень зрелости. Именно такую логику сегодня формализует методология Continuous Threat Exposure Management (CTEM): она предлагает оценивать не отдельные недостатки сами по себе, а их роль в реальных сценариях атак и приоритизировать меры по тому, насколько они снижают подверженность инфраструктуры, тем самым повышая киберустойчивость компании. Без нормальной инвентаризации активов, регулярного сканирования, понятной ответственности и дисциплины исправлений дальше двигаться бессмысленно. Но один фундамент не дает полной картины. Нужна экспертная аналитика, которая свяжет найденные уязвимости с конфигурациями, сетевой доступностью, учетными записями, зависимостями и ценностью актива для бизнеса.
Сильная сторона такого подхода в том, что значительно снижает степень неопределенности. Когда команда видит не просто длинный список проблем, а реальные пути атак, которыми хакер может воспользоваться в любой удобный момент, приоритеты быстро меняются. Уже не так важно, сколько всего уязвимостей, и других недостатков, накопилось в системе. Куда важнее, какие действия реально нейтрализуют опасные сценарии передвижения хакеров к самым чувствительным целям.
Именно поэтому решения, которые умеют видеть инфраструктуру насквозь и показывают связную модель возможностей атакующих в ней, выглядят сегодня убедительнее многих классических дашбордов. Их ценность не в том, что они добавляют еще один красивый экран, а в том, что помогают увидеть текущую подверженность атакам и управлять ей. В российском контексте такой сдвиг хорошо иллюстрирует MaxPatrol Carbon, который строит граф возможностей хакеров в инфраструктуре, с учетом всех ее особенностей, недостатков и реальных действий атакующих, и затем, моделирует пути атак, и поднимая наверх не самые громкие, а самые опасные источники угроз внутри инфраструктуры.
Как выглядит зрелый подход на практике
Зрелый подход начинается с неприятной честности. Компания должна признать, что безопасность нельзя мерить только количеством патчей, найденных CVE и выполненных сроков. Дальше начинается менее приятная работа: вычищать инвентарь, искать теневые активы, связывать ИТ-объекты с бизнес-процессами, отмечать внешнюю доступность, разбирать доверительные отношения и перестраивать отчетность так, чтобы она показывала не комфортные, а полезные цифры.
Следующий шаг связан с ответственностью. У каждой критичной проблемы должен быть не просто исполнитель, а владелец риска, который понимает цену откладывания. Без этого процесс быстро превращается в поток задач между отделами. В такой модели ни один участник не видит картину целиком, а значит никто не отвечает за то, что маршрут атаки в итоге остался открытым.
Наконец, организации полезно развести два типа действий. Есть быстрые меры, которые нужны для немедленного снижения риска. Есть корневые исправления, без которых та же проблема позже появится в другом месте. Пока обе категории смешаны в одном общем счете закрытых задач, команда будет инстинктивно выбирать косметику. Зрелый процесс считает и быстрые меры, и устранение первопричин отдельно.
Что в итоге стоит помнить
Плохое управление уязвимостями опасно не тем, что находит мало слабых мест. Плохой процесс опасен тем, что создает удобную и ложную картину защищенности. Метрики, которые кажутся безобидными, постепенно перенастраивают поведение команды. Дашборд начинает поощрять не снижение риска, а снижение дискомфорта в отчетах. С этого момента организация может работать много, быстро и дисциплинированно, но не туда.
Хорошее управление уязвимостями начинается там, где компания перестает спорить о красоте цифр и начинает смотреть на потенциальные пути атаки. Меньше записей в таблице не всегда значит меньше риска. Зато меньше опасных маршрутов к критичным системам почти всегда значит, что защита стала сильнее. Все остальное, каким бы аккуратным ни выглядел дашборд, слишком легко превращается в витрину.
Поэтому главный вопрос для любого процесса звучит предельно просто. Не «сколько у нас осталось критических находок» и не «какую долю мы закрыли за квартал». Главный вопрос другой: насколько трудно атакующему добраться до того, что для бизнеса действительно важно. Если дашборд не помогает отвечать именно на него, значит дашборд работает против безопасности.
Автор: Игорь Панарин, руководитель направления анализа защищенности инфраструктуры ДИБ РАНХиГС