Dark patterns в VM - как метрики и дашборды ломают безопасность

Vulnerability Management или Управление уязвимостями, давно перестало быть исключительно технической задачей. Сегодня это процесс, в котором участвуют SOC, AppSec, DevOps, ИТ-менеджмент, бизнес, пентестеры, багхантеры. Возможно кто-то со мной не согласится и укажет на то, что зона ответственности VM - это узкая поляна, на которой с одной стороны сидят люди, отвечающие за сканирование инфраструктуры, с другой те, кто накатывает обновления. Я привык смотреть на вещи шире поэтому сегодня мы посмотрим на процесс управления уязвимостями под другим углом.

Что вообще такое Управление уязвимостями и как ими можно управлять?

Начнем с простого вопроса. Насколько защищена ваша инфраструктура прямо сейчас? Ведь прежде чем укреплять оборону, важно понять, где уже есть дыры, и насколько ваша текущая защита способна выдержать хотя бы минимальную атаку. Чаще всего злоумышленники не начинают с глубоких сложных сценариев. Они идут по пути наименьшего сопротивления — ищут так называемые "низко висящие фрукты": уязвимые сервисы на периметре, которые можно легко проэксплуатировать. Если атака не целевая, то, столкнувшись с хоть какой-то защитой, они просто переключаются на менее защищённую цель. 
Задача компании не в том, чтобы стать полностью неуязвимой — это невозможно. Но можно построить инфраструктуру как крепость, где каждая точка входа прикрыта, а путь к цели сложен, требует ресурсов, времени и командной работы со стороны атакующих. Такой штурм становится просто невыгодным.

Почему же тогда, несмотря на автоматизацию, мы до сих пор сталкиваемся с проблемами обновления и устранения уязвимостей? В то время, как новые уязвимости появляются ежедневно, а на создание рабочего эксплойта может уйти всего несколько часов.
Ответ — в зрелости процессов и инструментах. Управление уязвимостями — это не только про людей и регламенты. Без профессиональной системы управления уязвимостями, которая понимает, что реально эксплуатируемо, особенно в местах где это критически важно для инфраструктуры, команда может утонуть в потоке ложных тревог. Профессиональные VM-решения приносят с собой не только автоматизацию, но и экспертизу: приоритизацию, риск-оценку, сигналы из threat intelligence. Как пример - Трендовые уязвимости в MaxPatrol VM, где практикующие эксперты отбирают за вас именно те, что требуют оперативного устранения или принятия компенсирующих мер, так как они уже активно эксплуатируются злоумышленниками. Здесь важна оперативность и скорость реакции. Информация о таких уязвимостям поступает в течение 12 часов. Это крайне необходимо, так как, даже если новая критическая уязвимость еще не в ходу у злоумышленников и эксплойт не создан - это всегда вопрос времени и она может начать использоваться ими в ближайшее время. 

Но, здесь на сцену и выходят Dark Patterns.

Для начала разберемся, что же это такое. Объясню так, как понимаю термин я.

Dark Pattern - это приемы в дизайне, которые подталкивают пользователя к принятию решений, выгодных для системы, но не для него самого. Другими словами темные паттерны используются для достижения маркетинговых целей. Их задача в том, чтобы вы купили подписку, подключили дополнительные услуги. Они не появляются на странице случайно - это тщательно продуманные элементы интерфейса.

Возникает логичный вопрос - как все это связано с процессом управления уязвимостями? Ситуация здесь аналогична, только вместо пользователей - процессы и команды. Сами Dark Patterns в продуктах по управлению уязвимостями - это метрики, KPI и визуализация, которые при недостаточном опыте и неправильной интерпретации могут:

- стимулировать неправильное поведение

- скрывать реальные риски

- подменять безопасность формальными отчетами

Важно отметить, что часто это делается не из злого умысла или лени, а просто из желания упростить отчеты, показать руководству “прогресс” и уложиться в регламенты и SLA, связанные с VM-процессами. Те кто давно участвуют в программах BugBounty или занимаются пентестами знают, что бояться нужно не редкой CVE, а забытых тестовых поддоменов, утечек .git и различных мисконфигов.

В любом случае, для наглядности, рассмотрим несколько примеров dark patterns - они будут среднестатистические, просто чтобы было понятно о чем идет речь.

 #1. Количество обнаруженных уязвимостей

На дашборде вашей VM-системы это выглядит как цифра вида:

Total vulnerabilities: 12 438

High: 241

Critical: 17

Первое, что мы видим на экране - общее количество уязвимостей, иногда с разбивкой по критичности. На первый взгляд может показаться, что чем меньше уязвимостей, тем лучше. Я даже встречал в одной из статей название этим цифрам. Тщеславные метрики. Показывают объем работы, но не её пользу.

Из этого примера у нас может возникнуть KPI - сократить общее количество уязвимостей на 30%. Казалось бы, что здесь плохого? Цифры уменьшаются, мы показываем результат.

Фактически, команды начинают закрывать “дешевые” уязвимости и игнорировать сложные и реально опасные. Важно помнить, что уязвимости не равны по риску и несколько CVE уровня High в тестовом контуре, не так страшны, как две уязвимости на периметре со средним CVSS.

 #2. SLA по CVSS без контекста 

Допустим, время на устранение:

Critical — 24 часа

High — 72 часа

Medium — 30 дней

Почему плохо? CVSS не учитывает эксплуатируемость в конкретной инфраструктуре, наличие compensating controls не отражает критичность актива именно для вашего бизнеса. Кроме того, атакующие не читают ваши SLA. Они будут эксплуатировать уязвимости сразу, как найдут способ. Еще хуже, когда цепочка из middle уязвимостей способна привести к катастрофическим последствиям, за счет того, что каждая выполнит свою маленькую часть.
Это приводит к тому, что специалисты занижают CVSS при триаже, переводят уязвимости в false positive/ accepted risk и исправляют только то, что легко вписывается в SLA. В итоге на бумаге все соблюдено, а по факту безопасность инфраструктуры находится на грани.

 #3. % закрытых уязвимостей как KPI команды

Как это может выглядеть на практике?
Допустим команда должна закрывать не менее 95% уязвимостей в квартал. Соответственно KPI становится важнее риска, уязвимости массово начинают переводиться в risk accepted, закрываться только на бумаге и фикситься костылями без root cause - устранения первопричин. Специалисты применяют быстрые и поверхностные решения, которые временно маскируют проблему, чтобы уложиться в KPI, но не устраняют ее корень. В результате уязвимость может появиться снова или проявиться уже в другом месте. Да и вообще, можно повысить процент устранения, если не находить новые уязвимости :).

Главное, что здесь нужно понять - когда система показателей (KPI) становится важнее фактической цели (например, снижения киберугроз), вступает в силу закон Гудхарта: "Если показатель становится целью, он перестает быть хорошим показателем". В нашем случае, цель управления рисками — обеспечить надежную работу и стабильное развитие компании. Соответственно вместо того, чтобы заниматься комплексным решением проблем, команды ищут лазейки в системе оценки для создания видимости успеха, что в конечном итоге вредит бизнесу и снижает безопасность. Перефразируя закон Гудхарта - когда метрика становится целью — она перестаёт быть хорошей метрикой.

 #4. Дашборды и выгрузка уязвимостей без времени и динамики.

О чем здесь речь? Когда в красивом отчете мы не видим времени обнаружения и других подобных метрик, которые способны отсеять, а где-то наоборот показать, мы можем упустить (забыть) уязвимости, которые висят больше 180 дней (сроки зависят от ваших SLA). Другими словами - ваш дашборд не должен быть статическим - VM - это процесс во времени.

 #5. Нет уязвимостей - значит безопасно 

Мой фаворит. 

Специалист, отчитываясь о проделанной работе, может сказать - “критических уязвимостей не обнаружено”. И здесь появляется одно большое НО. Система управления уязвимостями, может не покрывать целый список активов.

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

Идем дальше. А проводится ли регулярный ручной пентест? Это один из способов анализа защищенности, но даже он не способен дать полной картины. Пентестеры могут проверить ограниченный скоуп активов и не увидеть какой-то опасной уязвимости в том сегменте, который просто не стали указывать.

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

С примерами закончили. А давайте попробуем ответить на вопрос - почему бизнес так любит все эти dark patterns? Здесь тоже все просто. 

Они просты и визуально понятны, легко укладываются в концепцию PowerPoint, где можно показать как все красиво и сколько у нас зеленых графиков. Реальные риск-метрики сложны и требуют контекста, объяснений и зрелых ИБ процессов.

Как должен выглядеть идеальный дашборд? Ответа на этот вопрос у меня нет, но думаю, как минимум он должен быть risk-based, когда мы уделяем внимание приоритизации рисков, в отличие от count-based, где главную роль играет их количество. Нельзя забывать про эксплуатируемость, доступность и влияние на бизнес.

Уязвимость с оценкой 10.0, но без рабочего PoC не так страшна, как такая же с рейтингом 7.0, которую активно применяют шифровальщики. Сервер в изолированном сегменте внутри сети и тот, что смотрит в интернет, имеют разный приоритет на установку обновлений. С этим можно поспорить, но здесь нам уже пригодится Business Impact, который подскажет, что если в сервер внутри закрытой сети принести что-то на флешке, последствия могут повлиять на само существование компании. Как видите, подход с количеством здесь не работает.

Как понять, что в процессе управления уязвимостями появились симптомы dark patterns?
Иногда достаточно просто взглянуть, какие уязвимости устраняются в первую очередь. Если фокус стабильно уходит на «удобные» для закрытия уязвимости с низким приоритетом — вместо действительно опасных и критичных — это уже тревожный сигнал. Но главный вопрос — приводит ли формальное «улучшение» цифр к повышению уровня защищенности по результатам следующего тестирования на проникновение? Если нет — перед вами один из классических признаков метрик, которые работают против безопасности.

Современные платформы VM уже давно перешли к модели RBVM (Risk-Based Vulnerability Management) — с приоритизацией не только по CVSS, но и с учётом контекста: значимости активов, наличия эксплойтов, признаков активной эксплуатации и пр. Однако и этих механизмов бывает недостаточно, если неверно определена критичность активов — например, нет выделения бизнес-критичных систем, не учтены системы, опубликованные во внешнюю сеть, или отсутствует маппинг ИТ-активов на бизнес-процессы.

В результате платформа может формально показывать «успешное» закрытие уязвимостей, в то время как реально опасные точки остаются незамеченными. И именно это искажённое представление о защищённости — типичный пример dark pattern в управлении уязвимостями.

Важно помнить, что метрики и дашборды, не только в VM-системах - это инструмент, который при неправильном использовании становится оружием против безопасности, успокаивая руководство, искажая приоритеты и создавая ложное чувство защищенности. Мой подход к VM прост - настоящее управление уязвимостями - это не меньше цифр, а меньше риска. Я не буду доволен результатом, где 99% систем пропатчены, но именно на оставшемся 1% будет висеть крит, смотрящий в интернет и именно этот актив может поставить под удар всю инфраструктуру компании. 

В текущих условиях встает закономерный вопрос, а достаточно ли только выстроенного процесса управления уязвимостями или функции специалиста по VM должны стать гораздо шире? Здесь все зависит от масштаба вашей компании, штата сотрудников и компетенций но в любом случае, стоит указать на ряд моментов.

На смену процессу Vulnerability Management приходит Exposure Management. Его можно считать как абсолютно новым подходом, так и очередной попыткой оживить процессы VM, но я бы скорее назвал его новым этапом эволюции Управления уязвимостями. Как мы уже выяснили ранее, регулярное сканирование и устранение CVE больше не гарантирует полноценную защиту, особенно в сложных современных инфраструктурах. В ответ на эти вызовы сформировался подход Exposure Management (Управление киберугрозами), расширяющий рамки VM. В него входит весь спектр уязвимых мест в широком смысле: не только уязвимости ПО, но и мисконфигурации сервисов, не закрытые порты, слабые пароли, избыточные привилегии и прочие проблемы безопасности. Задача Exposure Management – видеть картину целиком: понимать, каким образом злоумышленник может комбинировать различные слабые места для атаки на бизнес-активы, и устранять комплексно всеми источниками угроз внутри инфраструктуры компании. 

Gartner еще в 2022 году ввел термин Continuous Threat Exposure Management (CTEM) – непрерывное управление киберугрозами с учетом актуальных угроз и каждый год Exposure Management как класс и перспективное направление в рамках "предиктивной безопасности" (Preemptitive Cybersecurity) набирает все большую популярность среди специалистов в мире.

Сегодня компании сталкиваются с очевидной проблемой: даже управлять только уязвимостями становится всё сложнее. Их слишком много, не все из них можно оперативно закрыть, и при этом не всегда понятно, какие из них действительно опасны. А теперь представьте, что кроме CVE в инфраструктуре полно и других недостатков — открытые сервисы, слабые пароли, избыточные привилегии, ошибки конфигурации. Все они могут стать точкой входа или частью маршрута атаки. Кажется, с этим уже не справиться. Но здесь кроется важный инсайт: решающую роль играет не сам факт наличия уязвимостей, а то, какие из них могут быть реально использованы злоумышленником, чтобы достичь критичных систем. И чтобы понять это, нужен другой подход — поиск и моделирование потенциальных маршрутов атак. Это позволяет выявить те слабости, которые действительно опасны в контексте конкретной инфраструктуры, и сконцентрироваться на их устранении.

Иначе говоря, именно моделирование атак и есть ключ к управлению киберугрозами. Такой подход лежит в основе концепции Exposure Management, которая становится новым стандартом кибербезопасности. В глобальном масштабе это уже де-факто норма: зрелые компании по всему миру внедряют непрерывное управление киберугрозами, видя эффективность в проактивной оценке путей атаки. Даже рыночные исследования подтверждают смещение сегмента решений VM в сторону Vulnerability and Exposure Management. Ведущие мировые игроки уже представили свои решения в этом направлении. Из российских стоит отметить Positive Technologies MaxPatrol Carbon, который как раз реализует этот подход — строит граф инфраструктуры, просчитывает маршруты атак и помогает точечно устранять самые опасные изъяны.

Даже при выстроенном процессе VM ответ на вопрос «Хорошо ли мы защищены?» может быть отрицательным, если смотреть глазами атакующего. Дело в том, что уязвимости – лишь часть угроз. Практика инцидентов показывает, злоумышленники нередко обходят систему вовсе без использования новых CVE. По данным Positive Technologies, эксплойты действительно часто применяются на этапе первоначального проникновения в сеть (до 30% атак начинаются с “пробива периметра” через известную уязвимость), но на последующих этапах атаки, хакеры значительно реже эксплуатируют уязвимости – им проще воспользоваться другими методами.

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

Аналитики Splunk пришли к схожему выводу: до 26–40% инцидентов обусловлены уязвимостями в ПО, а остальное приходится на другие векторы атак, такие как компрометация учетных записей и злоупотребление сервисами удаленного доступа.

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

Рассмотрим простой пример. Компания не учла теневой сервер в DMZ: после изменения настройки на нем остался открытым порт, через который доступен сервис с известной RCE-уязвимостью. В итоге злоумышленник получает первоначальный доступ через этот забытый веб-сервер. Подобные «дыры» в инфраструктуре часто остаются за кадром классического VM-аудита, который фокусируется только на известных узлах и CVE. Системы управления уязвимостями, тот же MaxPatrol VM, способны проводить комплаенс-проверки на основе экспертизы вендора, но не все из них способны указать на слабый пароль или избыточные привилегии учетной записи. Именно такие лазейки злоумышленники и используют для развития атаки внутри сети. Пока команды ИБ и ИТ “тонут” в таблицах найденных уязвимостей и патчей, злоумышленник обладает фактически безграничным простором для поиска точки входа.

Таким образом, совокупность множества разрозненных на первый взгляд недочетов – от устаревшего софта до неправильно настроенного межсетевого экрана – могут сложиться для атакующего в скрытый маршрут к самым критичным системам. Здесь нам и помогают решения класса Exposure Management, которые способны “подсветить” такие маршруты.

Чтобы объективно оценить защищенность, недостаточно просто учитывать количество уязвимостей — важно понимать, какие из них действительно опасны с учетом конфигураций, прав доступа, сетевых связей и бизнес-контекста. Без целостной картины инфраструктуры легко упустить узел, через который атакующий может пройти к критичной системе. Поэтому всё чаще компании дополняют классическое управление уязвимостями - подходами, основанными на моделировании маршрутов атак и выявлении тех слабых мест, которые реально могут быть использованы для достижения недопустимых целей — будь то кража данных, остановка бизнеса или компрометация внутренних систем.

Такая стратегия лежит в основе концепции Exposure Management — эволюции VM, которая учитывает не только технические параметры, но и реальную активность злоумышленников, связь между уязвимостями и конфигурациями, а главное — возможные сценарии развития атаки.

В этом контексте инструменты моделирования атак и анализа цепочек помогают приоритизировать усилия и фокусироваться на действительно важных задачах, а не просто «гасить CVE по списку». Классический VM остаётся необходимым фундаментом, но его ценность значительно возрастает, когда он встроен в более зрелую стратегию проактивной киберзащиты.

Это и есть цель управления киберугрозами: сделать компанию сложной, непривлекательной мишенью, где даже при общем росте атак вы всегда на шаг впереди хакеров. С применением таких подходов, проблема темных паттернов если не исчезает полностью, то сокращается настолько, что они уже неспособны навредить безопасности компании.